Best Effort Daemonic Child Cleanup
Description
A cropped screenshot of technical documentation shows most surrounding lines blurred, while one sentence remains readable and partly highlighted in blue. The visible text says: "Of course you can, and should, use daemon even with multiprocessing. Here, when the main process exits, it attempts to terminate all of its daemonic child processes." The joke is the careful wording of "attempts to terminate," which turns what sounds like deterministic process cleanup into a best-effort promise. For experienced developers, the highlighted phrase evokes all the shutdown, signal-handling, and orphaned-process edge cases hidden behind a reassuring docs sentence.
Comments
24Comment deleted
Nothing says deterministic shutdown like documentation quietly downgrading it to a best-effort syscall fanfic.
hmm let's rephrase that "it attempts to kill all of its daemonic children" based christian thread Comment deleted
демон != даемон Comment deleted
please use english or provide a translation for your russian text Comment deleted
demon != daemon Comment deleted
"team was the first to use the term daemon, inspired by Maxwell's demon" So, it is. Comment deleted
please use Arabic or provide a translation for your English text Comment deleted
This chat is specifically English based, as it is international language, after all. If you have troubles understanding written text, perhaps, you should refer to translators or git gud at English. Comment deleted
Plus, j have no idea whether Google translated text to Arabic is any good Comment deleted
Im joking bro xd😹 Comment deleted
I still don't understand why darmon is used Comment deleted
daemons are just processes that run in the background for a long time, they're very useful for various stuff. Comment deleted
I want your opinion for something... I am not okay with any of these solutions... Comment deleted
whats the difference between daemon and thread ? Comment deleted
Threads share memory space and processes (usually) don't. Also signals and exitcodes are a process thing (on unix-like platforms). Daemon is just a process that doesn't interact with the user directly. In olden days it meant it detached from controlling terminal of user session and thus stopped getting session signals along with user input. (This is more and more recognized as a bad practice and dedicated process supervisors are used, first well known one was daemontools) Comment deleted
bad practice? But isn't basically everything started by systemd a daemon? Comment deleted
I'm talking specifically about processes that put themselves into background via double-fork and setsid (or equivalent) as opposed to letting supervisor do the processes management. The thing with signals and PIDs on unix is it's racy and the only process that can safely send a signal (in absence of freezer cgroup or similar platform-specific mechanism) is the direct parent as the kernel doesn't reuse the PID until wait() has been called from it. Comment deleted
ah, I see Comment deleted
I don’t get why it is a bad practice a separate low footprint process is useful for chat type apps to poll for new notifications. Instead of loading up a whole electron framework with chromium Comment deleted
Bad practice I was talking of was running background processes without any kind of supervision, relying only on not very robust mechanism of writing down process id in a plain file. Of course daemon processes are useful and they were here since the start of UNIX. Comment deleted
Loool okay well thats not how its supposed to be done Comment deleted
That's how it has been done since the inception though, many textbooks cover it, for example otherwise excellent APUE. It wasn't until DJB made daemontools that supervision started to be looked at as an option. And it took literal decades of disbelief and flamewars. Comment deleted
In other words process consists of one or more threads of execution that share resources, while processes are generally isolated. Incidentally on Windows the scheduler and memory manager was so bad they had to cram most backround services into few (daemon) processes called svchost.exe that load dynamic libraries for each service and run them as threads. This is really horrible for reliability as any error or fault will bring or possibly silently corrupt the whole thing. Comment deleted
Unless the OS can do that with a Push Notification service Comment deleted