I came up with the following PR (https://github.com/openwrt/packages/pull/4568) thinking it would be a trivial substitution of the procd primitives for what the old shell script was doing.
Turns out, I wasn’t even close. The problem turned out to be that when start_service() had exited, procd had received the request to start the service… but not acted on it. So faster than the service could be started, other services (some of them not procd-based, and therefore not subject to any sort of procd FIFO policy) were being started up. Indeed, even services that were procd-launched (like lighttpd and cron) were starting up ahead of syslog-ng, so part of their startup was spilling onto the console because they were failing to rendezvous with the logger. This might be (I’ve not dug too much yet) the behavior of foreground vs. backgrounded servers, i.e. when running the non-procd script I suspect that the parent process wouldn’t exit until it’s child was successfully started and ready for requests. Obviously when things are launched by procd fork'ing/exec'ing and then running them in the foreground, it’s different. There’s no obvious way to check for the status of the service… Could that be changed? Could some sort of synchronization primitives be added to start_service() where one could check to see if some observable external conditions had been met? In the case of syslog-ng, for instance, it would open up /dev/log. But there might be more complex (combinatorial) conditions, such as /dev/log being opened for reading, and there being a listener on UDP(0.0.0.0,514) (in the case of rsyslog). Or maybe other operators like OR and NOT in addition to AND. Then after the procd_close_instance, the script could choose to block on some condition that procd could instrument (or conversely a timeout for failure so it doesn’t block forever). Anyone else encountered similar issues when moving to procd-based startup? Thanks, -Philip _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
