2 ms·

It's Unix parlance for a forked child process that detaches from its interactive terminal with the setsid() syscall, becomes a child of init, possibly closes or

It's Unix parlance for a forked child process that detaches from its interactive terminal with the setsid() syscall, becomes a child of init, possibly closes or redirects the 0/1/2 file descriptors to logging facilities, possibly changes its CWD, and no longer receives terminal-originating signals like SIGHUP, SIGTTIN, SIGTTOU, etc. Apart from that, a robust non-daemon program should use the same defensive techniques. In a short-running command-line utility, it might seem "acceptable" to leak memory, not close resources and not do adequate error-checking, but that's just sloppy programming.

ksherlock 3y ago
Well... "Since the missile will explode when it hits it's target or at the end of it's flight, the ultimate in garbage collection is performed without programmer intervention." https://groups.google.com/g/comp.lang.ada/c/E9bNCvDQ12k/m/1tezW24ZxdAJ https://groups.google.com/g/comp.lang.ada/c/E9bNCvDQ12k/m/1t... "to my surprise the cp command didn't exit. Looking at the source again, I found that cp disassembles its hash table data structures nicely after copying (the forget_all call). Since the virtual size of the cp process was now more than 17 GB and the server only had 10 GB of RAM, it did a lot of swapping." (I believe GNU cp was updated to not free up structures at exiting due after this). https://lists.gnu.org/archive/html/coreutils/2014-08/msg00012.html https://lists.gnu.org/archive/html/coreutils/2014-08/msg0001...