Re: Generic interrupt command?
That's a tough call. On the one hand, it makes simple constructs safer. On the other, it adds complexity to interpreting the data programmatically ( the test / [ program errors for integer comparisons with text, and using scanf() to pull in the values for libc style programs wouldn't be so simple anymore). That was my thought process originally, but if it makes it riskier or more annoying for programs to use the result of s6-svstat, especially in scripts which are its likely users, I'm willing to change that. Also, while thinking about this, I wonder the risk of signaling the wrong program. When svc does it via supervise, it can know the right program gets the signal because it handles the cleaning of the child PID. In a script, there is a chance the child has exited and been replaced between the time the PID was queried by svstat and the time the kill command gets executed. I don't know how likely a new program might get the old PID in that time, this receiving the signal intended for the original child. Well that is one of the reasons for using a supervisor in the first place. Only the parent of a process can reliably send signals to it. Any time you're trying to signal a program and you're not a parent, you are subject to that risk condition. The only 100% safe way is using s6-svc, there's no changing that. So far the only real need to customize a signal has been for the signal that brings a service down, which is now achieved via ./down-signal. I haven't been told of any real use case where sending a non-supported signal, without intending to terminate the service, was necessary. -- Laurent
Re: Generic interrupt command?
On Tue, Feb 5, 2019, 2:30 PM Laurent Bercot >Not outputting anything causes kill (on my system at least) to exit non > >0 > > Not outputting anything isn't an option, for the case where -o pid is > used in addition to other fields. The field number and order must be > respected. > Agreed; I didn't mean to suggest that as an option, I just wanted to be thorough with testing. It's probably best to use some OOB indicator. How about NA, which I > already use for non-numeric fields? it makes kill correctly choke. > Would it be better to use NA in all the numeric fields, too? > That's a tough call. On the one hand, it makes simple constructs safer. On the other, it adds complexity to interpreting the data programmatically ( the test / [ program errors for integer comparisons with text, and using scanf() to pull in the values for libc style programs wouldn't be so simple anymore). Maybe adding a flag like -n as an output modifier to keep the relevant output numeric when wanted? Then the default could be NA. Of course, that adds complexity to the svstat program, it's interface and documentation. It is also incompatible with existing programs that may be using svstat already, requiring the flag for new versions of svstat and not the flag for old versions. Also, while thinking about this, I wonder the risk of signaling the wrong program. When svc does it via supervise, it can know the right program gets the signal because it handles the cleaning of the child PID. In a script, there is a chance the child has exited and been replaced between the time the PID was queried by svstat and the time the kill command gets executed. I don't know how likely a new program might get the old PID in that time, this receiving the signal intended for the original child. I think itis a low number, but not zero. This line of thinking unfortunately brings us back to the original post in this thread :-( -- John O'Meara >
Re: Generic interrupt command?
Not outputting anything causes kill (on my system at least) to exit non 0 Not outputting anything isn't an option, for the case where -o pid is used in addition to other fields. The field number and order must be respected. It's probably best to use some OOB indicator. How about NA, which I already use for non-numeric fields? it makes kill correctly choke. Would it be better to use NA in all the numeric fields, too? -- Laurent
Re: Generic interrupt command?
On Tue, Feb 5, 2019, 2:20 AM Laurent Bercot
wrote:
> >Be careful, though. If the service is down, kill will use -1 for the PID,
> >and will probably signal everything in your system except PID 1.
>
> That's a good point. Should s6-svstat use 0 as the "service is down"
> pid value instead, to avoid this ?
>
0 behaves better for this use case, but can still produce unexpected
behavior.
The construction "echo 0 | xargs kill -STOP" for example leaves behind a
paused background task that needs to be cleaned by hand.
The construction "kill -STOP $(echo 0)" hangs the terminal until someone
resumes the user's shell.
Most other "kill -whatever $(echo 0)" results in the shell exiting and the
user having to log back in.
So, 0 is a lot better than -1, but still not great.
Not outputting anything causes kill (on my system at least) to exit non 0
and give some diagnostic ("`' not a pid or valid pid spec", "you need to
specify whom to kill", or the usage message). That's nice, but would
probably break other scripting that expects a value, especially for
s6-svstat showing multiple fields.
I can't think of a safe and simple way to do this. For example, we could
suggest people do something like this (based on Roger Pate's post):
pid=$(s6-svstat -p /my/service) && [ "$pid" -ne -1 ] && kill -SIGNAL $pid
but that's a lot of typing and requires that people see and remember the
suggestion, so not quite simple :-/
--
John O'Meara
>
Re: Generic interrupt command?
Be careful, though. If the service is down, kill will use -1 for the PID, and will probably signal everything in your system except PID 1. That's a good point. Should s6-svstat use 0 as the "service is down" pid value instead, to avoid this ? -- Laurent
Re: Generic interrupt command?
On Mon, Feb 4, 2019 at 10:09 PM John O'Meara wrote: > On Sat, Feb 2, 2019, 4:40 PM Steve Litt wrote: >> On Sat, 2 Feb 2019 21:08:10 + Colin Booth wrote: >>> s6-svstat -p /path/to/service | xargs kill SIGNAL >> >> Cool. That's all that's needed. > > Be careful, though. If the service is down, kill will use -1 for the PID, > and will probably signal everything in your system except PID 1. pid="$(s6-svstat -p /path/to/service)" && kill SIGNAL "$pid" # avoid gratuitous xargs?
Re: Generic interrupt command?
On Sat, Feb 2, 2019, 4:40 PM Steve Litt wrote: > On Sat, 2 Feb 2019 21:08:10 + > Colin Booth wrote: > > > s6-svstat -p /path/to/service | xargs kill SIGNAL > > > > Cool. That's all that's needed. > > SteveT > -- > Be careful, though. If the service is down, kill will use -1 for the PID, and will probably signal everything in your system except PID 1. -- John O'Meara >
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: 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
Generic interrupt command?
Hi all, 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. Let's say a -z was added as an arg to s6-svc or a "genericinterrupt" was added as an arg to sv. Now you could say: sv genericinterrupt SIGIO myspecialdaemon s6-svc -z SIGIO myspecialdaemon The supervisor already knows the PID of what's being supervised, so it would be an easy way to get an arbitrary signal into a daemon, for those daemons that have non-standard signal usage. SteveT -- Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
