-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-04-19 at 14:27 -0500, M Harris wrote:

Its pretty normal, actually.

... what you want to do is to ssh to Boris and reboot the guy with this:

su - -c "shutdown -r +1"

It happens regardless of how you shutdown Boris; it might be some one else who is closing Boris.

message... or it will hang there for a long long long time. Eventually it will give up though and go away. I think its really a tcp/ip thing. :}

The problem is, that although the sshd daemon knows it is going down, and it knows perfectly well who is connected, it doesn't disconnect the clients before going down. It shouldn't be the responsibility of the user to detect that the server is going down and disconnect. Computers are made to automate things. So, unless there is an option in the sshd configuration to change this behavior, it is a bug or misfeature. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGJ8xZtTMYHG2NR9URAn4JAJ9fu4liPUrkzdGn+ZGXeEQQYU7hvQCfdXpW zXwrE1nKroXnqz4F2A1RJUY= =YKaO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2007-04-19 at 22:19 +0200, mourik jan heupink wrote:

Isn't this whole issue related to the fact that when a process is still active in that ssh session (namely: the reboot command), the session 'hangs' when closing..? This is normal, isn't it?

The original poster did not say that the shutdown command is issued from the ssh session. That's an assumption made later by Harris. Look: open a terminal in you computer, and do "ssh localhost". Then, shut down the sshd daemon. I just did, and the client ssh is still running and working! In fact, doing a "ps afx" shows that the sshd daemon did not die: 16412 ? Ss 0:00 sshd: cer [priv] 16414 ? S 0:00 \_ sshd: cer@pts/31 16415 pts/31 Ss+ 0:00 \_ -bash And the log shows: Apr 19 23:18:07 nimrodel sshd[16409]: Server listening on :: port 22. Apr 19 23:18:19 nimrodel sshd[16412]: Accepted publickey for cer from 127.0.0.1 port 23422 ssh2 Apr 19 23:18:29 nimrodel sshd[16409]: Received signal 15; terminating. but it hasn't terminated. During halt it will be forcibly killed later on the sequence. I killed it via "killall sshd" and then the client died. I'm not going to shutdown my computer to check, but as I recollect, I have seen client sessions not dying. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGJ+AAtTMYHG2NR9URApyIAJ9N+ND7sGiGK33RlNr1uZ9QajNb3wCfUJee c/c1pu5aH/2IoMr6a1xxK48= =aXVm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

The original poster did not say that the shutdown command is issued from the ssh session. That's an assumption made later by Harris.

That's right, ssh session is not terminated in any case - I can submit reboot from other session or locally, nothing matters.

Look: open a terminal in you computer, and do "ssh localhost". Then, shut down the sshd daemon. I just did, and the client ssh is still running and working! In fact, doing a "ps afx" shows that the sshd daemon did not die:

16412 ? Ss 0:00 sshd: cer [priv] 16414 ? S 0:00 \_ sshd: cer@pts/31 16415 pts/31 Ss+ 0:00 \_ -bash

And the log shows:

Apr 19 23:18:07 nimrodel sshd[16409]: Server listening on :: port 22. Apr 19 23:18:19 nimrodel sshd[16412]: Accepted publickey for cer from 127.0.0.1 port 23422 ssh2 Apr 19 23:18:29 nimrodel sshd[16409]: Received signal 15; terminating.

but it hasn't terminated. During halt it will be forcibly killed later on the sequence. I killed it via "killall sshd" and then the client died. I'm not going to shutdown my computer to check, but as I recollect, I have seen client sessions not dying.

Well, my experience is when you work on remote machine using ssh and restart sshd daemon (sshd gets killed for sure), no ssh session is terminated and you can work almost without interruption. Obviously, Suse behaves exactly the same way when rebooting. BUT every other distro I ever used extensively (Debian, RH, Fedora) terminated ssh sessions correctly upon reboot. Oh and I see that I forgot my second question before. It's related to shutdown rather that to startup though. I use OpenSuse 10.X with /home on NFS (not sure if it's significant...). The problem is that sometimes reboot or shutdown doesn't proceed and halts. Last message written on the console is "Sending processes the KILL signal". System is not dead (NumLock responding), but doesn't proceed with shutdown/reboot further. This happens everytime (or almost everytime) I try to shutdown/reboot from KDE or GDM or using "reboot" command. On the contrary, shutdown/reboot succeeds everytime when a) pressing Power button and letting ACPI do the trick or b) going to the console (real text console - Ctrl+Alt+F1...) and hitting Ctrl+Alt+Delete... I experienced such behaviour with all OpenSuse 10.x versions, on different machines, both i386 and x86_64 platforms. Thanks for suggestions. Petr -- Petr "Tosuja" Klíma Mail: tosuja@tosuja.info Web: www.tosuja.info ICQ: 52057532 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-04-20 at 17:07 +0200, Petr Klíma wrote:

Oh and I see that I forgot my second question before. It's related to shutdown rather that to startup though.

You'd better open a new thread. I'm changing the subject for this one, anyway.

I use OpenSuse 10.X with /home on NFS (not sure if it's significant...). The problem is that sometimes reboot or shutdown doesn't proceed and halts. Last message written on the console is "Sending processes the KILL signal". System is not dead (NumLock responding), but doesn't proceed with shutdown/reboot further.

This happens everytime (or almost everytime) I try to shutdown/reboot from KDE or GDM or using "reboot" command.

My guess is that the nfs session refuses to umount because there is a user process (the one doing the halt) running from there. Or the halt process is a child of kdesu that is running as user, or something of the sort.

I experienced such behaviour with all OpenSuse 10.x versions, on different machines, both i386 and x86_64 platforms.

You could open a bugzilla... I don't know if this is expected behaviour, or if some option in the nfs mount can help. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGKPWMtTMYHG2NR9URAgZyAJ9sgHhqPP3DMK51nE472iJ26fLrQwCfacVq CnTBDiVKWXvN4cnv6KTj45w= =eCYU -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2007-04-20 at 10:27 -0700, Randall R Schulz wrote:

...

My guess is that the nfs session refuses to umount because there is a user process (the one doing the halt) running from there. Or the halt process is a child of kdesu that is running as user, or something of the sort.

Almost certainly this is the correct explanation.

...

...

I experienced such behaviour with all OpenSuse 10.x versions, on different machines, both i386 and x86_64 platforms.

You could open a bugzilla... I don't know if this is expected behaviour, or if some option in the nfs mount can help.

I wouldn't do that. It's not a bug that umount fails if there are files open on the file system in question (including current working directories).

You are right, I was too fast; but there is one exception: when halting. I don't remember the exact sequence, but first process are politely killed, after some seconds the remaining are then forcibly killed, then filesystems are umounted. As there are no longer processes running, except init and maybe something else, there can not be anything opened that disallow umount. The exception might be the "/" mount, which is flushed instead, I think. I would have to read it up again. Where in that sequence is the nfs client umounted? Dunno, but there is a flaw somewhere. Either kde whatever should refuse to halt knowing that they will not be able to do so, or some script/program should be modified apropiately. Or the halt script should nicely recover, somehow. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGKQNvtTMYHG2NR9URAhe4AJsFoA/6FF1jahHhNNCK/Mkw6PVleACfSwnG IRZfzMq3ckv+NFkG0zDcBKY= =ZsKT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-04-23 at 09:19 +0200, Petr Klíma wrote:

Well, the halt problem seems to be solved. It was caused by mounting NFS filesystem within a tree of another NFS fs. Like mounting NFS on /home and then another NFS mount to /home/another/nfs. Obviously the umount of /home happens before umount of /home/another/nfs and fails. Once I have moved /home/another/nfs mountpoint out of /home, halt seems to work (several attempts, no failure).

I think the umount procedure/script/whatever should be clever enough to sort it out, ie, umount in the appropiate order. If that doesn't happen, I think it is a bug. Or, it depends on the order the mounts are listed in fstab.

I still wonder why the shutdown initiated by Power button or Ctrl+Alt+Del worked while GDM button didn't. There are no open files on /home/another/nfs (almost never).

Perhaps because it force-kills everything. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGLJ0VtTMYHG2NR9URAui1AJ0VVZuNDJJvavoZTij37KY2z288jwCgjYqG FWCavYEgU/bdPtUDAispT14= =nv7+ -----END PGP SIGNATURE-----