Re: RFC: killall5 for SIGSTOP and SIGCONT

2012-04-02 Thread Denys Vlasenko
On Tuesday 03 April 2012 04:31, ra...@gmx.de wrote: > Hi all, > > in some cases for system maintenance (e.g. shortly before putting the > system on standby or sleep) it could be wise to stop all running > processes (and let them continue after doing some operation). So how to > achieve this in she

Re: RFC: killall5 for SIGSTOP and SIGCONT

2012-04-02 Thread ra...@gmx.de
Hi! > Have you considered just running: > > kill -STOP -1 Oh yes, I did ... ohps ... -> Ctrl-Alt-Del > This will stop all the tasks except the shell that runs it (because > the 'kill' command is a shell builtin, and on Linux, kill(-1) doesn't > signal the caller, at least according to its man

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread ra...@gmx.de
Hi Rich! > Perhaps a more robust solution would be to do this: > > 1. Try /proc if it works. > > 2. Fallback to fstat() to read the major/minor number for stdin, and > use that to construct a candidate pathname based on standard naming > rules. stat() the pathname, and if they match, use it. >

Re: RFC: killall5 for SIGSTOP and SIGCONT

2012-04-02 Thread Avery Pennarun
On Mon, Apr 2, 2012 at 10:31 PM, ra...@gmx.de wrote: > There is a nice command to send signals to all processes except the own > session, init and it even allows to exclude specified processes ... the > killall5 ... but it fails to work on SIGSTOP :-( Have you considered just running: kill -ST

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread Rich Felker
On Tue, Apr 03, 2012 at 04:03:14AM +0200, ra...@gmx.de wrote: > Ok, I know, reading the link needs access to proc filesystem but which > Linux system do not enable that access in it's early boot stage? And > if proc is really not available (in the early boot process) the > call to ttyname may just

RFC: killall5 for SIGSTOP and SIGCONT

2012-04-02 Thread ra...@gmx.de
Hi all, in some cases for system maintenance (e.g. shortly before putting the system on standby or sleep) it could be wise to stop all running processes (and let them continue after doing some operation). So how to achieve this in shell scripts ... There is a nice command to send signals to all p

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread ra...@gmx.de
Hi Rich! > > So the reason why Busybox neglected to > > respond with the pty name was, I dropped the read permission of > > the /dev/pts and gave only execute permission to that directory. > > Please note that this does not provide *ANY* privacy/security > advantage. I know. It is just the way I

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread walter harms
It would be helpful if someone could write that down, so it can be added to "know known problems" or so. re, wh Am 02.04.2012 17:08, schrieb Laurent Bercot: > Hi Harald, > > >> As far as I know is tty specified to test the stdin so fd 0 is the >> right one (fd 2 was a typo of mine, sorry). C

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread Laurent Bercot
Hi Harald, > As far as I know is tty specified to test the stdin so fd 0 is the > right one (fd 2 was a typo of mine, sorry). Currently Busybox and GNU > tty test stdin and glibc does readlink /proc/self/fd/0 (from strace > output). Oh, right, my bad. /proc/self/fd/0, then: glibc is doing the

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread Rich Felker
On Mon, Apr 02, 2012 at 11:58:00AM +0200, Laurent Bercot wrote: > symlink at /proc/self/fd/2. So the reason why Busybox neglected to > respond with the pty name was, I dropped the read permission of > the /dev/pts and gave only execute permission to that directory. Please note that this does not p

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread ra...@gmx.de
Hi! > but I'm fairly sure you will break numerous other applications > by dropping the read permissions on /dev/pts/. May be I'm breaking things with those restrictive permissions for /dev/pts ... but beside this fixing the ttyname (and ttyname_r) functions in uClibc not only gives a speed improv

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread Ralf Friedl
ra...@gmx.de wrote: I think reading /proc/self/fd/1 (we want to test stdout, not stdin or stderr) is the right thing to do for the "tty" command, As far as I know is tty specified to test the stdin so fd 0 is the right one (fd 2 was a typo of mine, sorry). Currently Busybox and GNU tty tes

Re: [ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread ra...@gmx.de
Hallo Laurent! > Forwarded to the uClibc development mailing-list. > Mail-Followup-To set. Thx for forwarding! > I think reading /proc/self/fd/1 (we want to test stdout, > not stdin or stderr) is the right thing to do for the "tty" command, As far as I know is tty specified to test the stdin

[ra...@gmx.de: computer phenomena: output of tty applet]

2012-04-02 Thread Laurent Bercot
Forwarded to the uClibc development mailing-list. Mail-Followup-To set. I think reading /proc/self/fd/1 (we want to test stdout, not stdin or stderr) is the right thing to do for the "tty" command, but I'm fairly sure you will break numerous other applications by dropping the read permissions o