reacting to respawn giving up?

[Garrett Cooper]

On Thu, Nov 26, 2009 at 4:28 AM, Janne Karhunen
<janne.karhunen at gmail.com> wrote:
> Hi,
>
> Finally got around to this. There's a hacky patch attached that
> introduces 'reboot' stanza that will issue reboot given that we
> hit respawn limit for 'reboot' marked task. While this seems
> working, issuing reboot is probably not the correct way to
> reboot. Scott, your comments?
>
> On Tue, Nov 10, 2009 at 9:34 AM, Garrett Cooper <yanegomi at gmail.com> wrote:
>> On Mon, Nov 9, 2009 at 11:20 PM, Janne Karhunen
>> <janne.karhunen at gmail.com> wrote:
>>> Hi,
>>>
>>> Any ideas what would be the best way to react to respawn
>>> giving up? Certain services are critical enough to warrant a
>>> whole device restart once they fail. 'start on stopped
>>> <service>' might work, but it can also trigger during normal
>>> shutdown and that's not nice.
>>>
>>> If there is no other way, would you guys be willing to accept
>>> a patch for new 'reboot' stanza?
>>
>>
>>    Please -- this would get rid of a crappy hack that we have with
>> env and export in my group.

Uck. Why not just implement a function that either goes to rc6 or
implements the reboot syscall?

REBOOT(2)                  Linux Programmer's Manual                 REBOOT(2)



NAME
       reboot - reboot or enable/disable Ctrl-Alt-Del

SYNOPSIS
       /* For libc4 and libc5 the library call and the system call
          are identical, and since kernel version 2.1.30 there are
          symbolic names LINUX_REBOOT_* for the constants and a
          fourth argument to the call: */

       #include <unistd.h>
       #include <linux/reboot.h>

       int reboot(int magic, int magic2, int cmd, void *arg);

       /* Under glibc some of the constants involved have gotten
          symbolic names RB_*, and the library call is a 1-argument
          wrapper around the 3-argument system call: */

       #include <unistd.h>
       #include <sys/reboot.h>

       int reboot(int cmd);

In particular:

       LINUX_REBOOT_CMD_CAD_OFF
              (RB_DISABLE_CAD,  0).  CAD is disabled.  This means that the CAD
              keystroke will cause a SIGINT signal to be sent to init (process
              1),  whereupon  this  process  may  decide  upon a proper action
              (maybe: kill all processes, sync, reboot).

Still, probably not the upstart way -- but less error prone and more
secure than calling system("/sbin/reboot").

My 2 cents,
-Garrett