SIGINFO and linux support

[John Green]

Hi,

I have a project where using SIGINFO would be perfect for. The
problem is according to my googling research SIGINFO is not supported
on Linux. Is there an alternative I can use?

Thanks,

[Edward]

SIGUSR1 is pretty much always an alternative, if there's nothing better.
Also, SIGINT might be a reasonable thing to use (semantically, it's an
interrupt, and interrupts can be used for almost anything) - plus it's
easy to send one.
-Edward

--
"Sanity" is the last refuge of the unimaginative.
visit my useless website -- http://dev-null.chu.cam.ac.uk

[John Green]

On Oct 3, 11:54 am, Edward wrote:

> John wrote:
> > Hi,
>
> > I have a project where using SIGINFO would be perfect for.  The
> > problem is according to my googling research SIGINFO is not supported
> > on Linux.  Is there an alternative I can use?
>
> > Thanks,
>
> SIGUSR1 is pretty much always an alternative, if there's nothing better.
>   Also, SIGINT might be a reasonable thing to use (semantically, it's an
> interrupt, and interrupts can be used for almost anything) - plus it's
> easy to send one.
> -Edward

I will research SIGUSR1. I am already using SIGINT to catch Ctrl-C to
close the open files and exit the program properly.

What is the reason SIGINFO isn't available on Linux?

Thanks,

[Edward]

From what I can tell, it's because Linux uses it as a synonym for
SIGPWR. Allegedly. For any deeper reason, you'd have to ask someone
who actually knows what they're talking about (ie. not me).
SIGUSR1 is completely general purpose (hence 'user signal'); it and
SIGUSR2 have no predefined semantics.
As for using SIGINT to exit, perhaps SIGTERM would be better for that
(after all, that's what 'kill' sends by default). You should in any
case be trapping SIGTERM for a 'clean exit'.

[Lew Pitcher]

I can't say definitively, but SIGINFO doesn't seem to be part of the
POSIX/Single Unix Specification standard set of signals. IIRC, Linux
tries to implement POSIX/SUS, with some native extensions. Apparently,
SIGINFO isnt an extension implemented by Linux

[Lew Pitcher]

On Oct 3, 12:37 pm, John Green <johngr...@gmail.com> wrote:
> Hi,
>
> I have a project where using SIGINFO would be perfect for.  The
> problem is according to my googling research SIGINFO is not supported
> on Linux.

From the brief reading that I've done on SIGINFO, it looks like it is
possible that SIGINFO (at least under Linux) is /not/ perfect for your
project.

According to some articles,
"When received on a tty, the kernel will print the current load
average,
active process on that tty and how much cpu it has used since
launch. A
program may also catch the signal to print additional information."

This tells me that, on those systems where SIGINFO /is/ supported, a
SIGINFO to a suitably-enabled process will cause /two/ actions:
1) the kernel will print a number of statistics to the foreground
process
controlling terminal, and
2) the foreground process will /also/ print statistics on the
controlling
terminal

Now, there is no SIGINFO-equivalent signal in Linux; no signal will
natively cause the kernel to print stats to to the foreground process
controlling terminal.

If you implement a SIGINFO-like signal in your application, it can,
under Linux, /only/ print the application-level stats. The kernel-
level stats that this info is meant to augment /are not/ generated.

Can you live with this sort of "partial result"?

[John Green]

On Oct 4, 9:34 am, Lew Pitcher wrote:

This contradicts some of my research. From what I have read SIGINFO
can be trapped and display information from the running application.
For example SMARTD prints IO information when it gets a SIGINFO
signal.
http://unixsadm.blogspot.com/2008/01/disk-monitoring-and-tuning-with-dd-and.html
Maybe I misunderstood.

My plan was to print a custom message when my program traps a SIGINFO
signal.

Thanks,

[Gordon Burditt]

>> This tells me that, on those systems where SIGINFO /is/ supported, a
>> SIGINFO to a suitably-enabled process will cause /two/ actions:
>>   1) the kernel will print a number of statistics to the foreground
>> process
>>      controlling terminal, and
>>   2) the foreground process will /also/ print statistics on the
>> controlling
>>      terminal
>>
>> Now, there is no SIGINFO-equivalent signal in Linux; no signal will
>> natively cause the kernel to print stats to to the foreground process
>> controlling terminal.
>>
>> If you implement a SIGINFO-like signal in your application, it can,
>> under Linux, /only/ print the application-level stats. The kernel-
>> level stats that this info is meant to augment /are not/ generated.
>>
>> Can you live with this sort of "partial result"?
>
>This contradicts some of my research.

Contradicts *what*, exactly?

>From what I have read SIGINFO
>can be trapped and display information from the running application.

That's one of two uses of it.

SIGINFO can be used to
(a) print some kernel statistics about a running process
AND
(b) print some information from the running application.

You cannot "trap" SIGINFO and prevent (a) from happening,
at least not without setting specific modes on the tty, which
will also prevent (b).

In FreeBSD, SIGINFO is used for such things as "dd" presenting
a message about how much it's copied, and "fsck" will indicate
what phase it's in and a percentage of how far it is through
the current phase. So, yes, you can generate a custom message.

If you use SIGUSR1 in place of SIGINFO, you don't get (a), and
the signal is somewhat less convenient to generate since it
doesn't have its own keyboard character.

>For example SMARTD prints IO information when it gets a SIGINFO
>signal.
>http://unixsadm.blogspot.com/2008/01/disk-monitoring-and-tuning-with-dd-and.html
>Maybe I misunderstood.
>
>My plan was to print a custom message when my program traps a SIGINFO
>signal.

If the kernel statistics printed cause tech support calls every time
they are printed because users don't understand them, and they
ignore the line you print that says to ignore the line above, you
have a problem. If the users of this feature can understand the
kernel statistics at least enough to ignore them, you're fine.

Remember: don't use standard I/O from a SIGINFO signal handler (at
least not on the same stream the main program is using). Doing so
is a great way to get occasional difficult-to-explain segfaults.
Stick to write().

[Tim Bowler]

On 10/06/2010 11:26 PM, Gordon Burditt wrote:
>> From what I have read SIGINFO
>> can be trapped and display information from the running application.
>
> That's one of two uses of it.
>
> SIGINFO can be used to
> (a) print some kernel statistics about a running process
> AND
> (b) print some information from the running application.
>
> You cannot "trap" SIGINFO and prevent (a) from happening,
> at least not without setting specific modes on the tty, which
> will also prevent (b).
>
> In FreeBSD, SIGINFO is used for such things as "dd" presenting
> a message about how much it's copied, and "fsck" will indicate
> what phase it's in and a percentage of how far it is through
> the current phase. So, yes, you can generate a custom message.
>
> If you use SIGUSR1 in place of SIGINFO, you don't get (a), and
> the signal is somewhat less convenient to generate since it
> doesn't have its own keyboard character.
>

What key generates a SIGTERM?

[Gordon Burditt]

>> If you use SIGUSR1 in place of SIGINFO, you don't get (a), and
>> the signal is somewhat less convenient to generate since it
>> doesn't have its own keyboard character.
>>
>What key generates a SIGTERM?

SIGTERM *is* less convenient than SIGINT for an interactive program,
and I don't know of any program that tries to use SIGTERM for
something interactive. Lots of programs use SIGINT, largely for
"abort back to a command prompt". Daemons running in the background
are a different issue, since they are not attached to a terminal.

Trivia: Tandy Xenix on the Tandy Model 6000 in some of the later
versions provided a way to generate SIGHUP from the console. A
particular key sequence generated a brief drop of virtual "data
carrier detect" on the virtual serial port for the console.