1. Why should I use fallback-reboot?

    Because if you have a machine you suspect you might need to reboot someday, it may save you a trip to the machine's physical location
  2. Why is fallback-reboot any better than just ssh'ing in and running a "shutdown" or "reboot" or whatever?

    Because unlike sshd or whatever, I've attempted to make fallback-reboot depend on as few OS and machine resources as possible. Specifically, after the program has initialized itself:
    1. fallback-reboot does not require fork or exec to be working. It remains memory resident from boot time, until you need it.
    2. fallback-reboot does not require any disk drives to be working. It doesn't read or write any files - not even log files.
    3. fallback-reboot does not even appear to require the virtual memory system (code/data paging/swapping in VM) or demand paging from the filesystem to be functioning properly
  3. What protocol does fallback-reboot use? Isn't fallback-reboot going to have the same problems as whatever you built it overtop of?

    Yes, it does. However, what it's built overtop of is just TCP/IP, the openssl project's libcrypto, the C library, and a small bit of the berkeley sockets API.
  4. Is fallback-reboot secure?

  5. If you don't sync the disks, won't there be a need for a manual fsck - forcing me to go to the machine anyway?

    In all of my testing of fallback-reboot, I haven't had to do a single manual fsck. However, it is possible you will have to - just unlikely. Also, I'm presently of the belief that journaled/logging filesystems will make this even less likely than it used to be - which wasn't really all that likely to begin with.
  6. What platforms does fallback-reboot run on?

    1. Solaris 2.[79] (2.8 shouldn't be a problem, but building on it is untested)
    2. Linux (Redhat Enteprise 3, Fedora Core 3, Ubuntu 4.10, Mint 17),
    3. AIX 5.1 (requires prngd)
    4. FreeBSD 5.4 Beta 1
    ...but please see the file "Porting" in the tar ball.
    BTW, fallback-reboot 1.1 is known not to build on
    1. Solaris 2.6.
  7. How well tested is fallback-reboot?

    1. fallback-reboot has been used successfully on an FC3 system, at a time when sshd was unusable due to extremely high system load. And another time, on the same machine... evolution was growing huge, load was 48+, but fallback-reboot cheerfully gave a prompt. However, eventually, evolution OOM'd, so I didn't need fallback-reboot.
    2. Tested pretty extensively on Fedora, Redhat Enterprise and Solaris. BTW, once on a Solaris 8 system, while the SCSI subsystem was in ruins, fallback-reboot cheerfully gave a prompt.
    3. Tested it only a tiny bit on Ubuntu
    4. The AIX port is not that well tested yet - it compiles, runs, and accepts connections, but no reboots yet, as all of our AIX systems are in production. Unless someone else gives me feedback about how the program works on AIX, we'll have to wait until one of our local AIX systems has a serious problem.
    5. The FreeBSD port has seen only minimal testing, and that was with QEMU, not on physical hardware.
  8. Are there other ways of doing what fallback-reboot does?

    Certainly. AFAIK, fallback-reboot is somewhat unique, but there is a variety of ways of contending with crashy systems. The most similar project I've seen is rICMP, though it appears to be linux-specific, and I haven't seen it ported to kernel 2.6 yet.
  9. Why do I see "make: Fatal error in reader: Makefile, line 4: Unexpected end of line seen"?

    Please be sure to use GNU make, sometimes known as "gmake".
  10. Why do I get a connection refused error from falback-reboot-client, even though fallback-reboot (the daemon) is running?

    Give it a sec. Some forms of getting random data can take a while. Then try it again. If you're feeling in a hurry, you might try using a system call tracer to see what the daemon is up to.
  11. Where does fallback-reboot get its entropy (randomness) from?

    /dev/urandom, /dev/random, or prngd. If you don't have /dev/urandom or /dev/random, you can probably obtain prngd and build it for your system. Put it on tcp/708, unless you want to tell fallback-reboot's configure what port you're going to use for prngd. You may also be able to use egd instead of prngd.



Hits: 5719
Timestamp: 2024-03-29 08:07:27 PDT

Back to Dan's tech tidbits

You can e-mail the author with questions or comments: