Re: init spawning multiple cf-execd processes at once
On 07/21/2014 04:56 PM, Steve Litt wrote:
Did it for years, using runit-init (ie, the debian package that made
runit overtake sysvinit), until I noticed that the package no longer
existed; it worked like a charm, I simply never even remembered it
existed except on upgrades.
On Mon, 21 Jul 2014 14:39:16 +0200
Jimmy Thrasibule <email@example.com> wrote:
I've added a new line to the /etc/inittab file to monitor the CFEngine
daemon and restart it in case this one dies.
The cf-execd is re-spawned as expected, except the fact that multiple
processes are created at once.
I therefore have about 20+ cf-execd processes running where I only
Any idea what's causing this and how to solve it?
I have absolutely no idea.
But the systemd threads have all gotten me thinking: What if I were to
start my daemons with djb's daemontools?
I have no idea how much time you do or don't have, but if you're
interested/curious and have the time, you might try runnning cf-execd
from daemontools. One of the beauties of daemontools is you basically
make a shellscript to run the program in the foreground, wrap it with a
couple daemontools things, and bang, it's a daemon. Daemontools has
programs called svc and svstat to control and monitor your daemons.
Daemontools shellscripts are tiny and obvious, not the monstrosities
in the current (for Wheezy) init system.
Another thing that's cool is that with Daemontools' method of linking,
you can back up your entire Daemontools system, and nothing but the
Daemontools system, by backing up one tree. No more clobberation when
you wipe clean and install a later or different Linux version.
One thing I like about Daemontools is that, after 10 minutes of working
with it, you *know* it's written by a guy who loves Unix. All data
relationships are expressed in directory structures and small files. It
depends on nothing, and nothing depends on it. It makes sense.
Obviously, this is only practical for people who are facile with Linux
at the configuration and shellscript level. I would never recommend
this as the default. But for guys like us, it just might work.
I know my email doesn't address the root cause of your problem, but
given the way things are going, you've gotta wonder how long you'll be
able to put stuff in inittab, compatibility or not.
Right now I'm extremely busy for the next 2 weeks, but after that I
think I'm going to start turning off some of my daemons and instead
running them from Daemontools. Actually, I had been tempted to do that
long before the advent of systemd: It's not like Upstart or "sysvinit"
or whatever the current system is called were all that great either.
Thanks for the idea!
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
The advantage of runit over daemontools is that runit explains clearly
how to make sure that things go smoothly (ie, if eg apt-get upgrade
tries to run a /etc/init.d/foo, hijack the request to /service/foo), but
if you really wanted to you could quite easily use the same approach for
daemontools, s6, whatever.
The disadvantage is that I'm not sure if it plays nice with debian's
parallel startup, and you'll have to take care of things yourself anyway.
Imho it's a lot easier on the *BSDs: since they never ever
start/stop/restart anything by default, you get the daemontools running,
write your scripts and never again have to worry about dpkg-divert &
If you try, please let us know.