Strange fails with cronplus and exec nodes

General
1

For a very long time now I have been trying to figure out what is different between the cronplus node operating on it's schedule and my clicking on its "doit" tab manually. It ALWAYS works when I click and USUALLY fails when scheduled with this:

image
image346×511 34.2 KB

I thought that in time I'd see what the difference is but, hey, I'm getting old here! I've not figured out what "name or service" it's failing to find but it seems a moot point since it works when manually triggered. Can anyone see what it is???

Flow attached (click to reveal) 
[
    {
        "id": "16d11b5e.b2d195",
        "type": "cronplus",
        "z": "2bc59a52.1c3956",
        "name": "19 past every hour",
        "outputField": "payload",
        "timeZone": "",
        "persistDynamic": false,
        "commandResponseMsgOutput": "output1",
        "outputs": 1,
        "options": [
            {
                "name": "19 past every hour",
                "topic": "19 past every hour",
                "payloadType": "str",
                "payload": "start",
                "expressionType": "cron",
                "expression": "19 * * * *",
                "location": "",
                "offset": "0",
                "solarType": "all",
                "solarEvents": "sunrise,sunset"
            }
        ],
        "x": 130,
        "y": 90,
        "wires": [
            [
                "e877ec10f0a573db"
            ]
        ]
    },
    {
        "id": "e877ec10f0a573db",
        "type": "exec",
        "z": "2bc59a52.1c3956",
        "command": "ssh steve@localhost \"/usr/bin/speedtest-cli --json --secure\"",
        "addpay": "",
        "append": "",
        "useSpawn": "false",
        "timer": "",
        "winHide": false,
        "oldrc": false,
        "name": "Run SpeedTest",
        "x": 410,
        "y": 90,
        "wires": [
            [
                "7ac4f5ef7db02023"
            ],
            [
                "c84f09a7584f0bd3"
            ],
            [
                "46482f09f19056b1"
            ]
        ]
    }
]
2

It seems highly unlikely that the cron node is to blame. I just can't see how it it would be affected? I assume you have added a debug node to see if there's any difference in the complete message when the cron node triggers v manual trigger?

3

Yes but it's been a long time so I've just done it again. Here is the diff between a manual invocation (in red) and a timed one that succeeded! Don't it figure that it would work at this moment? :roll_eyes: I'll post again when I get a fail.

image

Perhaps I don't understand something about the Exec node but I am under the impression that the message contents don't matter one bit and that only the receipt of the message is significant. That is, of course, since I don't use any part of the incoming message contents to affect how the Exec node operates.

EDIT:

OK, just had a fail and here is the diff between the previous timed one that succeeded (in red) and the fail. I see nothing that would matter to the Exec node.

image

4

That is correct. That's why I am very sure it is unrelated.

Question:
Since operating the button manually, your computer must obviously be fully 'awake'. When it is a scheduled event, is your computer going to sleep? I have a distant memory of individual sleep settings on network cards causing issues in the past for me. What operating system & version are you using?

5

Thanks for confirming my understanding.

Yes, it never suspends. This box runs all of my home automation apps.

Arch Linux which is updated at least weekly. This issue has been around for maybe even a year, so through many versions.

6

Wow your debug colour scheme is hard to read!

Can you make a simple flow that shows the issue and post it here?

7

The pertinent nodes were posted in my opening post.

8

OK I didn't notice the little black triangle, sorry.

I'm not familiar with exec via ssh steve@localhost ...
I see no reason why this would make a difference but can you explain the reason for doing it like this?

Are you accessing Node-red from the Linux machine or some other desktop?
Does it fail if you are logged in to Node-red at 19 minutes past the hour and watching the flow when it is triggered?

9

NR is in Docker and this method allows access to the host's resources without mapping its filesystem into the container. It's also portable by simply changing the name after the @

Desktop

It matters not one way or the other.

10

Try specifying the server with speedtest-cli --server.

11

I am curious, does this mean it works sometimes?

Because then it is probably not the exec node that's failing.

If that is the case, is it possible that you try to run it multiple times concurrently and that it fails because some resource is locked?

12

Yes, as stated in the original post.

I don't think the NODE is failing, per se, I think it's the COMMAND specified in the node's setup that fails but that is a distinction without a difference.

Thanks for the thought but I have no evidence of concurrent instances tripping over each other. I just now manually ran a 2nd instance while the 1st was in progress and they both succeeded normally so I think that rules it out.

13

You might be on to something there but it's confusing me even more. It fails every time when a server is specified in the Exec node AND from the command line on the server where NR is hosted. Running the exact same command in a terminal on my desktop (same versions of Arch Linux and speedtest-cli) it's 50/50 success/fail. When it fails...

speedtest-cli --server 15985
Retrieving speedtest.net configuration...
Testing from As-sumo-idaho (130.51.30.95)...
Retrieving speedtest.net server list...
ERROR: No matched servers: 15985

It succeeds from the command line every time on either host if I don't specify a server (limited number of iterations, of course).

I don't know what to make of this.

14

I don't know what to make of it either.

I think you should be trying speedtest-cli --secure --server n because there is recent discussion online about speedtest failing without --secure.

If I try 15985 I get No matched servers too, but then the internet thinks I'm in London. Maybe Ookla refuse connections it thinks too distant, or maybe #15985 is dead

If I use a random server from the list given by speedtest-cli --list (the listed servers are in London) then it seems OK.

Are you using a VPN?

15

Actually, I do. I just didn't in that post because I hurried and grabbed the latest command where I'd left it off.

Thank you for testing!

No.

16

Ok, I just imported your flow. If I see correctly you are executing ssh steve@localhost "/usr/bin/speedtest-cli --json --secure".
But if you execute this within a docker container, you connect to the docker container, because localhost points to the docker container. Are you sure this is all correct?

17

Thanks for testing.

That would be true if the container weren't started with the

--network=host

option.

18

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.