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.
