Instead of straight removal, I'd try to find an adequate macro to put around that code: something like #ifndef __SYSTEMD__ (pseudo-code, I don't know if this actually exists) to avoid potentially breaking other init systems.

Do others actually need this? And how did the old code manage this?

I think this is the historical way of doing "daemons" processes. Maybe what's needed for systemd is the "-n" CLI argument.

Do others actually need this? And how did the old code manage this?

The old code ran daemon(), which isn't supported everywhere and is nonstandard, so for that reason I (basically) reimplemented it. Or, at least, tried to.

I notice I don't actually ship a systemd unit file upstream, but for Debian I have this:

[Unit]
Description=Network Block Device server
Documentation=man:nbd-server(1)
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
ExecStart=nbd-server
ExecReload=kill -HUP $MAINPID
PIDFile=nbd-server.pid
NoNewPrivileges=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target

... and that seems to work for me (I think the crucial bit is the "PIDFile" part).

I don't think this is working incorrectly (other than adding conditional code to notify systemd, but yuck), so I think closing this bug seems like the right thing to do?

If I'm missing something, please do let me know.

The old code ran daemon(), which isn't supported everywhere and is nonstandard, so for that reason I (basically) reimplemented it. Or, at least, tried to.

Well, yes. But looks like that did work without double fork as well.

I notice I don't actually ship a systemd unit file upstream, but for Debian I have this:
[snip]
... and that seems to work for me (I think the crucial bit is the "PIDFile" part).

This is the unit file we have for Arch Linux:
https://gitlab.archlinux.org/archlinux/packaging/packages/nbd/-/blob/4b97b2724423c70994e8d2443fa743024cd2c7c8/nbd.service

... and you are right, we do not have PIDFile in there.

Either way... Having an upstream unit file would be great.

I don't think this is working incorrectly (other than adding conditional code to notify systemd, but yuck), so I think closing this bug seems like the right thing to do?

I will give this a try when I have some spare time, stay tuned.

But anyway... Even if it works (mostly?) - I think the current code is racy. After fork() the parent does exit() immediately. So chances are that it is gone (and stops the service) before the child has written its pidfile. No idea how likely this is, though.

Just testing with your (Debian) unit file. It does start successfully, but systemd logs:

systemd[1]: nbd.service: Supervising process 87468 which is not our child. We'll most likely not notice when it exits.

The given pid is from the grandchild. I guess you see this in Debian as well?