A clever trick to deal with students powering off workstations

January 25, 2007

One of the eternal curses of student Unix labs is students casually turning off workstations the way they turn off other PCs when they're done with them. (A problem made worse by vendors putting glowing power buttons on the front panel of machines, where they become an easy temptation.)

In theory the answer to this is Wake-on-LAN. You probably have at least one inaccessible computer per lab, so run a daemon on that that notices when workstations are down and sends out a WoL packet to get them back up. In practice, WoL requires a fair number of things to be working just right and can be a bunch of work to get going.

Recently a co-worker shared an interesting low-tech solution to the problem. What we care most about is powered-off machines missing out the nightly updates and automatic maintenance (and somewhat having them ready for students in the morning). The simple way to deal with that is to set the PC BIOSes to power the machines on at 2am or so, somewhat before the scheduled nightly stuff starts.

This does nothing to machines that are already on but revives any machine that the students have powered off, and setting it significantly after your labs close means that students won't be around to turn them off again. (If you run 24-hour labs, I suppose you'll just have to hope.)

Also, modern machines with ACPI usually let you control what happens when the front panel power button is pushed. I recommend that you make it reboot the machine; making it do nothing will just encourage the students to reach around behind the machine and yank the power cord. (It is also cheap insurance against the machine actually needing a reboot to get out of some peculiar state.)


Comments on this page:

By Dan.Astoorian at 2007-01-26 15:13:14:

[...]set the PC BIOSes to power the machines on at 2am or so, somewhat before the scheduled nightly stuff starts.

Remembering, of course, to take into account whether the hardware clock is set to local time or to UTC.

Also, modern machines with ACPI usually let you control what happens when the front panel power button is pushed. I recommend that you make it reboot the machine;

I've seen enough computer cases with the power button too close to the floppy or CDROM eject button that I would be reluctant to implement that without a more explicit confirmation from the user. Handling power button presses doesn't add any functionality for the users sophisticated enough to use Ctrl-Alt-Delete (provided either that your windowing system doesn't get in the way, or that the users are also sufficiently sophisticated to get around it, e.g., by switching virtual consoles).

I've always been tempted to, in an homage to Douglas Adams, make the front panel power button pop up a window reading "Please do not press this button again."

making it do nothing will just encourage the students to reach around behind the machine and yank the power cord.

I think most of our users already figured out long ago that holding down the button for five seconds is as effective as pulling the plug.

--Dan

By cks at 2007-01-27 22:46:29:

I prefer making the power button do something because I generally assume that students are pushing it for a reason; either they're done using the computer and are turning it off as they leave to 'log out', or something has gone wrong and they think the computer needs to be reset. A reboot serves both purposes reasonably well.

(My past lab users have not been sophisticated enough to reboot the machine through C-A-D, since it would have required flipping to a text console first.)

I don't think I've seen a case where the power button was what I considered sufficiently close to the floppy/CD/DVD drive to be dangerous in that way. Especially for small form factor cases, my impression has been that companies like Dell work carefully to make sure their front panels aren't confusing that way.

(You may well have seen more perversely and/or terribly designed computer cases than I have.)

From 152.14.52.223 at 2007-02-05 17:06:47:

Where I did my undergrad, somehow the sysadmin had set it up to be notified who rebooted the machine. I was rebooting the Sun machines sometimes, because I could either legitimately freeze them while trying to do work, or screw something up with X while I was experimenting with it. In the cases where I screwed up X and couldn't get a terminal, I had always hoped that Solaris had some way of loging into another console ctrl+alt+F2 etc like linux, but the closest I ever found was ctrl+stop+a "boot" or whatever. Anyways he would call me in to his office and really yell at me. He was a huge guy and used to be in the Navy. Don't treat the students like that, because he was a real jerk.

By cks at 2007-02-26 00:02:17:

That machines can lock up is one reason why we never bothered writing up any sort of 'nag the user logged in when the machine rebooted' stuff; it would be too easy to wind up pestering someone who had a machine lock up on them and then walked away from it.

Also, I didn't really care that much; with an orderly reboot the students aren't actually damaging anything except my pride in long uptimes, and my pride had better be able to take it.

(Even if something did go wrong, we had a well-honed and mostly automated procedure to completely reinstall machines from scratch.)

Written on 25 January 2007.
« An irritation with current GUI interfaces
First impressions of pyOpenSSL »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jan 25 20:51:16 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.