Re: [systemd-devel] Boot ordering
On Wed, 18.03.15 17:10, Christoph Pleger (christoph.ple...@cs.tu-dortmund.de) wrote: Warming up this old thread... Why does systemd not follow the above instructions to start the services of test.target after those of basic.target and before those of multi-user.target? I figure this trhead already explaiend why this doesn't work as you suggest. I just wanted to add what I think si the best option to do what you want: make your service an early boot service (by specifying DefaultDependencies=no), then order it before basic.target. Then, order it after the precise units you need from early boot, or, if you really think you need all of them, order your unit after sysinit.target, local-fs.target and possibly sockets.target, paths.target, slices.target. That way you will run after whatever you pick from the basic system initialization, but before the first normal services are run. 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] Boot ordering
On Thu, Apr 9, 2015 at 12:18 PM, Lennart Poettering lenn...@poettering.net wrote: order it after the precise units you need from early boot, This is fragile because it will break every time precise units change. This is exact reason why we have systemd.special man page at all - to provide high level synchronization points that are not affected by underlying implementation change. The problem is, systemd does not allow to insert something *between* two synchronization points without knowing precise implementation. You seem to insist it is a feature. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, 09.04.15 12:26, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Thu, Apr 9, 2015 at 12:18 PM, Lennart Poettering lenn...@poettering.net wrote: order it after the precise units you need from early boot, This is fragile because it will break every time precise units change. This is exact reason why we have systemd.special man page at all - to provide high level synchronization points that are not affected by underlying implementation change. The problem is, systemd does not allow to insert something *between* two synchronization points without knowing precise implementation. You seem to insist it is a feature. Hmm? I am not sure I follow... I mean, as I explained you can insert your stuff between sysinit.target+local-fs.target and basic.target. In general: if you don't want to care about precise deps, then use socket activation and set DefaultDependencies=yes, and all is good. That's what I recommend to do. If you want to fiddle with the deps, then you get to keep the pieces, and you have to know what you do, and know what you need to depend on. It's a fair deal I think. 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] Boot ordering
Andrei Borzenkov arvidj...@gmail.com schrieb: On Fri, Mar 20, 2015 at 1:56 AM, Kai Krakow hurikha...@gmail.com wrote: The point is: Let's just find out why the intuitive way to solve the OPs problem doesn't work out and find the right solution. Let's face it: Trying to use targets as sysvinit runlevels equivalent is obviously not the working way although it looks promising and intuitive at first sysinit.target and basic.target are exact equivalent of sysvinit runlevels - they are hard serialization points between groups of services so that systemd will not proceed with next group until all services in previous group are started. The difference is that these runlevels are hardcoded and not configurable. All that OP asked for was a way to make it more flexible and customizable. Yes, you are right. Thanks for the pointer. I didn't realize that as part of the discussion. It still feels wrong to allow that because it will probably be overly mis- used by others (which doesn't mean the OP's intent is wrong) to mimic sysvinit behaviour and make systemd work no better than other init systems. But from man systemd.special I don't read that intentionally being hard serialization points. It clearly works this way because systemd automatically adds depends to all services to run after basic.target for example. But I think the design decision behind it was more of kind of a work-around than actually having hard serialization points. Otherwise it would probably not had become hard-coded. And most of those targets seem to be only special because they are part of udev rules or very early systemd initialization - making me think that, without looking at source code, that sysinit.target is the only target that by intent is serialized through means of code. For basic.target this looks more like (the intentional) side-effect of ordering all other services after it. But I understand the OPs request: it's not feasible to manually do the same as basic.target for his proposed target - it just won't really work except for well-defined system configurations. The question is if it is really needed if one relies on implicit dependencies provided by systemd (a fuzzy explanation like sometimes you need to run something before something else just doesn't cut it without specifying what some* is, not the OP's answer, tho). Currently I cannot think of a use case for a serialized extra target but I'm open to happily learn about it. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Am 19.03.2015 um 23:56 schrieb Kai Krakow: Reindl Harald h.rei...@thelounge.net schrieb: Am 19.03.2015 um 22:04 schrieb Kai Krakow: Christoph Pleger christoph.ple...@cs.tu-dortmund.de schrieb: I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. I think there is still this sysvinit-related misconception that systemd target equal sysvinit runlevels. Systemd uses automatic ordering of units through socket activation and explicitly defined dependencies (which BTW most of the time are not needed). Thus, a target just defines which set of services you want to run asap. Multiple targets can become active in parallel, and systemd will try to reach them in parallel. All dependencies will be thrown into the same soup and systemd works its way through it that is all fine but given that you don't know when a service is ready to accept connections and the whole world don't turn around systemd it is a legit need to control ordering sometimes strictly Well I don't see where the conflict is. Double-forking services should probably just not return to the caller until they are ready to accept connections. This is why you should design your service units for systemd to not fork but start the process in foreground (most services have a cmdline option for that since years) i guess that's whay mysqld needs ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID having a shell script waitig in a lopp until connections are accepted to prevent services with After=mysqld with foreground you have *no control at all* becasue systemd fires up the next service immediately, frankly systemd even don't know the startup time of Type=simple services, hence they are missing in systemd-anlyze blame P.S.: one identical answer on-list would have been enough signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Fri, Mar 20, 2015 at 1:56 AM, Kai Krakow hurikha...@gmail.com wrote: The point is: Let's just find out why the intuitive way to solve the OPs problem doesn't work out and find the right solution. Let's face it: Trying to use targets as sysvinit runlevels equivalent is obviously not the working way although it looks promising and intuitive at first sysinit.target and basic.target are exact equivalent of sysvinit runlevels - they are hard serialization points between groups of services so that systemd will not proceed with next group until all services in previous group are started. The difference is that these runlevels are hardcoded and not configurable. All that OP asked for was a way to make it more flexible and customizable. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
2015-03-20 9:12 GMT+01:00 Reindl Harald h.rei...@thelounge.net: Am 19.03.2015 um 23:56 schrieb Kai Krakow: Reindl Harald h.rei...@thelounge.net schrieb: Am 19.03.2015 um 22:04 schrieb Kai Krakow: Christoph Pleger christoph.ple...@cs.tu-dortmund.de schrieb: I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. I think there is still this sysvinit-related misconception that systemd target equal sysvinit runlevels. Systemd uses automatic ordering of units through socket activation and explicitly defined dependencies (which BTW most of the time are not needed). Thus, a target just defines which set of services you want to run asap. Multiple targets can become active in parallel, and systemd will try to reach them in parallel. All dependencies will be thrown into the same soup and systemd works its way through it that is all fine but given that you don't know when a service is ready to accept connections and the whole world don't turn around systemd it is a legit need to control ordering sometimes strictly Well I don't see where the conflict is. Double-forking services should probably just not return to the caller until they are ready to accept connections. This is why you should design your service units for systemd to not fork but start the process in foreground (most services have a cmdline option for that since years) Hm, this is a misunderstanding. Traditional daemons are supposed to be written in a way, that they setup all communication channels, and then fork. So the fork (or rather the exit of the parent process), was the signal, that the daemon is ready to accept connections. If your daemon doesn't use sd_notify or e.g. grabs a D-Bus name, I actually it's better keep using Type=forking instead of simple for the reasons Reindl mentioned. i guess that's whay mysqld needs ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID having a shell script waitig in a lopp until connections are accepted to prevent services with After=mysqld with foreground you have *no control at all* becasue systemd fires up the next service immediately, frankly systemd even don't know the startup time of Type=simple services, hence they are missing in systemd-anlyze blame Right, if a service needs to setup communication channels etc. for other services to talk to, then imho simple is not the best choice as you need to resort to hacks like you describe. Ideally, mysql would use sd_notify, Type=forking is probably the next best. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Fri, 2015-03-20 at 10:24 +0300, Andrei Borzenkov wrote: On Fri, Mar 20, 2015 at 1:56 AM, Kai Krakow hurikha...@gmail.com wrote: The point is: Let's just find out why the intuitive way to solve the OPs problem doesn't work out and find the right solution. Let's face it: Trying to use targets as sysvinit runlevels equivalent is obviously not the working way although it looks promising and intuitive at first sysinit.target and basic.target are exact equivalent of sysvinit runlevels - they are hard serialization points between groups of services so that systemd will not proceed with next group until all services in previous group are started. The difference is that these No, they are not hard serialization points. As I already mentioned in another part of this thread, it's perfectly possible for a service pulled in by multi-user.target to run before basic.target completes. The only reason that's not very typical is that most services use DefaultDependencies=yes unless they're specifically designed for early boot. But if a service has been written with DefaultDependencies=no (for example because it _could_ be a dependency of some other early-boot service in certain specific configurations) then it's quite normal for it to start before basic.target, even if the service is only part of multi-user.target. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Am 20.03.2015 um 21:19 schrieb Kai Krakow: Since your explanation makes sense, I wonder why there is that recommendation in the man page because without forking you just have one process, don#t need to guess the changing main-PID and watching the service for things like Restart=always is way easier - if that initial PID is gone the service has failed and needs to be restarted well and because not every service has listening sockets other daemon relies on and with foreground/type=simple you can fire up all that daemons of that type in parallel without wait for the forking and so boot much faster wich is fine until explcit or implicit dependencies are part of the game - the implicit dependencies maybe very different and depend on the local environemt and what services are started for what purpose and when signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Reindl Harald h.rei...@thelounge.net schrieb: Am 20.03.2015 um 21:10 schrieb Kai Krakow: i guess that's whay mysqld needs ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID having a shell script waitig in a lopp until connections are accepted to prevent services with After=mysqld I think MySQL is broken in this regard as it signals the caller to be ready before actually being ready. I think I've read this is a known problem and that there are plans to support socket activation/socket passing in the future. no - you refuse to understand that Type=simple (which is forground) just starts the binary and since there is no forking there is no knowledge when it is ready or that it can be ready for whatever it is just a process running and that's it Yes I understand it. It is logical consequence that Type=simple cannot let systemd know when the process is actually ready or what startup time it had. And yes, mysql is using Type=simple but probably just because it uses that script mysqld_safe to start which tries to do all sorts of things to properly support sysvinit, but additionally other unrelated things. Maybe mysqld-wait-ready should simply be properly integrated into mysqld_safe so that mysqld_safe would do it's work in the background by forking and the script returns when mysqld-wait-ready returns. Then, the systemd service file could resort to use Type=forking. The main problem here is probably that you cannot easily detacht processes from a shells job control so the start script would never return unless all children exited. Which in turn means: The mysqld startup process is broken by design. with foreground you have *no control at all* becasue systemd fires up the next service immediately, frankly systemd even don't know the startup time of Type=simple services, hence they are missing in systemd-anlyze blame Right, if a service needs to setup communication channels etc. for other services to talk to, then imho simple is not the best choice as you need to resort to hacks like you describe. Ideally, mysql would use sd_notify, Type=forking is probably the next best. Ooops, yes Michael, you are perfectly right. If the process is forking, it will (at least should) return only when it is ready and then it makes perfect sense. This would not be possible with non-forking processes and those would need to resort to socket passing to actually be ready the very moment when started. well, you where the one which said start processes in foreground is the sultion and recommended Yes, and I said I'm also here to learn. Let's change that to it's recommended if your service implements socket activation / socket passing. the point is just that a non-forking process without socket activation has no change to state anything and socket activation has it's other drawbacks like if i say sysetmctl stop i mean systemctl stop and not fire the service up again if a packet arrives on the socket I suppose one usually should stop the socket to prevent further startups. But you are right that this would not be the principle of least surprise: If I stop a service I usually expect it to be stopped and stay that way. PLEASE stop to hang on mysqld, i just explained why staring a service in foreground don't help in any case, the opposite is true, hence i changed the clamd-service which is default forground started to forking to order clamav-milter correctly (just another *example*) Yes, I'm getting the point. BTW: I'd be interested in your solution about removing mysqld_safe. Can I just change the distribution service file, set the right user/group - or do I need to take care of any other stuff that mysqld_safe prepares/does? -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Michael Biebl mbi...@gmail.com schrieb: 2015-03-20 9:12 GMT+01:00 Reindl Harald h.rei...@thelounge.net: Am 19.03.2015 um 23:56 schrieb Kai Krakow: Reindl Harald h.rei...@thelounge.net schrieb: Am 19.03.2015 um 22:04 schrieb Kai Krakow: Christoph Pleger christoph.ple...@cs.tu-dortmund.de schrieb: I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. I think there is still this sysvinit-related misconception that systemd target equal sysvinit runlevels. Systemd uses automatic ordering of units through socket activation and explicitly defined dependencies (which BTW most of the time are not needed). Thus, a target just defines which set of services you want to run asap. Multiple targets can become active in parallel, and systemd will try to reach them in parallel. All dependencies will be thrown into the same soup and systemd works its way through it that is all fine but given that you don't know when a service is ready to accept connections and the whole world don't turn around systemd it is a legit need to control ordering sometimes strictly Well I don't see where the conflict is. Double-forking services should probably just not return to the caller until they are ready to accept connections. This is why you should design your service units for systemd to not fork but start the process in foreground (most services have a cmdline option for that since years) Hm, this is a misunderstanding. Traditional daemons are supposed to be written in a way, that they setup all communication channels, and then fork. So the fork (or rather the exit of the parent process), was the signal, that the daemon is ready to accept connections. If your daemon doesn't use sd_notify or e.g. grabs a D-Bus name, I actually it's better keep using Type=forking instead of simple for the reasons Reindl mentioned. i guess that's whay mysqld needs ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID having a shell script waitig in a lopp until connections are accepted to prevent services with After=mysqld I think MySQL is broken in this regard as it signals the caller to be ready before actually being ready. I think I've read this is a known problem and that there are plans to support socket activation/socket passing in the future. with foreground you have *no control at all* becasue systemd fires up the next service immediately, frankly systemd even don't know the startup time of Type=simple services, hence they are missing in systemd-anlyze blame Right, if a service needs to setup communication channels etc. for other services to talk to, then imho simple is not the best choice as you need to resort to hacks like you describe. Ideally, mysql would use sd_notify, Type=forking is probably the next best. Ooops, yes Michael, you are perfectly right. If the process is forking, it will (at least should) return only when it is ready and then it makes perfect sense. This would not be possible with non-forking processes and those would need to resort to socket passing to actually be ready the very moment when started. But for MySQL: It think it is simply not ready yet when returning to the caller - probably that's because the service spawner mysqld_safe is a script which also tries to handle the PID file etc etc. That design is simply broken in a modern world with fast computers because a fast computer may well be ready to serve requests that need mysql before mysql itself is done with its internal setup. And the script mixes in a lot of stuff that actually systemd should do (and traditional sysvinit start wouldn't usually do, so it's some sort of construct of convenience to fix sysvinit behavior). -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Reindl Harald h.rei...@thelounge.net schrieb: with foreground you have *no control at all* becasue systemd fires up the next service immediately, frankly systemd even don't know the startup time of Type=simple services, hence they are missing in systemd-anlyze blame I wonder what's suitable for smbd/nmbd... My distribution ships it with default Type=forking and starts those services in daemon mode. But the man page tells that the suitable start mode for supervising init systems is starting the service in foreground mode. Since your explanation makes sense, I wonder why there is that recommendation in the man page. In a systemd world my distribution default would actually be the right thing to do. But then again, in openrc those services had a manual sleep to allow the services to become ready before another service may use it. This means, also smbd/nmbd are services which fork and return to the caller before they are really ready to serve requests. That makes me guess that probably many services out there are just wrongly designed. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Am 20.03.2015 um 21:10 schrieb Kai Krakow: i guess that's whay mysqld needs ExecStartPost=/usr/libexec/mysqld-wait-ready $MAINPID having a shell script waitig in a lopp until connections are accepted to prevent services with After=mysqld I think MySQL is broken in this regard as it signals the caller to be ready before actually being ready. I think I've read this is a known problem and that there are plans to support socket activation/socket passing in the future. no - you refuse to understand that Type=simple (which is forground) just starts the binary and since there is no forking there is no knowledge when it is ready or that it can be ready for whatever it is just a process running and that's it with foreground you have *no control at all* becasue systemd fires up the next service immediately, frankly systemd even don't know the startup time of Type=simple services, hence they are missing in systemd-anlyze blame Right, if a service needs to setup communication channels etc. for other services to talk to, then imho simple is not the best choice as you need to resort to hacks like you describe. Ideally, mysql would use sd_notify, Type=forking is probably the next best. Ooops, yes Michael, you are perfectly right. If the process is forking, it will (at least should) return only when it is ready and then it makes perfect sense. This would not be possible with non-forking processes and those would need to resort to socket passing to actually be ready the very moment when started. well, you where the one which said start processes in foreground is the sultion and recommended But for MySQL: It think it is simply not ready yet when returning to the caller - probably that's because the service spawner mysqld_safe is a script which also tries to handle the PID file etc etc nobody talks about mysqld_safe, nobody needs it because the only purpose is to restart mysqld if it fails - that systemd also can, will and does - no mysqld_safe here, our private builds even remove it from the package the point is just that a non-forking process without socket activation has no change to state anything and socket activation has it's other drawbacks like if i say sysetmctl stop i mean systemctl stop and not fire the service up again if a packet arrives on the socket PLEASE stop to hang on mysqld, i just explained why staring a service in foreground don't help in any case, the opposite is true, hence i changed the clamd-service which is default forground started to forking to order clamav-milter correctly (just another *example*) it's not that easy and the world is not and won't be perfect signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Reindl Harald h.rei...@thelounge.net schrieb: BTW: I'd be interested in your solution about removing mysqld_safe. Can I just change the distribution service file, set the right user/group - or do I need to take care of any other stuff that mysqld_safe prepares/does? do *never* touch the distribution unit-file it would be overwritten by updates Yes, that is clear. I'm administrating servers since maybe 15 years and running on Gentoo for about 10 years now. I also prefer to use systemctl edit to change files - keeping in mind the caveat that you need to clear out lines with Exec*= (empty) to replace process execution. the most helpful deign change of systemd is that you just can disbale any service, copy the systemd-unit for /usr/lib/systemd/system/ to /etc/systemd/system/ and enable the service, from that moment on only your personalized systemd-unit would be used Or use *.d directories for overrides - whatever is more appropriate. below my systemd-unit (for F21 and recent systemd versions) Thanks, very much appreciated. It contains a lot of stuff. ;-) I snip away what I don't need. What I don't like about the mysql-wait-ready solution is that it loops with a sleep 1. I'd prefer mysqld having a real daemonize option. It would solve a lot of headache I guess. I've found the bug report on Fedora bugzilla you were involved with [1]. I guess that socket activation did not work out? I tried that also way back when I started using systemd and it didn't really work for me. Besides that your solution works fine for me. It also has the benefit of not duplicating configuration items like sockets and ports - which would probably be a problem with using a mysqld.socket file. I'm currently migrating our servers over to systemd because logging and service quality work better for us with systemd in place. So this will certainly help. Thanks again. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=714426 -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Am 20.03.2015 um 22:44 schrieb Kai Krakow: I've found the bug report on Fedora bugzilla you were involved with [1]. I guess that socket activation did not work out? I tried that also way back when I started using systemd and it didn't really work for me. Besides that your solution works fine for me. It also has the benefit of not duplicating configuration items like sockets and ports - which would probably be a problem with using a mysqld.socket file well, i have a ton of machines with more than one mysqld-instance on different ports, mostly backup/replication instances and so on or a own instance for dbmail to synch machines except the mail storage (home / office workstation and so on) clone the mysqld-ready script with the same suffix and change path inside is easy __ BTW mine don't use sleep since usleep exists :-) #!/usr/bin/bash # Service file passes us the daemon's PID daemon_pid=$1 # Wait for the server to come up or for the mysqld process to disappear ret=0 while /usr/bin/true; do RESPONSE=`/usr/bin/mysqladmin --defaults-file=/etc/my.cnf --socket=/var/lib/mysql/mysql.sock --user=UNKNOWN_MYSQL_USER ping 21` mret=$? if [ $mret -eq 0 ]; then break fi # exit codes 1, 11 (EXIT_CANNOT_CONNECT_TO_SERVICE) are expected, # anything else suggests a configuration error if [ $mret -ne 1 -a $mret -ne 11 ]; then ret=1 break fi # Access denied also means the server is alive echo $RESPONSE | grep -q Access denied for user break # Check process still exists if ! /usr/bin/kill -0 $daemon_pid 2/dev/null; then ret=1 break fi usleep 10 done exit $ret signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Hello, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: I want a program to be run at boot time without any other systemd services starting concurrently. The program needs the services from basic.target and may influence everything in multi-user.target and later targets, so I guess that between basic.target and multi-user.target is a good time for execution of the program. I hoped that this can be achieved by simply defining a new target, setting after basic.target dependencies for it and changing the dependencies of multi-user.target from basic.target to my new target. This would not require me too know anything about the specific services in basic.target and multi-user.target . Sounds like you want to create intermediate.target, change default.target to point at it, boot all the way up to intermediate.target, and at that point isolate or start multi-user.target. I chose that solution, because from all possible solutions for the desired boot order, it seems to be the one which is closest to my idea. Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Reindl Harald h.rei...@thelounge.net schrieb: Am 19.03.2015 um 22:04 schrieb Kai Krakow: Christoph Pleger christoph.ple...@cs.tu-dortmund.de schrieb: I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. I think there is still this sysvinit-related misconception that systemd target equal sysvinit runlevels. Systemd uses automatic ordering of units through socket activation and explicitly defined dependencies (which BTW most of the time are not needed). Thus, a target just defines which set of services you want to run asap. Multiple targets can become active in parallel, and systemd will try to reach them in parallel. All dependencies will be thrown into the same soup and systemd works its way through it that is all fine but given that you don't know when a service is ready to accept connections and the whole world don't turn around systemd it is a legit need to control ordering sometimes strictly Well I don't see where the conflict is. Double-forking services should probably just not return to the caller until they are ready to accept connections. This is why you should design your service units for systemd to not fork but start the process in foreground (most services have a cmdline option for that since years). That is a clear signal for systemd that the service is ready (other signals are the appearence of a PID file for forking processes, but that is not recommended). Forking or double forking only gets in the way for that and is a design from sysvinit days to actually speedup boot (which you state should not be the priority, and I agree with that) and/or decouple the console so the process does not become killed by the HUP signal, or can setuid/setgid. If you don't want to trust some of those security measures to systemd (or start-stop-daemon in openrc, or whatever) then it is probably your task to ensure that the process is ready when the parent returns to the caller after forking. This is something often done wrong even for sysvinit - otherwise I cannot explain why we need sleep 5 or while try-something; do sleep 1; done in init scripts. And yes, I added such fixes myself to init scripts in the past. And not needing it with systemd has nothing to do with performance but with reliability, altough I appreciate the performance benefit of it and it also looks much cleaner without hacks. This goes along with clever tricks of init script maintainers who added to the process spawning to speed up things which I had to remove sometimes to get a much slower but at least reliable service startup. boot performance is not the only important thing - better said on servers it don't matter that much given you don't boot the machine all day long - relieable boot in every context is much more important while claiming everybody does soemthing wrong and systemd is right with it's assumptions don't help much You cannot simply say boot performance is not important for servers. I actually would easier accept boot performance is not important for desktops because we have hibernate/suspend/sleep - desktops don't really need to reboot except for updates. With modern servers which offer UEFI boot, POST time can be reduced to seconds when we had minutes sometimes in legacy BIOS. So, with the arrival of such servers we also have the need for fast boots - because service downtime can be a cost factor. In that regard, I cannot agree with you although I think that your argument is true for some, maybe most, scenarios. But let's also elaborate on reliable boot: This is, what systemd actually offers and even can guarantee, in a much better way traditional sysvinit could ever do. It provides well defined targets telling me if a set of services is up (sysvinit doesn't). It provides supervising, and it provides socket activation with automatic blocking. For services designed to support systemd (and I don't think that is such a big deal for most services), you could even restart services without service interruption because socket activation can guaratee uninterrupted (though delayed) service provision. You may argue there are supervising managers like supervise, runit, etc. But first most of them cannot use socket activation and thus do not give the same guarantees, and if they do, they need to use the same or very similar modifications to your service as they need to use for supporting systemd. And after all one can still argue that using facilities like supervise is no longer traditional sysvinit - so where's the point? Noone claims that everyone is doing it wrong, neither that systemd is the only one doing it right. Everything is fine with traditional
Re: [systemd-devel] Boot ordering
Hello, I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. There is no feasible way to do it right now. So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, Mar 19, 2015 at 1:00 PM, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. There is no feasible way to do it right now. So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? After means exactly what it says - multi-user.target waits for all units listed in After line. It does not imply anything about relative ordering of those units. Unless they have other dependencies all of them will (attempted to) be started in parallel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On 19 March 2015 at 10:00, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. There is no feasible way to do it right now. So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? Correct. You can move a service to be started earlier. You cannot force move a service to be started later. E.g. if foo.service is WantedBy=multi-user.target, yet bar.service declares Wants=foo.service and bar.service is to be started e.g. for basic.target, foo.service will be already running by the time multi-user.target starts activation of its wants. (in simplified description) This is by design, and hard / non-needed to be fixed. However their might be alternative solutions to your problem. What is the the problem you are trying to solve by implementing a new 'intermediate' runlevel ? -- Regards, Dimitri. Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On 19 March 2015 at 12:09, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? Correct. ... What is the the problem you are trying to solve by implementing a new 'intermediate' runlevel ? I want a program to be run at boot time without any other systemd services starting concurrently. The program needs the services from basic.target and may influence everything in multi-user.target and later targets, so I guess that between basic.target and multi-user.target is a good time for execution of the program. I hoped that this can be achieved by simply defining a new target, setting after basic.target dependencies for it and changing the dependencies of multi-user.target from basic.target to my new target. This would not require me too know anything about the specific services in basic.target and multi-user.target . Sounds like you want to create intermediate.target, change default.target to point at it, boot all the way up to intermediate.target, and at that point isolate or start multi-user.target. If your default.target points at multi-user.target, there is no way to prevent multi-user things from not running until after itermediate.target. -- Regards, Dimitri. Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Hello, So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? Correct. ... What is the the problem you are trying to solve by implementing a new 'intermediate' runlevel ? I want a program to be run at boot time without any other systemd services starting concurrently. The program needs the services from basic.target and may influence everything in multi-user.target and later targets, so I guess that between basic.target and multi-user.target is a good time for execution of the program. I hoped that this can be achieved by simply defining a new target, setting after basic.target dependencies for it and changing the dependencies of multi-user.target from basic.target to my new target. This would not require me too know anything about the specific services in basic.target and multi-user.target . Regards Christoph Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, Mar 19, 2015 at 3:09 PM, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? Correct. ... What is the the problem you are trying to solve by implementing a new 'intermediate' runlevel ? I want a program to be run at boot time without any other systemd services starting concurrently. The program needs the services from basic.target Well, for the specific service you do know which services it requires, right? Then simply start it as part of basic.target and make sure it is ordered after required services. and may influence everything in multi-user.target and later targets, so I guess that between basic.target and multi-user.target is a good time for execution of the program. I hoped that this can be achieved by simply defining a new target, setting after basic.target dependencies for it and changing the dependencies of multi-user.target from basic.target to my new target. This would not require me too know anything about the specific services in basic.target and multi-user.target . Regards Christoph Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, Mar 19, 2015 at 3:19 PM, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? After means exactly what it says - multi-user.target waits for all units listed in After line. It does not imply anything about relative ordering of those units. Unless they have other dependencies all of them will (attempted to) be started in parallel. Then, I still do not understand why my definition of a new target did not work. What is the difference between multi-user.target waiting for basic.target on the one hand and new.target waiting for basic.target and multi-user.target waiting for new.target on the other hand, aside from that one intermediate step? Everything else that is ordered before multi-user.target is started concurrently with your new.target. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Am 19.03.2015 um 13:09 schrieb Christoph Pleger: What is the the problem you are trying to solve by implementing a new 'intermediate' runlevel ? I want a program to be run at boot time without any other systemd services starting concurrently. The program needs the services from basic.target and may influence everything in multi-user.target and later targets, so I guess that between basic.target and multi-user.target is a good time for execution of the program. I hoped that this can be achieved by simply defining a new target, setting after basic.target dependencies for it and changing the dependencies of multi-user.target from basic.target to my new target. This would not require me too know anything about the specific services in basic.target and multi-user.target what about After=basic.target Before=multi-user.target signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Hello, So, if the original unit file multi-user.target contains After=basic.target rescue.service rescue.target this after does not really mean anything and jobs wanted or required by multi-user.target can already be started when some jobs from basic.target have not been started??? After means exactly what it says - multi-user.target waits for all units listed in After line. It does not imply anything about relative ordering of those units. Unless they have other dependencies all of them will (attempted to) be started in parallel. Then, I still do not understand why my definition of a new target did not work. What is the difference between multi-user.target waiting for basic.target on the one hand and new.target waiting for basic.target and multi-user.target waiting for new.target on the other hand, aside from that one intermediate step? Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, Mar 19, 2015 at 4:27 PM, Christoph Pleger christoph.ple...@cs.tu-dortmund.de wrote: Hello, Then, I still do not understand why my definition of a new target did not work. What is the difference between multi-user.target waiting for basic.target on the one hand and new.target waiting for basic.target and multi-user.target waiting for new.target on the other hand, aside from that one intermediate step? Everything else that is ordered before multi-user.target is started concurrently with your new.target. Hm. But I have no idea why for example gdm3 is started while my test script is still executing its sleep command. Because gdm3 has no ordering dependencies against your test script so both are scheduled to be started concurrently. Which one will be first is more or less random. This is the output of systemd-analyze dot | grep gdm: shutdown.target-gdm.service [color=green]; shutdown.target-gdm.service [color=red]; graphical.target-gdm.service [color=grey66]; x-display-manager.target-gdm.service [color=green]; x-display-manager.target-gdm.service [color=black]; gdm.service-systemd-user-sessions.service [color=green]; gdm.service-getty@tty7.service [color=green]; gdm.service-plymouth-quit.service [color=green]; gdm.service-systemd-journald.socket [color=green]; gdm.service-basic.target [color=green]; gdm.service-system.slice [color=green]; gdm.service-basic.target [color=black]; gdm.service-x-display-manager.target [color=grey66]; gdm.service-system.slice [color=grey66]; gdm.service-getty@tty7.service [color=red]; gdm.service-plymouth-quit.service [color=red]; gdm.service-shutdown.target [color=red]; getty@tty7.service-gdm.service [color=red]; plymouth-quit.service-gdm.service [color=red]; plymouth-halt.service-gdm.service [color=green]; plymouth-reboot.service-gdm.service [color=green]; Color legend: black = Requires dark blue = Requisite dark grey = Wants red = Conflicts green = After If I understand this correctly, gdm is pulled into the boot process only by graphical.target, which according to target unit definitions should be after multi-user.target , which should be after my new.target ... You seem to misunderstand what target does. Target simply tells systemd if you start me, start also these other services. Those other services are started as soon as possible. Ordering of target units has absolutely no relation to startup order of other services. The only thing I can imagine what causes my problem is that Debian jessie does not use only systemd units, but also init scripts in /etc/rc*.d/ and that this brakes my desired boot order. Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Hello, Then, I still do not understand why my definition of a new target did not work. What is the difference between multi-user.target waiting for basic.target on the one hand and new.target waiting for basic.target and multi-user.target waiting for new.target on the other hand, aside from that one intermediate step? Everything else that is ordered before multi-user.target is started concurrently with your new.target. Hm. But I have no idea why for example gdm3 is started while my test script is still executing its sleep command. This is the output of systemd-analyze dot | grep gdm: shutdown.target-gdm.service [color=green]; shutdown.target-gdm.service [color=red]; graphical.target-gdm.service [color=grey66]; x-display-manager.target-gdm.service [color=green]; x-display-manager.target-gdm.service [color=black]; gdm.service-systemd-user-sessions.service [color=green]; gdm.service-getty@tty7.service [color=green]; gdm.service-plymouth-quit.service [color=green]; gdm.service-systemd-journald.socket [color=green]; gdm.service-basic.target [color=green]; gdm.service-system.slice [color=green]; gdm.service-basic.target [color=black]; gdm.service-x-display-manager.target [color=grey66]; gdm.service-system.slice [color=grey66]; gdm.service-getty@tty7.service [color=red]; gdm.service-plymouth-quit.service [color=red]; gdm.service-shutdown.target [color=red]; getty@tty7.service-gdm.service [color=red]; plymouth-quit.service-gdm.service [color=red]; plymouth-halt.service-gdm.service [color=green]; plymouth-reboot.service-gdm.service [color=green]; Color legend: black = Requires dark blue = Requisite dark grey = Wants red = Conflicts green = After If I understand this correctly, gdm is pulled into the boot process only by graphical.target, which according to target unit definitions should be after multi-user.target , which should be after my new.target ... The only thing I can imagine what causes my problem is that Debian jessie does not use only systemd units, but also init scripts in /etc/rc*.d/ and that this brakes my desired boot order. Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
Am 19.03.2015 um 18:00 schrieb Uoti Urpala: On Thu, 2015-03-19 at 18:41 +0300, Andrei Borzenkov wrote: On Thu, Mar 19, 2015 at 6:11 PM, Michael Biebl mbi...@gmail.com wrote: The summary of my reply was What you probably want, is hook into basic.target or sysinit.target, use DefaultDependencies=no, and specify the dependencies/orderings explicitly. Apparently, this didn't stick. The reality is, this question comes again and again; and the very fact that we had to add *-pre.target to allow such kind of ordering dependencies shows that the problem is real. What exactly is your definition of this question and the problem? I don't see any natural definition that would equally apply to what the original poster was trying to do and things like local-fs-pre.target that you have sometimes things where you want to make sure a specific order and say: don't start my target until basic target is started and don't start anything until all the services of my target are up it would make ordering way easier and give a ton of flexibility for unit-writers (which are not only distributions but end-users/admins with very specific environments) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, 2015-03-19 at 18:41 +0300, Andrei Borzenkov wrote: On Thu, Mar 19, 2015 at 6:11 PM, Michael Biebl mbi...@gmail.com wrote: The summary of my reply was What you probably want, is hook into basic.target or sysinit.target, use DefaultDependencies=no, and specify the dependencies/orderings explicitly. Apparently, this didn't stick. The reality is, this question comes again and again; and the very fact that we had to add *-pre.target to allow such kind of ordering dependencies shows that the problem is real. What exactly is your definition of this question and the problem? I don't see any natural definition that would equally apply to what the original poster was trying to do and things like local-fs-pre.target. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, 2015-03-19 at 14:27 +0100, Christoph Pleger wrote: Then, I still do not understand why my definition of a new target did not work. What is the difference between multi-user.target waiting for basic.target on the one hand and new.target waiting for basic.target and multi-user.target waiting for new.target on the other hand, aside from that one intermediate step? You're misunderstanding some of the basics of unit ordering. That multi-user.target has an After: relationship to basic.target only means that multi-user.target ITSELF will not be considered to have been successfully started before basic.target has. This does not say anything about the ordering of any other units, such as the services that are started because multi-user.target wants them - the reason why some service is started at boot (such as which target pulls it in via a Wants/Requires relationship) says NOTHING about where the service can be ordered. If multi-user.target wants some service, it's up to the individual dependencies of that service to determine when the service can be started. Typically most services started by multi-user.target run after basic.target, but that's only because they each have the default configuration DefaultDependencies=yes, which implies After: basic.target. If some service has DefaultDependencies=no and defines no other ordering requirements, it can even be the first service to run at boot even if it's only wanted by multi-user.target. Thus your between basic.target and multi-user.target is not a well-defined requirement. My best guess about what you might actually want to achieve (assuming you aren't so thoroughly confused that it makes no sense at all) is a service that runs before any service that has DefaultDependencies enabled, and which requires (most of) basic.target. I think this would be most practically implemented as a DefaultDependencies=no service, which is wanted by basic.target, and which has explicit dependencies on (most of) other services that are wanted by basic.target. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
2015-03-19 15:46 GMT+01:00 Uoti Urpala uoti.urp...@pp1.inet.fi: On Thu, 2015-03-19 at 14:27 +0100, Christoph Pleger wrote: Then, I still do not understand why my definition of a new target did not work. What is the difference between multi-user.target waiting for basic.target on the one hand and new.target waiting for basic.target and multi-user.target waiting for new.target on the other hand, aside from that one intermediate step? You're misunderstanding some of the basics of unit ordering. That multi-user.target has an After: relationship to basic.target only means that multi-user.target ITSELF will not be considered to have been successfully started before basic.target has. This does not say anything about the ordering of any other units, such as the services that are started because multi-user.target wants them - the reason why some service is started at boot (such as which target pulls it in via a Wants/Requires relationship) says NOTHING about where the service can be ordered. If multi-user.target wants some service, it's up to the individual dependencies of that service to determine when the service can be started. Typically most services started by multi-user.target run after basic.target, but that's only because they each have the default configuration DefaultDependencies=yes, which implies After: basic.target. If some service has DefaultDependencies=no and defines no other ordering requirements, it can even be the first service to run at boot even if it's only wanted by multi-user.target. Thus your between basic.target and multi-user.target is not a well-defined requirement. My best guess about what you might actually want to achieve (assuming you aren't so thoroughly confused that it makes no sense at all) is a service that runs before any service that has DefaultDependencies enabled, and which requires (most of) basic.target. I think this would be most practically implemented as a DefaultDependencies=no service, which is wanted by basic.target, and which has explicit dependencies on (most of) other services that are wanted by basic.target. I already told Christoph that a week ago, since he was posting the same question on debian-user. The summary of my reply was What you probably want, is hook into basic.target or sysinit.target, use DefaultDependencies=no, and specify the dependencies/orderings explicitly. Apparently, this didn't stick. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
On Thu, Mar 19, 2015 at 6:11 PM, Michael Biebl mbi...@gmail.com wrote: The summary of my reply was What you probably want, is hook into basic.target or sysinit.target, use DefaultDependencies=no, and specify the dependencies/orderings explicitly. Apparently, this didn't stick. The reality is, this question comes again and again; and the very fact that we had to add *-pre.target to allow such kind of ordering dependencies shows that the problem is real. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Boot ordering
В Wed, 18 Mar 2015 17:10:11 +0100 Christoph Pleger christoph.ple...@cs.tu-dortmund.de пишет: Hello, I am experimenting a little with systemd and trying to define a new intermediate runlevel, a runlevel between basic.target and multi-user.target. This means that I want the services which are required by my new runlevel to be started after all services from basic.target have been started and to be finished before any service from multi-user.target is started. There is no feasible way to do it right now. In special cases it was worked around by adding second target (local-fs.target = local-fs-pre.target) and explicitly ordering units after it. Unfortunately it is not clear how to compute such dependency automatically. So effectively if you want to insert some target you need to order *all* units after it (or it before all units). Which does not scale ... So far, I created /lib/systemd/test.target with [Unit] Description=Test target Requires=basic.target Conflicts=rescue.service rescue.target Before=multi-user.target After=basic.target rescue.service rescue.target and /lib/systemd/test.service with [Unit] Description=Test service [Service] Type=oneshot ExecStart=/usr/local/bin/test [Install] RequiredBy=test.target /usr/local/bin/test is a simple script which just echoes some words on the display and then sleeps for some minutes. In /lib/systemd/system/multi-user.target, in lines Requires= and After=, I replaced basic.target with test.target . Then I called 'systemctl enable linf.service' and rebooted. The result was that the computer booted up to the graphical login screen much before the time I had put in the sleep command of my test script. I logged in from a remote machine by ssh and used ps to find out if there was a running sleep command from my script, and there was. So, obviously my script was executed during the boot phase, but not in the intended order after basic.target and before multi-user.target. Why does systemd not follow the above instructions to start the services of test.target after those of basic.target and before those of multi-user.target? Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
