gobengo
commented
6 years ago systemd has built in support for managing dependencies like this I think. Can we use it here to help, instead of crafting dependency management into init.d scripts?
On Fri, Mar 23, 2018, 7:50 AM Benny Lichtner notifications@github.com wrote:
cc @jhpoelen https://github.com/jhpoelen
The home node startup sequence is finicky. It seems like the two main components, tunneldigger and babeld, need to be started in a certain sequence, and with adequate delay between the two. Some notes:
1.
On boot, the home node starts up a bunch of processes, including babeld and tunneldigger. At some point, dhcp messages trigger the /etc/udhcpc.user script to wait, pinging (or, after patch23 https://github.com/sudomesh/bugs/issues/23, inspecting the public route table) in a loop until finding evidence that packets are routing through the l2tp interface successfully (see here https://github.com/sudomesh/makenode/blob/a3b243e69d2e4bddedbbb0a48f24315d4ea04e14/configs/ar71xx/home_nodes/templates/files/etc/udhcpc.user#L44-L62). This usually does not work the first time (maybe it never works the first time). Instead, 20 of these checks fail, then /etc/init.d/meshrouting restart is called, restarting both tunneldigger and babeld. Routing tends to get setup successfully on this second attempt. 2.
Restarting tunneldigger by itself breaks the routing table (all routes become unreachable). This makes some sense--I might not expect babeld to know that the tunnel interface is back up and ready. Maybe it eventually checks? In my recent tests, I didn't wait long enough. Restarting babeld quickly brings the route table back. 3.
Restarting tunneldigger + babeld via /etc/init.d/meshrouting restart also tends to break the routing table. Again, restarting babeld is a quick fix. In this case, /etc/init.d/meshrouting restart should probably be improved to just work.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sudomesh/sudowrt-firmware/issues/128, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKfBoulfV9vyeOztqFxKvvbpPMJGVSsks5thJsjgaJpZM4S4P_z .
jhpoelen
paidforby
cc @jhpoelen
The home node startup sequence is finicky. It seems like the two main components, tunneldigger and babeld, need to be started in a certain sequence, and with adequate delay between the two. Some notes:
1) On boot, the home node starts up a bunch of processes, including babeld and tunneldigger. At some point, dhcp messages trigger the
/etc/udhcpc.userscript to wait, pinging (or, after patch23, inspecting the public route table) in a loop until finding evidence that packets are routing through the l2tp interface successfully (see here). This usually does not work the first time (maybe it never works the first time). Instead, 20 of these checks fail, then/etc/init.d/meshrouting restartis called, restarting both tunneldigger and babeld. Routing tends to get setup successfully on this second attempt.2) Restarting tunneldigger by itself breaks the routing table (all routes become unreachable). This makes some sense--I might not expect babeld to know that the tunnel interface is back up and ready. Maybe it eventually checks? In my recent tests, I didn't wait long enough. Restarting babeld quickly brings the route table back.
3) Restarting tunneldigger + babeld via
/etc/init.d/meshrouting restartalso tends to break the routing table. Again, restarting babeld is a quick fix. In this case,/etc/init.d/meshrouting restartshould probably be improved to just work.