On Tue, Jan 11, 2022 at 01:15:05PM +0100, Andrei POPESCU wrote: > On Lu, 03 ian 22, 14:02:05, Roy J. Tellason, Sr. wrote: > > In the one that was running to start with, the command line shown to > > me in system monitor includes "daemonize=no". I would guess that to > > be the problem, but why is that in there?
You need to rewind quite a few years of history for a full answer to this. > In general it's recommended programs rely on systemd for running in > background instead of implementing their own code for that (re-inventing > the wheel and all that). > > Of course, some programs (including PulseAudio) predate systemd and/or > need to run on systems / platforms where systemd (or something > compatible) is not even available, so they will continue to support both > methods. Imagine that you're sitting down at a Unix workstation back in the 1980s or 1990s. There's no systemd, no dbus, no CORBA, nothing at all like that. You probably login via xdm, and you get an X11 session with a single xterm and twm as your window manager. That's it. That's your whole session. Nothing else is running -- just the X server, the window manager, and a single terminal. Now, you'd like to run a few more things. So you focus on the terminal and you start running some commands: xclock & xbiff & xterm -e top & xterm & xterm & Now you've got some additional terminals with interactive shells in them, and some programs that give you information. If you'd like all of these programs to start next time you login, there will be some kind of dot-file that you can edit, probably ~/.xsession. You just put those commands in there, and then... whoops, you forgot to put your window manager! So, you login remotely, fix the ~/.xsession file so that it ends with "exec twm" or whatever, and you're good to go. Do you see how all of the commands that you wanted to run end with "&" so that they will be placed in the background by the shell? There's nothing wrong with that at all, but it will become relevant in a moment. Next, imagine that you're the system administrator of a Unix workstation back in the 1980s or 1990s. You'd like to run some programs at boot time -- maybe one of those fancy Internet mail transport programs like sendmail! After reading manuals for a few hours, you manage to get sendmail installed and configured, and now that it's time to run it, you put some command like this into /etc/rc.local: /usr/lib/sendmail & And... it works, maybe. You've applied your knowledge of the shell to a system administration problem. Only, maybe it doesn't work. Maybe your particular flavor of Unix runs /etc/rc.local with a shell where background jobs are terminated after the shell exits. So, if you're on one of those systems, you cobble together a workaround: csh -cf '/usr/lib/sendmail &' And this works! But it's so ugly. But hey, this idea of programs running automatically when the system boots is starting to gain some traction. People are doing it everywhere. Literally hundreds of Unix sites around the country! So, at some point, the people who write system software like sendmail all decided to make the system administrator's life "easier", and they added options to "daemonize" themselves. Now the system administrator wouldn't have to do all that crazy shell stuff. They can simply write: /usr/lib/sendmail -bd And voila. The sendmail daemon will fork a child process, and then the parent will terminate. The abandoned child will be re-parented by the init daemon (process ID 1). The abandoned child is the real daemon, and it will continue running in the background, forever. Or until it crashes. But that's a next year problem! For a decade or two, this became the norm across BSD-like systems. Newly written daemons all decided that they should either fork and abandon a child process by default, or offer an option to do this. It became the new fad. All the cool kids were doing it. And then the problems started. Maybe you didn't *want* the same instance of sendmail to run forever. What if you edited the configuration file, and wanted to reload the daemon with the new configs? How do you do that? Well, obviously, you sit down at the console, login as root, and use commands like "ps auxw | grep sendmail" to find the daemon. Then when you've found it, you can use a command like "kill -1 2345" to send a signal to the daemon, telling it to reread the configs. Of course, finding a running process this way is an art, not a science. A human system administrator can do it. It's not all that hard, right? If Susan is sendiing mail right now, her sendmail process is going to look different from the daemon that you're trying to locate in the haystack. You'll be able to tell the difference and identify the correct process. It just takes a few moments of careful attention and effort. A computer program can't do that. So, what happens when your operating system introduces this brand new shiny "init system" that tries to unify the way daemons are started and controlled? We're solidly into the 1990s by now, or maybe the 2000s, and most systems are using a variant of the "System V init" software with "rc scripts". Basically, these things are shell scripts that take a mandatory argument like "start" or "stop". The idea is that you (the system administrator) can write one of these shell scripts and have it either start or stop the daemon. Then you drop it in a special directory, and the operating system will run it with the argument "start" at boot time, and again with the argument "stop" at shutdown time. Or you can run it yourself at any time you like, if you want to restart the daemon. But... all of the daemons are still using that faddish "-bd" style code from the 1980s. How do you write a shell script to stop a daemon that is really an abandoned child process? You'd have to find its process ID somehow. How are you going to do that? Your script doesn't have the brain power of a human being, so it can't sift through the output of "ps". People who write programs like sendmail came up with an answer to that: they told the daemon to write its PID into a file in a known location on the disk. So in an "rc script" for sendmail, you can put code like this: case $1 in start) /usr/lib/sendmail -bd ;; stop) kill `cat /var/lib/sendmail.pid` ;; esac The idea of the "PID file" became the new norm. But what happens if sendmail crashes on its own? Maybe it has a bug! (In real life, sendmail had so many bugs that it's amazing people used it for so long.) If the sendmail daemon that was started at boot time (and wrote its PID into that PID file) crashes, then the PID is freed for reuse by the adoptive parent process. You can't have a bunch of zombies walking around! So, the PID goes back in the pool, and eventually, some other program will use it. Now you've got a PID file that contains the PID of some entirely different program, which has nothing do with sendmail. Maybe it's your boss's window manager! It could be anything! This is why PID files are terrible. But they're necessary! Because all of the daemons put themselves in the background! Because that's such a stylish thing to do! As it turns out, having daemons put themselves into the background was in fact a *terrible* idea. It breaks everything else, and creates an ecosystem of workarounds. In the late 1990s and early 2000s, when System V init/rc was running rampant through the increasingly popular Linux communities, some other folks realized the issue, and started working on alternative init systems. If you'd like more details on this, I recommend JDEBP's web site. You can start at <http://jdebp.info/FGA/system-5-rc-problems.html>. In a nutshell, the alternatives to sysvinit all start out with the premise that a daemon should *not* abandon a child in the background. The daemon should simply run like a normal program, only terminating when it's told to do so, or when it encounters a fatal condition. Then, the init system can manage it like any normal program. The init system will immediately know when it terminates, and can restart it if the system administrator desires. Or, if the admin wants to restart it, the init system knows exactly which process ID to send a signal to. There's no "stale PID file" problem, because PIDs aren't written to files. Process IDs are held by the parents. Everything works so much better. But... we've still got all of these old system programs like sendmail that have -bd options. Or worse, some of them may create and abandon a child process by default! How do we deal with this mess? In some cases, you simply stop using the -bd option, or its equivalent. In other cases, maybe you have to patch the daemon to offer a new option which says *don't* create a child process -- just run normally. That's what you're seeing here with Pulse Audio. > > In the one that was running to start with, the command line shown to > > me in system monitor includes "daemonize=no". I would guess that to > > be the problem, but why is that in there? This is a program whose default behavior was to create a child process, and an option was added to tell it not to do that. Since systemd is one of the new alternative init systems that want normal daemons, it's using that option to force normal behavior. Maybe in a few more years, or decades, all of the old "daemonize by default" programs will have gone away, or will have changed their default behavior to the more sensible "don't daemonize by default" choice. Until that happens, you're going to continue to see a chaotic mix of programs that behave in different ways, with different options to control them. Welcome to Unix.
