:: Re: [DNG] OpenRC: was s6-rc, a s6-…
Top Page
Delete this message
Reply to this message
Author: Timo Buhrmester
Date:  
To: Steve Litt
CC: dng
Subject: Re: [DNG] OpenRC: was s6-rc, a s6-based service manager for Unix systems
> OpenRC? I just don't get it.
OpenRC is twisted because Linux people [are said to] not understand BSD;
Here's a median-length rc.d script (the one for inetd)
| #!/bin/sh
| #
| # $NetBSD: inetd,v 1.7 2004/08/13 18:08:03 mycroft Exp $
| #
|
| # PROVIDE: inetd
| # REQUIRE: DAEMON LOGIN
| # KEYWORD: shutdown

N.B. These comments having a special meaning is the entirety of what you
call "a special language that's confusingly almost but not quite /bin/sh"
Bit of a stretch, if you ask me.
|
| $_rc_subr_loaded . /etc/rc.subr
|
| name="inetd"
| rcvar=$name
| command="/usr/sbin/${name}"
| pidfile="/var/run/${name}.pid"
| required_files="/etc/${name}.conf"
| extra_commands="reload"
|
| load_rc_config $name
| run_rc_command "$1"


That's it.

> It can't respawn

Probably because people don't want this behavior. Auto-respawn only
makes sense when you're "relying" on buggy software you already expect
to blow up, *and* are unwilling to debug it. "Try turning it off
and on again", "A restart will fix it" is the Windows-way...

In all other cases (I can think of), respawning a crashed service
is exactly *not* what I want to happen (it could have crashed because
it was exploited, providing the attacker with unlimited attempts).
Or it could have crashed because there's an environmental problem
that isn't directly under the program's control, in which case
restarting it would just be pointless, because it likely can't start
at all.
Bonus points if the logs of the initial problem get rotated away due to
excessive retrying, or the core dump of the initial crash gets
overwritten...

Just my 2ct