Re: Generic interrupt command?
Colin Booth: As documented here: https://www.skarnet.org/software/s6/s6-svstat.html s6-svstat -p /path/to/service | xargs kill SIGNAL You can thank Jos Backus for similar functionality in the nosh toolset since 2013, with program-readable output that one can use existing tools to pull arbitrary fields from. % svshow --json /var/sv/* 2>/dev/null | jq '."/var/sv/bcron-sched".MainPID' 1861 % svshow --json /var/sv/* 2>/dev/null | jq '."/var/sv/bcron-sched".RunTimestamp' 4611686019976326000 % svshow --json /var/sv/* 2>/dev/null | jq '."/var/sv/bcron-sched".DaemontoolsEncoreState' "running" % svshow --json /var/sv/* 2>/dev/null | jq '."/var/sv/bcron-sched"."Wanted-By"' [ "/etc/service-bundles/targets/server" ] %
Re: Generic interrupt command?
On Sat, Feb 02, 2019 at 02:30:14PM -0500, Steve Litt wrote: > On Sat, 02 Feb 2019 09:07:31 + > "Laurent Bercot" wrote: > > > kill -s SIGKILL `sv pid agetty-tty6` > > > I don't know if the s6-svc command already has the equivalent of a > hypothetical sv "pid" command, but if it doesn't, I imagine it would be > easy to put in and very helpful to those forging shellscripts. > > By adding this little addition to s6-svc (and hopefully sv if Gerrit > can scrape together the time), no hackiness would be added to s6 or > runit: Any hackiness would be in the shellscript created by the > programmer using s6 or runit. > As documented here: https://www.skarnet.org/software/s6/s6-svstat.html s6-svstat -p /path/to/service | xargs kill SIGNAL -- Colin Booth
Re: smaclennan/doorknob
On Sun, 27 Jan 2019 14:39:16 + Jonathan de Boyne Pollard wrote: > A lot of constructive comments on doorknob which I am not going to > include here. Well, I have updated doorknob to *hopefully* respond to all the comments. I have pushed the changes to github if anybody is interested. The big changes are moving the default location of the directories and changing ownership. Doorknob now has its own user. It basically does: 1. change to queue directory 2. setup inotify 3. drop privileges to doorknob user 4. read config 5. start handling messages sendmail and mailq are now owned by the mail user and group (configurable) and are +s. The queues are now (by default): chown mail.mail /var/spool/doorknob chown mail.mail /var/spool/doorknob/queue chown mail.mail /var/spool/doorknob/tmp chmod 750 /var/spool/doorknob chmod 777 /var/spool/doorknob/queue chmod 700 /var/spool/doorknob/tmp Everything is configurable. You can make the doorknob user root, the mail user root, and everything is as before. Comments welcome. Cheers, Sean
Re: How best to ensure s6-managed services are shut down cleanly?
On Fri, Feb 1, 2019 at 1:46 PM Laurent Bercot wrote: > The question is, how does systemd decide to proceed with the rest of > the shutdown? If it's just waiting for s6-svscan to die, then it's > easy: don't allow s6-svscan to die before all your services are > properly shut down. That can be done by a single s6-svwait invocation > in .s6-svscan/finish: > > #!/bin/sh > exec s6-svwait -D -T6 /scandir/* > > and s6-svscan's death won't be reported to systemd before all your > services are really down, or one minute, whichever happens sooner. > Perfect! I figured there would be something. Thanks as always for your help. -- Brett Neumeier (bneume...@gmail.com)
Re: Is s6/s6-rc ready to be the ubiquitous init?
1) Where can I find the s6/s6-rc project's preferred directories for everything? If there is *one thing* you should know about s6, and that you should convey to your readers, it is that *it does not provide, or care about, policy*. I thought it would be abundantly clear by now. That means there are *no* preferred directories. People can do whatever they want. Yeah, this is a hard concept to grasp in the era of systemd, but the Overton window needs a big fat shift towards flexibility and user choice. Of course, there are smarter choices than others. I have expressed and explained my own preferences several times, both in parts of the s6 and s6-rc documentation, and on this mailing-list when the subject came up. You can find them in the archives. But these are my preferences and recommendations, not official policies. Official policies should be done in the context of a _distribution_. I'd prefer not to put anything directly off the root directory: Too many people would object. Boy, if your audience is going to clutch their pearls at the mention of adding something to the root directory, just wait until they hear about how to write init scripts. :P Again, directories can be put *wherever*, and you don't have to create anything in the root directory. But approaching this with the angle of "I won't say anything radical to avoid scaring my audience" is the wrong mindset. You will never convince people who are far enough gone to believe that nothing should ever be created in the root directory despite having accepted /media without questioning because it came from a Standard™. 2) Does there exist a block diagram of either s6, s6-rc, or both combined, and if so, where? Well, dear, that's one of the things that are missing and that you're going to provide, isn't it? -- Laurent
Re: Generic interrupt command?
I think a cool addition to runit program sv and s6's s6-svc would be a command to send an arbitrary signal to the daemon being supervised. Yes, that would be a nice feature. I've been thinking about it for some time. Unfortunately, that's not at all suited to the way the control program communicates with the supervisor, and adding this feature, as simple as it seems, would require significant work. There is probably a (dirty, hackish) way to make it work with normal signals (<128). But there's absolutely no way to ever make it work with real-time signals or anything with a signal number over 128 without rewriting the supervisor state machine and making it more complex and more brittle. Which is an instant nope from me. Restricting the feature to normal signals would probably be enough, but even then, I'm not comfortable with the level of hackiness it would require. I don't think the feature is worth it; I'd rather add more signals to the explicitly supported list. -- Laurent
