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
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:
fallback-reboot does not require fork or exec to be working.
It remains memory resident from boot time, until you need it.
fallback-reboot does not require any disk drives to be
working. It doesn't read or write any files - not even log
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
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.
Is fallback-reboot secure?
I hope so!
Seriously, the server process is written in carefully coded C. It
checks return values carefully, and it only reads data with fgets and
fgetc. But if you have doubts, please download the code and
look it over yourself! The more skeptical you are, the better.
Also, fallback-reboot uses an accepted algorithm to get a
nonreplayable challenge-response authentication system based on
RIPEMD-160, which to my knowledge is a hash function that hasn't yet
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.
What platforms does fallback-reboot run on?
Solaris 2. (2.8 shouldn't be a problem, but building on it is
Linux (Redhat Enteprise 3, Fedora Core 3, Ubuntu 4.10),
AIX 5.1 (requires prngd)
FreeBSD 5.4 Beta 1
...but please see the file "Porting" in the tar ball.
BTW, fallback-reboot 0.998 is known not to build on
How well tested is fallback-reboot?
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
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.
Tested it only a tiny bit on Unbuntu
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.
The FreeBSD port has seen only minimal testing, and that was
with QEMU, not on physical hardware.
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.
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".
Why do I get a connection refused error from
falback-reboot-client, even though fallback-reboot (the daemon) is
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.
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.