[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/
