systemd: please stop trying to take over the world :)

[Denys Vlasenko]

Hi Lennart,

systemd is eating a lot more memory than any other init process
I ever played with.

Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

systemctl --all shows 258 units total on my machine,
thus systemd uses ~40 *KILO*bytes of state per unit?

I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know. It's called "featuritis".
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Look where it is now:

Top:

Mem total:2035840 anon:431208 map:78924 free:419084
slab:91624 buf:108040 cache:942336 dirty:196 write:0
Swap total:4095996 free:4095996
PID VSZ VSZRW RSS (SHR)*DIRTY (SHR) STACK COMMAND
1818 624m 365m 185m 13472 155m 64 224 /usr/lib/firefox-4/firefox
1816 433m 189m 166m 17248 142m 0 204 evolution
1257 53672 40400 22664 6004 18336 4176 132 /usr/bin/Xorg
1 15384 11856 13664 1340 11752 0 132 /sbin/init
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ 11.7 megs of malloc space

1839 275m 40224 24208 10572 11020 0 132 /usr/bin/gnome-terminal
1713 202m 45284 20308 9736 9604 576 132 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
1843 171m 9448 20264 10012 8440 344 204 xchat
1770 152m 55672 19412 10972 6108 0 132 nautilus

It's the *fourth* largest process on my system!


# ldd `which systemd`
linux-gate.so.1 => (0x00a6b000)
libselinux.so.1 => /lib/libselinux.so.1 (0x414f6000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x41bc1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0019a000)
libudev.so.0 => /lib/libudev.so.0 (0x422c9000)
libwrap.so.0 => /lib/libwrap.so.0 (0x420fa000)
libpam.so.0 => /lib/libpam.so.0 (0x420e6000)
libaudit.so.1 => /lib/libaudit.so.1 (0x420cc000)
libcap.so.2 => /lib/libcap.so.2 (0x4152f000)
librt.so.1 => /lib/librt.so.1 (0x00be8000)
libc.so.6 => /lib/libc.so.6 (0x00295000)
/lib/ld-linux.so.2 (0x00276000)
libdl.so.2 => /lib/libdl.so.2 (0x00af6000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00f68000)
libnsl.so.1 => /lib/libnsl.so.1 (0x0095c000)
libattr.so.1 => /lib/libattr.so.1 (0x420c5000)

Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

libwrap? systemd is a network application now too?

libaudit? What systemd has in common with audit?

libdbus?... this is a lost battle I guess...

I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*

At the very least, I would like to see its memory consumption
to go down substantially.

It is an *init replacement*, not the replacement for everything.
One of init's goal is to be *simple* and *stable*.
Every new feature you add and library you link against
works against that goal.

To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...

[Michal Schmidt]

Post by Denys Vlasenko
I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know.

You're exaggerating.

Post by Denys Vlasenko
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

Post by Denys Vlasenko
libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

systemd uses libcap. libcap depends on libattr.

Post by Denys Vlasenko
libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

Post by Denys Vlasenko
libaudit? What systemd has in common with audit?

Start and stop of a service is an auditable event.
http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html

Post by Denys Vlasenko
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...

systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.

Michal

[Steve Clark]

Post by Michal Schmidt

Post by Denys Vlasenko
I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know.

You're exaggerating.

Post by Denys Vlasenko
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

Post by Denys Vlasenko
libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?

systemd uses libcap. libcap depends on libattr.

Post by Denys Vlasenko
libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

Post by Denys Vlasenko
libaudit? What systemd has in common with audit?

Start and stop of a service is an auditable event.
http://lists.fedoraproject.org/pipermail/devel/2010-August/141543.html

Post by Denys Vlasenko
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...

systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
^^^^^^^

So you just end up with a "froze" system instead of a crashed system????

Post by Michal Schmidt
Michal

--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: [phone]
Fax: [phone]
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110610/16d43148/attachment.html

[Michal Schmidt]

Post by Steve Clark

Post by Michal Schmidt
systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
^^^^^^^

So you just end up with a "froze" system instead of a crashed system????

No, only systemd freezes itself. Other processes continue running.

Michal

[Denys Vlasenko]

Post by Michal Schmidt

Post by Steve Clark

Post by Michal Schmidt
systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
^^^^^^^

So you just end up with a "froze" system instead of a crashed system????

No, only systemd freezes itself. Other processes continue running.

systemd-26/src/main.c::crash() is the function which does it.
Assuming it will not recurse by crashing again, of course. It calls
log_error and assert_se, which go into log_dispatch(), which logs to
syslog, may try to write to klog, and whatnot... this doesn't look
too robust to me.

But anyway. Assuming it successfully froze. Does it help?
Yes. How much? Well, it's better than instant oops which happens
when PID 1 exits, but reaping of processes reparented
to init will stop, which, for example, makes the hang from pid
exhaustion just a question of time.

Ultimately, this stems from the decision to make systemd
to run as PID 1 process. Are there technical reasons for this?

[mike cloaked]

Post by Denys Vlasenko

Post by Michal Schmidt

Post by Steve Clark

Post by Michal Schmidt
systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
? ? ? ? ? ? ? ? ? ? ? ? ^^^^^^^

So you just end up with a "froze" system instead of a crashed system????

No, only systemd freezes itself. Other processes continue running.

systemd-26/src/main.c::crash() is the function which does it.
Assuming it will not recurse by crashing again, of course. It calls
log_error and assert_se, which go into log_dispatch(), which logs to
syslog, may try to write to klog, and whatnot... this doesn't look
too robust to me.
But anyway. Assuming it successfully froze. Does it help?
Yes. How much? Well, it's better than instant oops which happens
when PID 1 exits, but reaping of processes reparented
to init will stop, which, for example, makes the hang from pid
exhaustion just a question of time.
Ultimately, this stems from the decision to make systemd
to run as PID 1 process. Are there technical reasons for this?

Would be nice to see the systemd author join this discussion?

[Rahul Sundaram]

Post by mike cloaked
Would be nice to see the systemd author join this discussion?

I am sure you can get answers when someone is off vacation. However
what would be really nice is to redirect systemd discussions to its
upstream mailing list. Fedora devel is hardly the best place for it.

Rahul

[mike cloaked]

Post by mike cloaked
Would be nice to see the systemd author join this discussion?

I am sure you can get answers when someone is off vacation. ?However
what would be really nice is to redirect systemd discussions to its
upstream mailing list. ?Fedora devel is hardly the best place for it.
Rahul

OK I guess we'll get more discussion when he comes back from his
holiday - sorry I was unaware of the vacation but thanks for
clarifying.

I guess that your reference to moving to upstream indicates that
systemd is now sufficiently established that discussion of problems is
an upstream issue for bug triage/fixing? I would imagine that the user
list may have useful exchanges too but that it would be important to
get any issues moved upstream from there too? The most important
outcome is that bugs are fixed so whatever route is best for that
(including bugzilla of course) users should add input to. Hence links
to upstream for systemd are made available so that the best exposure
to recourse to resolution is optimised?

[mike cloaked]

Post by mike cloaked
I guess that your reference to moving to upstream indicates that
systemd is now sufficiently established that discussion of problems is
an upstream issue for bug triage/fixing? I would imagine that the user
list may have useful exchanges too but that it would be important to
get any issues moved upstream from there too? The most important
outcome is that bugs are fixed so whatever route is best for that
(including bugzilla of course) users should add input to. Hence links
to upstream for systemd are made available so that the best exposure
to recourse to resolution is optimised?

I also presume that by upstream you are referring to
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[Clyde E. Kunkel]

Post by mike cloaked

Post by Rahul Sundaram

Post by mike cloaked
Would be nice to see the systemd author join this discussion?

I am sure you can get answers when someone is off vacation. However
what would be really nice is to redirect systemd discussions to its
upstream mailing list. Fedora devel is hardly the best place for it.
Rahul

OK I guess we'll get more discussion when he comes back from his
holiday - sorry I was unaware of the vacation but thanks for
clarifying.
I guess that your reference to moving to upstream indicates that
systemd is now sufficiently established that discussion of problems is
an upstream issue for bug triage/fixing? I would imagine that the user
list may have useful exchanges too but that it would be important to
get any issues moved upstream from there too? The most important
outcome is that bugs are fixed so whatever route is best for that
(including bugzilla of course) users should add input to. Hence links
to upstream for systemd are made available so that the best exposure
to recourse to resolution is optimised?

I hope discussions continue on Fedora lists as well. systemd impacts
lots of fedora users who just read Fedora lists. I've subscribed to
gnome, network manager, btrfs, virt, lvm, selinux, anaconda, kickstart,
desktop, and etc. Sure, folks subscribe to more lists than that, but
when you can't spend much timre reading the lists, having discussions
concentrated in your distro of choice's lists frees up precious time to
actively participate in testing. As a Fedora user and tester it is far
easier to just peruse the Fedora lists. Once systemd settles in and is
no longer viewed with suspicion, then maybe add upstream for the rare issue.

Please don't be a wet blanket, folks, let the discussions continue here.

[Genes MailLists]

Post by Rahul Sundaram
what would be really nice is to redirect systemd discussions to its
upstream mailing list. Fedora devel is hardly the best place for it.
Rahul

Beg to differ - rather vehemently too - politely but vehemently.

systemd is only available in fedora[1] - we are the test pigs for
better or for worse - and there are most certainly bugs in fedora's systemd.

Lets be blunt here - he pushed very very very hard on these very lists
to get systemd in - now its in F15 and there are problems - so no
punting please. Upstream and fedora are the same for systemd.

Some bugs like sendmail failing to start have been there since
September 2010 ( almost 9 months ... ) - people are reporting the same
issue on F15 in the fedora lists ... who is fixing this stuff ?

e.g.

https://bugzilla.redhat.com/show_bug.cgi?id=692008
https://bugzilla.redhat.com/show_bug.cgi?id=633774


Ok so he's on vacation - this is a very core part of the OS - who is
backing him up I wonder? Who else is on the project?

Surely you're not saying there is no-one else working on systemd...
and when LP is away/busy nothing will get done ... otherwise I strongly
urge it be replaced by upstart asap.



gene/


[1] Yes he spoke with another distro - but no-one is using it. So its a
fedora only project until its picked up somewhere else - which has not
happened yet.

[Rahul Sundaram]

Post by Genes MailLists
Lets be blunt here - he pushed very very very hard on these very lists
to get systemd in - now its in F15 and there are problems - so no
punting please. Upstream and fedora are the same for syste

That is a gross over simplification. Fedora is just one of the many
distros integrating systemd and there are developers from other distros
including Novell involved in systemd and contributing to it. If we
start discussing every project where Red Hat is heaving involved, that
list is long

Post by Genes MailLists
[1] Yes he spoke with another distro - but no-one is using it. So its a
fedora only project until its picked up somewhere else - which has not
happened yet.

That's not true. Mandriva 2011 is already including it by default. So
is MeeGo. OpenSUSE has announced that it is using it by default in
their next release. Not to mention other distros who have included it
in their repos. It is far from a Fedora only project. The proper
place for general discussions about systemd is

http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Only Fedora specific bugs should be discussed here.

Rahul

[Peter Robinson]

Post by Rahul Sundaram

Post by Genes MailLists
Lets be blunt here - he pushed very very very hard on these very lists
to get systemd in - now its in F15 and there are problems - so no
punting please. Upstream and fedora are the same for syste

That is a gross over simplification. Fedora is just one of the many
distros integrating systemd and there are developers from other distros
including Novell involved in systemd and contributing to it. If we
start discussing every project where Red Hat is heaving involved, that
list is long

Post by Genes MailLists
[1] Yes he spoke with another distro - but no-one is using it. So its a
fedora only project until its picked up somewhere else - which has not
happened yet.

That's not true. Mandriva 2011 is already including it by default. So
is MeeGo.

actually meego will only ship it in 1.3 which will be out around the time of
f16

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110611/aa63bcf8/attachment.html

[Peter Robinson]

Post by Genes MailLists

Post by Rahul Sundaram
what would be really nice is to redirect systemd discussions to its
upstream mailing list. Fedora devel is hardly the best place for it.
Rahul

Beg to differ - rather vehemently too - politely but vehemently.
systemd is only available in fedora[1] - we are the test pigs for
better or for worse - and there are most certainly bugs in fedora's systemd.

Both opensuse and meego are moving to it currently and it will be in their
next releases. Fedora being the first isn't surprising as Red Hat employed
people are the leads on the project and its one of our four foundations. I
would be be very surprised if there weren't bugs, its the first rewrite of
the init system for decades. Fedora 14's init system isn't that different to
the first version of RHL (4.0) I started using back in 96.

Post by Genes MailLists
Lets be blunt here - he pushed very very very hard on these very lists
to get systemd in - now its in F15 and there are problems - so no
punting please. Upstream and fedora are the same for systemd.

Not sure what your point is here.

Post by Genes MailLists
Some bugs like sendmail failing to start have been there since
September 2010 ( almost 9 months ... ) - people are reporting the same
issue on F15 in the fedora lists ... who is fixing this stuff ?
e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=692008
https://bugzilla.redhat.com/show_bug.cgi?id=633774

Reading through both of those bugs they both look to be a regression in the
handling of NetworkManager dispatcher scripts [1] which are now fixed and
should be in stable [2] since 2nd June have you bothered to test this and
update the bugs? Its unfortunate the problem with the dispatcher scripts
wasn't picked up prior to release but the bug was fixed upstream by the NM
maintainer in a day once it was reported [3].

Post by Genes MailLists
Ok so he's on vacation - this is a very core part of the OS - who is
backing him up I wonder? Who else is on the project?

A number of people, but as pointed out above its not necessarily always
systemd's fault. System startup is a complex process and has a lot of
interdependencies.

Post by Genes MailLists
Surely you're not saying there is no-one else working on systemd...
and when LP is away/busy nothing will get done ... otherwise I strongly
urge it be replaced by upstart asap.

That's certainly not the case, you only have to look as far as the upstream
mailing list to see that. The fact that Ubuntu is the only project now
sticking with upstart (and i believe it was actually used by Fedora in a
mainline release first too) shows its uptake. A lot of projects will have a
lead architect that is the main driving force behind the project in the
early stages of the project, systemd is certainly not alone here. In fact if
you bothered to go and look at upstart I think you'll find its the same
there, and what's more with everyone moving to systemd there's likely a lot
less people working on upstart.

Peter

[1] https://bugzilla.redhat.com/show_bug.cgi?id=703321
[2]
https://admin.fedoraproject.org/updates/NetworkManager-0.8.9997-1.git20110531.fc15
[3] https://bugzilla.gnome.org/show_bug.cgi?id=649773
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110611/a3e4f7e1/attachment.html

[Toshio Kuratomi]

for decades. Fedora 14's init system isn't that different to the first version
of RHL (4.0) I started using back in 96.

This is somewhat misleading. There have been many rewrites of the init
system in the past decade. In fact, the Fedora 14 init system has the
capability to be quite different than the SysVinit scripts that were adopted
in the mid-90s. What is true is that Fedora 14 had not switched to using
the incompatible-with-SysVinit features of its default (or any of its
optional) init systems so the presentation and behaviour was almost the
same as older SysVinit.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110611/ac1c0904/attachment.bin

[drago01]

for decades. Fedora 14's init system isn't that different to the first version
of RHL (4.0) I started using back in 96.

This is somewhat misleading. ?There have been many rewrites of the init
system in the past decade. ?In fact, the Fedora 14 init system has the
capability to be quite different than the SysVinit scripts that were adopted
in the mid-90s. ?What is true is that Fedora 14 had not switched to using
the incompatible-with-SysVinit features of its default (or any of its
optional) init systems so the presentation and behaviour was almost the
same as older SysVinit.

That's true but due to the way we used it upstart was more or less a
renamed sysVinit.

[Toshio Kuratomi]

Post by drago01

for decades. Fedora 14's init system isn't that different to the first version
of RHL (4.0) I started using back in 96.

This is somewhat misleading. ?There have been many rewrites of the init
system in the past decade. ?In fact, the Fedora 14 init system has the
capability to be quite different than the SysVinit scripts that were adopted
in the mid-90s. ?What is true is that Fedora 14 had not switched to using
the incompatible-with-SysVinit features of its default (or any of its
optional) init systems so the presentation and behaviour was almost the
same as older SysVinit.

That's true but due to the way we used it upstart was more or less a
renamed sysVinit.

Which is what I said in my last sentence, yes? ;-)

I wanted to clarify that there have been a lot of new, rewritten init
systems in the Linux ecosystem in the past decade, including upstart. It's
just the Fedora default init system that's been an old fuddy-duddy about
adopting any of the rewritten-requiring features until now.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110612/12945ebd/attachment.bin

[drago01]

Post by Toshio Kuratomi

Post by drago01

for decades. Fedora 14's init system isn't that different to the first version
of RHL (4.0) I started using back in 96.

This is somewhat misleading. ?There have been many rewrites of the init
system in the past decade. ?In fact, the Fedora 14 init system has the
capability to be quite different than the SysVinit scripts that were adopted
in the mid-90s. ?What is true is that Fedora 14 had not switched to using
the incompatible-with-SysVinit features of its default (or any of its
optional) init systems so the presentation and behaviour was almost the
same as older SysVinit.

That's true but due to the way we used it upstart was more or less a
renamed sysVinit.

Which is what I said in my last sentence, yes? ;-)

Oh indeed ... probably a case of -E_NOCOFFEE ;)

[Lennart Poettering]

Post by Genes MailLists

Post by Rahul Sundaram
what would be really nice is to redirect systemd discussions to its
upstream mailing list. Fedora devel is hardly the best place for it.
Rahul

Beg to differ - rather vehemently too - politely but vehemently.
systemd is only available in fedora[1] - we are the test pigs for
better or for worse - and there are most certainly bugs in fedora's systemd.

Uh. You are confusing "available" with "being default". It is available
in quite a a number of distros, but F15 is the first big one to make it
the default.

Post by Genes MailLists
Ok so he's on vacation - this is a very core part of the OS - who is
backing him up I wonder? Who else is on the project?

A lot of folks. To join our community just drop by on #systemd and the
ML and you will always find folks happy to respond to your questions
UNLESS OF COURSE YOU LIKE TO WRITE THEM ALL IN UPPERCASE LETTERS WITH A
LOT OF EXCLAMATIONS AND INSULTS LIKE SOME PEOPLE ON THIS MAILING LIST
LIKE TO DO IT. In fact shouting all the time is a great way to get
yourself ignored.

Post by Genes MailLists
Surely you're not saying there is no-one else working on systemd...
and when LP is away/busy nothing will get done ... otherwise I strongly
urge it be replaced by upstart asap.

Just because I am away for a week or two systemd development didn't
stop. We have quite a few contributors (ohloh counts 66 patch authors),
and there a 5 folks with commit access, and a couple of patches went in
while I was gone.

I think systemd is a very healthy project. Much healthier than a lot of
projects we ship in our distribution by default and even then some of
its core components.

Uh, and even much healthier than Upstart, which you seem to be a big fan
of. Ohloh lists 3 patch authors. (But I figure that is out-of-date, it
cannot be that low)

Lennart

[Casey Dahlin]

Post by Lennart Poettering
Uh, and even much healthier than Upstart, which you seem to be a big fan
of. Ohloh lists 3 patch authors. (But I figure that is out-of-date, it
cannot be that low)

I'm guessing its just ohloh having as much trouble operating launchpad
as humans do. I know I have quite a large branch somewhere in there, but
it usually takes me a good while to find evidence of it too.

In general, though, someone else would have to understand what Upstart
is supposed to be in order to contribute code. Since that is explicitly
and by choice only documented in Scott's head, its kinda hard to do.

--CJD

[Lennart Poettering]

Post by Denys Vlasenko

Post by Michal Schmidt

Post by Steve Clark

Post by Michal Schmidt
systemd does not take the system down when it crashes. It catches the
signal, dumps core and freezes, but does not exit.
^^^^^^^

So you just end up with a "froze" system instead of a crashed system????

No, only systemd freezes itself. Other processes continue running.

systemd-26/src/main.c::crash() is the function which does it.
Assuming it will not recurse by crashing again, of course. It calls
log_error and assert_se, which go into log_dispatch(), which logs to
syslog, may try to write to klog, and whatnot... this doesn't look
too robust to me.
But anyway. Assuming it successfully froze. Does it help?
Yes. How much? Well, it's better than instant oops which happens
when PID 1 exits, but reaping of processes reparented
to init will stop, which, for example, makes the hang from pid
exhaustion just a question of time.
Ultimately, this stems from the decision to make systemd
to run as PID 1 process. Are there technical reasons for this?

Yupp, if we oops the kernel all processes are aborted at the same
time. If we just freeze systemd they can still be shutdown cleanly and
everything synced to disk.

Lennart

[Denys Vlasenko]

Post by Michal Schmidt

Post by Denys Vlasenko
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

I don't see any users of this feature on my F15.
I searched with Google and come up empty too.

But anyway, assuming it's a useful feature, why it has to be done by
systemd?

I looked at implementation.
systemd-26/src/execute.c::setup_pam():

/* We set up PAM in the parent process, then fork. The child
* will then stay around until killed via PR_GET_PDEATHSIG or
* systemd via the cgroup logic. It will then remove the PAM
* session again. The parent process will exec() the actual
* daemon. We do things this way to ensure that the main PID
* of the daemon is the one we initially fork()ed. */

I don't see any attempt to free at least something in the child.
So, systemd forks a process with eleven megabyte of malloced stuff
to act just as a babysitter - wait for parent to die, call pam_end,
exit?
For how long will it hang around in the system - possibly days?

Yes, COW, so not all of these eleven megabytes will be around...
...at first, until parent execs, or modifies sufficiently many pages
so that most of them are copied.

But memory consumption is not really the gist of my argument, it's:
why systemd tries to be all things for all people?

Why it has to care about PAM? I think most tools which need it do it
themselves, and we can write a small, really small helper for those
which don't.

Post by Michal Schmidt

Post by Denys Vlasenko
libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

Again, why it has to be done *by systemd*?

Post by Michal Schmidt

Post by Denys Vlasenko
Yes, whatever happened to the *NIX philosophy of simple non-complex

programs that did their job well. It has seemed to serve well since
the 70's.

Exactly my point.

[Lucas]

Post by Denys Vlasenko

Post by Michal Schmidt

Post by Denys Vlasenko
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

I don't see any users of this feature on my F15.
I searched with Google and come up empty too.
But anyway, assuming it's a useful feature, why it has to be done by
systemd?
I looked at implementation.
/* We set up PAM in the parent process, then fork. The child
* will then stay around until killed via PR_GET_PDEATHSIG or
* systemd via the cgroup logic. It will then remove the PAM
* session again. The parent process will exec() the actual
* daemon. We do things this way to ensure that the main PID
* of the daemon is the one we initially fork()ed. */
I don't see any attempt to free at least something in the child.
So, systemd forks a process with eleven megabyte of malloced stuff
to act just as a babysitter - wait for parent to die, call pam_end,
exit?
For how long will it hang around in the system - possibly days?
Yes, COW, so not all of these eleven megabytes will be around...
...at first, until parent execs, or modifies sufficiently many pages
so that most of them are copied.
why systemd tries to be all things for all people?
Why it has to care about PAM? I think most tools which need it do it
themselves, and we can write a small, really small helper for those
which don't.

Post by Michal Schmidt

Post by Denys Vlasenko
libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

Again, why it has to be done *by systemd*?

Post by Michal Schmidt

Post by Denys Vlasenko
Yes, whatever happened to the *NIX philosophy of simple non-complex

programs that did their job well. It has seemed to serve well since
the 70's.

Exactly my point.

It looks like it is the right time to think about upstart again. I will definitely check it out on
rawhide.
Thanks to OP for pointing on some difficulties. More important that it will be not so easy to clean
that all up latter and we will get eventually unmanageable windows.

[Michal Schmidt]

Post by Denys Vlasenko

Post by Michal Schmidt

Post by Denys Vlasenko
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

I don't see any users of this feature on my F15.
I searched with Google and come up empty too.
But anyway, assuming it's a useful feature, why it has to be done by
systemd?

A nice property of systemd is that it takes care of setting up
the environment for each service.
PAMName can be considered one of the pieces of the environment.
It is expected that services will eventually start taking advantage of
it and cease to implement these things themselves. It makes them
simpler.
See http://0pointer.de/public/systemd-man/daemon.html for how
"new-style" daemons are made simpler.

Post by Denys Vlasenko

Post by Michal Schmidt

Post by Denys Vlasenko
libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

Again, why it has to be done *by systemd*?

As systemd takes away the responsibility of creating sockets
from the services when it offers socket activation, it makes sense to
offer the option to filter the activation requests using libwrap.

Michal

[Lennart Poettering]

Post by Denys Vlasenko

Post by Michal Schmidt

Post by Denys Vlasenko
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?

to implement PAMName= (man systemd.exec)

I don't see any users of this feature on my F15.
I searched with Google and come up empty too.
But anyway, assuming it's a useful feature, why it has to be done by
systemd?

It's simply more correct to call into PAM when changing to a different
user, i.e. to implement /etc/security/limits.conf and suchlike. We do
not call into PAM by default, but you can enable it and I expect many
admins to configure things that way.

Also note that we will make use of this features when introducing the
D-Bus user bus, to ensure while the user bus runs as user it still has
all PAM limits set.

Post by Denys Vlasenko
why systemd tries to be all things for all people?

It doesn't. Just what you need to spawn a service in a confined
environment with all system limits applied correctly.

I am pretty sure people would complain very loudly if they use User= in
systemd and have no way to apply the PAM system limits to that.

Post by Denys Vlasenko

Post by Michal Schmidt

Post by Denys Vlasenko
libwrap? systemd is a network application now too?

to implement TCPWrapName= (man systemd.exec)

Again, why it has to be done *by systemd*?

Socket activation.

Lennart

[Steve Clark]

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.
systemctl --all shows 258 units total on my machine,
thus systemd uses ~40 *KILO*bytes of state per unit?
I understand your desire to replace everything by systemd.
I really do. syslogd, klogd, mount, fsck, and a dozen other things
I forget or don't know. It's called "featuritis".
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).
Mem total:2035840 anon:431208 map:78924 free:419084
slab:91624 buf:108040 cache:942336 dirty:196 write:0
Swap total:4095996 free:4095996
PID VSZ VSZRW RSS (SHR)*DIRTY (SHR) STACK COMMAND
1818 624m 365m 185m 13472 155m 64 224 /usr/lib/firefox-4/firefox
1816 433m 189m 166m 17248 142m 0 204 evolution
1257 53672 40400 22664 6004 18336 4176 132 /usr/bin/Xorg
1 15384 11856 13664 1340 11752 0 132 /sbin/init
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ 11.7 megs of malloc space
1839 275m 40224 24208 10572 11020 0 132 /usr/bin/gnome-terminal
1713 202m 45284 20308 9736 9604 576 132 /usr/libexec/xfce4/panel-plugins/xfce4-mixer-plugin
1843 171m 9448 20264 10012 8440 344 204 xchat
1770 152m 55672 19412 10972 6108 0 132 nautilus
It's the *fourth* largest process on my system!
# ldd `which systemd`
linux-gate.so.1 => (0x00a6b000)
libselinux.so.1 => /lib/libselinux.so.1 (0x414f6000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x41bc1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0019a000)
libudev.so.0 => /lib/libudev.so.0 (0x422c9000)
libwrap.so.0 => /lib/libwrap.so.0 (0x420fa000)
libpam.so.0 => /lib/libpam.so.0 (0x420e6000)
libaudit.so.1 => /lib/libaudit.so.1 (0x420cc000)
libcap.so.2 => /lib/libcap.so.2 (0x4152f000)
librt.so.1 => /lib/librt.so.1 (0x00be8000)
libc.so.6 => /lib/libc.so.6 (0x00295000)
/lib/ld-linux.so.2 (0x00276000)
libdl.so.2 => /lib/libdl.so.2 (0x00af6000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00f68000)
libnsl.so.1 => /lib/libnsl.so.1 (0x0095c000)
libattr.so.1 => /lib/libattr.so.1 (0x420c5000)
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?
libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?
libwrap? systemd is a network application now too?
libaudit? What systemd has in common with audit?
libdbus?... this is a lost battle I guess...
I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*
At the very least, I would like to see its memory consumption
to go down substantially.
It is an *init replacement*, not the replacement for everything.
One of init's goal is to be *simple* and *stable*.
Every new feature you add and library you link against
works against that goal.
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.
Then, if service manager would crash, at least it doesn't
take system down with it...

Yes, whatever happened to the *NIX philosophy of simple non-complex programs that did
their job well. It has seemed to serve well since the 70's.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: [phone]
Fax: [phone]
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110610/13dc118d/attachment.html

[Colin Walters]

Post by Denys Vlasenko
It's the *fourth* largest process on my system!
# ldd `which systemd`

1) Looking at what libraries a binary links to a is a terrible way to
optimize memory usage; try massif, say
2) It'd be a lot more productive to be positive and not phrase your
message in such an antagonistic way (in fact, this message would
probably be better on the systemd-devel mailing list)

[Adam Jackson]

Post by Denys Vlasenko
At the very least, I would like to see its memory consumption
to go down substantially.

Let's try to turn this into something constructive. I'll start with
David Malcolm's rather nifty, if unpolished, 'heap' plugin for gdb:

https://fedorahosted.org/gdb-heap/wiki

Simply running the 'heap' command tells me that systemd is using 21M of
malloc'd data, and that about 11M of it is entirely within allocations
that are all 2064 bytes apiece. Everything else, in comparison, is
pretty insignificant:

Domain Kind Detail Count Allocated size
------------- ----------- ------------ ------- --------------
uncategorized 2064 bytes 5,370 11,083,680
uncategorized 32 bytes 70,788 2,265,216
uncategorized 1072 bytes 1,503 1,611,216
uncategorized 96 bytes 11,420 1,096,320
C string data 12,964 630,672
uncategorized 528 bytes 1,067 563,376
uncategorized 528384 bytes 1 528,384
uncategorized 272 bytes 1,894 515,168
uncategorized 64 bytes 6,342 405,888
uncategorized 48 bytes 8,446 405,408
/* a bunch of stuff in between omitted */
uncategorized 2272 bytes 1 2,272
uncategorized 1568 bytes 1 1,568
uncategorized 800 bytes 1 800
TOTAL 127,119 21,934,576

That's a pretty unusual size, 2064 bytes. That works out to 2048 + 16,
though, which are much more natural-sounding numbers. A quick
experiment with a demo program (allocate a 32-byte struct and then call
pause()) shows that the 16 is actually the overhead from malloc itself:

Domain Kind Detail Count Allocated size
------------- ---- -------- ----- --------------
uncategorized 48 bytes 1 48
TOTAL 1 48

So now the problem is simply to find a 2048-sized allocation within
systemd, or one of its libraries. Anyone interested in a homework problem?

- ajax

[Michal Schmidt]

Post by Adam Jackson
Domain Kind Detail Count Allocated size
------------- ----------- ------------ ------- --------------
uncategorized 2064 bytes 5,370 11,083,680

Probably the SELinux file labelling database, all the regexes.
Related to https://bugzilla.redhat.com/show_bug.cgi?id=709014#c2

Michal

[David Malcolm]

Post by Adam Jackson

Post by Denys Vlasenko
At the very least, I would like to see its memory consumption
to go down substantially.

Let's try to turn this into something constructive. I'll start with
https://fedorahosted.org/gdb-heap/wiki

Woot! Fame at last! :)

Various comments inline below...

Post by Adam Jackson
Simply running the 'heap' command tells me that systemd is using 21M of
malloc'd data, and that about 11M of it is entirely within allocations
that are all 2064 bytes apiece. Everything else, in comparison, is
Domain Kind Detail Count Allocated size
------------- ----------- ------------ ------- --------------
uncategorized 2064 bytes 5,370 11,083,680

[...snip...]

"uncategorized" means that gdb-heap doesn't know how to deal with bytes
in question. If it's from a library, and you figure out what the above
is, we could add a categorizer for it.

Post by Adam Jackson
C string data 12,964 630,672

...

Post by Adam Jackson
TOTAL 127,119 21,934,576
That's a pretty unusual size, 2064 bytes. That works out to 2048 + 16,
though, which are much more natural-sounding numbers. A quick
experiment with a demo program (allocate a 32-byte struct and then call
Domain Kind Detail Count Allocated size
------------- ---- -------- ----- --------------
uncategorized 48 bytes 1 48
TOTAL 1 48

Yes: IIRC, the "size" is actually the offset to the next chunk. glibc's
malloc allocates two size_t fields at the top of each chunk.

Post by Adam Jackson
So now the problem is simply to find a 2048-sized allocation within
systemd, or one of its libraries. Anyone interested in a homework problem?

gdb-heap has a search/querying feature:

If you run :
(gdb) heap select size == 2048
it will try to show addresses and partial hexdumps of the relevant
buffers. (I _think_ so, but you might need 2064 instead).

The addresses it reports are those of where the allocation begins (as
seen by the program) i.e. it does the offset for you.

Given an address, there's also a
(gdb) hexdump ADDR
command, which you can use to scroll through memory.

If you stare at the hexdump you can sometimes figure out what the data
is.

If you think that an allocation is of some given type, you can also try
casting the data, e.g.:

(gdb) print *(some_struct*)ADDR

and see if looks meaningful.

Hope this is helpful.
Dave

[Kevin Kofler]

Post by Denys Vlasenko
Mem total:2035840 anon:431208 map:78924 free:419084

[snip]

Post by Denys Vlasenko
1 15384 11856 13664 1340 11752 0 132 /sbin/init

So this singleton process is taking 0.76% of your RAM. What the heck are you
complaining about?

Kevin Kofler

[drago01]

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

~11MB equals ~8 cents of RAM ... so meh.

If that's all you have to worry about its a good indication that they
aren't any real problems ;)

[Peter Robinson]

Post by drago01

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

~11MB equals ~8 cents of RAM ... so meh.
If that's all you have to worry about its a good indication that they
aren't any real problems ;)

11Mb on a device that may only have 256 such as an XO-1 or a phone or some
other ARM based device is actually quite a bit, over 4% in fact. 8c x 2.5m
devices is around $200K. While 4Gb is pretty standard in laptops, and 1Tb
isn't uncommon in servers now days there are also 100s of devices that run
linux in a whole lot less than that.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110611/7763d92b/attachment.html

[Denys Vlasenko]

Post by drago01

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

Sloppy attitude like this is the reason just about any daemon
(more and more of which pop up like mushrooms in every new release,
I must add) eats at least a few megabytes of RAM.

It's quite pathetic, really. You can easily tell which software
was developed earlier just by looking at its memory usage.
Example from my machine:
Good old ssh-agent: 404 kbytes.
Shiny new dconf-service: 2452 kbytes.
Shinier newer polkitd: 2836 kbytes.
e-addressbook-factory: 5488 kbytes.

Of course. What did you think. *Addressbook*! (Empty one in my case).
No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :(

Post by drago01
~11MB equals ~8 cents of RAM ... so meh.

Are you volunteering to buy more RAM for every Fedora user? ;)

[drago01]

Post by Denys Vlasenko

Post by drago01
~11MB equals ~8 cents of RAM ... so meh.

Are you volunteering to buy more RAM for every Fedora user? ;)

Maybe if you send me the money first ;)

(Sorry for private spam, hit wrong button)

[Adam Jackson]

Post by Denys Vlasenko
Sloppy attitude like this is the reason just about any daemon
(more and more of which pop up like mushrooms in every new release,
I must add) eats at least a few megabytes of RAM.

I'd have more empathy for your position if you'd made even a cursory
investigation into what that memory was being used for.

To be clear, this is an observation about how you're presenting your
argument. The original post reads mostly as "this looks like it's doing
too much, because of these things that I don't understand but I just
_know_ they're not necessary, so obviously this is all crap and everyone
who's working on it should be ashamed". Even if you were right, that's
not a tone of voice that makes people want to listen to you.

Would you rather make a good OS, or have internet arguments about why
we're making a bad OS?

If you approach a project by saying "I've found that we're burning a lot
of memory here, and I don't quite understand why, but it seems to be
related to the frobnitz component", that's productive. It shows that
you're concerned with quality, and that you've put some effort into
understanding how things are already structured, even if you don't have
a solution. It's a sign that you have some skin in the game (apologies
if that idiom doesn't translate well).

Post by Denys Vlasenko
It's quite pathetic, really. You can easily tell which software
was developed earlier just by looking at its memory usage.

... the message is that you're not, in fact, invested, that you're
perfectly happy to just switch back to twm because you don't need all
that fancy stuff. That's an individual choice you are perfectly free to
make, of course, but this is not the list for "here's the choices I've
made to set up my Fedora machine just the way I like it". This is the
list for solutions, not configurations, and not complaints.

- ajax

[Denys Vlasenko]

Post by Adam Jackson

Post by Denys Vlasenko
Sloppy attitude like this is the reason just about any daemon
(more and more of which pop up like mushrooms in every new release,
I must add) eats at least a few megabytes of RAM.

I'd have more empathy for your position if you'd made even a cursory
investigation into what that memory was being used for.
To be clear, this is an observation about how you're presenting your
argument. The original post reads mostly as "this looks like it's doing
too much, because of these things that I don't understand but I just
_know_ they're not necessary,

Yes, this is essentially correct.

Post by Adam Jackson
so obviously this is all crap and everyone
who's working on it should be ashamed".

To be sure, I reviewed my mail which started the thread.
I didn't say anything like that.

Post by Adam Jackson
Would you rather make a good OS, or have internet arguments about why
we're making a bad OS?

Well, I would like to do something which will make future Fedora
releases to go into better direction than F15 went.

Of course I want to make a good OS. It's not that easy though, because
OS can't be written by one person, therefore we need to work together,
and different people have different ideas what is good. Worse still,
"computer guys" in general (me included) are not masters of
communication...

Post by Adam Jackson
If you approach a project by saying "I've found that we're burning a lot
of memory here, and I don't quite understand why, but it seems to be
related to the frobnitz component", that's productive. It shows that
you're concerned with quality, and that you've put some effort into
understanding how things are already structured, even if you don't have
a solution. It's a sign that you have some skin in the game (apologies
if that idiom doesn't translate well).

You are right. However, I can participate in only so much open source
projects before my day stops fitting into 24 hours.

Should I not comment at all on any projects where I don't have time to
become a contributor?

Post by Adam Jackson

Post by Denys Vlasenko
It's quite pathetic, really. You can easily tell which software
was developed earlier just by looking at its memory usage.

... the message is that you're not, in fact, invested, that you're
perfectly happy to just switch back to twm because you don't need all
that fancy stuff.

I am not really that far in geek field to go back to using software from
1980s. I do think that progress is needed.

How can I express a point "the software becomes more bloated in general
and I think it's wrong"?

The options which you seem to advocate is to spend three weeks digging
in the sources of dozens of projects and present my findings where
exactly it happens. There is a few problems with it:

One, it is far too time-consuming. I do have more useful things to do, I
really do. For one, I can work on fixing one of 40+ open bugs in *my*
project.

Second, no one would listen. I know it *because it was already done*.
My colleague Jaroslav Reznik tells me a story about a guy who spend lots
of time investigating and prepared a presentation "Why KDE is bloated"
where he did exactly that: presented concrete examples where KDE fumbles
badly on memory consumption front. Guess what: a few years later the
presentation is still relevant, because KDE people did not act on the
data.

So yes, you are right that most likely Lennart will simply ignore
everything I say.

I disagree, though, that being extra nice and/or investing more time
into deeply investigating systemd code and trying to become a
co-developer would meaningfully change the outcome. I tried this several
times with various projects. I know when it makes sense to do it, and
this is not such case.

[Lennart Poettering]

Post by Denys Vlasenko

Post by drago01

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

Sloppy attitude like this is the reason just about any daemon
(more and more of which pop up like mushrooms in every new release,
I must add) eats at least a few megabytes of RAM.
It's quite pathetic, really. You can easily tell which software
was developed earlier just by looking at its memory usage.
Good old ssh-agent: 404 kbytes.
Shiny new dconf-service: 2452 kbytes.
Shinier newer polkitd: 2836 kbytes.
e-addressbook-factory: 5488 kbytes.
Of course. What did you think. *Addressbook*! (Empty one in my case).
No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :(

Post by drago01
~11MB equals ~8 cents of RAM ... so meh.

Are you volunteering to buy more RAM for every Fedora user? ;)

As mentioned this is primarily the SELinux policy we load. I wished
libselinux would optimize memory usage transparently, but even without
any changes in libselinux we should be able to optimize this a bit.

Yes, using SELinux makes your boot a bit slower and consumes more
resources, there is no news in that, and there's also no news in the
fact that we can optimize this a bit when we are aware of it.

Lennart

[Daniel J Walsh]

Post by Lennart Poettering

Post by Denys Vlasenko

Post by drago01

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

Sloppy attitude like this is the reason just about any daemon
(more and more of which pop up like mushrooms in every new release,
I must add) eats at least a few megabytes of RAM.
It's quite pathetic, really. You can easily tell which software
was developed earlier just by looking at its memory usage.
Good old ssh-agent: 404 kbytes.
Shiny new dconf-service: 2452 kbytes.
Shinier newer polkitd: 2836 kbytes.
e-addressbook-factory: 5488 kbytes.
Of course. What did you think. *Addressbook*! (Empty one in my case).
No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :(

Post by drago01
~11MB equals ~8 cents of RAM ... so meh.

Are you volunteering to buy more RAM for every Fedora user? ;)

As mentioned this is primarily the SELinux policy we load. I wished
libselinux would optimize memory usage transparently, but even without
any changes in libselinux we should be able to optimize this a bit.
Yes, using SELinux makes your boot a bit slower and consumes more
resources, there is no news in that, and there's also no news in the
fact that we can optimize this a bit when we are aware of it.
Lennart

I just released an updated version of libselinux that will no longer do
the dups check on loading file labeling. Testing with matchpathcon, I
see a four time speed up on loading the file context file. Basically
from 1 Second down to .25 seconds.

The memory problem is just the share number of file context that we are
loading, each line of the file_context file is a regex. Currently the
file_context file on my Rawhide machine is 4209 lines. If we can
determine the only file context that systemd will need, based on
directories we can eliminate some of the regexes. For example if we
just loaded paths that begin with /var, /tmp, /dev, we would drop the
regexs down to 1500.

[Stephen Smalley]

Post by Daniel J Walsh
The memory problem is just the share number of file context that we are
loading, each line of the file_context file is a regex. Currently the
file_context file on my Rawhide machine is 4209 lines. If we can
determine the only file context that systemd will need, based on
directories we can eliminate some of the regexes. For example if we
just loaded paths that begin with /var, /tmp, /dev, we would drop the
regexs down to 1500.

selabel_close() will free all of the file contexts mapping.
So if you can bracket the usage of the mapping with a
selabel_open();...;selabel_close();, then you'll only be consuming the
memory when using the file contexts mapping. You don't want to do that
around every file creation / relabel, of course.

[Lennart Poettering]

Post by Denys Vlasenko

Post by drago01

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

Sloppy attitude like this is the reason just about any daemon
(more and more of which pop up like mushrooms in every new release,
I must add) eats at least a few megabytes of RAM.
It's quite pathetic, really. You can easily tell which software
was developed earlier just by looking at its memory usage.
Good old ssh-agent: 404 kbytes.
Shiny new dconf-service: 2452 kbytes.
Shinier newer polkitd: 2836 kbytes.
e-addressbook-factory: 5488 kbytes.
Of course. What did you think. *Addressbook*! (Empty one in my case).
No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :(

Post by drago01
~11MB equals ~8 cents of RAM ... so meh.

Are you volunteering to buy more RAM for every Fedora user? ;)

As mentioned this is primarily the SELinux policy which we load into
RAM. I wished libselinux would optimize resource usage transparently a
bit better, but even without that we should be able to optimize this a
bit in the way systemd loads the policy.

SELinux makes boot slower and uses more resources, there is no news in
that. There's also no news in the fact that we can definitely optimize
its impact wherever we are aware of it.

Lennart

[Stephen Smalley]

Post by Lennart Poettering

Post by Denys Vlasenko

Post by drago01

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

Sloppy attitude like this is the reason just about any daemon
(more and more of which pop up like mushrooms in every new release,
I must add) eats at least a few megabytes of RAM.
It's quite pathetic, really. You can easily tell which software
was developed earlier just by looking at its memory usage.
Good old ssh-agent: 404 kbytes.
Shiny new dconf-service: 2452 kbytes.
Shinier newer polkitd: 2836 kbytes.
e-addressbook-factory: 5488 kbytes.
Of course. What did you think. *Addressbook*! (Empty one in my case).
No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :(

Post by drago01
~11MB equals ~8 cents of RAM ... so meh.

Are you volunteering to buy more RAM for every Fedora user? ;)

As mentioned this is primarily the SELinux policy which we load into
RAM. I wished libselinux would optimize resource usage transparently a
bit better, but even without that we should be able to optimize this a
bit in the way systemd loads the policy.
SELinux makes boot slower and uses more resources, there is no news in
that. There's also no news in the fact that we can definitely optimize
its impact wherever we are aware of it.

Just to clarify: what is unique here is a long-running daemon that is
loading the entire file_contexts configuration into memory and keeping
it there for its entire lifetime. Previously, the closest analogy was
udev, which was quickly optimized to only load entries under /dev. Old
init systems didn't load the file contexts configuration at all; they
didn't need it for anything. systemd needs it because it handles
creation and labeling of files and sockets that used to be either
handled by the daemons themselves (in which case policy could
transparently label them based on their creator) or by rc scripts that
would fork+exec short-lived restorecon processes to fix up labels.

Ways to improve the situation for systemd would include:
- Only load a subset of file_contexts entries, similar to udev.
- Only load the file contexts entries temporarily, using selabel_open +
selabel_close to bracket entire blocks where files are created or
relabeled.

[Miloslav Trmač]

Post by Stephen Smalley
- Only load a subset of file_contexts entries, similar to udev.
- Only load the file contexts entries temporarily, using selabel_open +
selabel_close to bracket entire blocks where files are created or
relabeled.

- At policy build time, precompute a DFA for all of the regexps, and
store it in a file. This file could be mmap()ed into any user of the
policy, requiring no malloc(), and allowing the kernel to free the
memory when it is no longer used; this should also make loading of the
file_contexts configuration faster.
Mirek

[Daniel J Walsh]

Post by Miloslav Trmač

Post by Stephen Smalley
- Only load a subset of file_contexts entries, similar to udev.
- Only load the file contexts entries temporarily, using selabel_open +
selabel_close to bracket entire blocks where files are created or
relabeled.

- At policy build time, precompute a DFA for all of the regexps, and
store it in a file. This file could be mmap()ed into any user of the
policy, requiring no malloc(), and allowing the kernel to free the
memory when it is no longer used; this should also make loading of the
file_contexts configuration faster.
Mirek

I was wondering if this was possible. Any example of how to do it?

[Jakub Jelinek]

Post by Daniel J Walsh

Post by Miloslav Trmač

Post by Stephen Smalley
- Only load a subset of file_contexts entries, similar to udev.
- Only load the file contexts entries temporarily, using selabel_open +
selabel_close to bracket entire blocks where files are created or
relabeled.

- At policy build time, precompute a DFA for all of the regexps, and
store it in a file. This file could be mmap()ed into any user of the
policy, requiring no malloc(), and allowing the kernel to free the
memory when it is no longer used; this should also make loading of the
file_contexts configuration faster.
Mirek

I was wondering if this was possible. Any example of how to do it?

At least with glibc regex, that would be terribly unportable and
wouldn't buy much, as regcomp isn't very expensive, the DFA nodes
are created on the fly during regexec as needed.

Jakub

[Miloslav Trmač]

Post by Daniel J Walsh

Post by Miloslav Trmač
- At policy build time, precompute a DFA for all of the regexps, and
store it in a file. ?This file could be mmap()ed into any user of the
policy, requiring no malloc(), and allowing the kernel to free the
memory when it is no longer used; this should also make loading of the
file_contexts configuration faster.
? ?Mirek

I was wondering if this was possible.

Looking at the output of (semanage fcontext -l), it seems that all
entries could be handled by a DFA. Of course this might mean changing
the documented semantics of the regexp (in particular to forbid
backreferences). The practical question is whether the DFA will be
small enough, I can't really see much reason for a large state
explosion - most of the regexps are very simple.

Post by Daniel J Walsh
?Any example of how to do it?

Not really... the idea was prompted by a mention of re2c, but I
suppose you don't want to involve a C compiler in the policy build
process. Still, that's something to start from. (And of course, a
student of automata theory should be able to build this from scratch.
Perhaps a bachelor thesis?)
Mirek

[Lennart Poettering]

Post by Denys Vlasenko
Hi Lennart,
systemd is eating a lot more memory than any other init process
I ever played with.
Granted, systemd does a bit more that "typical" init, but I think
using *eleven plus megabytes* of malloced space is a bit much.

As pointed out elsewhere, this is mostly the SELinux policy, and
definitely something we can optimize in one way or another.

Post by Denys Vlasenko
I understand your desire to replace everything by systemd.

I have no such desire.

Post by Denys Vlasenko
I really do. syslogd, klogd, mount, fsck, and a dozen other things

We don't replace syslogd, klogd, mount, fsck and dozen of other things.

Post by Denys Vlasenko
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Yes, systemd as a platform will include a tiny daemon which takes over
the role of CK.

Post by Denys Vlasenko
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?
libattr? Does it mean it requires filesystem which implements
extended attributes? If not, why does it use libattr then?
libaudit? What systemd has in common with audit?

Michal already answered these questions, so I am not going to repeat
this here.

Post by Denys Vlasenko
libwrap? systemd is a network application now too?

Yupp, Google for "socket activation systemd".

Post by Denys Vlasenko
libdbus?... this is a lost battle I guess...

Yupp, since Upstart used that already since ages.

Post by Denys Vlasenko
I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*

I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart. (How?
We simply spawn shell (or even zero) shells and other interpretors, and
start a number of seldom-things only when needed and the rest in
parallel).

Post by Denys Vlasenko
It is an *init replacement*, not the replacement for everything.

I like to see it as a modular platform to build an OS from. It includes an
init system and a few auxiliary tools (readahead for example, and C
implementations of the basic boot scripts).

Post by Denys Vlasenko
Every new feature you add and library you link against
works against that goal.

Nah, don't think so. We have fewer deps, and less dependencies than the
equivalent Upstart- and shell based boot. It is my intention to minimize
the minimum set of packages you need to bootstrap a Linux system. While
the systemd package might get a bit bigger than sysvinit through that --
*overall* you get a much smaller and simpler system, build from a much
smaller number of source packages. That saves resources, makes things
simpler and faster.

Post by Denys Vlasenko
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.

No, that would complicate things for little reason. I find a system
whose PID after boot is in the 500 range much simpler and leaner than
one that is in the 5000 range.

Post by Denys Vlasenko
Then, if service manager would crash, at least it doesn't
take system down with it...

If systemd crashes it will freeze, but not take the system down.

Lennart

[Denys Vlasenko]

Hi Lennart,

Post by Lennart Poettering

Post by Denys Vlasenko
I understand your desire to replace everything by systemd.

I have no such desire.

What is this then?

int main(int argc, char *argv[]) {
...
if (arg_running_as == MANAGER_SYSTEM && !serialization) {
locale_setup();

if (arg_show_status || plymouth_running()) <== ??
status_welcome();

kmod_setup(); <=== ???
hostname_setup(); <=== ???
machine_id_setup(); <=== ???
loopback_setup();

test_mtab();
test_usr();
test_cgroups();
}

"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?
This is an antithesis to modular, Unix way of doing things.
It starts to have shadows of monolithic Windows-like
"we know better than you what you need" approach.

hostname_setup()?
machine_id_setup()? Why systemd has *source-code-level knowledge*
about it? I would say that if admin wants to have /etc/machine-id,
he can set up startup code to generate it.

For one, I had no /etc/machine-id on machines I was administering
for decades, with no ill effects. I don't want init to know better
than me what I want to have.

kmod_setup() loads autofs4, ipv6 and unix modules.
Why? What if I don't want to run automounter?
systemd will force me to do so?
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.

Post by Lennart Poettering

Post by Denys Vlasenko
I really do. syslogd, klogd, mount, fsck, and a dozen other things

We don't replace syslogd, klogd, mount, fsck and dozen of other things.

What is /lib/systemd/systemd-fsck then?
/lib/systemd/systemd-logger?
(Also, most of them don't emit useful info on --help...)

Post by Lennart Poettering

Post by Denys Vlasenko
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Yes, systemd as a platform will include a tiny daemon which takes over
the role of CK.

That's what I was referring to by "taking over the world".

Today I can remove CK from my Fedora install if I want to.
If it goes into systemd, I will be unable to do so.
Yet another bit of freedom taken away.

Post by Lennart Poettering

Post by Denys Vlasenko
I propose to stop for a second and optimize systemd down
instead of trying to add even more bells and whistles to it.
Or else you'll soon end up linking against every /lib/lib*.so*

I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.

I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.

Post by Lennart Poettering
(How?
We simply spawn shell (or even zero) shells and other interpretors, and
start a number of seldom-things only when needed and the rest in
parallel).

Optimizing towards not spawning shell at all is a strange optimization
target. Reducing the need to spawn shells - yes, eliminating - no.

Post by Lennart Poettering

Post by Denys Vlasenko
It is an *init replacement*, not the replacement for everything.

I like to see it as a modular platform to build an OS from.

That's what I was referring to by "taking over the world".

Post by Lennart Poettering
It includes an
init system and a few auxiliary tools (readahead for example, and C
implementations of the basic boot scripts).

Readahead is a band aid for stuff which is bloated enough
to affect boot by sheer amount of necessary reading.
I don't say others must not use it, but I would like to be able
to switch it off. (For one, it makes bloat more noticeable,
so I can see what needs fixing.)
As I said, freedom to do things as admin wants
is important trait of Unix way.

C implementation of shell scripts tends to be too rigid.
I don't see why you are trying to do that.
If it because bash startup time is too long, I have
a few faster shells for you...

Post by Lennart Poettering

Post by Denys Vlasenko
Every new feature you add and library you link against
works against that goal.

Nah, don't think so. We have fewer deps, and less dependencies than the
equivalent Upstart- and shell based boot.

Competing with Upstart is easy :)

Post by Lennart Poettering
It is my intention to minimize
the minimum set of packages you need to bootstrap a Linux system. While
the systemd package might get a bit bigger than sysvinit through that --
*overall* you get a much smaller and simpler system, build from a much
smaller number of source packages. That saves resources, makes things
simpler and faster.

Everyone who likes coding thinks that his favorite package is great.
I have no doubt that you are proud of systemd. It actually isn't
a bad software.

However, allow me to have a not completely rosy view of it either.
"Saves resources" is not exactly true, as I see it,
on memory consumption front.

Post by Lennart Poettering

Post by Denys Vlasenko
To be honest, I doubt the wisdom of implementing service manager
as an init process. There is no inherent reason why it has to be init -
you can run it as *a child of init*, and keep init very simple.

No, that would complicate things for little reason.

How running under PID != 1 makes any difference? I was running
various service monitoring tools as ordinary
(non-init) processes and it works equally good. No, better,
because crashes in non-init are not as detrimental.

Post by Lennart Poettering
I find a system
whose PID after boot is in the 500 range much simpler and leaner than
one that is in the 5000 range.

That's what I was referring to by "taking over the world".
You want to be "special". You want to have PID 1.

[Lennart Poettering]

Post by Denys Vlasenko
kmod_setup(); <=== ???

We load a couple of kernel modules which systemd needs, and are
sometimes compiled as module only and which cannot be autoloaded for a
reason or another. This is ipv6, autofs4, unix.ko, and we load them
explicitly so that we can use them.

Post by Denys Vlasenko
hostname_setup(); <=== ???

We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a separate
binary is just absurd. This way we also can ensure that the hostname is
always initialised which is very useful for early boot logging and other
stuff. On systemd you get the guarantee that the hostname is always set
up if you run in userspace, among other things (for example, the
loopback device is always set up, you can always bind to 127.0.0.1 and ::1).

Post by Denys Vlasenko
machine_id_setup(); <=== ???

Similar to the hostname we ensure that the machine id is always
initialized, and has the same lifetime and validity guarantees as the
hostname. i.e. that it is simply usable by *every* process started,
regardless when.

Post by Denys Vlasenko
"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?

Because we need to constantly send updates to it. It's a trivial socket
operation. It's a trivial thing and spawning a separate process to send
those updates each and every single time is a major waste of resources
and basically doubles the processes we have to spawn at boot.

Post by Denys Vlasenko
This is an antithesis to modular, Unix way of doing things.

Just because you can turn each trivial operation into a separate binary
you shouldn't necessarily do that. It is what makes your system slow and
heavy-weight. Insisting that we invoke sethostname() in a separate
process is just stupid. I am mean, come on, think about it. It is *ONE*
system call to the the hostname with sethostname(). Invoking
/bin/hostname instead is at least 40 or so (and many of those quite
heavy weight). And really, why are we even discussing the frickin
hostname like this?

And invoking the plymouth update tool after each process we start
practically doubles the amount of processes we have to spawn. Which is a
great way to make things slow, little more.

Post by Denys Vlasenko
It starts to have shadows of monolithic Windows-like
"we know better than you what you need" approach.

OMG! You used the "W"-word!

Do you know what "mono" means? It's greek and means "one". And "lithic"
means "stone". And if systemd communicates with Plymouth, then this is
not monolothic at all, since systemd and ply are two processes, not
one.

systemd is not running Plymouth stuff in the same process, is it merely
communicating with it. And the communication is very very
trivial.

Post by Denys Vlasenko
hostname_setup()?
machine_id_setup()? Why systemd has *source-code-level knowledge*
about it? I would say that if admin wants to have /etc/machine-id,
he can set up startup code to generate it.

Well, the point is to offer the machine id unconditionally, so that apps
can start relying on them and stop misuing the hostname for stuff they
shouldn't use it for.

Post by Denys Vlasenko
kmod_setup() loads autofs4, ipv6 and unix modules.
Why? What if I don't want to run automounter?

systemd supports .automount units, and to make that work we need to load
the autofs kmod, if it is not compiled in.

Post by Denys Vlasenko
systemd will force me to do so?

No, systemd tries to load those modules but if you are into retro
computing you can still blacklist them using the usual modprobe
blacklisting, and systemd will honour that (i.e. by passing -b to
modprobe).

Post by Denys Vlasenko
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.

Nah. udev loads modules automatically. In fact on almost all systems
there should be no need to ever load a module manually. And if the admin
wants to blacklist a module he can easily do so via the modprobe config,
how it should be done.

Post by Denys Vlasenko

Post by Lennart Poettering
We don't replace syslogd, klogd, mount, fsck and dozen of other things.

What is /lib/systemd/systemd-fsck then?

A wrapper, which handles the exit code and reacts properly to it.

Post by Denys Vlasenko
/lib/systemd/systemd-logger?

It's service systemd uses to provide logging for processes it
spawns. i.e. in systemd you can simply configure in a service file that
stdout/stderr of a process should go to syslog, and this is needed for
that.

Post by Denys Vlasenko
(Also, most of them don't emit useful info on --help...)

They aren't user binaries. They are in /lib/systemd, not /usr/bin...

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Yes, systemd as a platform will include a tiny daemon which takes over
the role of CK.

That's what I was referring to by "taking over the world".

Well, we simplify things a lot that way, and unify the behaviour of
system and user services (i.e. they appear in the same cgroup hierarchy
and so on).

Post by Denys Vlasenko
Today I can remove CK from my Fedora install if I want to.

You'll be left with very little if you do that.

But why would you even want to remove that?

Post by Denys Vlasenko
If it goes into systemd, I will be unable to do so.
Yet another bit of freedom taken away.

Yes, correct. I hate freedom. Muauauauahah!

Post by Denys Vlasenko

Post by Lennart Poettering
I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.

I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.

daemontools does not support socket activation for parallelizing
execution of servers with its clients. So yes, we can beat *that*.

Post by Denys Vlasenko

Post by Lennart Poettering
We simply spawn fewer (or even zero) shells and other interpretors, and
start a number of seldom-things only when needed and the rest in
parallel).

Optimizing towards not spawning shell at all is a strange optimization
target. Reducing the need to spawn shells - yes, eliminating - no.

Well, zero might not be realistic anytime soon, but as mentioned, I want
to start fewer shells by default at boot.

Post by Denys Vlasenko
I don't say others must not use it, but I would like to be able
to switch it off. (For one, it makes bloat more noticeable,
so I can see what needs fixing.)

You can easily disable readahead:

systemctl disable systemd-readahead-replay.service systemd-readahead-collect.service

Post by Denys Vlasenko

Post by Lennart Poettering
Nah, don't think so. We have fewer deps, and less dependencies than the
equivalent Upstart- and shell based boot.

Competing with Upstart is easy :)

Why do you say that? It's the benchmark so far. The best solution that
existed on Linux so far.

Post by Denys Vlasenko

Post by Lennart Poettering
I find a system
whose PID after boot is in the 500 range much simpler and leaner than
one that is in the 5000 range.

That's what I was referring to by "taking over the world".
You want to be "special". You want to have PID 1.

Hmm? systemd is an init system, so it is of course PID 1.

Lennart

[Miloslav Trmač]

On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering

Post by Lennart Poettering

Post by Denys Vlasenko
"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?

Because we need to constantly send updates to it. It's a trivial socket
operation. It's a trivial thing and spawning a separate process to send
those updates each and every single time is a major waste of resources
and basically doubles the processes we have to spawn at boot.

The long-term question here is "what happens when Plymouth is replaced
by something different, first in one specialist distribution, later by
one major distribution (perhaps Fedora), and only much later by most
distributions?". Will systemd only support the new thing, forcing the
"slower" distributions to backport patches? Will systemd support both
systems, and over time become burdened with compatibility code?
Something else?

Historically, each distribution had its own system integration scripts
that supported only the tools the distribution cared about, so there
never was a single project fighting with the matrix of N distributions
x M implementations of major features.

Post by Lennart Poettering

Post by Denys Vlasenko
What is /lib/systemd/systemd-fsck then?

A wrapper, which handles the exit code and reacts properly to it.

Post by Denys Vlasenko
(Also, most of them don't emit useful info on --help...)

They aren't user binaries. They are in /lib/systemd, not /usr/bin...

But they do implement user-visible functionality, and have
user-visible /proc/cmdline options. Yes, old initscripts didn't
document the behavior either, but the sysadmin (who, for better or
worse, pretty much has to be able to read shell code) could find them
and could understand and debug the boot process by reading /etc/rc.*.
I think that asking the sysadmin to read the C code of systemd to
understand the boot process and how it can be configured is rather
excessive.
Mirek

[Lennart Poettering]

Post by Miloslav Trmač
On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering

Post by Lennart Poettering

Post by Denys Vlasenko
"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?

Because we need to constantly send updates to it. It's a trivial socket
operation. It's a trivial thing and spawning a separate process to send
those updates each and every single time is a major waste of resources
and basically doubles the processes we have to spawn at boot.

The long-term question here is "what happens when Plymouth is replaced
by something different, first in one specialist distribution, later by
one major distribution (perhaps Fedora), and only much later by most
distributions?". Will systemd only support the new thing, forcing the
"slower" distributions to backport patches? Will systemd support both
systems, and over time become burdened with compatibility code?
Something else?

As usual, we'll decide case-by-case and as I know myself and the
triviality of this code we'd probably support both for a while and then
drop the old code a bit later.

Post by Miloslav Trmač
Historically, each distribution had its own system integration scripts
that supported only the tools the distribution cared about, so there
never was a single project fighting with the matrix of N distributions
x M implementations of major features.

With systemd we have a very strict policy: we want to gently push the
distros to standardize on the same components for the base system. That
means that if you use ply and systemd together you get the best features
but you can still use them independently too. It's loosely coupled, but
we do want to get people to use this combination and no other by
offering them the best support for this combination.

Post by Miloslav Trmač

Post by Lennart Poettering

Post by Denys Vlasenko
(Also, most of them don't emit useful info on --help...)

They aren't user binaries. They are in /lib/systemd, not /usr/bin...

But they do implement user-visible functionality, and have
user-visible /proc/cmdline options. Yes, old initscripts didn't
document the behavior either, but the sysadmin (who, for better or
worse, pretty much has to be able to read shell code) could find them
and could understand and debug the boot process by reading /etc/rc.*.
I think that asking the sysadmin to read the C code of systemd to
understand the boot process and how it can be configured is rather
excessive.

I think systemd documentation is much better than the documentation of
most other open source projects. If we missed something in the
documentation please file a bug and we'll fix it.

Lennart

[Denys Vlasenko]

Post by Lennart Poettering

Post by Denys Vlasenko
kmod_setup(); <=== ???

We load a couple of kernel modules which systemd needs, and are
sometimes compiled as module only and which cannot be autoloaded for a
reason or another. This is ipv6, autofs4, unix.ko, and we load them
explicitly so that we can use them.

You assume that everyone uses IPv6. This is not true.

Post by Lennart Poettering

Post by Denys Vlasenko
hostname_setup(); <=== ???

We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a separate
binary is just absurd. This way we also can ensure that the hostname is
always initialised which is very useful for early boot logging and other
stuff. On systemd you get the guarantee that the hostname is always set
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.

Why do you set up stuff no one asked you to?

Post by Lennart Poettering

Post by Denys Vlasenko
machine_id_setup(); <=== ???

Similar to the hostname we ensure that the machine id is always
initialized, and has the same lifetime and validity guarantees as the
hostname. i.e. that it is simply usable by *every* process started,
regardless when.

Point me at one program which uses machine id. I never saw one.
And anyway, why do you set up stuff no one asked you to?

Post by Lennart Poettering

Post by Denys Vlasenko
"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?

Because we need to constantly send updates to it. It's a trivial socket
operation. It's a trivial thing and spawning a separate process to send
those updates each and every single time is a major waste of resources
and basically doubles the processes we have to spawn at boot.

Plymouth is not a part of Unix. Init process has no business knowing
about distro specific stuff like that.

Post by Lennart Poettering

Post by Denys Vlasenko
This is an antithesis to modular, Unix way of doing things.

Just because you can turn each trivial operation into a separate binary
you shouldn't necessarily do that.

Where did I propose turning everything into a separate binary?

Post by Lennart Poettering
It is what makes your system slow and
heavy-weight. Insisting that we invoke sethostname() in a separate
process is just stupid. I am mean, come on, think about it. It is *ONE*
system call to the the hostname with sethostname(). Invoking
/bin/hostname instead is at least 40 or so (and many of those quite
heavy weight). And really, why are we even discussing the frickin
hostname like this?

Because it's a perfect example of a thing init process has no business
doing. Ever. The lightness of the syscall is irrelevant. For example,
you also do modprobing of various things, which is far from being
"just one syscall", so this argument is moot.

Post by Lennart Poettering
Do you know what "mono" means? It's greek and means "one". And "lithic"
means "stone". And if systemd communicates with Plymouth, then this is
not monolothic at all, since systemd and ply are two processes, not
one.

Init process should not have intrinsic knowledge about splash screens!
This is basic idea of modularity. This is how Unix always worked.
Things should not be *too* interconnected. Things should be modular.

In your presentation, you have "Integration" as slide 17 and
"Modularization" as slide 18. Do you realize that these are the opposite
things? "More integration" means "less modularization". You can't have
both.

Post by Lennart Poettering
systemd is not running Plymouth stuff in the same process, is it merely
communicating with it.

Thanks that at least for now you don't have plans to incorporate
Plymouth.

Post by Lennart Poettering
No, systemd tries to load those modules but if you are into retro
computing you can still blacklist them using the usual modprobe
blacklisting, and systemd will honour that (i.e. by passing -b to
modprobe).

Post by Denys Vlasenko
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.

Nah. udev loads modules automatically.

udev loads modules according to config file, not by hard-coding stuff in
C code. IOW: udev does not load modules which *udev developer*
wants, it loads modules which *admin* wants. (Of course,
admin might choose to use standard config, but he does this
on his own volition).

Post by Lennart Poettering
In fact on almost all systems
there should be no need to ever load a module manually.

Maybe. It's not up to a piece of software to decide.
In Unix, admins should have power to decide, not programs.
Programs provide the means, they don't dictate policies.

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
Now I hear about plans to incorporate ConsoleKit into it
(hearsay, so maybe it's not true).

Yes, systemd as a platform will include a tiny daemon which takes over
the role of CK.

That's what I was referring to by "taking over the world".

Well, we simplify things a lot that way, and unify the behaviour of
system and user services (i.e. they appear in the same cgroup hierarchy
and so on).

Post by Denys Vlasenko
Today I can remove CK from my Fedora install if I want to.

You'll be left with very little if you do that.

Try "rm /usr/sbin/console-kit-daemon". Works like a charm.

Post by Lennart Poettering
But why would you even want to remove that?

If I would be willing to work in an OS with attitudes like this,
I'd be hacking in Windows. I don't.

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering
I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.

I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.

daemontools does not support socket activation for parallelizing
execution of servers with its clients. So yes, we can beat *that*.

I said "you can't beat *that* on resource front". On resource front.
Can you beat it on resource front?

Indeed, daemontools don't provide socket activation. Please note that I
don't argue against socket activation.

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering
I find a system
whose PID after boot is in the 500 range much simpler and leaner than
one that is in the 5000 range.

That's what I was referring to by "taking over the world".
You want to be "special". You want to have PID 1.

Hmm? systemd is an init system, so it is of course PID 1.

Again. *Why it has to have PID 1* to spawn and control services?
Can you please answer this?

[Matthew Garrett]

Post by Denys Vlasenko

Post by Lennart Poettering
We load a couple of kernel modules which systemd needs, and are
sometimes compiled as module only and which cannot be autoloaded for a
reason or another. This is ipv6, autofs4, unix.ko, and we load them
explicitly so that we can use them.

You assume that everyone uses IPv6. This is not true.

The point of providing a platform is that developers can make certain
assumptions about available functionality. It's no longer reasonable to
treat IPv6 as an optional part of the internet, any more than it's
reasonable to consider IPv4 as optional. But if you don't want it,
simply don't build it.

[Peter Robinson]

Post by Matthew Garrett

Post by Denys Vlasenko

Post by Lennart Poettering
We load a couple of kernel modules which systemd needs, and are
sometimes compiled as module only and which cannot be autoloaded for a
reason or another. This is ipv6, autofs4, unix.ko, and we load them
explicitly so that we can use them.

You assume that everyone uses IPv6. This is not true.

The point of providing a platform is that developers can make certain
assumptions about available functionality. It's no longer reasonable to
treat IPv6 as an optional part of the internet, any more than it's
reasonable to consider IPv4 as optional. But if you don't want it,
simply don't build it.

I believe the ipv6 module is going to be built in soon anyway.

http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110613/379dded0/attachment.html

[Matthew Garrett]

On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett <mjg59 at srcf.ucam.org>
The point of providing a platform is that developers can make certain
assumptions about available functionality. It's no longer reasonable to
treat IPv6 as an optional part of the internet, any more than it's
reasonable to consider IPv4 as optional. But if you don't want it,
simply don't build it.
I believe the ipv6 module is going to be built in soon anyway.
http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html

I'd assumed that Dennis was talking about non-Fedora environments, since
ipv6 hasn't been meaningfully optional in Fedora for ages.

[Lennart Poettering]

Post by Matthew Garrett

On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett <mjg59 at srcf.ucam.org>
The point of providing a platform is that developers can make certain
assumptions about available functionality. It's no longer reasonable to
treat IPv6 as an optional part of the internet, any more than it's
reasonable to consider IPv4 as optional. But if you don't want it,
simply don't build it.
I believe the ipv6 module is going to be built in soon anyway.
http://lists.fedoraproject.org/pipermail/kernel/2011-June/003105.html

I'd assumed that Dennis was talking about non-Fedora environments, since
ipv6 hasn't been meaningfully optional in Fedora for ages.

Note that ipv6-less systems are explicitly supported by systemd, by
means of blacklisting the kmod in the modprobe configuration.

Lennart

[Simo Sorce]

Post by Lennart Poettering

Post by Lennart Poettering
We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

Post by Lennart Poettering
binary is just absurd. This way we also can ensure that the hostname

is

Post by Lennart Poettering
always initialised which is very useful for early boot logging and

other

Post by Lennart Poettering
stuff. On systemd you get the guarantee that the hostname is always

set

Post by Lennart Poettering
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.
Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for trouble.
What's the problem of having a specific hostname set up at boot time ?

Simo.

[Denys Vlasenko]

Post by Simo Sorce

Post by Lennart Poettering

Post by Lennart Poettering
We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

Post by Lennart Poettering
binary is just absurd. This way we also can ensure that the hostname

is

Post by Lennart Poettering
always initialised which is very useful for early boot logging and

other

Post by Lennart Poettering
stuff. On systemd you get the guarantee that the hostname is always

set

Post by Lennart Poettering
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.
Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for trouble.

I just tried it. So far flames don't shoot out of my notebook.

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot time?

The problem with having specific hostname I had is when I boot many
dozens of diskless machines off the very same network filesystem,
I definitely DONT want them to use the same hostname.

One method I saw in use in real world in this situation is to assign
hostnames by looking up (MAC_address,hostname) pairs in a database (say,
a config file), and then set the found hostname. Of course, this is not
possible until said database is available over network.

[Simo Sorce]

Post by Denys Vlasenko

Post by Simo Sorce

Post by Lennart Poettering

Post by Lennart Poettering
We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

Post by Lennart Poettering
binary is just absurd. This way we also can ensure that the hostname

is

Post by Lennart Poettering
always initialised which is very useful for early boot logging and

other

Post by Lennart Poettering
stuff. On systemd you get the guarantee that the hostname is always

set

Post by Lennart Poettering
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.
Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for trouble.

I just tried it. So far flames don't shoot out of my notebook.

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot time?

The problem with having specific hostname I had is when I boot many
dozens of diskless machines off the very same network filesystem,
I definitely DONT want them to use the same hostname.

But until you can get "the real one" you basically are.

Post by Denys Vlasenko
One method I saw in use in real world in this situation is to assign
hostnames by looking up (MAC_address,hostname) pairs in a database (say,
a config file), and then set the found hostname. Of course, this is not
possible until said database is available over network.

In this case you are not better/worse than before, once the network will
come up you'll add a script to change the hostname.
Setting it earlier in systemd makes no difference.

Simo.

[Denys Vlasenko]

Post by Simo Sorce

Post by Denys Vlasenko

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot time?

The problem with having specific hostname I had is when I boot many
dozens of diskless machines off the very same network filesystem,
I definitely DONT want them to use the same hostname.

But until you can get "the real one" you basically are.

Yes, and as far as it is a temporary condition for a few seconds at
boot, it's not a problem. So why the rush to set it as soon as possible
via systemd?

Post by Simo Sorce

Post by Denys Vlasenko
One method I saw in use in real world in this situation is to assign
hostnames by looking up (MAC_address,hostname) pairs in a database (say,
a config file), and then set the found hostname. Of course, this is not
possible until said database is available over network.

In this case you are not better/worse than before, once the network will
come up you'll add a script to change the hostname.
Setting it earlier in systemd makes no difference.

You continue to avoid answering my question: WHY systemd, a service
management tool, bothers with setting hostname? It's not its task!

I wouldn't bother much if it would be just one tiny bit of strange code
in systemd, but it is FAR from being the only such code. There are lots
of similar stuff, and it's not accidental.

Look at Lennart's presentation:


Slide 6:
"We can now boot a system shell-free"

IOW: shell is bad, my new shiny toy is good.


Slide 14:
"systemd is an Init System"
"systemd is a Platform"

systemd is a platform? Really? What next? systemd is an Aircraft
Carrier? More to the point: Lennart can call his program whatever he
wants, even Nuclear Submarine. The point is: some people might disagree
with having service management tool with Napoleonic aspirations. For
one, I do!


Slide 50:
"Shell is evil"
"Move to systemd, daemons, kernel, udev, ..."

Again, shell, a tool which endured for 40+ years, is suddenly "evil".
I don't think this being the consensus.


Slide 79:
"Substantial coverage of basic OS boot-up tasks, including fsck,
mount, quota, hwclock, readahead, tmpfiles, random-seed, console,
static module loading, early syslog, plymouth, shutdown, kexec,
SELinux, initrd+initrd-less boots, cryptsetup, ..."


That's what I refer to by "taking over the world".

Note that neither slides, nor this email thread produced an explanation
WHY all this stuff is thrown together into one project.
I mean, really, look at the list. Readahead? Random seed saving?!
Plymouth?!?!

What's going on here???

[seth vidal]

Post by Denys Vlasenko
"systemd is an Init System"
"systemd is a Platform"
systemd is a platform? Really? What next? systemd is an Aircraft
Carrier? More to the point: Lennart can call his program whatever he
wants, even Nuclear Submarine. The point is: some people might disagree
with having service management tool with Napoleonic aspirations. For
one, I do!
"Shell is evil"
"Move to systemd, daemons, kernel, udev, ..."
Again, shell, a tool which endured for 40+ years, is suddenly "evil".
I don't think this being the consensus.

I think this is the crux of the argument. It seemed to me one of the
goals of systemd was to stop having a wide variety of possible
mechanisms to do similar things. To intentionally remove the ability to
swap out components. Part of that was to make things faster, part of it
was to make them "simpler" (for uses of simpler meaning fewer options).

The trick is whether or not you agree with that as a set of goals.

If you do not then systemd is not fun and not for you.
If you do then you are happy with it.

I think the problem I've heard repeatedly is that a fair number of
people are surprised how the decisions about those goals were made.

I also think that as it becomes more well known: the lack of flexibility
in specific places in systemd will be patched out/around.

So, the items you're complaining about will become options or
configuration items when people with significant-enough clout demand
they change.

It happens all the time.

Some folks adapt to how things are and work with what their given.

Others take out a baseball bat and beat things until they work and send
their patches along.

Others still take out a checkbook and start writing checks or
alternatively, refrain from writing those checks.

-sv

[Karl Misselt]

Post by seth vidal

Post by Denys Vlasenko
"systemd is an Init System"
"systemd is a Platform"
systemd is a platform? Really? What next? systemd is an Aircraft
Carrier? More to the point: Lennart can call his program whatever he
wants, even Nuclear Submarine. The point is: some people might disagree
with having service management tool with Napoleonic aspirations. For
one, I do!
"Shell is evil"
"Move to systemd, daemons, kernel, udev, ..."
Again, shell, a tool which endured for 40+ years, is suddenly "evil".
I don't think this being the consensus.

I think this is the crux of the argument. It seemed to me one of the
goals of systemd was to stop having a wide variety of possible
mechanisms to do similar things. To intentionally remove the ability to
swap out components. Part of that was to make things faster, part of it
was to make them "simpler" (for uses of simpler meaning fewer options).
The trick is whether or not you agree with that as a set of goals.
If you do not then systemd is not fun and not for you.
If you do then you are happy with it.
I think the problem I've heard repeatedly is that a fair number of
people are surprised how the decisions about those goals were made.
I also think that as it becomes more well known: the lack of flexibility
in specific places in systemd will be patched out/around.
So, the items you're complaining about will become options or
configuration items when people with significant-enough clout demand
they change.

....

Post by seth vidal
-sv

Coming out of pure lurk mode - I think Seth's observations here
are true for a many of the things that have gone on in Fedora
recently (at the risk of opening wounds... eg. gnome3). Your
options are:

1) Complain
2) Get involved in the development to the point where you are one
of those with enough clout to 'demand change' - or at least do
1) with some concrete technical observations as devoid as possible
of vitriol and anger, at which point "Complain" would no longer really
be the correct term.
3) Quietly move on to something more suited to your needs.

For my part I've chosen 3). My servers have always run Scientific Linux
and I've migrated my laptop to SL6 rather than F15. My desktops and
those of my users have been updated to F14, though I'll 'support' F15 for
those who want to pursue that upgrade path. In the F14 EOL time frame,
I'll re-evaluate F16 wrt whether some of my issues with F15 have been
patched out/around and make a decision as to whether to fully migrate
away from Fedora at that point.

As a pure consumer of the product without the time to get involved with 2),
I don't think it's my place to pursue 1), nor would it be very
productive. If
you choose to pursue 1), I think you'd have more success and have a more
productive hearing if you were to also engage in 2). To pursue only 1),
as many
seem to, will only lead to bad blood and a sore head as you continue to
bang
it into that tree. To emphasize, this is not intended as a complaint or
a flame
towards those working on Fedora development - just an observation on where
time might be more productively spent for those who have a problem with
certain components/development directions in Fedora.
Returning to lurk mode,
-Karl

[Kevin Kofler]

Post by Karl Misselt
Coming out of pure lurk mode - I think Seth's observations here
are true for a many of the things that have gone on in Fedora
recently (at the risk of opening wounds... eg. gnome3).

If GNOME 3 is your problem, try KDE Plasma or Xfce.

Kevin Kofler

[Simo Sorce]

Post by Denys Vlasenko

Post by Simo Sorce

Post by Denys Vlasenko

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot time?

The problem with having specific hostname I had is when I boot many
dozens of diskless machines off the very same network filesystem,
I definitely DONT want them to use the same hostname.

But until you can get "the real one" you basically are.

Yes, and as far as it is a temporary condition for a few seconds at
boot, it's not a problem. So why the rush to set it as soon as possible
via systemd?

Seriously, what are you arguing about ?
It is so simple to set it via systemd and it *is* an init task that it
just fine to set it in there so all process will just have the right
answer from the get go.

Unless there is a *problem* with doing it early I really don't want to
get int the bike shedding here.

Post by Denys Vlasenko

Post by Simo Sorce

Post by Denys Vlasenko
One method I saw in use in real world in this situation is to assign
hostnames by looking up (MAC_address,hostname) pairs in a database (say,
a config file), and then set the found hostname. Of course, this is not
possible until said database is available over network.

In this case you are not better/worse than before, once the network will
come up you'll add a script to change the hostname.
Setting it earlier in systemd makes no difference.

You continue to avoid answering my question: WHY systemd, a service
management tool, bothers with setting hostname? It's not its task!

Because it *is* a system initialization task, and systemd can do it
better than a shell script called in a random order later on, without,
as far as I can see, any side effects in this case.

Post by Denys Vlasenko
I wouldn't bother much if it would be just one tiny bit of strange code
in systemd, but it is FAR from being the only such code. There are lots
of similar stuff, and it's not accidental.

It is definitely not accidental, but unless you have bugs to file, I
don't think complain generically about systemd architecture here is any
productive. We discussed systemd for quite a while here and it certainly
far from perfect, for some things probably not even "good" yet. But its
time to file bugs for real problems, not time for bike shedding on
architectural decision that have been taken quite a while ago, unless
you want to argue for getting rid of it completely and reverting back to
the previous init mechanism.

Simo.

[Denys Vlasenko]

Post by Simo Sorce

Post by Denys Vlasenko
I wouldn't bother much if it would be just one tiny bit of strange code
in systemd, but it is FAR from being the only such code. There are lots
of similar stuff, and it's not accidental.

It is definitely not accidental, but unless you have bugs to file, I
don't think complain generically about systemd architecture here is any
productive.

Where, in your opinion, is the place to discuss systemd architecture?

Post by Simo Sorce
We discussed systemd for quite a while here and it certainly
far from perfect, for some things probably not even "good" yet. But its
time to file bugs for real problems, not time for bike shedding on
architectural decision that have been taken quite a while ago.

I disagree, and I find the attitude "we are developers, you are idiot"
both quite common and quite wrong.

I am a developer too, do you want me to treat *you* this way too when
you will have trouble with my software?

[Rahul Sundaram]

Post by Denys Vlasenko

Post by Simo Sorce

Post by Denys Vlasenko
I wouldn't bother much if it would be just one tiny bit of strange code
in systemd, but it is FAR from being the only such code. There are lots
of similar stuff, and it's not accidental.

It is definitely not accidental, but unless you have bugs to file, I
don't think complain generically about systemd architecture here is any
productive.

Where, in your opinion, is the place to discuss systemd architecture?

systemd upstream list as I has been pointed out a few times

http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Post by Denys Vlasenko
I disagree, and I find the attitude "we are developers, you are idiot"
both quite common and quite wrong.
I am a developer too, do you want me to treat *you* this way too when
you will have trouble with my software?

I don't think you are helping yourself with the antagonistic approach
you have taken. If I had trouble with your software, I would start by
asking questions on why things the way they are rather than immediately
start telling you, the way you have written it is entirely wrong.

Rahul

[Lennart Poettering]

Post by Denys Vlasenko

Post by Simo Sorce

Post by Denys Vlasenko
I wouldn't bother much if it would be just one tiny bit of strange code
in systemd, but it is FAR from being the only such code. There are lots
of similar stuff, and it's not accidental.

It is definitely not accidental, but unless you have bugs to file, I
don't think complain generically about systemd architecture here is any
productive.

Where, in your opinion, is the place to discuss systemd architecture?

systemd is being discussed on the systemd mailing list and on the IRC
channel. This is much like most projects are discussed on their
respective mailing lists and IRC channels, and you should know that.

Post by Denys Vlasenko

Post by Simo Sorce
We discussed systemd for quite a while here and it certainly
far from perfect, for some things probably not even "good" yet. But its
time to file bugs for real problems, not time for bike shedding on
architectural decision that have been taken quite a while ago.

I disagree, and I find the attitude "we are developers, you are idiot"
both quite common and quite wrong.

Oh come on. I have wide open ears. If people make constructive
suggestions we listen, and we change things. We'll not change everything,
and not without very good reasons, but claiming we wouldn't listen is
just insulting. I am pretty sure you you will find a bunch of people who
will testify that we implemented a feature they requested on this ML, on
bz, at a conference, on IRC or some other place for them. Or we fixed a
bug for them, or we even changed behaviour of systemd in one way or
another on their request. Making a good case, being polite and
convincing gets you a long way. systemd is developed in the open. You
can easily participate in various ways.

However, if you come overly late to the party, are insulting and
demanding, imply we are idiots OR SHOUT ALL THE TIME, then we might be
less willing to consider your requests.

Lennart

[Simo Sorce]

Post by Denys Vlasenko

Post by Simo Sorce

Post by Denys Vlasenko

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot time?

The problem with having specific hostname I had is when I boot many
dozens of diskless machines off the very same network filesystem,
I definitely DONT want them to use the same hostname.

But until you can get "the real one" you basically are.

Yes, and as far as it is a temporary condition for a few seconds at
boot, it's not a problem. So why the rush to set it as soon as possible
via systemd?

Seriously, what are you arguing about ?
It is so simple to set it via systemd and it *is* an init task that it
just fine to set it in there so all process will just have the right
answer from the get go.

Unless there is a *problem* with doing it early I really don't want to
get int the bike shedding here.

Post by Denys Vlasenko

Post by Simo Sorce

Post by Denys Vlasenko
One method I saw in use in real world in this situation is to assign
hostnames by looking up (MAC_address,hostname) pairs in a database (say,
a config file), and then set the found hostname. Of course, this is not
possible until said database is available over network.

In this case you are not better/worse than before, once the network will
come up you'll add a script to change the hostname.
Setting it earlier in systemd makes no difference.

You continue to avoid answering my question: WHY systemd, a service
management tool, bothers with setting hostname? It's not its task!

Because it *is* a system initialization task, and systemd can do it
better than a shell script called in a random order later on, without,
as far as I can see, any side effects in this case.

Post by Denys Vlasenko
I wouldn't bother much if it would be just one tiny bit of strange code
in systemd, but it is FAR from being the only such code. There are lots
of similar stuff, and it's not accidental.

It is definitely not accidental, but unless you have bugs to file, I
don't think complain generically about systemd architecture here is any
productive. We discussed systemd for quite a while here and it certainly
far from perfect, for some things probably not even "good" yet. But its
time to file bugs for real problems, not time for bike shedding on
architectural decision that have been taken quite a while ago, unless
you want to argue for getting rid of it completely and reverting back to
the previous init mechanism.

Simo.

[Lennart Poettering]

Post by Denys Vlasenko

Post by Simo Sorce
In this case you are not better/worse than before, once the network will
come up you'll add a script to change the hostname.
Setting it earlier in systemd makes no difference.

You continue to avoid answering my question: WHY systemd, a service
management tool, bothers with setting hostname? It's not its task!

As mentioned already: so that all userspace can rely on a valid hostname
to be set. Which makes things much nicer for early boot logging as one
example. And then there is simplicity, because you need no further
configured service deps and you use less resources too, and it's simpler
to read the sources, and faster, and more robust.

Post by Denys Vlasenko
"We can now boot a system shell-free"
IOW: shell is bad, my new shiny toy is good.

Oh god. If you had listened you'd have understood that my aim is to
deemphasize shell in the boot process, not as an interactive tool or
scripting tool. It's about the boot process, and nothing but the boot
process.

And as a matter of fact in all my talks I explicitly underline that
fact.

You are FUDding, and it's not helpful.

Post by Denys Vlasenko
"systemd is an Init System"
"systemd is a Platform"
systemd is a platform? Really? What next? systemd is an Aircraft
Carrier?

That is not a technical argument, but just FUDing. Of course, systemd is
not an aircraft carrier. If all arguments you can come up with are made
up arguments then you have no arguments at all. If you want to criticise
systemd, then do it on technical grounds, not FUDing with things I never
said and you sucked out of your fingers.

Post by Denys Vlasenko
More to the point: Lennart can call his program whatever he
wants, even Nuclear Submarine. The point is: some people might disagree
with having service management tool with Napoleonic aspirations. For
one, I do!

Good for you then.

Post by Denys Vlasenko
"Shell is evil"
"Move to systemd, daemons, kernel, udev, ..."
Again, shell, a tool which endured for 40+ years, is suddenly "evil".
I don't think this being the consensus.

Yeah, it's not the right tool for the boot process. Doesn't mean it
wasn't useful for interactive use or for scripting. Just not the right
tool for the boot process. Since you seem to have trouble understanding
that, let me repeat it a couple of times: shell is not the best tool to
accomplish a quick and reliable bootup. shell is not the best tool to
accomplish a quick and reliable bootup. shell is not the best tool to
accomplish a quick and reliable bootup. shell is not the best tool to
accomplish a quick and reliable bootup. shell is not the best tool to
accomplish a quick and reliable bootup.

Post by Denys Vlasenko
"Substantial coverage of basic OS boot-up tasks, including fsck,
mount, quota, hwclock, readahead, tmpfiles, random-seed, console,
static module loading, early syslog, plymouth, shutdown, kexec,
SELinux, initrd+initrd-less boots, cryptsetup, ..."
That's what I refer to by "taking over the world".

Well, I just refer to that as "systemd as a platform for building an OS from".

Post by Denys Vlasenko
Note that neither slides, nor this email thread produced an explanation
WHY all this stuff is thrown together into one project.

In fact those slides you refer to explain all that. If you don't listen
and don't want to read, then I cannot help you. One last try with
different words, nonetheless: simplicity, speed, robustness,
compactness, functionality.

Lennart

[Denys Vlasenko]

Post by Lennart Poettering

Post by Denys Vlasenko
"We can now boot a system shell-free"
IOW: shell is bad, my new shiny toy is good.

Oh god. If you had listened you'd have understood that my aim is to
deemphasize shell in the boot process

You go quite farther than that.

"We can now boot a system shell-free". *Shell-free*.

You are not saying "driving boot process by shell scripts is slow
because ... ... ..." (an argument I would agree with), you are
aiming at *eliminating* shell scripts from boot process.

Post by Lennart Poettering

Post by Denys Vlasenko
"systemd is an Init System"
"systemd is a Platform"
systemd is a platform? Really? What next? systemd is an Aircraft
Carrier?

That is not a technical argument, but just FUDing.

No, it is a technical argument. I am saying that this is not how things
are supposed to be done in Unix. I am saying that you are trying to
incorporate as much stuff as possible into systemd, and I think it's
wrong. You don't like me saying this? Well, not a surprise.
I also don't like when people tell me that I'm wrong.

Post by Lennart Poettering

Post by Denys Vlasenko
"Shell is evil"
"Move to systemd, daemons, kernel, udev, ..."
Again, shell, a tool which endured for 40+ years, is suddenly "evil".
I don't think this being the consensus.

Yeah, it's not the right tool for the boot process. Doesn't mean it
wasn't useful for interactive use or for scripting. Just not the right
tool for the boot process. Since you seem to have trouble understanding
that, let me repeat it a couple of times: shell is not the best tool to
accomplish a quick and reliable bootup.

Can shell play a part in the boot process, or is it now completely
banished? I don't know, is something like this acceptable in the new
world of systemd?

ulimit -d $((16*1024*1024))
exec my_favorite_program some_opts

Post by Lennart Poettering

Post by Denys Vlasenko
"Substantial coverage of basic OS boot-up tasks, including fsck,
mount, quota, hwclock, readahead, tmpfiles, random-seed, console,
static module loading, early syslog, plymouth, shutdown, kexec,
SELinux, initrd+initrd-less boots, cryptsetup, ..."
That's what I refer to by "taking over the world".

Well, I just refer to that as "systemd as a platform for building an OS from".

Post by Denys Vlasenko
Note that neither slides, nor this email thread produced an explanation
WHY all this stuff is thrown together into one project.

In fact those slides you refer to explain all that. If you don't listen
and don't want to read, then I cannot help you. One last try with
different words, nonetheless: simplicity, speed, robustness,
compactness, functionality.

Good that you don't include "modularity" any more. At least one of my
arguments reached through, it seems.

Let's take a look at each of them:

simplicity - I don't see it
speed - yes
robustness - actually yes, your code seems to be good in that area
compactness - no
functionality - too much of it. I'd call it bloat

I would also add "monolithic and inflexible". Sorry.

[Lennart Poettering]

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
"We can now boot a system shell-free"
IOW: shell is bad, my new shiny toy is good.

Oh god. If you had listened you'd have understood that my aim is to
deemphasize shell in the boot process

You go quite farther than that.
"We can now boot a system shell-free". *Shell-free*.

Yupp, and this is one of the reasons why we boot so fast and can boot
a reasonably comprehensive userspace in less than one second.

A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean,
I use bash all the time, it's a key way how I interface with my
machine. I use it in build scripts and everything, and I have no plans
at all to remove it from that and doing that would be crazy. But in the
boot process? I don't think it is the best tool for the job, and
unnecessary, and if we deemphasize or remove it from the boot process we
have a lot to win.

Post by Denys Vlasenko
You are not saying "driving boot process by shell scripts is slow
because ... ... ..." (an argument I would agree with), you are
aiming at *eliminating* shell scripts from boot process.

Yes, I want to deemphasize the shell in the boot process, and ideally
remove it entirely from the boot process.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
"systemd is an Init System"
"systemd is a Platform"
systemd is a platform? Really? What next? systemd is an Aircraft
Carrier?

That is not a technical argument, but just FUDing.

No, it is a technical argument. I am saying that this is not how things
are supposed to be done in Unix. I am saying that you are trying to
incorporate as much stuff as possible into systemd, and I think it's
wrong. You don't like me saying this? Well, not a surprise.
I also don't like when people tell me that I'm wrong.

Wow, you honestly believe that suggesting systemd would turn into an
aircraft carrier is a technical argument? Must be good stuff you are
smoking...

I think we'll just have to agree to disagree and leave it at that.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
"Shell is evil"
"Move to systemd, daemons, kernel, udev, ..."
Again, shell, a tool which endured for 40+ years, is suddenly "evil".
I don't think this being the consensus.

Yeah, it's not the right tool for the boot process. Doesn't mean it
wasn't useful for interactive use or for scripting. Just not the right
tool for the boot process. Since you seem to have trouble understanding
that, let me repeat it a couple of times: shell is not the best tool to
accomplish a quick and reliable bootup.

Can shell play a part in the boot process, or is it now completely
banished? I don't know, is something like this acceptable in the new
world of systemd?

systemd will not take /bin/sh away from you. It will just give you the
right tools so that you don't need it anymore for booting, thus saving
resources, making things faster and more robust. We will continue to
support SysV init scripts for a long time, for compatibility reasons,
and you'll always be able to plug a shell script into the ExecStart=
line of a systemd service file, if you want to.

Post by Denys Vlasenko
ulimit -d $((16*1024*1024))
exec my_favorite_program some_opts

Sure you can do that, systemd will not take that away from you. However,
we offer you a nicer, more descriptive, more homogenous way to do that in
the service file itself, simply by using LimitDATA= in the service
file. Easier to use, more descriptive, faster and involves no shell.

Post by Denys Vlasenko

Post by Lennart Poettering
In fact those slides you refer to explain all that. If you don't listen
and don't want to read, then I cannot help you. One last try with
different words, nonetheless: simplicity, speed, robustness,
compactness, functionality.

Good that you don't include "modularity" any more. At least one of my
arguments reached through, it seems.

Uh? systemd is modular. Absolutely, you can choose the parts you want
and the ones you don't, which is handy for embedded uses.

If you however ask why we integrate a lot of previously separate stuff
in systemd, then answering "to make it modular" would be kinda
bogus. systemd is absolutely modular, but modularity is not a reason for
integrating things the way we do.

Oh, and the list above why we do this is not complete anyway, there's a lot I
could still add as reasons why we integrate things like this. For
example we want to use systemd as gentle push for the distros using it
to unify, standardize and de-balkanize the basic set of components of
the OS.

Post by Denys Vlasenko
simplicity - I don't see it

What's so hard to understand, that with systemd you need 10 basic
packages to build a minimal system, and without systemd you need
50. systemd is hence much simpler to understand. (these are not exact numbers)

Post by Denys Vlasenko
speed - yes
robustness - actually yes, your code seems to be good in that area
compactness - no

Oh hell, absolutely. It's much more compact, since you need to build
only 10 instead of 50 packages to build your basic system...

Post by Denys Vlasenko
functionality - too much of it. I'd call it bloat

Well, I call a system bloated that is build from a myriad of separate
packages, with lots of glue kludges inbetween, and enourmous amounts of
duplication. However a systemd which simplifies, unifies, streamlines
the chaotic set of existing basic building blocks into a few, integrated
well-written ones, that's what I call the opposite of bloat, and that's
what systemd is.

Post by Denys Vlasenko
I would also add "monolithic and inflexible". Sorry.

Well, it's neither monolithic nor inflexbile, it's pretty much the
contrary. But I have enough of this nonsense. We have to agree to
disagree. I'll leave you to your opinions -- how wrong they might be.

Lennart

[Denys Vlasenko]

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
"We can now boot a system shell-free"
IOW: shell is bad, my new shiny toy is good.

Oh god. If you had listened you'd have understood that my aim is to
deemphasize shell in the boot process

You go quite farther than that.
"We can now boot a system shell-free". *Shell-free*.

Yupp, and this is one of the reasons why we boot so fast and can boot
a reasonably comprehensive userspace in less than one second.

Wrong. Running shell scripts per se is not a significant slowdown.
daemontools does it all the time. It just *runs them in parallel*.

Performing system initialization *from* shell scripts *is* significant
slowdown, because writing parallelized init in shell, correctly, is not
easy.

Post by Lennart Poettering
A shell-free boot doesn't mean there wasn't any /bin/sh anymore. I mean,
I use bash all the time, it's a key way how I interface with my
machine. I use it in build scripts and everything, and I have no plans
at all to remove it from that and doing that would be crazy.

I never thought you want to do that. No argument here.

Post by Lennart Poettering
But in the boot process? I don't think it is the best tool for the job, and
unnecessary, and if we deemphasize or remove it from the boot process we
have a lot to win.

I don't think this is the only your motivation. You want to acquire as
much "turf" as possible. Killing shell scripts everywhere in init
process and requiring everyone to use systemd's way to set ulimit and
whatnot etc will give you significant amounts of authority and "power".
Packaging people will be forced to come to you and ask for this and that
(anything they could do in shell scripts, but not they can't). This will
feel good, right? You will be such an important guy!

I don't see any other reason for the crusade to eliminate shell
scripting from boot process. You are too clever to actually believe that
shell script start time is the biggest problem in boot time.

Post by Lennart Poettering
systemd will not take /bin/sh away from you. It will just give you the
right tools so that you don't need it anymore for booting, thus saving
resources, making things faster and more robust. We will continue to
support SysV init scripts for a long time, for compatibility reasons,
and you'll always be able to plug a shell script into the ExecStart=
line of a systemd service file, if you want to.

Post by Denys Vlasenko
ulimit -d $((16*1024*1024))
exec my_favorite_program some_opts

Sure you can do that, systemd will not take that away from you. However,
we offer you a nicer, more descriptive, more homogenous way to do that in
the service file itself, simply by using LimitDATA= in the service
file. Easier to use, more descriptive, faster and involves no shell.

Exactly as I suspected. Your new shiny way is better than our stupid old
way. Except that I was quite happy with the old stupid way of setting
data segment limit. I don't want to learn new way just to stroke your
oversized ego by being forced to do it your way.

daemontools has it right: it doesn't force me to abandon what worked so
well for 40 years. It allowed me to run a service by writing a small
shell script which can set, say, ulimit. Or cd to a directory. Or
chroot. Or export a variable. Or mkdir /var/run/FOO...

[Olav Vitters]

Post by Denys Vlasenko
(anything they could do in shell scripts, but not they can't). This will
feel good, right? You will be such an important guy!

I think most lurkers have understood you seem to have some personal
issues with Lennart. Please still show some respect or continue in
private please.

[Przemek Klosowski]

Post by Denys Vlasenko
You go quite farther than that.
"We can now boot a system shell-free". *Shell-free*.
You are not saying "driving boot process by shell scripts is slow
because ... ... ..." (an argument I would agree with), you are
aiming at *eliminating* shell scripts from boot process.

I think the key word here is 'can': Lennart is saying that shell is slow
and unreliable and systemd allows you to engineer a streamlined boot
process that brings all the necessary parts of the system up without the
shell. He's not eliminating the possibility of using shell for any
additional stuff, if that's what you want---just like you can get it to
run a telnetd service, you should be able to run '/bin/sh myscript' service.

Post by Denys Vlasenko

Post by Denys Vlasenko
"systemd is an Init System"
"systemd is a Platform"

I am saying that this is not how things
are supposed to be done in Unix. I am saying that you are trying to
incorporate as much stuff as possible into systemd, and I think it's
wrong.
[...]
I would also add "monolithic and inflexible". Sorry.

You argue that it should be possible to tailor systemd to bring up a
different system than Lennart imagined. It seems to me that it's
reasonable that you need a different systemd, then. There are several
ways of approaching this, from the most crude to most elegant:

- edit the part of systemd where Lennart starts the services and
compile your own version
- reconfigure via compile-time conditionals
- reconfigure at run-time via loadable modules, like the kernel

I think that currently systemd is not configurable in the second and
third sense. I agree with you that it be more in the Unix way for it to
be configurable.

I wonder if it's worth the effort to make it run-time configurable, even
if it could use some existing run-time modular infrastructure, e.g. from
the kernel.

[Bill Nottingham]

Post by Denys Vlasenko

Post by Simo Sorce
In this case you are not better/worse than before, once the network will
come up you'll add a script to change the hostname.
Setting it earlier in systemd makes no difference.

You continue to avoid answering my question: WHY systemd, a service
management tool, bothers with setting hostname? It's not its task!

It's part of the task of booting the system. For example, rc.sysinit,
in order:

1) mount assorted psuedo-filesystems
2) print a welcome message
3) start udev
a.) set clock
b.) initialize console settings
c.) bring up loopback
4) load ancient legacy module scripts
5) run sysctl
6) set hostname
... whole bunch of other stuff after this elided ...

None of these were user-modifiable actions; attempting to change any of
these is a void-your-warranty-you-get-all-pieces action.

So, in migrating to systemd, we have an opportunity to examine each of
these actions that's done at boot, and decide the most appopriate place
for it.

For the above items, 1, 2, 3a, 3c, and 6 are done in systemd itself. 3, 3b,
4, and 5 are done as standard systemd units.

If you're seriously arguing that we should have instead made all these
things configurable, I'm not really interested - they weren't before, and
making them configurable isn't really useful for making a standardized OS
platform.

If you want to discuss which is done in which place during startup, we
can do that, but at that point we're arguing over details which aren't all
that relevant.

Post by Denys Vlasenko
"Shell is evil"
"Move to systemd, daemons, kernel, udev, ..."
Again, shell, a tool which endured for 40+ years, is suddenly "evil".
I don't think this being the consensus.

It's a needless pejorative, yes. But it doesn't change the fact that
shell is highly overused in our prior boot process. ~1000 lines
of initscripts + functions to cover what is essentially 'exec atd'
is overkill, and isn't really needed.

Post by Denys Vlasenko
"Substantial coverage of basic OS boot-up tasks, including fsck,
mount, quota, hwclock, readahead, tmpfiles, random-seed, console,
static module loading, early syslog, plymouth, shutdown, kexec,
SELinux, initrd+initrd-less boots, cryptsetup, ..."
That's what I refer to by "taking over the world".

Yes, it's obviously taking over the world by:

- changing where fsck is called from point A to point B
- changing where mount is called from point A to point B
- loading policy from init, *just as it was with SysVinit*
- adding features to support initrd-less boots (which we didn't have
before)
- handling shutdown (WTF is your init system supposed to do if not
this?)

Bill

[Lennart Poettering]

Post by Denys Vlasenko

Post by Simo Sorce

Post by Lennart Poettering

Post by Lennart Poettering
We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

Post by Lennart Poettering
binary is just absurd. This way we also can ensure that the hostname

is

Post by Lennart Poettering
always initialised which is very useful for early boot logging and

other

Post by Lennart Poettering
stuff. On systemd you get the guarantee that the hostname is always

set

Post by Lennart Poettering
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.
Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for trouble.

I just tried it. So far flames don't shoot out of my notebook.

Wow, that's convincing proof.

Lennart

[Steve Clark]

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Simo Sorce

Post by Lennart Poettering

Post by Lennart Poettering
We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

Post by Lennart Poettering
binary is just absurd. This way we also can ensure that the hostname

is

Post by Lennart Poettering
always initialised which is very useful for early boot logging and

other

Post by Lennart Poettering
stuff. On systemd you get the guarantee that the hostname is always

set

Post by Lennart Poettering
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.
Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for trouble.

I just tried it. So far flames don't shoot out of my notebook.

Wow, that's convincing proof.
Lennart

One question - does systemd run /etc/rc.local script?
If not where do I put my own little things I want to happen at boot up.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: [phone]
Fax: [phone]
Email: steve.clark at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110614/10141acb/attachment.html

[Lennart Poettering]

Post by Steve Clark

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Simo Sorce

Post by Lennart Poettering

Post by Lennart Poettering
We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

Post by Lennart Poettering
binary is just absurd. This way we also can ensure that the hostname

is

Post by Lennart Poettering
always initialised which is very useful for early boot logging and

other

Post by Lennart Poettering
stuff. On systemd you get the guarantee that the hostname is always

set

Post by Lennart Poettering
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.
Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for trouble.

I just tried it. So far flames don't shoot out of my notebook.

Wow, that's convincing proof.
Lennart

One question - does systemd run /etc/rc.local script?
If not where do I put my own little things I want to happen at boot up.

Yes, it does run that on Fedora by default.

Lennart

[Lennart Poettering]

Post by Simo Sorce

Post by Lennart Poettering

Post by Lennart Poettering
We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a

separate

Post by Lennart Poettering
binary is just absurd. This way we also can ensure that the hostname

is

Post by Lennart Poettering
always initialised which is very useful for early boot logging and

other

Post by Lennart Poettering
stuff. On systemd you get the guarantee that the hostname is always

set

Post by Lennart Poettering
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.
Why do you set up stuff no one asked you to?

Changing a machine hostname at random times is just asking for
trouble.

Well, but it has been used in the past, and as definitely something we
should support in one way or another. Which is why we have this:

https://fedoraproject.org/wiki/Features/nssmyhostname

and

http://www.freedesktop.org/wiki/Software/systemd/hostnamed

and there are even people working on sending out change notifications
from /proc/sys/kernel/hostname in the kernel.

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot time ?

The user might want to change it? DHCP wants to change it? Name conflict
in the local network, and Avahi wants to change it? Of course, the
latter we don't necessarily want to do by default, but they are valid uses.

Lennart

[Simo Sorce]

Post by Lennart Poettering

Post by Simo Sorce
Changing a machine hostname at random times is just asking for trouble.

Well, but it has been used in the past, and as definitely something we
should support in one way or another.

Never said we shouldn't allow it to change, just that if you do some
things may break in more or less evident ways.

Post by Lennart Poettering
https://fedoraproject.org/wiki/Features/nssmyhostname
and
http://www.freedesktop.org/wiki/Software/systemd/hostnamed
and there are even people working on sending out change notifications
from /proc/sys/kernel/hostname in the kernel.

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot

time ?
The user might want to change it?

Does setting it at boot time prevent you from changing it later ?

Post by Lennart Poettering
DHCP wants to change it? Name conflict in the local network, and Avahi
wants to change it? Of course, the latter we don't necessarily want to
do by default, but they are valid uses.

There is always good reasons to change it at one time or another, none
of these say it is a bad idea to set it early though.

In general I see 3 categories of machine:
- diskless machines that needs to get the hostname from DHCP as they
have no local configuration storage whatsoever
- personal, un-managed machines that can change name on a whim.
- managed machines, that may have keytabs and can never change name but
use things like dynDNS instead to tell other machines where they are.

Simo.

[Lennart Poettering]

Post by Simo Sorce

Post by Simo Sorce

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot

time ?
The user might want to change it?

Does setting it at boot time prevent you from changing it later ?

No, systemd will initialize it at boot and is happy if you change it later.

Lennart

[Simo Sorce]

Post by Lennart Poettering

Post by Simo Sorce

Post by Simo Sorce

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot

time ?
The user might want to change it?

Does setting it at boot time prevent you from changing it later ?

No, systemd will initialize it at boot and is happy if you change it later.

As I thought, then I see no problem here.

Simo.

[Dan Williams]

Post by Simo Sorce

Post by Lennart Poettering

Post by Simo Sorce

Post by Simo Sorce

Post by Simo Sorce
What's the problem of having a specific hostname set up at boot

time ?
The user might want to change it?

Does setting it at boot time prevent you from changing it later ?

No, systemd will initialize it at boot and is happy if you change it later.

As I thought, then I see no problem here.

systemd might be happy if you change it later, but other stuff is not.
The canonical example is X, where the hostname was used as the xauth key
to allow you to actually talk to the X server. When the hostname
changed, there was no authorization for the new hostname in your xauth
file, so starting new apps would silently fail. Basing *anything* like
that on your machine hostname is just stupid. It might work for you,
but it doesn't work for lots of other people, so lets fix it for
everyone. And we did back in the F10 timeframe
with /etc/X11/xinit/xinitrc.d/localuser.sh where we just let any local
user connect, since that's exactly what xauth's hostname thing was
supposed to do anyway.

The next example is apps that try to find out your IP address by looking
up your hostname. That's completely broken too. Do you have multiple
interfaces? Multiple IP addresses? Are you behind NAT? Yeah, all that
will torpedo hostname->IP lookups. Hostnames are *informational* and
are never a good way to identify anything concrete on a local machine.
That didn't used to be the case, but now it is. Things change in 40
years.

Dan

[Adam Jackson]

Post by Dan Williams
systemd might be happy if you change it later, but other stuff is not.
The canonical example is X, where the hostname was used as the xauth key
to allow you to actually talk to the X server. When the hostname
changed, there was no authorization for the new hostname in your xauth
file, so starting new apps would silently fail. Basing *anything* like
that on your machine hostname is just stupid. It might work for you,
but it doesn't work for lots of other people, so lets fix it for
everyone. And we did back in the F10 timeframe
with /etc/X11/xinit/xinitrc.d/localuser.sh where we just let any local
user connect, since that's exactly what xauth's hostname thing was
supposed to do anyway.

To clarify, we allow local connections where the UID of the connecting
process matches the one specified in the xhost call (which is run after
you've established a session, so you know the UID of the user whose
session is trying to connect). Dan's statement could be read that we
allow connections from any local user at all, which is definitely not
true.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110615/3b872c8c/attachment.bin

[Simo Sorce]

Post by Dan Williams
The next example is apps that try to find out your IP address by looking
up your hostname. That's completely broken too. Do you have multiple
interfaces? Multiple IP addresses? Are you behind NAT? Yeah, all that
will torpedo hostname->IP lookups. Hostnames are *informational* and
are never a good way to identify anything concrete on a local machine.
That didn't used to be the case, but now it is. Things change in 40
years.

The hostname is still used a lot in many kerberos aware programs to try
to match the keys in keytabs, we are slowly trying to get over that by
matching any key that can actually decrypt the ticket you are receiving,
but still many programs initialize GSSAPI passing in the hostname. Until
all software is fixed (NFS server is still one of them although we are
in the process of fixing it) changing the hostname arbitrarily is still
problematic.

Simo.

[Kevin Kofler]

Post by Denys Vlasenko
Try "rm /usr/sbin/console-kit-daemon". Works like a charm.

Randomly removing pieces of installed packages has never been supported.

Kevin Kofler

[Miroslav Lichvar]

Post by Kevin Kofler

Post by Denys Vlasenko
Try "rm /usr/sbin/console-kit-daemon". Works like a charm.

Randomly removing pieces of installed packages has never been supported.

I think the console-kit-daemon service can be disabled, but xinit
prefixes xsession with ck-xinit-session which seems to start the
daemon on demand. It would be nice if xinit could be configured to not
use it. Same for ssh-agent.

[Kevin Kofler]

Post by Miroslav Lichvar
I think the console-kit-daemon service can be disabled, but xinit
prefixes xsession with ck-xinit-session which seems to start the
daemon on demand. It would be nice if xinit could be configured to not
use it.

ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able
to access your hardware without it.

Kevin Kofler

[Miroslav Lichvar]

Post by Kevin Kofler

Post by Miroslav Lichvar
I think the console-kit-daemon service can be disabled, but xinit
prefixes xsession with ck-xinit-session which seems to start the
daemon on demand. It would be nice if xinit could be configured to not
use it.

ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able
to access your hardware without it.

You can still manage permissions of the devices by other means, which
may fit better your use cases. I have edited the xinitrc-common
script, but it's not marked as config, so the change is lost after
every xorg-x11-xinit update.

[Reindl Harald]

Post by Kevin Kofler

Post by Miroslav Lichvar
I think the console-kit-daemon service can be disabled, but xinit
prefixes xsession with ck-xinit-session which seems to start the
daemon on demand. It would be nice if xinit could be configured to not
use it.

ConsoleKit is not optional (at least in Fedora 7 to 15). You won't be able
to access your hardware without it

so tell me why our main server runs without even for usb-devices?
fedora 9 - 14

/etc/rc.local
# nobody needs
killall console-kit-daemon 2> /dev/null > /dev/null


[root at arrakis:~]$ ps aux | grep -i console
root 13685 0.0 0.0 105440 864 pts/1 S+ 17:36 0:00 grep --color -i console

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110614/01dfabcc/attachment.bin

[Lennart Poettering]

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
kmod_setup(); <=== ???

We load a couple of kernel modules which systemd needs, and are
sometimes compiled as module only and which cannot be autoloaded for a
reason or another. This is ipv6, autofs4, unix.ko, and we load them
explicitly so that we can use them.

You assume that everyone uses IPv6. This is not true.

No I am not. You can still blacklist the ipv6 module if you want to via
the normal modprobe blacklisting mechanisms. (As mentioned, systemd
passes -b to the modprobe command line to ensure that). I explicitly
said that in a previous mail.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
hostname_setup(); <=== ???

We invoke sethostname() from inside systemd since that is one of the
most trivial system calls known to men and doing this with a separate
binary is just absurd. This way we also can ensure that the hostname is
always initialised which is very useful for early boot logging and other
stuff. On systemd you get the guarantee that the hostname is always set
up if you run in userspace,

You can't possibly know what kind of (possibly dynamic) hostname
admin might want to assign to his machine. The static hostname
may be as useless as default "(none)" which is set by kernel.
Anyway, logging with default hostname is not a catastrophe.

(none) is what the bash makes from empty hostname, which is the
default. We just fill in one.

Just because systemd sets up a hostname at boot it doesnt mean it
couldn't be changed dynamically later on. In fact if you are into
dynamic hostnames you should send me a big cake for my birthday as thank
you, because I give you stuff like this for F16:

https://fedoraproject.org/wiki/Features/nssmyhostname

http://www.freedesktop.org/wiki/Software/systemd/hostnamed

Post by Denys Vlasenko
Why do you set up stuff no one asked you to?

Yeah, I explained that already.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
machine_id_setup(); <=== ???

Similar to the hostname we ensure that the machine id is always
initialized, and has the same lifetime and validity guarantees as the
hostname. i.e. that it is simply usable by *every* process started,
regardless when.

Point me at one program which uses machine id. I never saw one.
And anyway, why do you set up stuff no one asked you to?

/etc/machine-id is a generalization of the D-Bus machine id, which is
used by quite a number of programs directly and indirectly. With systemd
we try to make this available globally and independently of D-Bus and
add new semantics for stateless systems.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?

Because we need to constantly send updates to it. It's a trivial socket
operation. It's a trivial thing and spawning a separate process to send
those updates each and every single time is a major waste of resources
and basically doubles the processes we have to spawn at boot.

Plymouth is not a part of Unix. Init process has no business knowing
about distro specific stuff like that.

Well, since you appear to have invented Unix I think we simply have to
disagree here.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
This is an antithesis to modular, Unix way of doing things.

Just because you can turn each trivial operation into a separate binary
you shouldn't necessarily do that.

Where did I propose turning everything into a separate binary?

Well, I say calling sethostname() is a syscall we should simply do in
PID 1 and then forget about, but you want this in a separate process
(hence separate binary).

Post by Denys Vlasenko

Post by Lennart Poettering
It is what makes your system slow and
heavy-weight. Insisting that we invoke sethostname() in a separate
process is just stupid. I am mean, come on, think about it. It is *ONE*
system call to the the hostname with sethostname(). Invoking
/bin/hostname instead is at least 40 or so (and many of those quite
heavy weight). And really, why are we even discussing the frickin
hostname like this?

Because it's a perfect example of a thing init process has no business
doing. Ever. The lightness of the syscall is irrelevant. For example,
you also do modprobing of various things, which is far from being
"just one syscall", so this argument is moot.

Well, I guess we simply have to disagree. My interest is a tighly
integrated, small, minimal, lightweight system. Yours seem to be a big,
archaic, chaotic, redundant, resource intensive system. But that's fine.

Post by Denys Vlasenko

Post by Lennart Poettering
Do you know what "mono" means? It's greek and means "one". And "lithic"
means "stone". And if systemd communicates with Plymouth, then this is
not monolothic at all, since systemd and ply are two processes, not
one.

Init process should not have intrinsic knowledge about splash screens!

systemd knows nothing about splash screens. All it does is send status
updates to Plymouth.

Post by Denys Vlasenko
This is basic idea of modularity. This is how Unix always worked.
Things should not be *too* interconnected. Things should be modular.

And they are. Plymouth and systemd are two separate modules, which
however communicate with each other (actually, strictly one way).

Post by Denys Vlasenko
In your presentation, you have "Integration" as slide 17 and
"Modularization" as slide 18. Do you realize that these are the opposite
things? "More integration" means "less modularization". You can't have
both.

Oh, of course you have. You must have that. The kernel for example is
one module of the OS, your syslog another, and and your cron
another. And don't tell me they wouldn't communicate with each
other. They do; *of course* they do. Modularization without
communication is uselessness.

Post by Denys Vlasenko

Post by Lennart Poettering
systemd is not running Plymouth stuff in the same process, is it merely
communicating with it.

Thanks that at least for now you don't have plans to incorporate
Plymouth.

Dude, "for now", thanks for that. I mean, thanks for implying I had evil
plans which I just wouldn't show right now. I mean seriously dude,
there's really no point in doubting everything I say. Because if you do
I see little point in even bothering with responding to you. Because if
you want to believe what you believe regardless what I say I see no
point in saying it.

Post by Denys Vlasenko

Post by Lennart Poettering
No, systemd tries to load those modules but if you are into retro
computing you can still blacklist them using the usual modprobe
blacklisting, and systemd will honour that (i.e. by passing -b to
modprobe).

Post by Denys Vlasenko
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.

Nah. udev loads modules automatically.

udev loads modules according to config file, not by hard-coding stuff in
C code. IOW: udev does not load modules which *udev developer*
wants, it loads modules which *admin* wants. (Of course,
admin might choose to use standard config, but he does this
on his own volition).

That is simply not true. Of course the autoloading rules are all
compiled into the kmods.

Post by Denys Vlasenko

Post by Lennart Poettering
In fact on almost all systems
there should be no need to ever load a module manually.

Maybe. It's not up to a piece of software to decide.
In Unix, admins should have power to decide, not programs.
Programs provide the means, they don't dictate policies.

Dude, systemd requires the functionality of the three modules it loads
explicitly. It needs it at a time where udev is not running, hence
autoloading doesn't work. There is *no* *other* *option* to work
properly than to explicitly load those modules.

And really, systemd honours the modprobe blacklist, and does so
explicitly (i.e. the modprobe -b switch), so systemd enforces very
little. it just makes sure it works properly in the default case on
distros which do not compile the modules in question into the kernel.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
Today I can remove CK from my Fedora install if I want to.

You'll be left with very little if you do that.

Try "rm /usr/sbin/console-kit-daemon". Works like a charm.

Yeah, and equally well or badly "rm /lib/systemd/systemd-logind" will
work.

Post by Denys Vlasenko

Post by Lennart Poettering
But why would you even want to remove that?

If I would be willing to work in an OS with attitudes like this,
I'd be hacking in Windows. I don't.

You apparently have very little idea how Windows works.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering
I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.

I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.

daemontools does not support socket activation for parallelizing
execution of servers with its clients. So yes, we can beat *that*.

I said "you can't beat *that* on resource front". On resource front.
Can you beat it on resource front?

I mean, this is like comparing apples and oranges. systemd gives you an
OS building box, daemontools nothing but a service supervisor. If you
use daemontools you also need an init system, and boot scripts, and
everything else. So yeah, if you compare systemd and
daemontools+sysvinit+initscripts then, hell yeah, I can beat that.

Post by Denys Vlasenko

Post by Lennart Poettering
Hmm? systemd is an init system, so it is of course PID 1.

Again. *Why it has to have PID 1* to spawn and control services?
Can you please answer this?

Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized
processes.

Lennart

[Denys Vlasenko]

Post by Lennart Poettering

Post by Denys Vlasenko
Maybe. It's not up to a piece of software to decide.
In Unix, admins should have power to decide, not programs.
Programs provide the means, they don't dictate policies.

Dude, systemd requires the functionality of the three modules it loads
explicitly.

systemd requires ipv6.
And you pitch systemd to be used by embedded devices.

Do you really think all embedded devices will be happy with having such
an arbitrary requirement? Heck, I know embedded device people who remove
even ipv4!

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering
I think systemd is much more optimized that what existed
previously. (what else is parallelization but optimization?) I bet with
you that a systemd system (modulo SELinux) can be built in a way that
uses much less resources and boot time than one built on Upstart.

I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.

daemontools does not support socket activation for parallelizing
execution of servers with its clients. So yes, we can beat *that*.

I said "you can't beat *that* on resource front". On resource front.
Can you beat it on resource front?

I mean, this is like comparing apples and oranges. systemd gives you an
OS building box, daemontools nothing but a service supervisor.

Which is what I *like* about daemontools. It's Unix way to be "nothing
but" a tool for one purpose, ans serve it well.

Post by Lennart Poettering
If you
use daemontools you also need an init system, and boot scripts, and
everything else. So yeah, if you compare systemd and
daemontools+sysvinit+initscripts then, hell yeah, I can beat that.

This is not true.

daemontools can be set up in a way than most init scripts are
no longer necessary. It also achieves parallelized start.

It can also be used as an init replacement, but unlike systemd, it does
not make it a requirement.

On my home machine I use a separate init (which does only child
reaping), daemontools, and a very small set of init scripts (yes,
horror, shell scripts). It starts in about 3 seconds. The system fully
booted to text mode uses 20 megs of RAM total, all processes plus
kernel, but excluding fs cache.

You can't beat that. In fact, you are yet to reply why systemd uses
eleven megs of RAM all by itself.


daemontools don't do socket activation, therefore I'm not proposing
we use daemontools instead of systems. IOW, I do not claim that
daemontools is a better service management tool that systemd.

I do argue that deamontools goal to provide ONLY service management
instead of being "shampoo and conditioner in one pack" is a better
approach.

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering
Hmm? systemd is an init system, so it is of course PID 1.

Again. *Why it has to have PID 1* to spawn and control services?
Can you please answer this?

Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized
processes.

Why service daemon needs to receive death notifications from daemonized
processes?

[&quot;Andy Green (林安廸)&quot;]

On 06/14/2011 11:17 AM, Somebody in the thread at some point said:

Hi -

Post by Denys Vlasenko

Post by Lennart Poettering
Dude, systemd requires the functionality of the three modules it loads
explicitly.

systemd requires ipv6.
And you pitch systemd to be used by embedded devices.
Do you really think all embedded devices will be happy with having such
an arbitrary requirement? Heck, I know embedded device people who remove
even ipv4!

IPv6 is optional though, Lennart says you can blacklist the module. If
it acts gracefully if IPv6 is not builtin or installable by module then
all is well.

"Embedded" as an argument needs a lot of care. It means several very
different things, but many of those things are out of scope for Fedora,
eg, ARM7. (Use busybox there ^^)

For what's left, eg ARM9+ that you can run normal Linux and Fedora on,
ipv6 is going to be workable if the memory allows. Looking a year or
two ahead, where "Embedded" will extend to Cortex A15 quad core, and
IPv6 will presumably have gained traction, the tradeoffs involved with
cutdown environments like busybox / dropbear and IPv4-only are going to
start being harder to accept.

So while it's super healthy to press system tools on bloat, it is quite
possible to deploy the "Embedded" argument to go too far and conflict
with what Fedora is and trying to do overall -- and what other Embedded
guys will want from it in future. "Embedded" is generally converging
towards the kind of full strength systems we use on x86 today.

-Andy

[Denys Vlasenko]

Post by &quot;Andy Green (林安廸)&quot;

Post by Denys Vlasenko

Post by Lennart Poettering
Dude, systemd requires the functionality of the three modules it loads
explicitly.

systemd requires ipv6.
And you pitch systemd to be used by embedded devices.
Do you really think all embedded devices will be happy with having such
an arbitrary requirement? Heck, I know embedded device people who remove
even ipv4!

IPv6 is optional though, Lennart says you can blacklist the module. If
it acts gracefully if IPv6 is not builtin or installable by module then
all is well.
"Embedded" as an argument needs a lot of care. It means several very
different things, but many of those things are out of scope for Fedora,
eg, ARM7. (Use busybox there ^^)
For what's left, eg ARM9+ that you can run normal Linux and Fedora on,
ipv6 is going to be workable if the memory allows. Looking a year or
two ahead, where "Embedded" will extend to Cortex A15 quad core, and
IPv6 will presumably have gained traction, the tradeoffs involved with
cutdown environments like busybox / dropbear and IPv4-only are going to
start being harder to accept.

I talk to a lot of embedded people. Tiny machines are not going to
disappear anytime soon - they just go into smaller and smaller gadgets.

For example, there are still a noticeable segment of NOMMU CPUs, meaning
if you really target embedded, you need to learn how to live with vfork
only.

You can't just handwave embedded away by assuming that "embedded will
get big enough for me to not really care about optimizing for size".

[Rahul Sundaram]

Post by Denys Vlasenko
I talk to a lot of embedded people. Tiny machines are not going to
disappear anytime soon - they just go into smaller and smaller gadgets.
For example, there are still a noticeable segment of NOMMU CPUs, meaning
if you really target embedded, you need to learn how to live with vfork
only.
You can't just handwave embedded away by assuming that "embedded will
get big enough for me to not really care about optimizing for size".

Since ipv6 is really optional in systemd, why are you even arguing about
this at all, anymore?

Rahul

[Lucas]

Is not it easy to remove everything from:
default.target
basic.target
graphical.target
...

and then add whatever we want to start or to execute or mount?

I do not really care what systemd CAN do, but really care what it is doing on my system.
So, may be some cleaning will be the wise solution.


One would like to eat fish
Eat one's cake and have it
? ????? ???? ? ???? ????.

[&quot;Andy Green (林安廸)&quot;]

Post by Denys Vlasenko

Post by &quot;Andy Green (林安廸)&quot;
For what's left, eg ARM9+ that you can run normal Linux and Fedora on,
ipv6 is going to be workable if the memory allows. Looking a year or
two ahead, where "Embedded" will extend to Cortex A15 quad core, and
IPv6 will presumably have gained traction, the tradeoffs involved with
cutdown environments like busybox / dropbear and IPv4-only are going to
start being harder to accept.

I talk to a lot of embedded people. Tiny machines are not going to
disappear anytime soon - they just go into smaller and smaller gadgets.

Me too... I think maybe considerations valid at the low-end devices you
know very well are blinding you a bit to how applicable those
considerations are, eg -->

Post by Denys Vlasenko
For example, there are still a noticeable segment of NOMMU CPUs, meaning
if you really target embedded, you need to learn how to live with vfork
only.

... NOMMU and ARM7 that can't run Fedora are to discussions about
architecture of Fedora.

Post by Denys Vlasenko
You can't just handwave embedded away by assuming that "embedded will
get big enough for me to not really care about optimizing for size".

My point was that pressure against bloat is good.

But when I look at compromises made in stuff commonly used in ARM7 /
cross world, I wouldn't want to see that happening in Fedora in the name
of a debloating jihad that simply doesn't matter on most of the
platforms it targets.

Still, I hope this thread at least reminded people that it doesn't hurt
to have a modest memory footprint ^^

-Andy

[Lennart Poettering]

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko
Maybe. It's not up to a piece of software to decide.
In Unix, admins should have power to decide, not programs.
Programs provide the means, they don't dictate policies.

Dude, systemd requires the functionality of the three modules it loads
explicitly.

systemd requires ipv6.

No it doesn't.

All it does is make use of IPv6 if it is available (where available
means: if compiled in to the kernel or compiled as kmod and not
blacklisted). It requires the kernel module to be loaded properly at
boot to make use of that, hence it will try loading it, unless it is
explicitly blacklisted.

Post by Denys Vlasenko
And you pitch systemd to be used by embedded devices.

Yes, I do.

Post by Denys Vlasenko
Do you really think all embedded devices will be happy with having such
an arbitrary requirement? Heck, I know embedded device people who remove
even ipv4!

I said multiple times explicitly that systemd explicitly supports
IPv6-less systems.

Post by Denys Vlasenko

Post by Lennart Poettering
If you
use daemontools you also need an init system, and boot scripts, and
everything else. So yeah, if you compare systemd and
daemontools+sysvinit+initscripts then, hell yeah, I can beat that.

This is not true.

It is.

Post by Denys Vlasenko
daemontools can be set up in a way than most init scripts are
no longer necessary. It also achieves parallelized start.

This is bogus.

Post by Denys Vlasenko
It can also be used as an init replacement, but unlike systemd, it does
not make it a requirement.
On my home machine I use a separate init (which does only child
reaping), daemontools, and a very small set of init scripts (yes,
horror, shell scripts). It starts in about 3 seconds. The system fully
booted to text mode uses 20 megs of RAM total, all processes plus
kernel, but excluding fs cache.

Good for you, but what does that have to do with Fedora?

Post by Denys Vlasenko
You can't beat that. In fact, you are yet to reply why systemd uses
eleven megs of RAM all by itself.

Hey, read my mails: SELinux policy, SELinux policy, SELinux policy,
SELinux policy, SELinux policy.

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering
Hmm? systemd is an init system, so it is of course PID 1.

Again. *Why it has to have PID 1* to spawn and control services?
Can you please answer this?

Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized
processes.

Why service daemon needs to receive death notifications from daemonized
processes?

To be able to supervise them? That's a key feature of supervision of
services: that you know when a daemon is gone, and know the exit code
and whether it crashed or not.

Lennart

[Denys Vlasenko]

Post by Denys Vlasenko
daemontools can be set up in a way than most init scripts are

Post by Denys Vlasenko
no longer necessary. It also achieves parallelized start.

This is bogus.

Amazingly deep argument. Can you do better than this?

Post by Denys Vlasenko

Post by Denys Vlasenko

Post by Lennart Poettering

Post by Denys Vlasenko

Post by Lennart Poettering
Hmm? systemd is an init system, so it is of course PID 1.

Again. *Why it has to have PID 1* to spawn and control services?
Can you please answer this?

Yupp, read up on Unix. Only PID 1 gets SIGCHLD for daemonized
processes.

Why service daemon needs to receive death notifications from daemonized
processes?

To be able to supervise them? That's a key feature of supervision of
services: that you know when a daemon is gone, and know the exit code
and whether it crashed or not.

This is bogus (c) Lennart.

You can't know that because you have no idea that dead process with pid
N is a daemon you started for service FOO. Because when you started it,
its pid was not N (if it really did daemonize).

With sufficient amount of nutty hackery it may be possible to figure is
out, but it will be either racy, or will require labeling (process
groups? session ids? cgroups?) which, in general, is not reliable:
processes can escape from that.

Much saner solution is to simply require controlled processes to not
daemonize. (Today it is a common practice to equip every daemon with a
"don't daemonize" switch for this, so it's not a problem.) This way,
service management tool will get death notifications in a natural way,
via its parent-child relationship with the service process.

[Casey Dahlin]

Post by Denys Vlasenko
With sufficient amount of nutty hackery it may be possible to figure is
out, but it will be either racy, or will require labeling (process
processes can escape from that.

Cgroups. And it is reliable. And processes cannot escape it. That's part
of why Cgroups were created, because all of the other options you
mentioned have precisely the flaw you point out. Cgroups does not.

--CJD