[RFC] The SIGINFO signal from BSD

[RFC] The SIGINFO signal from BSD

[Martin Tournoij]

Hi there,

As a long-time BSD user, I have become quite used to the SIGINFO (sent with ^t)
feature; after switching to Linux as my desktop a few months ago, I very much
miss this.

SIGINFO prints the status of the process to the terminal; BSD cp, for example,
shows show much data it's copied:

    $ cp large_file /dev/null
    <press ^t>
    load: 1.39  cmd: cp 85837 [running] 3.91r 0.00u 0.98s 8% 2340k
    large_file -> /dev/null  15%

As you see, it shows the current load, pid, process status, memory usage, as
well as how much of the file has been copied. Many other BSD tools print similar
statistics (mv, tar, dd, sleep, fetch, etc.).

On Linux, sometimes SIGUSR1 is used for similar purposes, the problem with this
is that SIGUSR{1,2} will terminate a program if a program doesn't have a signal
handler installed(!)
SIGUSR1 also has no defined meaning, and may do something radically different;
nginx, for example, reopens the logfiles on SIGUSR1, and SIGUSR2 upgrades the
nginx executable on-the-fly.

So you need to carefully inspect the documentation, hope it's not out of date,
and then send SIGUSR1 and pray.

This is different from SIGINFO, which does nothing when it's not installed,
which is safe. You can send SIGINFO to any process, and not be afraid you kill
it.

In addition, it's also not easy to send SIGUSR1, you need to open a new
terminal, find the pid, and use a kill command (you could also use
pkill/killall, with the risk of sending the signal to other processes).

SIGINFO is, AFAIK, supported since 4.4BSD & descendants (ie. all modern BSD
systems), as well as MacOS X. Perhaps other systems as well (but did not
investigate).

Why don't we have SIGINFO on Linux? Would a patch to implement this be accepted?

SIGINFO is not defined in any standard, but Linux already implements other
useful non-standard signals (most notably SIGWINCH). IMHO it's a very useful
feature.

Thanks,
Martin

PS.
I am *not* subscribed to this maillist; please cc me in replies!

Re: [RFC] The SIGINFO signal from BSD

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 3149 bytes --]

On 2014-11-05 10:17, Martin Tournoij wrote:
> Hi there,
>
> As a long-time BSD user, I have become quite used to the SIGINFO (sent with ^t)
> feature; after switching to Linux as my desktop a few months ago, I very much
> miss this.
>
> SIGINFO prints the status of the process to the terminal; BSD cp, for example,
> shows show much data it's copied:
>
>      $ cp large_file /dev/null
>      <press ^t>
>      load: 1.39  cmd: cp 85837 [running] 3.91r 0.00u 0.98s 8% 2340k
>      large_file -> /dev/null  15%
>
> As you see, it shows the current load, pid, process status, memory usage, as
> well as how much of the file has been copied. Many other BSD tools print similar
> statistics (mv, tar, dd, sleep, fetch, etc.).
>
> On Linux, sometimes SIGUSR1 is used for similar purposes, the problem with this
> is that SIGUSR{1,2} will terminate a program if a program doesn't have a signal
> handler installed(!)
> SIGUSR1 also has no defined meaning, and may do something radically different;
> nginx, for example, reopens the logfiles on SIGUSR1, and SIGUSR2 upgrades the
> nginx executable on-the-fly.
>
> So you need to carefully inspect the documentation, hope it's not out of date,
> and then send SIGUSR1 and pray.
>
> This is different from SIGINFO, which does nothing when it's not installed,
> which is safe. You can send SIGINFO to any process, and not be afraid you kill
> it.
>
> In addition, it's also not easy to send SIGUSR1, you need to open a new
> terminal, find the pid, and use a kill command (you could also use
> pkill/killall, with the risk of sending the signal to other processes).
>
> SIGINFO is, AFAIK, supported since 4.4BSD & descendants (ie. all modern BSD
> systems), as well as MacOS X. Perhaps other systems as well (but did not
> investigate).
>
> Why don't we have SIGINFO on Linux? Would a patch to implement this be accepted?
>
> SIGINFO is not defined in any standard, but Linux already implements other
> useful non-standard signals (most notably SIGWINCH). IMHO it's a very useful
> feature.
>
> Thanks,
> Martin
>
> PS.
> I am *not* subscribed to this maillist; please cc me in replies!
Given a quick look at the signal(7) man page, it appears that on at 
least alpha and sparc systems, SIGINFO is a synonym for SIGPWR, which 
comes from SVR4, where it was used to indicate that the system had lost 
power (I don't really understand this usage, but my guess was that UPS 
monitoring software was supposed to send init a SIGPWR when the UPS 
switched off AC to the backup power source).

You have to understand however, that the reason that SIGINFO works like 
that on *BSD is that the kernel and core userspace are developed 
together, whereas on Linux, they are maintained entirely separately. 
Outside of core userspace components, using SIGINFO that way on *BSD is 
just convention.  The people to talk to about that for the core 
utilities on Linux would be the maintainers of the GNU coreutils, or 
whatever your distribution might use in their place (I think it's very 
unlikely that busybox or toybox would implement it however).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: [RFC] The SIGINFO signal from BSD

[Theodore Ts'o]

On Wed, Nov 05, 2014 at 02:31:12PM -0500, Austin S Hemmelgarn wrote:
> >
> >SIGINFO prints the status of the process to the terminal; BSD cp, for example,
> >shows show much data it's copied:
> >
> >     $ cp large_file /dev/null
> >     <press ^t>
> >     load: 1.39  cmd: cp 85837 [running] 3.91r 0.00u 0.98s 8% 2340k
> >     large_file -> /dev/null  15%
> >
> >As you see, it shows the current load, pid, process status, memory usage, as
> >well as how much of the file has been copied. Many other BSD tools print similar
> >statistics (mv, tar, dd, sleep, fetch, etc.).
> 
> You have to understand however, that the reason that SIGINFO works like that
> on *BSD is that the kernel and core userspace are developed together,
> whereas on Linux, they are maintained entirely separately. Outside of core
> userspace components, using SIGINFO that way on *BSD is just convention.

Actually, the first line:

	load: 1.39  cmd: cp 85837 [running] 3.91r 0.00u 0.98s 8% 2340k

is actually printed by the kernel.  It's actually something which is
implemented in the BSD N_TTY line displine.  We never implemented it
(at least when I was maintaining the tty subsystem) mostly out of
laziness.  Part of the reason is that the main reason was that main
reason why people (at least systems programmers / kernel programers
like me) used ^T was to debug an apparently hung system, and for
Linux, we had a much more powerful system using the magic-sysrq key.

Changing various userspace utilities to set up a signal handler for
SIGINFO and then printing some extra information, such as:

	large_file -> /dev/null  15%

is a much more recent innovation (at least, newer than BSD 4.3 in the
early 90's, which is the last time I hacked on BSD :-), and is largely
separate from the question of implementing ^T in the N_TTY line
displine.

In a world where we have a GUI desktop, I suspect implementing ^T is
much less interesting, but if someone were to submit a patch to at
least make ^T send a SIGINFO, I can't think of a reason why it
wouldn't be accepted.  (BTW, if you're going to do this, note that ^T
could be remapped to any control character via stty; so to do this we
would need to define an extra index in c_cc[] array in the struct
termios.)

Cheers,

					- Ted

Re: [RFC] The SIGINFO signal from BSD

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

On 2014-11-05 15:14, Theodore Ts'o wrote:
> On Wed, Nov 05, 2014 at 02:31:12PM -0500, Austin S Hemmelgarn wrote:
>>>
>>> SIGINFO prints the status of the process to the terminal; BSD cp, for example,
>>> shows show much data it's copied:
>>>
>>>      $ cp large_file /dev/null
>>>      <press ^t>
>>>      load: 1.39  cmd: cp 85837 [running] 3.91r 0.00u 0.98s 8% 2340k
>>>      large_file -> /dev/null  15%
>>>
>>> As you see, it shows the current load, pid, process status, memory usage, as
>>> well as how much of the file has been copied. Many other BSD tools print similar
>>> statistics (mv, tar, dd, sleep, fetch, etc.).
>>
>> You have to understand however, that the reason that SIGINFO works like that
>> on *BSD is that the kernel and core userspace are developed together,
>> whereas on Linux, they are maintained entirely separately. Outside of core
>> userspace components, using SIGINFO that way on *BSD is just convention.
>
> Actually, the first line:
>
> 	load: 1.39  cmd: cp 85837 [running] 3.91r 0.00u 0.98s 8% 2340k
>
> is actually printed by the kernel.  It's actually something which is
> implemented in the BSD N_TTY line displine.  We never implemented it
> (at least when I was maintaining the tty subsystem) mostly out of
> laziness.  Part of the reason is that the main reason was that main
> reason why people (at least systems programmers / kernel programers
> like me) used ^T was to debug an apparently hung system, and for
> Linux, we had a much more powerful system using the magic-sysrq key.
>
I hadn't realized that it was actually the kernel printing that, but 
then I've never really looked all that deep into the BSD source code.
Ironically, the magic-sysrq key is one of the big reasons I've 
personally chosen to stay with Linux over any of the BSD derivatives. :)


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: [RFC] The SIGINFO signal from BSD

[Martin Tournoij]

On Wed, Nov 5, 2014, at 20:31, Austin S Hemmelgarn wrote:
> The people to talk to about that for the core 
> utilities on Linux would be the maintainers of the GNU coreutils, or 
> whatever your distribution might use in their place (I think it's very 
> unlikely that busybox or toybox would implement it however).

Well, if the kernel doesn't provide the feature, then we can be sure it
will never be implemented :-)
I thought this was a good place to start asking,, and even if GNU
coreutils opt to not implement this for whatever reasons, other
applications still can (mine will!)
Besides, there are already many tools which use this feature when
available, these would for with no or minimal adjustments.


On Wed, Nov 5, 2014, at 21:14, Theodore Ts'o wrote: 
> In a world where we have a GUI desktop, I suspect implementing ^T is
> much less interesting but if someone were to submit a patch to at
> least make ^T send a SIGINFO, I can't think of a reason why it
> wouldn't be accepted.  (BTW, if you're going to do this, note that ^T
> could be remapped to any control character via stty; so to do this we
> would need to define an extra index in c_cc[] array in the struct
> termios.)

Thanks, this is what I needed :-) I wondered if there is a specific reason
it's not implemented, or if it was just something no one ever did.

I can start my investigation in the kernel sources ;)

Thanks,
Martin

Re: [RFC] The SIGINFO signal from BSD

[Pádraig Brady]

On 11/05/2014 11:13 PM, Martin Tournoij wrote:
> On Wed, Nov 5, 2014, at 20:31, Austin S Hemmelgarn wrote:
>> The people to talk to about that for the core 
>> utilities on Linux would be the maintainers of the GNU coreutils, or 
>> whatever your distribution might use in their place (I think it's very 
>> unlikely that busybox or toybox would implement it however).
> 
> Well, if the kernel doesn't provide the feature, then we can be sure it
> will never be implemented :-)
> I thought this was a good place to start asking,, and even if GNU
> coreutils opt to not implement this for whatever reasons, other
> applications still can (mine will!)

GNU coreutils dd will already support SIGINFO if available
(and if dd is recompiled with appropriate headers).
dd currently emulates that using SIGUSR1 though as you say
that's awkward to support robustly, and there has been
a recent GNU coreutils change in relation to that:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=27d2c738

I like the idea of making SIGINFO generally available
and GNU coreutils at least would add extra handling
to cp etc. if that was the case.

thanks,
Pádraig.

Re: [RFC] The SIGINFO signal from BSD

[One Thousand Gnomes]

> wouldn't be accepted.  (BTW, if you're going to do this, note that ^T
> could be remapped to any control character via stty; so to do this we
> would need to define an extra index in c_cc[] array in the struct
> termios.)

We have 19 entries in the array and no platforms that byte pack so that
would actually be doable I think.

I'm really dubious about its value in the Linux world. You could do far
better teaching the GUI desktop to walk the process tree of clients and
dump the window owners process subtrees in a nice pop up window.

PS: Austin - SIGPWR was used on the System 5 boxes I used to indicate
power had been *restored* not lost. The primary usage was in curses and
termios using apps so that when the power came back on they would redraw
the screens on all the terminals.

You have to think back to a world of a generator/battery backed servers
and non battery backed terminals for that to make sense.

Alan

Re: [RFC] The SIGINFO signal from BSD

[Martin Tournoij]

On Mon, Nov 10, 2014, at 15:22, One Thousand Gnomes wrote:
> > wouldn't be accepted.  (BTW, if you're going to do this, note that ^T
> > could be remapped to any control character via stty; so to do this we
> > would need to define an extra index in c_cc[] array in the struct
> > termios.)
> 
> We have 19 entries in the array and no platforms that byte pack so that
> would actually be doable I think.
> 
> I'm really dubious about its value in the Linux world. You could do far
> better teaching the GUI desktop to walk the process tree of clients and
> dump the window owners process subtrees in a nice pop up window.

I don't use a GUI desktop, and almost none of my programmer friends do.

Re: [RFC] The SIGINFO signal from BSD

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On 2014-11-10 09:22, One Thousand Gnomes wrote:
>> wouldn't be accepted.  (BTW, if you're going to do this, note that ^T
>> could be remapped to any control character via stty; so to do this we
>> would need to define an extra index in c_cc[] array in the struct
>> termios.)
>
> We have 19 entries in the array and no platforms that byte pack so that
> would actually be doable I think.
>
> I'm really dubious about its value in the Linux world. You could do far
> better teaching the GUI desktop to walk the process tree of clients and
> dump the window owners process subtrees in a nice pop up window.
>
> PS: Austin - SIGPWR was used on the System 5 boxes I used to indicate
> power had been *restored* not lost. The primary usage was in curses and
> termios using apps so that when the power came back on they would redraw
> the screens on all the terminals.
>
> You have to think back to a world of a generator/battery backed servers
> and non battery backed terminals for that to make sense.
Ah, I'd been misinformed then, that usage makes a lot more sense.  I've 
not personally used System 5 (or for that matter anything older than 
HP-UX 10.20), so I'm not always very well informed about it.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: [RFC] The SIGINFO signal from BSD

[Pavel Machek]

On Mon 2014-11-10 14:22:00, One Thousand Gnomes wrote:
> > wouldn't be accepted.  (BTW, if you're going to do this, note that ^T
> > could be remapped to any control character via stty; so to do this we
> > would need to define an extra index in c_cc[] array in the struct
> > termios.)
> 
> We have 19 entries in the array and no platforms that byte pack so that
> would actually be doable I think.
> 
> I'm really dubious about its value in the Linux world. You could do far
> better teaching the GUI desktop to walk the process tree of clients and
> dump the window owners process subtrees in a nice pop up window.

I use ssh way too much, so yes, I'd like to see SIGINFO.

Forgetting to add -v to cp command line is too common.

I can help testing patches :-).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html