pid 1 design
 

On 08/09/2012 04:02 PM, Peter Stuge wrote:
> Luca Barbato wrote:
>> Repeat after me: having your first process require anything more
>> than libc is stupid and dangerous.
>
> Why do you say?

Because libc supposedly should be stable, other libraries are a bit more
prone to radical changes and other annoyances. You wouldn't like to
reboot your system if you replace/update dbus or glib, do you?

> And why is libc different from other libraries, say libuuid or
> libext2fs? I mean: Why allow pid 1 to require libc, it could
> just be statically linked.

Actually statically linked initial process would be another reason why
you'd like to NOT use large libraries and in large number.

Obviously if you are thinking about desktop and not system in which
replacing kernels should be done w/out downtime (qnx and some linux
patches let you do that) it isn't a huge concern.

Yet I'm not used to have to reboot after issuing emerge -u world and
most of the times I don't have even to restart X...

lu

pid 1 design
 

On Thu, Aug 9, 2012 at 11:25 AM, Rich Freeman <rich0@gentoo.org> wrote:
> ...have an init as PID=1 that does
> nothing but launch systemd and keep it propped up until it gets a
> signal from systemd. However, that could have issues I'm just not
> thinking of.

I'm not the maintainer, but this method does seem to work pretty well
for OpenRC and our old friend baselayout-1 (so, the last decade or so,
as I understand it).

pid 1 design
 

On Thu, Aug 9, 2012 at 12:00 PM, Wyatt Epp <wyatt.epp@gmail.com> wrote:
> On Thu, Aug 9, 2012 at 11:25 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> ...have an init as PID=1 that does
>> nothing but launch systemd and keep it propped up until it gets a
>> signal from systemd. However, that could have issues I'm just not
>> thinking of.
>
> I'm not the maintainer, but this method does seem to work pretty well
> for OpenRC and our old friend baselayout-1 (so, the last decade or so,
> as I understand it).

Yes, but OpenRC basically just launches processes and considers itself
done with them. Systemd is a bit more like a shepherd, looking after
things for their entire lifecycle. When you use openrc to stop a
process it just runs a script which is responsible for cleaning up.
If you stop a systemd service it can try nicely first, but if any
descendant of the service is left running it will be cleaned up with a
vengeance. If a process is supposed to be running and stops, systemd
can restart it (which makes it more like init - which restarts
anything in inittab if it dies).

Systemd isn't a like-for-like replacement for traditional inits. It
aims to be much more, so this is a bit of an apples-to-oranges
comparison. Again, I'm not sure that it HAS to work the way it does,
but I wouldn't dismiss their design simply because it is different.
Also again, if curious I'd probably ask on their own list, assuming it
hasn't already been answered there.

Rich

pid 1 design
 

On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote:
> Yet I'm not used to have to reboot after issuing emerge -u world and
> most of the times I don't have even to restart X...

What if sysvinit is updated as part of that emerge -u world? Don't you
reboot then?

William

pid 1 design
 

Ok folks, I hit the wrong key; this was meant to go to the list.

On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote:
> Yet I'm not used to have to reboot after issuing emerge -u world and
> most of the times I don't have even to restart X...

What if sysvinit is updated during that emerge -u world? Don't you
reboot then?

William

pid 1 design
 

Rich Freeman wrote:
> Systemd is a bit more like a shepherd, looking after things for
> their entire lifecycle.

This is a big part of why it is so useful.

I threw out init scripts because it was retarded to not monitor
long-running processes on servers.

Those processes shouldn't fail, but sometimes they do anyway.

sysvinit does the monitoring already and I wanted to write my own
monitoring solution sometime in the 90s, until I found daemontools
which did exactly what I wanted to do, and in a way quite similar
to how I would have implemented it. Win. o/


> Systemd isn't a like-for-like replacement for traditional inits.
> It aims to be much more, so this is a bit of an apples-to-oranges
> comparison.

Yes, it is much more, which is a very nice thing on the systems
it supports. I believe systemd is not usuable at all outside Linux
and will not likely ever be, so for prefix there will anyway always
be systemd alternatives in Gentoo! And on those systems the service
files should never be installed.


> Again, I'm not sure that it HAS to work the way it does

I would say that it does, because it is required in order to
accomplish what systemd wants to deliver.


//Peter

pid 1 design
 

On Thu, 9 Aug 2012 22:27:37 +0200
Peter Stuge <peter@stuge.se> wrote:

> Rich Freeman wrote:
> > Systemd is a bit more like a shepherd, looking after things for
> > their entire lifecycle.
>
> This is a big part of why it is so useful.
>
> I threw out init scripts because it was retarded to not monitor
> long-running processes on servers.
>
> Those processes shouldn't fail, but sometimes they do anyway.
>
> sysvinit does the monitoring already and I wanted to write my own
> monitoring solution sometime in the 90s, until I found daemontools
> which did exactly what I wanted to do, and in a way quite similar
> to how I would have implemented it. Win. o/

I still remember using djbdns for a while. I especially threw away
the daemontools part of it and wrote openrc scripts to not have 20
additional processes to run a tiny DNS server.

> > Systemd isn't a like-for-like replacement for traditional inits.
> > It aims to be much more, so this is a bit of an apples-to-oranges
> > comparison.
>
> Yes, it is much more, which is a very nice thing on the systems
> it supports. I believe systemd is not usuable at all outside Linux
> and will not likely ever be, so for prefix there will anyway always
> be systemd alternatives in Gentoo! And on those systems the service
> files should never be installed.

Considering that systemd unit files are sometimes shipped with upstream
packages, and often they are practically equivalent to openrc init
scripts, I'd rather see openrc supporting that file format
as an extension and using it instead of duplicating the same thing
in init.d scripts.

And yes, that means that people masking service files shoot themselves
in the foot.

Also, if I had more time (or support), I'd probably start working
on a systemd-compatible init system with a more portable design.

> > Again, I'm not sure that it HAS to work the way it does
>
> I would say that it does, because it is required in order to
> accomplish what systemd wants to deliver.

Not necessarily. You can move many 'extra' systemd features outside of
PID 1. For example, unit dependency trees are complex by definition
and practically not necessary for PID 1.

In other words, it could be designed to move more complex (and thus
risky) tasks outside of PID 1.

--
Best regards,
Michał Górny

pid 1 design
 

On Thu, Aug 9, 2012 at 4:37 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Thu, 9 Aug 2012 22:27:37 +0200
> Peter Stuge <peter@stuge.se> wrote:
>
>> Rich Freeman wrote:

[snip]

>> > Systemd isn't a like-for-like replacement for traditional inits.
>> > It aims to be much more, so this is a bit of an apples-to-oranges
>> > comparison.
>>
>> Yes, it is much more, which is a very nice thing on the systems
>> it supports. I believe systemd is not usuable at all outside Linux
>> and will not likely ever be, so for prefix there will anyway always
>> be systemd alternatives in Gentoo! And on those systems the service
>> files should never be installed.
>
> Considering that systemd unit files are sometimes shipped with upstream
> packages, and often they are practically equivalent to openrc init
> scripts, I'd rather see openrc supporting that file format
> as an extension and using it instead of duplicating the same thing
> in init.d scripts.
>
> And yes, that means that people masking service files shoot themselves
> in the foot.
>
> Also, if I had more time (or support), I'd probably start working
> on a systemd-compatible init system with a more portable design.

I would find this very interesting. I doubt I could find time for much
active contribution, unfortunately, but I'd help where I could.

>
>> > Again, I'm not sure that it HAS to work the way it does
>>
>> I would say that it does, because it is required in order to
>> accomplish what systemd wants to deliver.
>
> Not necessarily. You can move many 'extra' systemd features outside of
> PID 1. For example, unit dependency trees are complex by definition
> and practically not necessary for PID 1.
>
> In other words, it could be designed to move more complex (and thus
> risky) tasks outside of PID 1.

+1

--
:wq

pid 1 design
 

On Thu, 9 Aug 2012 12:30:54 -0500
William Hubbs <williamh@gentoo.org> wrote:

> Ok folks, I hit the wrong key; this was meant to go to the list.
>
> On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote:
> > Yet I'm not used to have to reboot after issuing emerge -u world and
> > most of the times I don't have even to restart X...
>
> What if sysvinit is updated during that emerge -u world? Don't you
> reboot then?
>
> William
>

# telinit U

(also works for libc replacement, and it’s actually done automatically
by the sysvinit ebuild)

Chris

pid 1 design
 

On Thu, 9 Aug 2012 16:45:28 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Thu, Aug 9, 2012 at 4:37 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > On Thu, 9 Aug 2012 22:27:37 +0200
> > Peter Stuge <peter@stuge.se> wrote:
> >
> >> Rich Freeman wrote:
>
> [snip]
>
> >> > Systemd isn't a like-for-like replacement for traditional inits.
> >> > It aims to be much more, so this is a bit of an apples-to-oranges
> >> > comparison.
> >>
> >> Yes, it is much more, which is a very nice thing on the systems
> >> it supports. I believe systemd is not usuable at all outside Linux
> >> and will not likely ever be, so for prefix there will anyway always
> >> be systemd alternatives in Gentoo! And on those systems the service
> >> files should never be installed.
> >
> > Considering that systemd unit files are sometimes shipped with
> > upstream packages, and often they are practically equivalent to
> > openrc init scripts, I'd rather see openrc supporting that file
> > format as an extension and using it instead of duplicating the same
> > thing in init.d scripts.
> >
> > And yes, that means that people masking service files shoot
> > themselves in the foot.
> >
> > Also, if I had more time (or support), I'd probably start working
> > on a systemd-compatible init system with a more portable design.
>
> I would find this very interesting. I doubt I could find time for much
> active contribution, unfortunately, but I'd help where I could.

Well, the sad thing is that I don't really have much expertise in this
area. I like the philosophy of designing many smalls things which just
work well together, so I would probably start that by reinventing some
helper tools.

It would be most helpful to get some aid from OpenRC team. I believe
that some common-use tools written for the project could be used
and tested in OpenRC first. And that way, slowly a new init system
could enter the world.

Sadly, it would be strictly bound to file formats and names set by
systemd team.

--
Best regards,
Michał Górny