[a-dub]

actually no. there are a bunch of properties to properly daemonize in unix. things like special handling for stdin/stdout/stderr, reparenting, signal handling... look it up.

classic rookie mistake to just call a program that doesn't exit a daemon...

proper daemons can stay up for years.

[megous]

Infinite loop will stay up for years too.

Running "in the background", handling of stdin/out/err, logging, detaching from tty, creating a new process group/session, closing fds, and much more is handled these days mostly by systemd. No need to put all this into your program at all.

I'll give you that signal handling still needs to be done in the target process, if the defaults don't satisfy you.

But you really don't need anything special anymore to make any old script into a daemon.

[a-dub]

so if your daemon is ever started by hand or is used on a system without systemd it won't work correctly? that doesn't sound great.

[megous]

Only time I'm starting daemon by hand is to debug it. So having it stay in foreground and log to console is good in that case.

[a-dub]

so if someone else starts it by hand it won't work correctly?

if someone else runs it on a system without systemd it won't work correctly?

[megous]

Why would it not work correctly?

Without systemd you can use daemonize from shell, for example. I either run these kinds of service scripts via systemd in production, or via my special program that takes care of starting and monitoring, and restarting when the code of the script changes.

Why should I stuff daemonization machinery into every single script I might want to run as a daemon, especially when it's cumbersome in many languages where I want to do it, like bash or PHP, and in general less flexible than using some external tool?

[a-dub]

maybe you're right. shrug. does your script change the working directory? do all systems have fancy core file management now? does it still cause issues with unmounting?

it is true that it's rare to see a daemonize flag these days...