Re: [arch-general] /etc/rc.d/foo restart
2009/5/28 Frédéric Perrin <frederic.perrin@resel.fr>:
I'm just an user, but... if I ask the service to be restarted when it is not started yet, I would expect the rc script to fail as early and loudly as possible, no ?
-- Fred
Currently the rc scripts just do a "stop" followed by a "start" to restart. Should this be done differently? Personally I have no issue with this, and it's beneficial to me.
Daenyth Blank wrote:
2009/5/28 Frédéric Perrin <frederic.perrin@resel.fr>:
I'm just an user, but... if I ask the service to be restarted when it is not started yet, I would expect the rc script to fail as early and loudly as possible, no ?
-- Fred
Currently the rc scripts just do a "stop" followed by a "start" to restart. Should this be done differently? Personally I have no issue with this, and it's beneficial to me.
The only small issue for me is for example the sshd. This is the scenario: 1) Login with ssh to Arch Linux machine. 2) Do some task. 3) shutdown/reboot The ssh session is _hold_ no ^C ^D respond. This is because only the "sshd master" is killed on stop, and not the childrens. Then when network is stop.... just freeze. At this point can happends two scenarios: 4a) timeout ocurr at some time acording to tcp timeout setting, so the local shell is again for you. (if remote machine is shutdown) 4b) the ssh session continues normally when remote machine is up again. (an openssh feature?) (if remote machine is reboot) Solutions can have many: S1) Just killall on sshd "stop" (but not on "restart", because can be useful doing a "restart" on some upgrade, an users connected to the system, can stay on it, and new users will get the new configuration/libs) S2) Do not stop network in the loop, just omit them. And stop, after the killall5 commands. This also ensure that all daemons and your childs are stopped, the shutdown the network. S3) Any other better idea. :) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Thu, May 28, 2009 at 20:23, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
The only small issue for me is for example the sshd.
This is the scenario:
1) Login with ssh to Arch Linux machine. 2) Do some task. 3) shutdown/reboot
The ssh session is _hold_ no ^C ^D respond. This is because only the "sshd master" is killed on stop, and not the childrens. Then when network is stop.... just freeze. At this point can happends two scenarios:
4a) timeout ocurr at some time acording to tcp timeout setting, so the local shell is again for you. (if remote machine is shutdown) 4b) the ssh session continues normally when remote machine is up again. (an openssh feature?) (if remote machine is reboot)
Solutions can have many:
S1) Just killall on sshd "stop" (but not on "restart", because can be useful doing a "restart" on some upgrade, an users connected to the system, can stay on it, and new users will get the new configuration/libs)
S2) Do not stop network in the loop, just omit them. And stop, after the killall5 commands. This also ensure that all daemons and your childs are stopped, the shutdown the network.
S3) Any other better idea. :)
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
I'm not really sure what the best behavior in this case is... If you look at the example of a multi-user system, killing all sshd processes has the potential to boot off quite a few users unexpectedly.. It seems to me that the only time you would want that behavior is when you're the only one using it. Either that or you'd want to «wall» first.
Daenyth Blank wrote:
I'm not really sure what the best behavior in this case is... If you look at the example of a multi-user system, killing all sshd processes has the potential to boot off quite a few users unexpectedly.. It seems to me that the only time you would want that behavior is when you're the only one using it. Either that or you'd want to «wall» first.
Yes, but is stop so is supose to stop! So if is a real multi-user as you said, you need to take some preventions acording to the setup. The real problem in doing a killall sshd, is for example if you run multiple sshd on the same machine. (I do this for example for my build chroots) So the S1 of doing a killall is very anoying of course. In any way, is interesting in considering that stop "network" should be the last step just after killall5 in rc.{shutdown,single} of course if this don't have any problems with the differents setups that the user can configure ;) PS: I am very happy with ssh escapes :P that Jared suggested. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Thu, May 28, 2009 at 5:23 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
4a) timeout ocurr at some time acording to tcp timeout setting, so the local shell is again for you. (if remote machine is shutdown)
OT: type <enter> ~. to disconnect a hung ssh session. (See "ESCAPE CHARACTERS" in man ssh) Jared
Jared Casper wrote:
On Thu, May 28, 2009 at 5:23 PM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
4a) timeout ocurr at some time acording to tcp timeout setting, so the local shell is again for you. (if remote machine is shutdown)
OT: type <enter> ~. to disconnect a hung ssh session. (See "ESCAPE CHARACTERS" in man ssh)
Jared
hohoh! this is awesome!, many thanks for the tip! Good Luck! -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Thu, May 28, 2009 at 20:44, Jared Casper <jaredcasper@gmail.com> wrote:
OT: type <enter> ~. to disconnect a hung ssh session. (See "ESCAPE CHARACTERS" in man ssh)
Jared
Oh nice, never knew that one!
participants (3)
-
Daenyth Blank
-
Gerardo Exequiel Pozzi
-
Jared Casper