systemd: please stop trying to take over the world :)
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
06-10-2011, 01:59 PM
Steve Clark
systemd: please stop trying to take over the world :)
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@netwolves.com
http://www.netwolves.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
06-10-2011, 02:09 PM
Steve Clark
systemd: please stop trying to take over the world :)
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).
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@netwolves.com
http://www.netwolves.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
06-10-2011, 02:11 PM
Michal Schmidt
systemd: please stop trying to take over the world :)
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
06-10-2011, 04:42 PM
Denys Vlasenko
systemd: please stop trying to take over the world :)
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
06-10-2011, 04:58 PM
Denys Vlasenko
systemd: please stop trying to take over the world :)
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
06-10-2011, 05:00 PM
Lucas
systemd: please stop trying to take over the world :)
On 06/10/2011 08:42 PM, Denys Vlasenko wrote:
> On Fri, 2011-06-10 at 15:36 +0200, Michal Schmidt wrote:
>>> Why does systemd link against libpam?
>>> systemd does logins now, not /bin/login or gdm or ...?
>>
>> to implement PAMName= (man systemd.exec)
>
> I don't see any users of this feature on my F15.
> I searched with Google and come up empty too.
>
> But anyway, assuming it's a useful feature, why it has to be done by
> systemd?
>
> I looked at implementation.
> systemd-26/src/execute.c::setup_pam():
>
> /* We set up PAM in the parent process, then fork. The child
> * will then stay around until killed via PR_GET_PDEATHSIG or
> * systemd via the cgroup logic. It will then remove the PAM
> * session again. The parent process will exec() the actual
> * daemon. We do things this way to ensure that the main PID
> * of the daemon is the one we initially fork()ed. */
>
> I don't see any attempt to free at least something in the child.
> So, systemd forks a process with eleven megabyte of malloced stuff
> to act just as a babysitter - wait for parent to die, call pam_end,
> exit?
> For how long will it hang around in the system - possibly days?
>
> Yes, COW, so not all of these eleven megabytes will be around...
> ...at first, until parent execs, or modifies sufficiently many pages
> so that most of them are copied.
>
> But memory consumption is not really the gist of my argument, it's:
> why systemd tries to be all things for all people?
>
> Why it has to care about PAM? I think most tools which need it do it
> themselves, and we can write a small, really small helper for those
> which don't.
>
>
>>> libwrap? systemd is a network application now too?
>>
>> to implement TCPWrapName= (man systemd.exec)
>
> Again, why it has to be done *by systemd*?
>
>
>
>
> On Fri, 2011-06-10 at 10:09 -0400, Steve Clark wrote:
>>> Yes, whatever happened to the *NIX philosophy of simple non-complex
>> programs that did their job well. It has seemed to serve well since
>> the 70's.
>
> Exactly my point.
>
It looks like it is the right time to think about upstart again. I will definitely check it out on
rawhide.
Thanks to OP for pointing on some difficulties. More important that it will be not so easy to clean
that all up latter and we will get eventually unmanageable windows.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
06-10-2011, 05:02 PM
Colin Walters
systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 9:07 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote:
>
> It's the *fourth* largest process on my system!
>
>
> # ldd `which systemd`
1) Looking at what libraries a binary links to a is a terrible way to
optimize memory usage; try massif, say
2) It'd be a lot more productive to be positive and not phrase your
message in such an antagonistic way (in fact, this message would
probably be better on the systemd-devel mailing list)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
systemd: please stop trying to take over the world :)
