A crop of new capabilities [LWN.net]

A crop of new capabilities

Posted Jun 8, 2020 23:37 UTC (Mon) by NYKevin (subscriber, #129325)
Parent article: A crop of new capabilities

> Some users run the equivalent of a fork bomb, quickly creating (and killing) processes to cycle through the process-ID space up to the desired value.

Wait, what???

Are people actually doing that in production, or is it one of those "gee willikers, look what I can do" GitHub repositories?

A crop of new capabilities

Posted Jun 11, 2020 16:17 UTC (Thu) by Jandar (subscriber, #85683) [Link] (5 responses)

I have long running (multiple months) screen sessions on some production servers to which I connect frequently. To connect to screen you have to specify the unique beginning of the screens pid. All pids beginning with a higher digit as the begin of max-pid are 10 times rarer than those with a lower digit. If I get a screen with pid 9* it's normally sufficient to type 'screen -r 9' to reconnect.

Do you have to make many guesses about what I do when starting the screen? ;-)

A crop of new capabilities

Posted Jun 11, 2020 18:13 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (4 responses)

A true hacker's hack. Or you could use tmux and the you get access to named sessions/sockets ;) .

This probably works much better when pids are small (when uptime is low). Now to get such a pid after you already have pid 1000000 spawned, your process comet probably takes a non-negligible amount of time. And then you're stuck with another million or so pids until it is unique again.

A crop of new capabilities

Posted Jun 11, 2020 20:41 UTC (Thu) by Jandar (subscriber, #85683) [Link]

> This probably works much better when pids are small (when uptime is low).

The uptime doesn't factor in. The production systems of our customers mostly have max-pid of 64k with a high uptime. The pid wraps around after a few hours to a few days. So if someone other starts a screen from the shared admin-account it gets a pid nearly at random. The pids starting from 1 to 5 are from a set of 11111 numbers (disregarding special pids like 1) and pids starting from 7 to 9 are from a set of 1111.

while [[ $(readlink /proc/self) != 9* ]]; do :; done && screen -S Jandar

As normally at most a handful screen are running, the chance to have 9* exclusively for myself is high because no workmate uses the shell-prompt to type in loops. Probability with 5 other screen = (1-1111/2^16)^5 = .91807.

A crop of new capabilities

Posted Jun 11, 2020 23:24 UTC (Thu) by kmweber (guest, #114635) [Link] (2 responses)

> Or you could use tmux and the you get access to named sessions/sockets

You can do that with screen, too.

A crop of new capabilities

Posted Jun 12, 2020 2:24 UTC (Fri) by Jandar (subscriber, #85683) [Link] (1 responses)

> You can do that with screen, too.

I was going to say: it doesn't work that way, but I tested it before commenting. In reality it does work.

The only explanation I have is, that the manual shows contradicting usages.

1) from the Synopsis:
screen -r [[pid.]tty[.host]]
2) from the section COMMAND-LINE OPTIONS:
-r [pid.tty.host]
-r sessionowner/[pid.tty.host]
In 2) the pid seems to be not optional and the sessionname from -S sessionname
only substitutes tty.host. The text description for -r says "prefix of [pid.]tty.host" so pid seems optional.

I have never tested if screen -r sessionname works, I've always assumed pid is mandatory. *facepalm*

A crop of new capabilities

Posted Jun 16, 2020 13:55 UTC (Tue) by geert (subscriber, #98403) [Link]

I use "screen -dRR -S <sessionname> ..." all the time, from a script that knows how to connect to whatever target board I specify.

There is one caveat though: if a session name is an abbreviation of another session name, and the session with the shorter name doesn't exist yet, then screen will happily connect to the (wrong) session with the longer name instead. Once the session has been created, everything works as expected, though.
Solution: create your sessions in the right order, so they never match an existing one.