Well, in my case, it's already dead, but now I just need it (promptly) killed as far as the linode services are concerned.

See, I have this problem. I tend to run my 360 out of RAM on a semi-often basis. I'm sure the linode staff would either grin or cry at this statement, as two of the times I've done it, I didn't realize what happened, and put in support tickets. (Something about running a UT2004 server while torrenting the complete CentOS 5.1 DVD ISO at 5MB/second (so I have a 'fast' HTTP mirror for a few projects of mine). Among many other things.)

Long story short, I run my linode out of RAM often, causing some awesome crashes. The problem is the recovery process. I've either got to wait for lassie to find that the linode has died (which in this case is much more than a minute, for whatever reason), or I've got to insert the shutdown/startup jobs myself. While I have no problem doing the jobs manually (as the only times I'm run it OOM, I was really *using* it at that same moment, and likewise know what just happened). The problem is that even after issuing the shutdown command, the host sits there for 2m30s until it times out and marks the linode as having 'shut down' and hence completing the job (allowing for the job queue to progress).

I know the linode died. So why must I wait 2m30s for the linode services to decide that on their own? Implement a 'force-shutdown' or 'kill' command in lish. Essentially, this would just kill the UML process, mark it as dead, and call it good.

It's not something I would expect to use often, but when I really know what happened, and I'm really sure I want to hit the hard reset button, I'd simply like to have one :).

sysrq b seems to work nicely :)

You know I tried that. Still didn't cause the linode services to recognize the linode instance as "dead."

Then it didn't make it die. Once your kernel exits, our system will recognize it as down.

If you're causing your Linode to OOM frequently enough to get frustrated by the shutdown delay, then I think you should suffer the 2:30 wait, but "sysrq b" should work.

-Chris