tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Controlling Daemons (inetd or aunchd or relaunchd?)
Steffen Nurpmeso wrote in
<20230226013826.renHc%steffen%sdaoden.eu@localhost>:
|Bruno Melo wrote in
| <g7EJelBCZlm3Y4JxNh1J9f2guqWnLrf9HljjW41O2j7QBQwl9bNtkSOAr3WNrbc1QwRGXSf\
| brlg2YyD6USd_p8nbTai_GXUR-nk2dl_UlZs=@protonmail.com>:
...
|I personally use something scripted that polls periodically
|instead (for most). It is pretty easy (most of the time), like
...
|I personally think UNIX should be as easy as the above.
|runit is very interesting, but i think being able to redirect
|deaths of daemonized programs to another process like init(8) is
|a real improvement that Linux has with PR_SET_CHILD_SUBREAPER and
|PR_SET_PDEATHSIG of prctl(2), and the FreeBSD approach is even
|more fine-grained. But i personally again really admire
|unshare(1) of Linux with CLONE_NEWPID.
Ie like cgroups:
pid=${!}
[ -d /sys/fs/cgroup/_box_web ] && printf '%s\n' ${pid} > /sys/fs/cgroup/_box_web/cgroup.procs
...
$ cat /sys/fs/cgroup/_box_web/cgroup.procs
9390
9391
9392
9393
9448
9471
9508
9559
9562
9564
9648
I have not tried whether inotifyd can be used to track such files.
And not to think about the possibility to migrate responsiblity of
an entire (even daemonized) process tree to some other program
simply by writing the pid, or say "IDENT PID" somewhere, for
example to a pipe.
|I think what i mean is, isn't it better to have the possibilities
|in the kernel to provide such, and then the freedom to use shell
|scripts, than something like systemd?
...
(Unfortunately the above has a race condition.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Home |
Main Index |
Thread Index |
Old Index