What happens when the console dies?

fossette

fossette

Does it go to heaven? More seriously, the question should perhaps be, what happens when the parent process dies? I've launched X Display/Window Manager processes in the background on a remote pc from a ssh(1) shell as a user. Today, I just noticed output on the ssh(1) shell of what appears to be standard error stream data from an application launched within the Window Manager. My question is, what will happen when I log out of my ssh(1) shell? Will future standard error stream data be flushed? Will they be buffered? And if buffered, is there a specific limit, or will the system explode or freeze once the space runs out? The stdio(3) man page says that the standard error stream is not buffered initially, but lots of sub-systems are involved here.

I'm asking this question because I'm wondering if it could be related to the problem that I reported here:
No reply to SSH login or SSH stops responding (deadlock?)

Dominique.
 
I don't have answers to your direct questions, however, I would suggest using screen(1) when you connect to a remote host via ssh(1). That way you will always have a live console. You can then (re)attach it to another ssh or local session.
 
At the risk of turning this into bias, I'd recommend sysutils/tmux over Screen. In a way there's personal preference at work here, but I do think it's fair to mention that screen still relies on a setuid root being set whereas TMux does not.

Each to their own but I prefer limiting the commands which utilize root privileges.
 
Unfortunately tmux(1) does not support serial connections (yet?), which I use much working with embedded software. Otherwise it's great.
Many people are too lazy (including me) to learn completely different default key bindings or configure ones.
 
I'll study screen(1) and tmux(1) further to see how I can integrate either of them in my power-up procedure. I favor tmux(1) at this time because it seems to have less dependencies and can run as a user...

As I expected, no standard error stream data is displayed in a newly created ssh(1) session, i.e. after closing the ssh(1) session that was the mother-of-all-processes. I launched xconsole(1) as root to see if anything is logged in there xconsole -daemon -verbose. Absolutely nothing is echoed. A config/usage issue maybe? How can I test it without breaking stuff or causing a panic? I tried echo ConsoleTest > /dev/console as root but that doesn't output anything.

Another question, Section 3.2.1. Virtual Consoles of the Handbook says:
system messages are configured by default to display on the system console.
Click to expand...
How do we change it? Changing the famous Line 8 in /etc/syslog.conf?

And how about the standard output stream and standard error stream of an orphan process, can they be redirected to a new terminal easily? or the use of a detachable virtual terminal is the only way to go?

Again, thanks for the suggestions you have provided. I really appreciate it!

Doing further reading,
Dominique.
 
fossette said:
Changing the famous Line 8 in /etc/syslog.conf?
Click to expand...
Yes.

And how about the standard output stream and standard error stream of an orphan process, can they be redirected to a new terminal easily? or the use of a detachable virtual terminal is the only way to go?
Click to expand...
Not sure if you can pickup the streams from an orphaned process but there are ways not to let them dangle. Besides tmux(1) and all, traditionally it was done with nohup(1).
 
Just to familiarize myself, I tried nohup sleep 10 ; echo NohupTest &, and quickly [CTRL-D] my xterm(1), but that doesn't seem to work. Nothing in ./nohup.out (./ = ~/ this time), even after touching it and even assigning it to wheel (+rw). nohup.c is very short, but I have yet to fully understand it. Either, it doesn't recognize virtual terminals, or its decision is taken way too early, and misses the fact that the virtual terminal will be terminated soon after.

Nevertheless, it occurs to me that to prevent the dangling orphaned process, I may as well pipe the standard output+error streams to a file right from the start because I know for sure that the ssh(1) session will not last. Man! I can't see it when it's so simple...

Btw, I just noticed that the Parent Process ID of orphaned processes seems to be 1, that is /sbin/init --. That narrows it down greatly to what may happen when the console dies, but I'm definitely not ready to read that source code yet. I'll have way too many nightmares. ;-)

Dominique.
 
fossette said:
Nevertheless, it occurs to me that to prevent the dangling orphaned process, I may as well pipe the standard output+error streams to a file right from the start because I know for sure that the ssh(1) session will not last. Man! I can't see it when it's so simple...
Click to expand...
Sometimes you can't see the forest through the trees ;)

As for your nohup(1) test, sleep(1) doesn't produce output so nohup.out will always be empty.
 
SirDice said:
As for your nohup(1) test, sleep(1) doesn't produce output so nohup.out will always be empty.
Click to expand...
Ah? Operators precedence? So how about creating this ./mynohuptest.tcsh script:
Code: 
#!/bin/tcsh
sleep 10
echo NohupTest
Then I execute this command nohup ./mynohuptest.tcsh & quickly followed by [CTRL-D]. I see this for a brief moment:
Code: 
% ps
1268  3- S  0:00.01 /bin/tcsh ./mynohuptest.tcsh
but no ./nohup.out file in the end. The End

Anyway, I simply redirect the standard output & error streams to a file using this command qvwm >& ~/.logQvwm.txt &. The log file is out of sight by default and will be erased on next reboots. I just need to make sure to get what I need if need be before rebooting. However, with that change, I wonder if the deadlock that I encountered will still happen. Time will tell.

Dominique.
 
~/nohup.out is created by /usr/bin/nohup, thus it works with e.g. bash(1).
tcsh(1) has a built-in nohup, which works in a different way (I haven't used it).
fossette , so your example above works fine with bash(1), if you explicitly use it in tcsh(1):
Code: 
/usr/bin/nohup ./mynohuptest.tcsh &
it perfectly works too and creates ~/nohup.out.
 
You must log in or register to reply here.
Back
Top