- This topic has 8 replies, 2 voices, and was last updated 4 years, 3 months ago by gemba.
-
Posted in: Muster usage
-
16th January 2020 at 10:20 am #27695
Hello.
I have a question about Scheduled wakeup.
When wakeup node using Schedule wakeup setting, is it necessary to combine with options such as Available, Full load, and Pool Require?
After the specified time with only the scheduled wakeup set, the Dispatcher log will show “Waking up host <HOSTNAME> (IPADDR)-Host matched time rule”, but the machine will not actually start.
Testing Environment:
-Dispatcher version: 9.0.13, 9.0.14-11518
-Node version: 9.0.13, 9.0.14-11518
-Wakeup:
-Wakeup manually from Dispatcher: Success
-Option
-Wakeup:
-When the farm is at full load: off
-When the client is required by a job pool: off
-Matches wakeup rules with availability rules: off
-Schedule
Day range, Mon-Fri, 10: 00-20: 00, wake up17th January 2020 at 12:00 pm #27749Hi there,
If you get a wakeup in the log, that means the message is effectively sent. Consider that the wakeup you send manually is sent from Console, not the Dispatcher, so be sure that the dispatcher UDP connections can reach your clients
20th January 2020 at 5:55 am #27877Hi Leonardo,
Thanks for your reply.
We have confirmed that the dispatcher server (CentOS 7) can be started from the server using Ether-Wake or a self-made script that sends WoL packets to UDP port 7 or 9.
At the timing when the log that executed WoL by the dispatcher was output, packets could not be captured by tcpdump, and it was not possible to confirm whether or not they were being executed.
Packet capture command
tcpdump -UlnXi eth0 ether proto 0x0842 or udp port 9 or udp port 7
Is it possible to check in other ways?
As additional information,
Two options, “When the farm is at full load” and “When the client is required by a job pool”, performed WoL and confirmed that the node started.
However, packets cannot be captured by tcpdump.Best regards.
24th January 2020 at 10:28 am #28081After inspecting some stuff, the manual sent WOL packet is sent on port 40000, that is the default WOL port by specs, while the automated Wakeup is sent to a random port, while this works in most circumstances because the WOL just need to have the headers regardless of the port where is sent, some machine/OS distinguish between port 40000, 7 and 9. We are packing this configurable for the next release.
Thanks.
27th January 2020 at 5:37 am #28217Hi Leonardo,
Thanks for your reply.
Since it was any port of 7,9,40000 / UDP, I tried to capture with the following pattern.
Also, taking into account the possibility of jumping to a random port, we tried to capture the entire UDP packet, rewrite the filter of tcpdump to filter only some UDP / SSH packets, and tried to capture.
The result is as follows:
tcpdump command:
tcpdump -i eth0 -ne src host 172.16.203.182 and udp port not \(137 or 138 or 546 or 5355 or 5353 or 1947 or 4679 \) and tcp port not 22 and not arp
Note:
172.16.203.182 ― Dispatcher IP
172.16.203.88 ― Node IPResult:
– “When the farm is at full load” Only -> SuccessDispatcher log: 12:50:02 Waking up host gem88(172.16.203.88) - Farm at full load tcpdump log: 12: 50: 03.890666 26: c6: cb: 9e: a8: 39> Broadcast, ethertype IPv4 (0x0800), length 144: 172.16.203.182.33749> 255.255.255.255.safetynetp: UDP, length 102
– “When the client is required by a job pool” Only -> Success
Dispatcher log: 13:05:10 Waking up host gem88(172.16.203.88) - required pool tcpdump log: 13: 05: 11.276099 26: c6: cb: 9e: a8: 39> Broadcast, ethertype IPv4 (0x0800), length 144: 172.16.203.182.51160> 255.255.255.255.safetynetp: UDP, length 102
– Schedule Only -> Failure
Day range, Mon-Fri, 10: 00-20: 00, wake upDispatcher log: 12:03:55 Waking up host gem88(172.16.203.88) - Host matched time rule tcpdump log: not logging
– Schedule and Available match rule. -> Failure
Day range, Mon-Fri, 10: 00-20: 00, wake up
(Wake-up schedule and available schedule are at the same time.)
tcpdump log : not logging
`Considering the possibility of our environmental problems, we set up another server,
The result was the same as above.
Are others working?Thanks.
Wakabayashi27th January 2020 at 7:59 am #28222Yes it seems to work on most circumstances but as I said it is effectively a bug and we already patched it to be sent to port 40000 under any circumstances at the moment. For the next service release, the port will be configurable because many systems distinguish between 7 and 9. On what version are you actually ?
We can send you an hot fix that at the moment is assured to send the WOL of port 40000. In the meanwhile we are going to check if there’s any difference when the WOL is sent by rules but I suspect there’s no difference.
Are you on V9 LTS ?27th January 2020 at 9:30 am #28228Do not try 11518, it has the same problem, get in touch with me with a support ticket and I’ll send you a link to an hot fix. Please specify if you’re running Windows or Linux
-
You must be logged in to reply to this topic.