8:07 a.m.
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...
--
vda
8:36 a.m.
On 06/10/2011 03:07 PM, Denys Vlasenko wrote:
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.
Why does systemd link against libpam?
systemd does logins now, not /bin/login or gdm or ...?
to implement PAMName= (man systemd.exec)
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.
libwrap? systemd is a network application now too?
to implement TCPWrapName= (man systemd.exec)
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
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
8:59 a.m.
On 06/10/2011 09:36 AM, Michal Schmidt wrote:
On 06/10/2011 03:07 PM, Denys Vlasenko wrote:
> 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.
> Why does systemd link against libpam?
> systemd does logins now, not /bin/login or gdm or ...?
to implement PAMName= (man systemd.exec)
> 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.
> libwrap? systemd is a network application now too?
to implement TCPWrapName= (man systemd.exec)
> 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
> 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????
Michal
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
9:11 a.m.
On 06/10/2011 03:59 PM, Steve Clark wrote:
On 06/10/2011 09:36 AM, Michal Schmidt wrote:
> 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
11:58 a.m.
On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote:
On 06/10/2011 03:59 PM, Steve Clark wrote:
> On 06/10/2011 09:36 AM, Michal Schmidt wrote:
>> 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?
--
vda
2:06 p.m.
On Fri, Jun 10, 2011 at 5:58 PM, Denys Vlasenko <dvlasenk(a)redhat.com> wrote:
On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote:
> On 06/10/2011 03:59 PM, Steve Clark wrote:
> > On 06/10/2011 09:36 AM, Michal Schmidt wrote:
> >> 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?
--
mike c
2:13 p.m.
On 06/11/2011 12:36 AM, mike cloaked wrote:
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
3:44 p.m.
On Fri, Jun 10, 2011 at 8:13 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 06/11/2011 12:36 AM, mike cloaked wrote:
> 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 c
3:48 p.m.
On Fri, Jun 10, 2011 at 9:44 PM, mike cloaked <mike.cloaked(a)gmail.com> wrote:
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
--
mike c
5:13 p.m.
On 06/10/2011 04:44 PM, mike cloaked wrote:
On Fri, Jun 10, 2011 at 8:13 PM, Rahul
Sundaram<metherid(a)gmail.com> wrote:
> On 06/11/2011 12:36 AM, mike cloaked wrote:
>> 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.
--
Regards,
OldFart
6:50 p.m.
On 06/10/2011 03:13 PM, Rahul Sundaram wrote:
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.
9:31 p.m.
On 06/11/2011 05:20 AM, Genes MailLists wrote:
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
[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
3:04 a.m.
On 11 Jun 2011 03:35, "Rahul Sundaram" <metherid(a)gmail.com> wrote:
On 06/11/2011 05:20 AM, Genes MailLists wrote:
> 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
> [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
6:03 a.m.
On Sat, Jun 11, 2011 at 12:50 AM, Genes MailLists <lists(a)sapience.com>wrote:
On 06/10/2011 03:13 PM, Rahul Sundaram wrote:
> 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.
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.
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].
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.
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.git2011...
[3] https://bugzilla.gnome.org/show_bug.cgi?id=649773
11:42 p.m.
On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote:
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
1:19 a.m.
On Sun, Jun 12, 2011 at 6:42 AM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote:
>
> 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.
11:01 a.m.
On Sun, Jun 12, 2011 at 08:19:03AM +0200, drago01 wrote:
On Sun, Jun 12, 2011 at 6:42 AM, Toshio Kuratomi
<a.badger(a)gmail.com> wrote:
> On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote:
>>
>> 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
11:23 a.m.
On Sun, Jun 12, 2011 at 6:01 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Sun, Jun 12, 2011 at 08:19:03AM +0200, drago01 wrote:
> On Sun, Jun 12, 2011 at 6:42 AM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> > On Sat, Jun 11, 2011 at 12:03:33PM +0100, Peter Robinson wrote:
> >>
> >> 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 ;)
3:33 a.m.
On Fri, 10.06.11 19:50, Genes MailLists (lists(a)sapience.com) wrote:
On 06/10/2011 03:13 PM, Rahul Sundaram wrote:
> 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.
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.
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
--
Lennart Poettering - Red Hat, Inc.
3:54 p.m.
On Mon, Jun 13, 2011 at 10:33:19AM +0200, Lennart Poettering wrote:
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
3:17 a.m.
On Fri, 10.06.11 18:58, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Fri, 2011-06-10 at 16:11 +0200, Michal Schmidt wrote:
> On 06/10/2011 03:59 PM, Steve Clark wrote:
> > On 06/10/2011 09:36 AM, Michal Schmidt wrote:
> >> 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
--
Lennart Poettering - Red Hat, Inc.
11:42 a.m.
On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
> 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.
> libwrap? systemd is a network application now too?
to implement TCPWrapName= (man systemd.exec)
Again, why it has to be done *by systemd*?
On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote:
> 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.
--
vda
noon
On 06/10/2011 08:42 PM, Denys Vlasenko wrote:
On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
>> 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.
>> libwrap? systemd is a network application now too?
>
> to implement TCPWrapName= (man systemd.exec)
Again, why it has to be done *by systemd*?
On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote:
>> 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.
8:18 p.m.
On Fri, 10 Jun 2011 18:42:11 +0200 Denys Vlasenko wrote:
On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
> > 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.
> > 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
3:21 a.m.
On Fri, 10.06.11 18:42, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
> > 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.
But memory consumption is not really the gist of my argument,
it's:
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.
> > 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
--
Lennart Poettering - Red Hat, Inc.
9:09 a.m.
On 06/10/2011 09:07 AM, Denys Vlasenko wrote:
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...
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: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
12:02 p.m.
On Fri, Jun 10, 2011 at 9:07 AM, Denys Vlasenko <dvlasenk(a)redhat.com> wrote:
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)
2:55 p.m.
New subject: systemd memory usage
On 6/10/11 9:07 AM, Denys Vlasenko wrote:
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
4:55 p.m.
New subject: systemd memory usage
On Fri, 10 Jun 2011 15:55:14 -0400 Adam Jackson wrote:
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
5:18 p.m.
New subject: systemd memory usage
On Fri, 2011-06-10 at 15:55 -0400, Adam Jackson wrote:
On 6/10/11 9:07 AM, Denys Vlasenko wrote:
> 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
Woot! Fame at last! :)
Various comments inline below...
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
[...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.
C string data 12,964 630,672
...
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
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.
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
3:17 a.m.
On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko <dvlasenk(a)redhat.com> wrote:
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 ;)
4:15 a.m.
On Sat, Jun 11, 2011 at 9:17 AM, drago01 <drago01(a)gmail.com> wrote:
On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko
<dvlasenk(a)redhat.com>
wrote:
> 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
11:18 a.m.
On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote:
On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko
<dvlasenk(a)redhat.com> wrote:
> 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! :( :( :(
~11MB equals ~8 cents of RAM ... so meh.
Are you volunteering to buy more RAM for every Fedora user? ;)
--
vda
12:35 p.m.
New subject: effective communication and effective free software
On 6/13/11 12:18 PM, Denys Vlasenko wrote:
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).
Instead, when you say things like:
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
6:14 a.m.
New subject: effective communication and effective free software
On Mon, 2011-06-13 at 13:35 -0400, Adam Jackson wrote:
On 6/13/11 12:18 PM, Denys Vlasenko wrote:
> 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.
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.
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...
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?
Instead, when you say things like:
> 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.
--
vda
3 a.m.
On Mon, 13.06.11 18:18, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote:
> On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko <dvlasenk(a)redhat.com> wrote:
> > 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! :( :( :(
> ~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
--
Lennart Poettering - Red Hat, Inc.
7:53 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/14/2011 04:00 AM, Lennart Poettering wrote:
On Mon, 13.06.11 18:18, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
>
> On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote:
>> On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko <dvlasenk(a)redhat.com>
wrote:
>>> 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! :( :( :(
>
>
>> ~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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk33Wb0ACgkQrlYvE4MpobNmgQCgw65ed5f489YvTnB4XZ6fMbxG
X+0AnRi2iUSSuqsb/GzIPeXg5lLh8Cr1
=L1oe
-----END PGP SIGNATURE-----
9:11 a.m.
On Tue, 2011-06-14 at 08:53 -0400, Daniel J Walsh wrote:
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.
--
Stephen Smalley
National Security Agency
3:03 a.m.
On Mon, 13.06.11 18:18, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote:
> On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko <dvlasenk(a)redhat.com> wrote:
> > 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! :( :( :(
> ~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
--
Lennart Poettering - Red Hat, Inc.
9:44 a.m.
On Tue, 2011-06-14 at 10:03 +0200, Lennart Poettering wrote:
On Mon, 13.06.11 18:18, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
>
> On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote:
> > On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko <dvlasenk(a)redhat.com>
wrote:
> > > 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! :( :( :(
>
>
> > ~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.
--
Stephen Smalley
National Security Agency
10:03 a.m.
On Wed, Jun 15, 2011 at 4:44 PM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
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.
- 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
10:12 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/15/2011 11:03 AM, Miloslav Trma? wrote:
On Wed, Jun 15, 2011 at 4:44 PM, Stephen Smalley
<sds(a)tycho.nsa.gov> wrote:
> 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.
- 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk34y+MACgkQrlYvE4MpobNqQgCgyXPAzaA15Cjsaq7BmZoy+5s5
kRYAn3hf6N4QbNFaPyszp4L6i7vHhlSR
=/ZtQ
-----END PGP SIGNATURE-----
10:22 a.m.
On Wed, Jun 15, 2011 at 11:12:35AM -0400, Daniel J Walsh wrote:
On 06/15/2011 11:03 AM, Miloslav Trma? wrote:
> On Wed, Jun 15, 2011 at 4:44 PM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
>> 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.
> - 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
10:35 a.m.
On Wed, Jun 15, 2011 at 5:12 PM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
On 06/15/2011 11:03 AM, Miloslav Trma? wrote:
> - 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.
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
6:51 a.m.
On Wed, Jun 15, 2011 at 05:35:19PM +0200, Miloslav Trmač wrote:
On Wed, Jun 15, 2011 at 5:12 PM, Daniel J Walsh
<dwalsh(a)redhat.com> wrote:
> On 06/15/2011 11:03 AM, Miloslav Trma? wrote:
>> - 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.
> 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?)
Rather than writing from scratch, modify:
http://augeas.net/libfa/
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
3:15 a.m.
On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
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.
I understand your desire to replace everything by systemd.
I have no such desire.
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.
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.
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.
libwrap? systemd is a network application now too?
Yupp, Google for "socket activation systemd".
libdbus?... this is a lost battle I guess...
Yupp, since Upstart used that already since ages.
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).
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).
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.
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.
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
--
Lennart Poettering - Red Hat, Inc.
8:27 a.m.
Hi Lennart,
On Mon, 2011-06-13 at 10:15 +0200, Lennart Poettering wrote:
On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> 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.
> 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...)
> 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.
> 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.
(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.
> 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".
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...
> 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 :)
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.
> 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.
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.
--
vda
10:29 a.m.
On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
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.
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).
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.
"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.
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.
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.
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.
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.
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).
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.
> 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.
/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.
(Also, most of them don't emit useful info on --help...)
They aren't user binaries. They are in /lib/systemd, not /usr/bin...
> > 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).
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?
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!
> 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*.
> 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.
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
> 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.
> 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
--
Lennart Poettering - Red Hat, Inc.
11:01 a.m.
On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
> "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.
> What is /lib/systemd/systemd-fsck then?
A wrapper, which handles the exit code and reacts properly to it.
> (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
2:51 a.m.
On Mon, 13.06.11 18:01, Miloslav Trmač (mitr(a)volny.cz) wrote:
On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
>> "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.
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.
>> (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
--
Lennart Poettering - Red Hat, Inc.
11:01 a.m.
On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote:
On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> 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.
> 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?
> 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?
> "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.
> 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?
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.
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.
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.
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).
> 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).
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.
> > > 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).
> 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.
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.
> > 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.
> > 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?
--
vda
11:05 a.m.
On Mon, Jun 13, 2011 at 06:01:22PM +0200, Denys Vlasenko wrote:
On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote:
> 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.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:13 a.m.
On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett <mjg59(a)srcf.ucam.org>wrote:
On Mon, Jun 13, 2011 at 06:01:22PM +0200, Denys Vlasenko wrote:
> On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote:
> > 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
11:19 a.m.
On Mon, Jun 13, 2011 at 05:13:39PM +0100, Peter Robinson wrote:
On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org>
wrote:
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.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
2:43 a.m.
On Mon, 13.06.11 17:19, Matthew Garrett (mjg59(a)srcf.ucam.org) wrote:
On Mon, Jun 13, 2011 at 05:13:39PM +0100, Peter Robinson wrote:
> On Mon, Jun 13, 2011 at 5:05 PM, Matthew Garrett <mjg59(a)srcf.ucam.org>
> wrote:
> 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
--
Lennart Poettering - Red Hat, Inc.
11:37 a.m.
On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:
> 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?
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.
--
Simo Sorce * Red Hat, Inc * New York
12:02 p.m.
On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote:
On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:
> > 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?
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.
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.
--
vda
12:30 p.m.
On Mon, 2011-06-13 at 19:02 +0200, Denys Vlasenko wrote:
On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote:
> On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:
> > > 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?
>
> 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.
> 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.
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.
--
Simo Sorce * Red Hat, Inc * New York
3:46 p.m.
On Mon, 2011-06-13 at 13:30 -0400, Simo Sorce wrote:
> > 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?
> 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???
--
vda
4:10 p.m.
On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote:
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.
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
5:26 p.m.
On 06/13/2011 02:10 PM, seth vidal wrote:
On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote:
> 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.
>
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.
....
-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
--
--------------------------------------------------------------------
| Karl A. Misselt Office: Steward 254 |
| Steward Observatory Phone: 520-626-0196 |
| University of Arizona FAX: 520-621-9555 |
| Tucson, AZ 85721-0065 misselt(a)as.arizona.edu |
--------------------------------------------------------------------
| Malo Periculosam Libertatem Quam Quietum Servitium |
--------------------------------------------------------------------
8:44 p.m.
On Mon, 2011-06-13 at 22:46 +0200, Denys Vlasenko wrote:
On Mon, 2011-06-13 at 13:30 -0400, Simo Sorce wrote:
> > > 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.
> > 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.
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.
--
Simo Sorce * Red Hat, Inc * New York
2:20 a.m.
On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote:
> 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?
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?
--
vda
2:31 a.m.
On 06/14/2011 12:50 PM, Denys Vlasenko wrote:
On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote:
>> 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
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
3:32 a.m.
On Tue, 14.06.11 09:20, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Mon, 2011-06-13 at 21:44 -0400, Simo Sorce wrote:
> > 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.
> 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
--
Lennart Poettering - Red Hat, Inc.
3:20 a.m.
On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> 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.
Slide 6:
"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.
Slide 14:
"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.
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.
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.
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.
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".
Well, I just refer to that as "systemd as a platform for building an OS from".
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
--
Lennart Poettering - Red Hat, Inc.
5:36 a.m.
On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote:
On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> Slide 6:
> "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.
> Slide 14:
> "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.
> 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.
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
> 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".
Well, I just refer to that as "systemd as a platform for building an OS from".
> 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.
--
vda
6:14 a.m.
On Tue, 14.06.11 12:36, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> > Slide 6:
> > "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.
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.
> > Slide 14:
> > "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.
> > 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.
>
> 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.
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.
> 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.
Let's take a look at each of them:
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)
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...
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.
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
--
Lennart Poettering - Red Hat, Inc.
6:42 a.m.
On Tue, 2011-06-14 at 13:14 +0200, Lennart Poettering wrote:
On Tue, 14.06.11 12:36, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
>
> On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote:
> > On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> > > Slide 6:
> > > "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.
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.
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.
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.
> 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...
--
vda
7:01 a.m.
On Tue, Jun 14, 2011 at 01:42:42PM +0200, Denys Vlasenko wrote:
(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.
--
Regards,
Olav
10:18 a.m.
On 06/14/2011 06:36 AM, Denys Vlasenko wrote:
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.
>> Slide 14:
>> "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.
2 p.m.
Denys Vlasenko (dvlasenk(a)redhat.com) said:
> 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.
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.
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.
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".
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
3:06 a.m.
On Mon, 13.06.11 19:02, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote:
> On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:
> > > 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?
>
> 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
--
Lennart Poettering - Red Hat, Inc.
6:14 a.m.
On 06/14/2011 04:06 AM, Lennart Poettering wrote:
On Mon, 13.06.11 19:02, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote:
>> On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:
>>>> 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?
>> 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: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
6:15 a.m.
On Tue, 14.06.11 07:14, Steve Clark (sclark(a)netwolves.com) wrote:
On 06/14/2011 04:06 AM, Lennart Poettering wrote:
>On Mon, 13.06.11 19:02, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
>
>>On Mon, 2011-06-13 at 12:37 -0400, Simo Sorce wrote:
>>>On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:
>>>>>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?
>>>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 - Red Hat, Inc.
2:53 a.m.
On Mon, 13.06.11 12:37, Simo Sorce (simo(a)redhat.com) wrote:
On Mon, 2011-06-13 at 18:01 +0200, Denys Vlasenko wrote:
> > 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?
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.
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
--
Lennart Poettering - Red Hat, Inc.
6:25 a.m.
On Tue, 2011-06-14 at 09:53 +0200, Lennart Poettering wrote:
> 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.
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.
> 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 ?
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.
--
Simo Sorce * Red Hat, Inc * New York
7:08 a.m.
On Tue, 14.06.11 07:25, Simo Sorce (simo(a)redhat.com) wrote:
> > 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
--
Lennart Poettering - Red Hat, Inc.
9:21 a.m.
On Tue, 2011-06-14 at 14:08 +0200, Lennart Poettering wrote:
On Tue, 14.06.11 07:25, Simo Sorce (simo(a)redhat.com) wrote:
> > > 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.
--
Simo Sorce * Red Hat, Inc * New York
9:23 p.m.
On Tue, 2011-06-14 at 10:21 -0400, Simo Sorce wrote:
On Tue, 2011-06-14 at 14:08 +0200, Lennart Poettering wrote:
> On Tue, 14.06.11 07:25, Simo Sorce (simo(a)redhat.com) wrote:
>
> > > > 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
8:40 a.m.
On Tue, 2011-06-14 at 21:23 -0500, Dan Williams wrote:
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
1:17 p.m.
On Wed, 2011-06-15 at 09:40 -0400, Adam Jackson wrote:
On Tue, 2011-06-14 at 21:23 -0500, Dan Williams wrote:
> 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.
Yeah, I was loose with the details. Thanks for clearing that up.
Dan
9:12 a.m.
On Tue, 2011-06-14 at 21:23 -0500, Dan Williams wrote:
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.
--
Simo Sorce * Red Hat, Inc * New York
2:50 a.m.
On Tue, Jun 14, 2011 at 01:13:01AM +0200, Kevin Kofler wrote:
Denys Vlasenko wrote:
> 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.
--
Miroslav Lichvar
9:36 a.m.
Miroslav Lichvar wrote:
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
10:33 a.m.
On Tue, Jun 14, 2011 at 04:36:25PM +0200, Kevin Kofler wrote:
Miroslav Lichvar wrote:
> 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.
--
Miroslav Lichvar
10:38 a.m.
Am 14.06.2011 16:36, schrieb Kevin Kofler:
Miroslav Lichvar wrote:
> 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@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
2:42 a.m.
On Mon, 13.06.11 18:01, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
>
> > 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.
> > 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
Why do you set up stuff no one asked you to?
Yeah, I explained that already.
> > 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.
> > "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.
> > 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).
> 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.
> 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.
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).
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.
> 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.
> 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).
>
> > 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.
> 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.
> > 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.
> 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.
> > > 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.
> 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
--
Lennart Poettering - Red Hat, Inc.
5:17 a.m.
On Tue, 2011-06-14 at 09:42 +0200, Lennart Poettering wrote:
On Mon, 13.06.11 18:01, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> 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!
> > > > 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.
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.
> > 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?
--
vda
5:31 a.m.
On 06/14/2011 11:17 AM, Somebody in the thread at some point said:
Hi -
> 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
5:43 a.m.
On Tue, 2011-06-14 at 11:31 +0100, "Andy Green (林安廸)" wrote:
>> 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".
--
vda
5:44 a.m.
On 06/14/2011 04:13 PM, Denys Vlasenko wrote:
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
5:57 a.m.
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
И волки сыты и овцы целы.
6:03 a.m.
On 06/14/2011 11:43 AM, Somebody in the thread at some point said:
> 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 -->
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.
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
5:53 a.m.
On Tue, 14.06.11 12:17, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
On Tue, 2011-06-14 at 09:42 +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 18:01, Denys Vlasenko (dvlasenk(a)redhat.com) wrote:
> > 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.
And you pitch systemd to be used by embedded devices.
Yes, I do.
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.
> 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.
daemontools can be set up in a way than most init scripts are
no longer necessary. It also achieves parallelized start.
This is bogus.
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?
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.
> > > 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
--
Lennart Poettering - Red Hat, Inc.
6:55 a.m.
On Tue, 2011-06-14 at 12:53 +0200, Lennart Poettering wrote:
daemontools can be set up in a way than most init scripts are
> no longer necessary. It also achieves parallelized start.
This is bogus.
Amazingly deep argument. Can you do better than this?
> > > > 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.
--
vda
12:48 p.m.
On Tue, Jun 14, 2011 at 01:55:08PM +0200, Denys Vlasenko wrote:
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.
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
8:51 p.m.
On Mon, 2011-06-13 at 15:27 +0200, Denys Vlasenko wrote:
"plymouth_running()"? Plymouth? Systemd knows about
plymouth? Why?
Because it has implications for the correct handoff of tty1, I believe.
This was one of the trickier things to get right in systemd.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4697
days inactive
4704
days old
101 comments
34 participants
participants (34)
-
Adam Jackson -
Adam Williamson -
Andy Green -
Bill Nottingham -
Casey Dahlin -
Clyde E. Kunkel -
Colin Walters -
Dan Williams -
Daniel J Walsh -
David Malcolm -
Denys Vlasenko -
drago01 -
Genes MailLists -
Jakub Jelinek -
Karl Misselt -
Kevin Kofler -
Lennart Poettering -
Lucas -
Matthew Garrett -
Michal Schmidt -
mike cloaked -
Miloslav Trmač -
Miroslav Lichvar -
Olav Vitters -
Peter Robinson -
Przemek Klosowski -
Rahul Sundaram -
Reindl Harald -
Richard W.M. Jones -
Seth Vidal -
Simo Sorce -
Stephen Smalley -
Steve Clark -
Toshio Kuratomi