Red Rozenglass on Nostr: Cocoa Hoto in real life opal i see, true. let's say we want to restart a service: svc ...

Cocoa Hoto in real life (nprofile…k9rm) opal (nprofile…w8cy) i see, true. let's say we want to restart a service: svc finds the service by directory name, opens a control file, writes the command to it, a supervisor instance is listening on that file (a fifo pipe), reads the command, sends signal to its forked child; we have a supervise instance per service (started by svscan), each of them forking the single service they oversee.

in contrast to the traditional slackware's raf daemon program, which also has one instance of the parent supervisor per forked child service, but when the raf daemon management command (equivalent to svc) is invoked by the user, it reads the pid of the supervisor (not the child service itself) from the named supervisor pidfile, and sends the signal to that supervisor, which then handles the signal, and sends it accordingly to its forked child process, to which it holds a pid in memory, just like djb supervise.

so, in simple terms, the djb service manager sends commands to the supervisor using text characters over a fifo pipe it finds and opens by directory name, while the raf manager daemon instance sends commands to the supervisor instance using a unix signal after it finds and opens the pidfile by name.

manager -> supervisor, using char over fifo opened in a named dir.
manager -> supervisor, using signal to pid read from a named file.

both afterwards do supervisor -> child service, using a unix signal.

i still don't see it. what problem exactly does djb's method fixes compared to raf's? djb's faq isn't helping, nor reading the code either so far. i would appreciate an explanation of a scenario where it breaks, or a link to something to read on that. i'm curios :)