[announce] release 0.2.2 of rc-shim
I'm announcing the release of rc-shim v0.2.2, a small script that is useful for adding supervision to existing installations already using SysV-styled rc scripts. I was going to withhold this announcement until the 0.3 release, but there were some bugs that needed to be addressed. The following has changed: * Debugging statements have been re-ordered so they fail immediately upon detecting a missed setting. * The STARTWAIT setting was moved in the script to fix a reference-before-declaration bug. More importantly, the script is no longer considered experimental. It appears to be performing its functions consistently and I will be extending its testing. I would rate it as "alpha" quality, meaning that some of the settings may be subject to change, but the function of it will continue as-is. Source can be obtained with mercurial or git at https://bitbucket.org/avery_payne/rc-shim. Incremental improvements will continue with each release and feedback is always appreciated.
Re: nosh per-user service management
Jean Louis:
So, placing user daemons into system supervision may not be the best
option, due to so many customization that have to be done for the
user, especially for GNU Emacs -- as one cannot know which programming
languages and their variables are required.
I just explained that these are *not* system-wide services, but per-user
ones. A user who is setting up environment variables for xyr own needs
to run emacs as a service simply sets up environment variables for xyr
own needs against the per-user service. Indeed, I already showed how
that is done. Once again:
Adjust its environment, if desired, in the conventional way
$ system-control --user set-service-env emacs DISPLAY :15.2
or (if /usr/local/sbin is on one's path)
$ rcctl set --user emacs DISPLAY :15.2
The idea that this is somehow difficult because one might have to set an
environment variable named GUILE_LOAD_PATH in this way, is just plain
wrong. This is just an envdir in a conventional place in a service
directory. It's actually easier to manipulate than a $HOME/.{z,}profile
or a $HOME/.login_conf for setting such an environment variable so that
one could spawn the daemon in an interactive login session.
subreapers
Martin "eto" Misuth: Point of tool is simple: it always runs marking itself as "subreaper", thus any descendants who lose parent, that was running under it, will get reparented (and their attached process subtrees as well) under it's process. Once "main", the important and original, child exits, tool tries to term and then kill all remaining descendants. By the way, you should talk to this person: * http://unix.stackexchange.com/questions/329631/
Re: subreapers
What M. Misuth is doing is the most imaginative use of local reapers that I have come across. What I wrote in the nosh doco back in version 1.0 was: > This yields a slightly more informative process tree. This was presented as a mere side-effect by Poettering and Sievers in 2012. The main idea was a rather vague, and in the end not implemented, notion that user instances of systemd could somehow make use of the fact that they were made the parents of orphaned grandchildren processes in order to Do Stuff. In fact, it is the mere side-effect that turns out in practice to be the major benefit. You should not underestimate how useful the effects on the process tree are. All service manager instances in nosh are local reapers, and one sees the effects with the system-wide service manager as well as with per-user service managers. One doesn't see such a pronounced effect with the system-wide service manager because, as I have noted elsewhere in this thread, as a result of the pressure from the daemontools world for the past two decades the world already makes the process tree of system-wide service management fairly well organized. Lots of daemons do not fork-and-exit-parent any more, and orphaned grandchildren simply do not arise as much in this area as they used to at the turn of the century. But the effect for per-user stuff is marked. This is because the world of per-user stuff includes "desktop services", like the roughly ten servers that have to be started up in order to run the "small and lightweight" GNOME Editor. This world is still replete with things that fork-and-exit-parent. To give another example: The PCDM startup of X desktop environments on TrueOS (formerly PC-BSD) starts up a whole bunch of user processes via fork-and-exit-parent. These all end up in a different part of the process tree to the desktop processes sitting under the top-of-desktop-session process, under process #1 or the nearest local reaper. In the output of "ps -dax", all of these processes are scattered all over the shop. One can improve this subtree with broken branches all over the forest floor with a local reaper. The benefit of local reapers is not a programmatic one for the likes of you and me. It is a usability one for administrators and end users trying to follow their process trees.
