Oregon, US
Comment by ~craftyguy on ~craftyguy/superd
On Thu, 12 May 2022 08:58:00 +0000 "~stacyharper" outgoing@sr.ht wrote:
hmm, I think supporting this would basically require supporting the "forking" service type: https://www.man7.org/linux/man- pages/man5/systemd.service.5.html
Mhh I'm not sure forking and exec works the same way. I'm not sure the parent process actually exit. But I'm not expert enough I think o_O
Ah, I think I misread your initial comment on this... So you want superd to supervise lisgd which is being run by some other script and backgrounded, while that other script continues on to do other stuff?
I'm not sure this is a good pattern to support with superd because:
if the child process dies, do you really want superd to re-execute the whole script that was used to run it? If that script is also running other services with '&', those will be run again, and again, and again, ad infinitum... every time superd sees a child die.
in a way, the script you are using to run lisgd is performing half of what superd already does: start a service, possibly in a particular order with other services. But the script doesn't supervise lisgd (restart it on failure). Why wouldn't you just use superd to run lisgd?
Or if you have to do some runtime setup before running it each time (e.g. set vars based on runtime situation or whatever), use a wrapper as I suggested earlier and have superd supervise that? For example something like:
/usr/local/bin/start_lisgd.sh:
#!/bin/sh FOO=bar # some dynamic runtime config [ -n $WHATEVER ] && FOO=bazz # note there is no backgrounding with '&': lisgd # lisgd died/returned at this point cleanup()Then a service config for superd:
[Unit] Description=lisgd After=<some thing lisgd depends, if there is something> [Service] Type=simple ExecStart=/usr/local/bin/start_lisgd.sh Restart=always RestartSec=1In the meantime, if you're running lisgd with superd, why do you need to exec it in your wrapper script? If you invoke lisgd in the script without exec, I think superd would be able to supervise it (by way of supervising the script that is blocked waiting for lisgd to return/exit). What do you think?
You right, not using exec solve this use case and seems to works better. I'm a little bit annoyed by this constraint. Ideally this sxmo_hook_lisgdstart.sh should be cleaner when used alone.
If the above doesn't answer your question, or you're still unsatisfied by that, could you explain a little bit more what you mean by "this constraint"? Perhaps I'm missing some other concern you have :)
-Clayton
bug added by ~craftyguy on ~craftyguy/superd
enhancement added by ~craftyguy on ~craftyguy/superd
bug added by ~craftyguy on ~craftyguy/superd
Comment by ~craftyguy on ~craftyguy/superd
hmm, I think supporting this would basically require supporting the "forking" service type: https://www.man7.org/linux/man-pages/man5/systemd.service.5.html
In the meantime, if you're running lisgd with superd, why do you need to exec it in your wrapper script? If you invoke lisgd in the script without exec, I think superd would be able to supervise it (by way of supervising the script that is blocked waiting for lisgd to return/exit). What do you think?
on ~craftyguy/superd
REPORTED RESOLVED IMPLEMENTED
Ticket created by ~craftyguy on ~craftyguy/superd
superd shouldn't try to restart a failing service indefinitely. I'm not sure what systemd defaults to for this, I'm fairly sure it gives up trying to start a failing service after some amount of tries... anyways, maybe 5 (chosen arbitrarily) is fine?