[gentoo-dev] OpenRC supporting systemd units

[gentoo-dev] OpenRC supporting systemd units

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

On Wed, May 08, 2013 at 07:07:17PM +0200, Michał Górny wrote:
> It is quite likely that OpenRC will start supporting unit files soon.
> Then in many cases we will be able to strip down this to just one init
> format which would satisfy both init systems.

Do you want to fill me in? ;-) I haven't seen or heard of any work to
make this happen.

OpenRC can't support units directly; if this ever did happen it would
have to be a tool that converts units to init scripts.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] OpenRC supporting systemd units

[Rich Freeman]

On Wed, May 8, 2013 at 2:32 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> OpenRC can't support units directly; if this ever did happen it would
> have to be a tool that converts units to init scripts.

Or an init script skeleton that interprets a unit file.  That seems
like it shouldn't be too hard to write for a limited number of systemd
features.  Just point the conf.d file to the unit file, or use a
convention for where the init.d script looks for the unit.

Init.d scripts are programs - they could probably do just about anything.

Rich

Re: [gentoo-dev] OpenRC supporting systemd units

[Ambroz Bizjak]

> Init.d scripts are programs - they could probably do just about anything.

They couldn't monitor a process and restart it when it crashes, as
specified by the restart options in the unit file. That is, without
significant modifications in the way OpenRC works, such as adding a
monitoring process, or hacks such as launching a daemon that monitor
that process specifically.

On Wed, May 8, 2013 at 8:45 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, May 8, 2013 at 2:32 PM, William Hubbs <williamh@gentoo.org> wrote:
>>
>> OpenRC can't support units directly; if this ever did happen it would
>> have to be a tool that converts units to init scripts.
>
> Or an init script skeleton that interprets a unit file.  That seems
> like it shouldn't be too hard to write for a limited number of systemd
> features.  Just point the conf.d file to the unit file, or use a
> convention for where the init.d script looks for the unit.
>
> Init.d scripts are programs - they could probably do just about anything.
>
> Rich
>

Re: [gentoo-dev] OpenRC supporting systemd units

[Jeroen Roovers]

On Wed, 8 May 2013 20:55:35 +0200
Ambroz Bizjak <ambrop7@gmail.com> wrote:

> > Init.d scripts are programs - they could probably do just about
> > anything.
> 
> They couldn't monitor a process and restart it when it crashes, as
> specified by the restart options in the unit file. That is, without
> significant modifications in the way OpenRC works, such as adding a
> monitoring process, or hacks such as launching a daemon that monitor
> that process specifically.

Sounds like a great feature. A crashed process is a buggy one, and I
would want to investigate said program before I relaunched it, and not
have it automatically relaunched as if nothing had happened.


     jer

Re: [gentoo-dev] OpenRC supporting systemd units

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Wed, 8 May 2013 13:32:01 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Wed, May 08, 2013 at 07:07:17PM +0200, Michał Górny wrote:
> > It is quite likely that OpenRC will start supporting unit files soon.
> > Then in many cases we will be able to strip down this to just one init
> > format which would satisfy both init systems.
> 
> Do you want to fill me in? ;-) I haven't seen or heard of any work to
> make this happen.

http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2013/Ideas/OpenRC_Improvements

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] OpenRC supporting systemd units

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On 05/08/2013 03:18 PM, Jeroen Roovers wrote:
> On Wed, 8 May 2013 20:55:35 +0200
> Ambroz Bizjak <ambrop7@gmail.com> wrote:
> 
>>> Init.d scripts are programs - they could probably do just about
>>> anything.
>>
>> They couldn't monitor a process and restart it when it crashes, as
>> specified by the restart options in the unit file. That is, without
>> significant modifications in the way OpenRC works, such as adding a
>> monitoring process, or hacks such as launching a daemon that monitor
>> that process specifically.
> 
> Sounds like a great feature. A crashed process is a buggy one, and I
> would want to investigate said program before I relaunched it, and not
> have it automatically relaunched as if nothing had happened.

That's highly, highly, highly use-case dependent. If it's a non-critical
service, or in a non-critical environment, that's one thing. If it's a
service whose downtime can be measured in value lost, that's quite another.

I've had setups where, yes, I had it respawn. But I also wanted it to
send me a core dump so I could investigate. Were I in that circumstance
again, I'd automate collection and analysis of the dumps to produce heat
maps for me.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] OpenRC supporting systemd units

[Chí-Thanh Christopher Nguyễn]

Jeroen Roovers schrieb:
> Sounds like a great feature. A crashed process is a buggy one, and I
> would want to investigate said program before I relaunched it, and not
> have it automatically relaunched as if nothing had happened.

Even worse if it keeps on thinking that the process has crashed when it
actually hasn't. Then it launches another instance, effectively creating a
forkbomb.

Though proper use of cgroups does prevent this.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] OpenRC supporting systemd units

[Rich Freeman]

On Wed, May 8, 2013 at 2:55 PM, Ambroz Bizjak <ambrop7@gmail.com> wrote:
>> Init.d scripts are programs - they could probably do just about anything.
>
> They couldn't monitor a process and restart it when it crashes, as
> specified by the restart options in the unit file. That is, without
> significant modifications in the way OpenRC works, such as adding a
> monitoring process, or hacks such as launching a daemon that monitor
> that process specifically.

Sure. I doubt anybody is suggesting that OpenRC would expand the full
feature set of systemd anyway (if it did the people who don't want to
use systemd would likely fork it back to where it is now anyway).

A unit can support dozens of options, but for the most part you can
get by with just a few.  I'm sure any support across the two systems
would start with the few features that get people 90% of the way
there.

If somebody wants to have their processes propped up, they can install
systemd.  Ditto for launching daemons in containers, implementing
xinetd, and all the other bells and whistles systemd offers.

All we really need to get working from a basic usability standpoint is
stuff like what to launch, what UID/niceness/etc to use, and what the
deps are - the stuff in the typical skeleton init.d script.  Really
all you need is some code at the top of the existing init.d script
that just populates some environment variables based on values
translated from the unit file and then invokes the typical current
logic.

The biggest issue I'd see would be around dependency translation.
Assuming our units use the same names as our existing package init.d
scripts (likely) that isn't a problem in most cases, but dependencies
on targets/etc in systemd might need a little handling.  I'm not
really a systemd guru yet so I'm sure I'm oversimplifying, but as long
as any translation focuses only on what openrc already supports it
shouldn't be a big problem.

Rich

Re: [gentoo-dev] OpenRC supporting systemd units

[Chí-Thanh Christopher Nguyễn]

Michael Mol schrieb:
>> Sounds like a great feature. A crashed process is a buggy one, and I 
>> would want to investigate said program before I relaunched it, and
>> not have it automatically relaunched as if nothing had happened.
> 
> That's highly, highly, highly use-case dependent. If it's a
> non-critical service, or in a non-critical environment, that's one
> thing. If it's a service whose downtime can be measured in value lost,
> that's quite another.

You could be looking at someone trying to compromise your system through a
buffer overflow or similar vulnerability. If you enable automatic respawn
then congratulations, you just gave the attacker unlimited tries to guess
the correct address/offset for his exploit.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] OpenRC supporting systemd units

[Rich Freeman]

On Wed, May 8, 2013 at 4:06 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> You could be looking at someone trying to compromise your system through a
> buffer overflow or similar vulnerability. If you enable automatic respawn
> then congratulations, you just gave the attacker unlimited tries to guess
> the correct address/offset for his exploit.

Hence the reason it is highly use-case dependent.  The same could be
said of inittab restarting agetty indefinitely.

You can configure rate-limiting on restarts, etc.

Somebody mentioned fork-bombs and cgroups.  From what I can read when
a systemd restarts something it first stops it and then starts it.
Stopping a unit by default involves sending SIGTERM followed by
SIGKILL to the cgroup.  In general your processes won't be getting
away unless they're root and manipulating such things.

Much of the systemd behavior is configurable though - you could
configure a unit to only kill the "main" process, and for that matter
you can configure how systemd figures out the PID of the "main"
process.

This is getting a bit off-topic though.  I doubt anybody is going to
want default behavior on a systemd unit to be to auto-restart, unless
you're talking about stuff that already goes into inittab.  If anybody
wants stuff to auto-restart they'll edit their unit files (so files in
/etc should override files elsewhere, or they should get config
protection).

Rich

Re: [gentoo-dev] OpenRC supporting systemd units

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

On 05/08/2013 04:06 PM, Chí-Thanh Christopher Nguyễn wrote:
> Michael Mol schrieb:
>>> Sounds like a great feature. A crashed process is a buggy one, and I 
>>> would want to investigate said program before I relaunched it, and
>>> not have it automatically relaunched as if nothing had happened.
>>
>> That's highly, highly, highly use-case dependent. If it's a
>> non-critical service, or in a non-critical environment, that's one
>> thing. If it's a service whose downtime can be measured in value lost,
>> that's quite another.
> 
> You could be looking at someone trying to compromise your system through a
> buffer overflow or similar vulnerability. If you enable automatic respawn
> then congratulations, you just gave the attacker unlimited tries to guess
> the correct address/offset for his exploit.

Without respawn, you're already bending over and taking a DoS. And when
you're in a situation where service uptime is a cap on  revenue, uptime
is pretty darn important.

That's not to say analyzing the crash isn't important, but if I allowed
a prod service to remain down while I investigated a crash, studied the
problem, evaluated a fix for correctness and lack of regressions,
scrubbed the fix and tried again, I wouldn't have that job for very long!

Certainly there are environments where it's sensible to take things slow
while you investigate (OpenVPN crashed? ssh crashed?), but there are
environments where that's not the case, too. It depends on your threat
model and a variety of cost/analysis factors. That's why I said "highly,
highly, highly use-case dependent."

If upstream provides a unit file, and that unit file specifies a
behavior, you should (by default) trust the upstream. If you don't like
what upstream does, convince them to change. If they won't, make your
changes locally. If it's _really_ bad, obviously you have an interesting
position as a dev in a distribution, and you might make your change
there, but that certainly shouldn't be your default course of action.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] OpenRC supporting systemd units

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]

Michael Mol wrote:
> obviously you have an interesting position as a dev in a distribution,
> and you might make your change there, but that certainly shouldn't be
> your default course of action.

+1 and not just for unit files.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

[gentoo-dev] Re: OpenRC supporting systemd units

[Steven J. Long]

Ambroz Bizjak wrote:
> Rich Freeman wrote:
> > Init.d scripts are programs - they could probably do just about anything.
> 
> They couldn't monitor a process and restart it when it crashes, as
> specified by the restart options in the unit file. That is, without
> significant modifications in the way OpenRC works, such as adding a
> monitoring process, or hacks such as launching a daemon that monitor
> that process specifically.

Actually a shell script can do that very easily, given a daemon that either
doesn't self-background, or can be given a switch to tell it not to "daemonize",
which reasonably modern services should support. See Q: 3.2 here:
  http://mywiki.wooledge.org/ProcessManagement (the linked "Wrapper Script" page
is interesting as well.)

That's assuming you don't want a simple respawn in inittab. Another common
loop is:

until somesrv -f "$blah"; do
	e=$?
	# stuff on abnormal termination, check situation etc
	all_ok || exit # exits $?, or use $e or 1..
done
# svc terminated normally
:
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)