LKML Archive on
 help / color / Atom feed
From: Austin S Hemmelgarn <>
To: Martin Tournoij <>,
Subject: Re: [RFC] The SIGINFO signal from BSD
Date: Wed, 05 Nov 2014 14:31:12 -0500
Message-ID: <> (raw)
In-Reply-To: <>

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

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-05 15:17 Martin Tournoij
2014-11-05 19:31 ` Austin S Hemmelgarn [this message]
2014-11-05 20:14   ` Theodore Ts'o
2014-11-05 20:30     ` Austin S Hemmelgarn
2014-11-05 22:13     ` Martin Tournoij
2014-11-06 13:19       ` Pádraig Brady
2014-11-10 14:22     ` One Thousand Gnomes
2014-11-10 14:34       ` Martin Tournoij
2014-11-10 16:16       ` Austin S Hemmelgarn
2014-11-23  9:48       ` Pavel Machek

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox