[systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

Matt Hoosier matt.hoosier at gmail.com
Fri Apr 17 20:29:47 PDT 2015


On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez <
crrodriguez at opensuse.org> wrote:

> On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier <matt.hoosier at gmail.com>
> wrote:
> > On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
> > <lennart at poettering.net> wrote:
> >>
> >> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoosier at gmail.com) wrote:
> >>
> >> > Hi,
> >> >
> >> > I'm writing to see whether there's a "best" way to allow systemd to
> >> > inherit
> >> > ownership of a process forked from a hand-crafted /sbin/init process
> >> > before
> >> > that hand-crafted process turns over the keys to systemd by doing
> >> > exec("/lib/systemd/systemd") over the top of itself and allowing it to
> >> > take
> >> > over as PID 1.
> >>
> >> We support this only really for "kernel-like" processes that are
> >> started from the initrd, and basically run as long as the system is up
> >> without every being restarted in between, thus effectively appearing
> >> much like a kernel process and nothing systemd should
> >> manage. Processes like this should be marked with argv[0][0] = '@',
> >> see for details:
> >>
> >> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
> >>
> >> > I know that sounds like an odd thing to ask about. The use-case has to
> >> > do
> >> > with being able to start some work extremely early during boot of
> >> > embedded
> >> > systems to achieve performance goals. I don't wish to subvert systemd,
> >> > and
> >> > in fact would love for systemd to be able to monitor the process, stop
> >> > it,
> >> > restart according to the normal [Service] configuration in a unit file
> >> > describing the process.
> >>
> >> Hmm, are you sure that invoking the binary from systemd as first
> >> service is really that much slower than starting systemd only
> afterwards?
> >
> >
> > The bootcharting that I do seems to show that about 1.2 - 1.5 sec are
> spent
> > internal to systemd before any external processes get run for the
> particular
> > embedded CPU I'm using. That gap is a killer at the moment.
>
> Did you watch this presentation ?
>
> https://www.youtube.com/watch?v=RFVlbaDqll8
>
> what part of systemd is taking 1.5 seconds to start, on what CPU and
> how much of RAM does the board has ?
>

Thanks, I hadn't found that presentation before. My board is essentially a
Panda ES, with gigabytes of RAM.

A small point of clarification: when I say that systemd takes 1.5 seconds,
I'm referring to the time that elapses between the moment that
/lib/systemd/systemd is exec'ed and the time that the first unit is shown
in the 'systemd-analyze plot'. I haven't done an internal profile on the
systemd binary to see what might be happening during that window yet.

Could you say a word more about the sys_accept4() and /sys/fs/cgroup issue?
Was its only symptom that it caused systemd to run slower?

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150417/0e8738f5/attachment.html>


More information about the systemd-devel mailing list