The ids don't seem to be Unix process ids, more like an internal array index. Why doesn't it report the true process ID?
The problem with all of those managing software is complexity and feature creep. A sane /sbin/init running as process 1 fits on a page of A4 paper, without resorting to unreadably small letters: Re^14: CPAN failed install
And I would prefer to have a tiny init, too stupid to crash. Why? Because if init crashes, you are f***ed. init MUST NOT CRASH. Adding a lot of dependencies adds a lot of ways to crash. init has one job, and it is in its name: It must initialize the system. Keeping it running is the job of other programs. These programs should not crash, but if they do, init will restart them.
Want to have some fun? Disturb the connection between systemd and dbus. Hope and pray that your data survives that: Re: How not to implement updaters. It is almost like hitting the reset button on a running system, but via SSH.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
”…don't seem to be Unix process ids…Why doesn't it report the true process ID?”
Yes i know, that's a bit of a pity. I don't know why they don't do that either.
karl@rantanplan:~/src/perl$ ps aux | grep [p]erl
karl 773100 0.0 0.0 13740 8056 ? Ss Apr13 0:00 perl /home/karl/src
+/perl/soc.pl
On the whole, I agree with you - but the features are really not bad. Unfortunately, you don't like features 😎🤪 A while ago I experimented a bit with Node and PM2 - the cluster capability impressed me a bit - I have to say. That's the reason I came across this tool.
| [reply]
[d/l] |
Unfortunately, you don't like features 😎🤪
I do, but I don't like them in critical processes / systems. An init that is too stupid to crash keeps the system running better than an everything-and-the-kitchen-sink init that itself depends on at least one other process, and containing an ever-increasing crapload of features. See Re: How not to implement updaters.
Having a fileserver that is unable to shut down because the f***ing init replacement has lost its ability to receive the shutdown command is not fun. It's worse enough if it happens to the fileserver containing your valuable collection of p*rn holiday images. But it is a nightmare if it happens to the company's fileserver. Yes, there is a daily backup. Created during the previous night. In the worst case, you loose an entire work day of the entire company. Plus at least one day to restore the backup. At that point, the inventor of this really great software was very lucky to be far away from me.
Oh, by the way: The fileserver runs in a virtual machine. Imagine the "fun" if you can't shut down a VM host running several VMs. Imagine the "fun" if NUT can't cleanly shut down the VM host because the UPS battery is almost empty, and the f***ing init process can't receive the shutdown command. Imagine the "fun" to restore the VM host and all VMs running on that machine. A "fun" week of restoring backups, in the worst case. Plus nobody being able to work with those VMs.
My idea of fun is very different from that. That's why I prefer a small and stupid init. There is plenty of room for tons of features in the management processes started by init.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |