systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Fri Jun 10 13:07:48 UTC 2011
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
systemd: please stop trying to take over the world :)
Michal Schmidt mschmidt at redhat.com
Fri Jun 10 13:36:29 UTC 2011
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
systemd: please stop trying to take over the world :)
Steve Clark sclark at netwolves.com
Fri Jun 10 13:59:41 UTC 2011
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 at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110610/16d43148/attachment.html
systemd: please stop trying to take over the world :)
Steve Clark sclark at netwolves.com
Fri Jun 10 14:09:47 UTC 2011
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 at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110610/13dc118d/attachment.html
systemd: please stop trying to take over the world :)
Michal Schmidt mschmidt at redhat.com
Fri Jun 10 14:11:20 UTC 2011
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
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Fri Jun 10 16:42:11 UTC 2011
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
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Fri Jun 10 16:58:01 UTC 2011
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
systemd: please stop trying to take over the world :)
mike cloaked mike.cloaked at gmail.com
Fri Jun 10 19:06:07 UTC 2011
On Fri, Jun 10, 2011 at 5:58 PM, Denys Vlasenko <dvlasenk at 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
systemd: please stop trying to take over the world :)
Rahul Sundaram metherid at gmail.com
Fri Jun 10 19:13:42 UTC 2011
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
systemd: please stop trying to take over the world :)
Genes MailLists lists at sapience.com
Fri Jun 10 23:50:56 UTC 2011
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.
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Mon Jun 13 08:15:34 UTC 2011
On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk at 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.
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Mon Jun 13 08:33:19 UTC 2011
On Fri, 10.06.11 19:50, Genes MailLists (lists at 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.
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Mon Jun 13 13:27:28 UTC 2011
Hi Lennart,
On Mon, 2011-06-13 at 10:15 +0200, Lennart Poettering wrote:
> On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk at 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
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Mon Jun 13 15:29:02 UTC 2011
On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk at 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.
systemd: please stop trying to take over the world :)
Miloslav Trmač mitr at volny.cz
Mon Jun 13 16:01:03 UTC 2011
On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering
<mzerqung at 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
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Mon Jun 13 16:01:22 UTC 2011
On Mon, 2011-06-13 at 17:29 +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 15:27, Denys Vlasenko (dvlasenk at 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
systemd: please stop trying to take over the world :)
Simo Sorce simo at redhat.com
Mon Jun 13 16:37:32 UTC 2011
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
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Mon Jun 13 17:02:09 UTC 2011
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
systemd: please stop trying to take over the world :)
Simo Sorce simo at redhat.com
Mon Jun 13 17:30:40 UTC 2011
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
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Mon Jun 13 20:46:30 UTC 2011
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
systemd: please stop trying to take over the world :)
Simo Sorce simo at redhat.com
Tue Jun 14 01:44:16 UTC 2011
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
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Tue Jun 14 07:20:51 UTC 2011
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
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Tue Jun 14 07:42:46 UTC 2011
On Mon, 13.06.11 18:01, Denys Vlasenko (dvlasenk at 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 at 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.
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Tue Jun 14 07:51:28 UTC 2011
On Mon, 13.06.11 18:01, Miloslav Trmač (mitr at volny.cz) wrote:
>
> On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering
> < mzerqung at 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.
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Tue Jun 14 08:06:02 UTC 2011
On Mon, 13.06.11 19:02, Denys Vlasenko (dvlasenk at 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.
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Tue Jun 14 08:20:04 UTC 2011
On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk at 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.
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Tue Jun 14 08:32:13 UTC 2011
On Tue, 14.06.11 09:20, Denys Vlasenko (dvlasenk at 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.
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Tue Jun 14 10:17:05 UTC 2011
On Tue, 2011-06-14 at 09:42 +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 18:01, Denys Vlasenko (dvlasenk at 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
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Tue Jun 14 10:36:53 UTC 2011
On Tue, 2011-06-14 at 10:20 +0200, Lennart Poettering wrote:
> On Mon, 13.06.11 22:46, Denys Vlasenko (dvlasenk at 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
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Tue Jun 14 10:53:58 UTC 2011
On Tue, 14.06.11 12:17, Denys Vlasenko (dvlasenk at 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 at 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.
systemd: please stop trying to take over the world :)
Lennart Poettering mzerqung at 0pointer.de
Tue Jun 14 11:14:32 UTC 2011
On Tue, 14.06.11 12:36, Denys Vlasenko (dvlasenk at 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 at 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.
systemd: please stop trying to take over the world :)
Denys Vlasenko dvlasenk at redhat.com
Tue Jun 14 11:42:42 UTC 2011
On Tue, 2011-06-14 at 13:14 +0200, Lennart Poettering wrote:
> On Tue, 14.06.11 12:36, Denys Vlasenko (dvlasenk at 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 at 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