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