rebooting ltsp server leaves client stuck

[Ian Jackson]

I installed an edubuntu server from the feisty dvd i386 20070416 and successfully booted a client.

When I selected to reboot the server, the server was able to shut down and reboot normally. However, the client was left in a stuck state: the applications and desktop were shut down but I was left with a blank desktop background where keyboard and mouse had no effect.

[Scott Balneaves (sbalneav)]

Well, a thin client relies on the server completely, for it's X session, file system, logging, etc. If you reboot the server, one can expect bad things on the client.

I suppose the real question is: what do you WANT the expected behaviour to be?

[Oliver Grawert (ogra)]

the proper solution would likely be that the client shuts down properly as well *before* the server is gone ... we could achieve that by having an ltsp-server initscript that is run on server shutdown and some yet to be specced and designed function that can shut down the clients remotely. marking that bug as whishlist so we can workout a spec for that at next UDS.

[Roland Ronquist (roland-ronquist)]

out of pure evilness, I found out that most of the times (in my environment)
the clients survived a server reboot as long as they where at the login prompt.
I know this may not be 100% expected and that this neither may be the
intended way of doing things.

Best,
r.r.

[Jordan Erickson (lns)]

Not sure how difficult this would be, but why not emulate the "good old TTY days" and send a broadcast message to all TCs, something like "Message: Server is going down NOW!", followed by a forced logout to LDM prompt.. ? Since LDM, according to Roland anyway, can survive a server reboot, kicking the clients back to a login prompt would be a good thing, to avoid having to reboot, say, a hundred thin-clients.

Another idea, maybe a hook on the server to warn the admin: "WARNING: XX number of client sessions are active - continue?"...Oh, oh, and what about some "shutdown" style options, maybe "Halt/reboot in X seconds/minutes"... shouldn't be difficult since the functionality already exists in the shutdown command, and LTSP setups really do sort of emulate the days in which this functionality was useful...

[Ronald van Engelen (ronalde)]

Although (in Hardy) ltsp clients seems to survive a server reboot (including the running gnome-sessions and applications), the ltsp-client root behaves odd after the reboot. We've seen random hanging ltsp-clients, no access to terminal 1 etc.

I guess this makes it an issue for nbd.

[Tyler Stafford (tstafford)]

When using XDMCP, rather than LDM/X Forwarding, clients handle this more gracefully. The client goes to a blank screen with an X cursor, and seems to wait until the server comes back up. At that point it brings up the GDM login screen.

[Jonathan Carter (jonathan)]

An ideal situation, although probably not to friendly on thin client usage, would be a program that possibly runs from a ramdisk when the connection to the server has been severed. Something that would display something similar to "Terminal server unavailable, system will shut down if no connection can be established in 1 hour."

If the server connection is re-established (perhaps it rebooted), LDM can be restarted. If the server is unavailable for a certain amount of time, the systems could shut down, reboot or switch to an alternate server depending on how they were configured.

[Scott Balneaves (sbalneav)]

Looks like Stephane's nbd proxy will help this.

[Alkis Georgopoulos (alkisg)]

I think the main problem is that `nbd-client -persist` doesn't put the client in a fs-wait-state or however else it's called, and it doesn't try to reconnect to the server after it's up and running again.
Removing the task from LTSP and adding NBD in the "affects" list.

[Rüdiger Kupper (ruediger.kupper)]

I confirm this problem.