No, there is not requirement to use PID files. That is simply a common way to implement a daemon. With sysvinit and sysvrc (or OpenRc), this kind of thing is an implementation detail that is out of scope.
Of course. Keeping track of running services is out of scope for a service management system. Genius.
It seems to me that the reason why pid files still exist is because sysv provides next to nothing, so people end up using the easiest, but about the worst approach available.
Patently incorrect, as I have used syslog to inspect startup crashes many times over the last *twenty years* I've been using UNIX. Maybe this has been a problem for other people, but I've never seen it. If your syslog is configured badly, that's an entirely separate problem.
Not startup. Crashes, as in segfaults. Those of course don't get logged since sysv doesn't monitor what it runs. Add the wonders of pid files to that and you get a service that sometimes needs to be fixed by hand to be restarted.
Also note that I'm talking about the init system, and not about individual services doing their own logging.
While I can't speak for all distributions (you seem to have had some history with poorly-configured environments), there is nothing wrong with using sleep based polling. The only reliable way to detect if a prerequisite service is ready is by directly polling the service. (e..g issue an HTTP GET to a web server) The timeout is to allow startup to proceed in case of an error, (so you don't end up bricked, unable to use your computer)
No, no polling. Just a plain "sleep 5" in a script that hopes that the service it depends on has time to properly get started in time. I sure hope no distribution ships this kind of crap anymore, but I seem to run into such hacks annoyingly often for some reason.
There is a reason most distributions stopped using super-servers like xinetd: on-demand startup isn't that useful. Start your service at boot. You can defer expensive tasks until the first requests, if you want, which is when you would pay that cost anyway in an "on demand" launch. Listen to on the port, block on accept(2) or select(2) or similar, and let the OS page you out to the swap partition.
Of course it's useful. Why should something like cups get started without a printer? Why should the user know to enable it once they get one? These days hardware changes at runtime, and things are expected to work when you plug in a printer or a bluetooth adapter, and not to complain or stop booting if some hardware turns out not to be there anymore.
Want to have some fun? On a systemd box, pretend you just installed some updates, and you need to restart a few daemons so they run the updated versions. Try restarting dbus (system, not user). (You might want to make sure any open files are saved first)
I get a slightly ugly message from systemctl, but other than that everything seems to be working fine. Restarted it a couple times just to be sure, checked that yep, the pid changes.
Also, you might want to actually read about UNIX before you make these kinds of accusations.
I speak from personal experience
Reading taoup is a good place to start.
Thanks, but I'm not religious. I prefer things that are convenient to those that are ideologically pure.