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 lenn...@poettering.net 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 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?
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 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 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 lenn...@poettering.net 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 04/18/2015 05:29 AM, Matt Hoosier wrote: On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez crrodrig...@opensuse.org 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, 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
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 lenn...@poettering.net 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, Apr 17, 2015 at 4:06 PM, Matt Hoosier matt.hoos...@gmail.com wrote: On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering lenn...@poettering.net 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 3:52 PM, Cristian Rodríguez crrodrig...@opensuse.org wrote: On Fri, Apr 17, 2015 at 4:06 PM, Matt Hoosier matt.hoos...@gmail.com wrote: On Fri, Apr 17, 2015 at 12:22 PM, Lennart Poettering lenn...@poettering.net 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
