Wednesday, July 11, 2012

Sidestep bugs by running multiple versions of BusyBox on ESXi 5

I recently discovered that ESXi 5 uses BusyBox 1.9.1 which includes a bug in nohup.  Christoph Gysin identified the issue and released a patch 4 years ago:

http://lists.busybox.net/pipermail/busybox/2008-January/064029.html

/bin # nohup

BusyBox v1.19.3 (2012-01-13 00:47:40 UTC) multi-call binary.



Usage: nohup PROG ARGS



Run PROG immune to hangups, with output to a non-tty


Alas, I don't want to straight out replace my busybox on my VMware server, as I have no idea what else will break.

Unfortunately I really needed nohup to work properly, as my scripts would be running for too  long to trust that my session wouldn't close.   Furthermore, walking over to the machine and plugging in a monitor to access the console sounded like a hassle.  I could probably have just written it into a script and kicked it off with cron, but in the end, I decided to fix nohup.

The first thing I tried was scp over my version of nohup from coreutils to the ESXi box.  Alas, the whole idea of busybox is to simply the myrid of prerequisites that a modern linux system requires:

/bin # nohup2

nohup2: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by nohup2)


But the same idea with busybox works great.

/bin # busybox-1.19.3 nohup

BusyBox v1.19.3 (2012-01-13 00:47:40 UTC) multi-call binary.



Usage: nohup PROG ARGS



Run PROG immune to hangups, with output to a non-tty






You can see the broken and working versions here:

/vmfs/volumes/4f3e8959-c92ca33c-dc7c-00215e26146e # /bin/busybox nohup esxtop -b -d 3 -n 28800 >output1.csv &

/vmfs/volumes/4f3e8959-c92ca33c-dc7c-00215e26146e # nohup: appending to nohup.out



/vmfs/volumes/4f3e8959-c92ca33c-dc7c-00215e26146e # /bin/busybox-1.19.3 nohup esxtop -b -d 3 -n 28800 >output2.csv & 

/vmfs/volumes/4f3e8959-c92ca33c-dc7c-00215e26146e # ls -l

-rw-r--r--    1 root     root                  0 Jul 11 15:53 output1.csv

-rw-r--r--    1 root     root             159368 Jul 11 15:54 output2.csv





Now I just changed the sym link for nohup

/bin # rm nohup

/bin # ln -s /bin/busybox-1.19.3 nohup

/bin # ls -l nohup

lrwxrwxrwx    1 root     root                 19 Jul 11 15:55 nohup -> /bin/busybox-1.19.3


And we're in business with a working nohup, and everything else stock.