i must say though, i'm not sure how i feel about a shell script "daemon"...

Daemon is just something running in a loop.

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.

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.

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.

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.

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?

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?

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...

This all depends on what the program does. If you have some app specific service that waits for postgresql NOTIFY messages, and does something in response, it doesn't matter that working dir is not /. You just stop the service and perform maintenance.

If it's something like sshd, it better not prevent any filesystems from umounting unless necessary.

Why? This is not a completely novel concept, and a daemon is not a particularly complicated thing. You can use shell scripts to easily "daemonize" small programs. It's both fun and effective to do so.