Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Wed, 06.05.15 09:28, Matt Hoosier (matt.hoos...@gmail.com) wrote:
> One final question on this topic:
>
> I'm not sure from the available discussion of the 'Alias=' directive in
> systemd.unit(5) whether it might be possible for me to have two units:
>
> /lib/systemd/system/dummy-adopted-service.service
> ...
> [Unit]
> DefaultDependencies=no
>
> [Service]
> Type=forking
> PIDFile=/var/run/already-forked-process.pid
> ExecStart=/bin/true
>
> [Install]
> Alias=the-service.service
> Wanted-By=sysinit.target
>
> /lib/systemd/system/real-service.service
> ...
> [Install]
> Alias=the-service.service
>
> such that clients always phrase their dependencies in terms of the aliased
> name ("the-service.service"). At startup time, the virtual unit name would
> always happen to be satisfied by dummy-adopted-service.service, but any
> subsequent restarts would be accomplished by systemd noticing that
> real-service.service exists and using it in preference over
> dummy-adopted-service.service.
>
> My gut feeling is that this approach doesn't play well with the way that
> 'systemctl enable' wants to place alias symlinks into /etc/systemd/system/.
> I.e., I think that systemd will only ever recognize one provider of the
> virtual/aliased service name.
Yes, each name may only refert to one single unit at a time.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
One final question on this topic:
I'm not sure from the available discussion of the 'Alias=' directive in
systemd.unit(5) whether it might be possible for me to have two units:
/lib/systemd/system/dummy-adopted-service.service
...
[Unit]
DefaultDependencies=no
[Service]
Type=forking
PIDFile=/var/run/already-forked-process.pid
ExecStart=/bin/true
[Install]
Alias=the-service.service
Wanted-By=sysinit.target
/lib/systemd/system/real-service.service
...
[Install]
Alias=the-service.service
such that clients always phrase their dependencies in terms of the aliased
name ("the-service.service"). At startup time, the virtual unit name would
always happen to be satisfied by dummy-adopted-service.service, but any
subsequent restarts would be accomplished by systemd noticing that
real-service.service exists and using it in preference over
dummy-adopted-service.service.
My gut feeling is that this approach doesn't play well with the way that
'systemctl enable' wants to place alias symlinks into /etc/systemd/system/.
I.e., I think that systemd will only ever recognize one provider of the
virtual/aliased service name.
Am I wrong in that assessment in the preceding paragraph?
On Mon, Apr 20, 2015 at 12:49 PM, Lennart Poettering wrote:
> On Mon, 20.04.15 12:12, Matt Hoosier (matt.hoos...@gmail.com) wrote:
>
> > > > inexperienced poking around the internal default suite of units
> packaged
> > > > with systemd.
> > >
> > > This is not available, though often requested. But I doubt this can
> > > ever work, since "running before 'everything'" or "running after
> > > 'everything'" is not particularly usefully defined as this all breaks
> > > down as soon as you have two services that want to be run like this
> >
> >
> > Okay, I appreciate that there's no built-in meta-unit that would permit
> me
> > to say "start me to the exclusion of absolutely everything else." I agree
> > that would fail the "what if two processes each tried to play that game?"
> > test.
> >
> > I was just hoping that some unit exists that is synonymous with "the
> point
> > upon which all traditional systemd work is dependent." I suppose nothing
> > still exists matching that kind of weaker description? E.g., ".slice" or
> > something like that.
>
> You could order yourself before "local-fs-pre.target" plus the various
> early-boot services we ship. That list is pretty limited and
> relatively stable, but there's nothing nicer currently, no.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Mon, 20.04.15 12:12, Matt Hoosier (matt.hoos...@gmail.com) wrote: > > > inexperienced poking around the internal default suite of units packaged > > > with systemd. > > > > This is not available, though often requested. But I doubt this can > > ever work, since "running before 'everything'" or "running after > > 'everything'" is not particularly usefully defined as this all breaks > > down as soon as you have two services that want to be run like this > > > Okay, I appreciate that there's no built-in meta-unit that would permit me > to say "start me to the exclusion of absolutely everything else." I agree > that would fail the "what if two processes each tried to play that game?" > test. > > I was just hoping that some unit exists that is synonymous with "the point > upon which all traditional systemd work is dependent." I suppose nothing > still exists matching that kind of weaker description? E.g., ".slice" or > something like that. You could order yourself before "local-fs-pre.target" plus the various early-boot services we ship. That list is pretty limited and relatively stable, but there's nothing nicer currently, no. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Mon, Apr 20, 2015 at 9:11 AM, Lennart Poettering wrote: > On Fri, 17.04.15 14:06, Matt Hoosier (matt.hoos...@gmail.com) wrote: > > > 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. > > > > I'm sure this is quite the naive question, but: is there a simple option > I > > can insert into my "super-important" first service that would cause all > > other units to be forestalled until my service reports that it's > > initialized? I.e., something like: > > > > [Unit] > > DefaultDependencies=no > > Before=very-first-normal-systemd-unit.service > > > > I didn't have luck identifying such a > > very-first-normal-systemd-unit.service on my own, but I'm admittedly > rather > > inexperienced poking around the internal default suite of units packaged > > with systemd. > > This is not available, though often requested. But I doubt this can > ever work, since "running before 'everything'" or "running after > 'everything'" is not particularly usefully defined as this all breaks > down as soon as you have two services that want to be run like this Okay, I appreciate that there's no built-in meta-unit that would permit me to say "start me to the exclusion of absolutely everything else." I agree that would fail the "what if two processes each tried to play that game?" test. I was just hoping that some unit exists that is synonymous with "the point upon which all traditional systemd work is dependent." I suppose nothing still exists matching that kind of weaker description? E.g., ".slice" or something like that. . > > The right way is usually to simply add the right deps of the stuff you > really want to be run before. > > That all said, I would be open to adding a "priority" concept to > units: if we are about to fork off a large number of processes at the > same time we do so sequentially but provide no control currently about > the order then. I'd be open making this configurable with a priority > values that can ensure we fork off some things before others when both > are runnable. This would not really fix your issue, sicne it wouldn't > really delay any other services, it would only configure the order of > the fork()s, but they'd still take place in a tight loop. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, 17.04.15 14:06, Matt Hoosier (matt.hoos...@gmail.com) wrote: > 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. > > I'm sure this is quite the naive question, but: is there a simple option I > can insert into my "super-important" first service that would cause all > other units to be forestalled until my service reports that it's > initialized? I.e., something like: > > [Unit] > DefaultDependencies=no > Before=very-first-normal-systemd-unit.service > > I didn't have luck identifying such a > very-first-normal-systemd-unit.service on my own, but I'm admittedly rather > inexperienced poking around the internal default suite of units packaged > with systemd. This is not available, though often requested. But I doubt this can ever work, since "running before 'everything'" or "running after 'everything'" is not particularly usefully defined as this all breaks down as soon as you have two services that want to be run like this. The right way is usually to simply add the right deps of the stuff you really want to be run before. That all said, I would be open to adding a "priority" concept to units: if we are about to fork off a large number of processes at the same time we do so sequentially but provide no control currently about the order then. I'd be open making this configurable with a priority values that can ensure we fork off some things before others when both are runnable. This would not really fix your issue, sicne it wouldn't really delay any other services, it would only configure the order of the fork()s, but they'd still take place in a tight loop. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, 17.04.15 22:29, Matt Hoosier (matt.hoos...@gmail.com) wrote: > 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. Well, the plot should also show what we spend the time on: running generators, loading/parsing unit files, loading selinux and things like that. Any chance you can figureout what precisely this time is spent on? "systemctl show -a" will also show you various timestamps over the early boot process. 1.5s sounds like quite a bit, even for weaker processes. I think it might be worth eliminating this away before resorting to hacks around using systemd for actually starting things... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On 04/18/2015 05:29 AM, Matt Hoosier wrote: > On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez > mailto:crrodrig...@opensuse.org>> wrote: > 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. Does it spend significant time in loading modules from kmod-setup.c maybe? Maybe adding 'debug' to your kernel command line gives you a hint. > 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? That was a udev issue which should not affect you anymore with recent kernel versions (note the presentation is from 2011). It certainly has nothing to do with the effect you're seeing. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez <
crrodrig...@opensuse.org> wrote:
> On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier
> wrote:
> > On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
> > wrote:
> >>
> >> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier wrote:
> On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering
> wrote:
>>
>> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@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 ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering wrote:
> On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@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.
I'm sure this is quite the naive question, but: is there a simple option I
can insert into my "super-important" first service that would cause all
other units to be forestalled until my service reports that it's
initialized? I.e., something like:
[Unit]
DefaultDependencies=no
Before=very-first-normal-systemd-unit.service
I didn't have luck identifying such a
very-first-normal-systemd-unit.service on my own, but I'm admittedly rather
inexperienced poking around the internal default suite of units packaged
with systemd.
>
> > I can achieve a poor man's version of this right now by telling my
> > hand-spawned process to write out a pid file, and then supplying a unit
> > file that looks something like:
> >
> > #foo.service
> > [Unit]
> > Description=Proxy unit file for foo run prior to systemd
> > ...
> >
> > [Service]
> > Type=forking
> > ExecStart=/bin/true
> > PIDFile=/var/run/my-hand-forked-process-pidfile.txt
>
> urks, but yeah, this should work, however, this will not move the
> process into the service's cgroup. For that you can probably script
> something easily that echoes the PID manually into the cgroups dir of
> the service (which you can reference via %c).
>
> > This is at least enough to get my process into the overall dependency
> graph
> > and to allow other units to depend on the process nominally described by
> > foo.service. But any kind of use of the 'Restart' option is out of the
> > question using this approach. Similarly, 'systemctl start foo.service'
> > wouldn't be able to really start the service explicitly.
> >
> > Is there a (sneaky?) way to inform systemd that a daemon described
> property
> > in a service file, has already been launched and that systemd should
> simply
> > adopt the running instance?
>
> Not really. Maybe you can make the start routine of your daemon smart
> enough to check if the daemon is already up. If so, you move that
> process to the cgroup the routine is started in. If not you fork off
> the real daemon. That way, you can start the daemon before systemd,
> then systemd will start it again, but instead of forking off a new
> instance it would just adopt the existing instance by systemd. When
> the daemon is the restarted through systemd then it will terminate the
> daemon cleanly and the new forked of process will be a regular again,
> if you follow what I mean.
>
Fair enough. That approach had occurred to me also.
>
> But this is all ugly, this is really nothing we want to support
> officially I am sure...
>
Understood.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
-Matt
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, 17.04.15 09:00, Matt Hoosier (matt.hoos...@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?
> I can achieve a poor man's version of this right now by telling my
> hand-spawned process to write out a pid file, and then supplying a unit
> file that looks something like:
>
> #foo.service
> [Unit]
> Description=Proxy unit file for foo run prior to systemd
> ...
>
> [Service]
> Type=forking
> ExecStart=/bin/true
> PIDFile=/var/run/my-hand-forked-process-pidfile.txt
urks, but yeah, this should work, however, this will not move the
process into the service's cgroup. For that you can probably script
something easily that echoes the PID manually into the cgroups dir of
the service (which you can reference via %c).
> This is at least enough to get my process into the overall dependency graph
> and to allow other units to depend on the process nominally described by
> foo.service. But any kind of use of the 'Restart' option is out of the
> question using this approach. Similarly, 'systemctl start foo.service'
> wouldn't be able to really start the service explicitly.
>
> Is there a (sneaky?) way to inform systemd that a daemon described property
> in a service file, has already been launched and that systemd should simply
> adopt the running instance?
Not really. Maybe you can make the start routine of your daemon smart
enough to check if the daemon is already up. If so, you move that
process to the cgroup the routine is started in. If not you fork off
the real daemon. That way, you can start the daemon before systemd,
then systemd will start it again, but instead of forking off a new
instance it would just adopt the existing instance by systemd. When
the daemon is the restarted through systemd then it will terminate the
daemon cleanly and the new forked of process will be a regular again,
if you follow what I mean.
But this is all ugly, this is really nothing we want to support
officially I am sure...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On Fri, Apr 17, 2015 at 09:00:49AM -0500, Matt Hoosier 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.
>
> 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.
>
> I can achieve a poor man's version of this right now by telling my
> hand-spawned process to write out a pid file, and then supplying a unit
> file that looks something like:
>
> #foo.service
> [Unit]
> Description=Proxy unit file for foo run prior to systemd
> ...
>
> [Service]
> Type=forking
> ExecStart=/bin/true
> PIDFile=/var/run/my-hand-forked-process-pidfile.txt
>
> This is at least enough to get my process into the overall dependency graph
> and to allow other units to depend on the process nominally described by
> foo.service. But any kind of use of the 'Restart' option is out of the
> question using this approach. Similarly, 'systemctl start foo.service'
> wouldn't be able to really start the service explicitly.
>
> Is there a (sneaky?) way to inform systemd that a daemon described property
> in a service file, has already been launched and that systemd should simply
> adopt the running instance?
See systemd.scope(5).
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
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.
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.
I can achieve a poor man's version of this right now by telling my
hand-spawned process to write out a pid file, and then supplying a unit
file that looks something like:
#foo.service
[Unit]
Description=Proxy unit file for foo run prior to systemd
...
[Service]
Type=forking
ExecStart=/bin/true
PIDFile=/var/run/my-hand-forked-process-pidfile.txt
This is at least enough to get my process into the overall dependency graph
and to allow other units to depend on the process nominally described by
foo.service. But any kind of use of the 'Restart' option is out of the
question using this approach. Similarly, 'systemctl start foo.service'
wouldn't be able to really start the service explicitly.
Is there a (sneaky?) way to inform systemd that a daemon described property
in a service file, has already been launched and that systemd should simply
adopt the running instance?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
