WOL Cron Job returned error (1)

Started by Seedman, May 05, 2026, 03:34:17 PM

Previous topic - Next topic
Hi,

I've been using the OS-WOL plug-in on OPNsense, with a daily cron job to wake my server from sleep for the last 2 years.
This has worked flawlessly from 24.7 all the way to 26.1.6.

The cron job started failing ever since I upgraded to 26.1.7 on the 1st of May 2026.

I can still wake my server up from the GUI Services - WOL. However the cron job fails. When I check the logs under system - log files - backend I get a "wol wake 192.168.50.255 xx:xx:xx:xx:xx:xx] returned Error (1) message.

I find this strange as I haven't made any changes to the WOL Cron Job in over 2 years and it now fails every time.

Just so its clear the parameters for the cron job were :- 192.168.50.255 MAC_ADDRESS

Any help on this would be greatly appreciated.

Please update to the latest hotfix.


Cheers,
Franco
"AI has absolutely reduced the cost of creating technical debt." -- ChatGPT

Thank you for your reply.

I've already updated to the latest hotfix 26.1.7_3 but the behaviour seems unchanged.


Aha, I see it now. You need to put each parameter on a separate line since 26.1.7. Right now it pushes "192.168.50.255 MAC_ADDRESS" because it's a single line.

This was changed to allow empty parameters and parameters with whitespaces plus longer parameters.


Cheers,
Franco
"AI has absolutely reduced the cost of creating technical debt." -- ChatGPT

Just so i understand this clear.:-

Old cron:-
192.168.50.255 MAC_ADDR


New cron:-
192.168.50.255
MAC_ADDR

Please correct me if I'm wrong.

Thank you for all the help


Yes correct. It's also written in the parameters help text:

"Enter parameters for this job if required. Each line represents a parameter that will be quoted including whitespaces. An empty parameter is rendered when followed by a newline character."

Looking at https://docs.opnsense.org/manual/settingsmenu.html#cron we never documented any cron jobs with more than one parameter which didn't mean they don't exist, but given the parameters ambiguity in the past it seemed like a good opportunity to structure this better including how configctl receives and parses these parameters.


Cheers,
Franco
"AI has absolutely reduced the cost of creating technical debt." -- ChatGPT