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. The runlevels as used by sysvinit were just there because its design of dependencies was virtually non-existent - or at least broken. Because there were no real dependencies, it had runlevels: points in time of the boot process to ensure that services which were more or less unrelated by means of dependencies could be run in a more or less defined order or maybe even in parallel (well, the "parallel" concept was exploitet by later incarnations of the sysvinit concept). But still the "runlevel" was a well definied point in time which explicitly decoupled services from each other in time which had strong dependencies on each other - like the presence of a fully mounted file system. Systemd usually does not need it: It uses automounts and socket activation (and probably other less obvious mechanics) to decouple service dependencies (which allows a myriad of other nice advantages which are a little out of scope here). So, to get the result you are expecting, you should first try to get away from the concept of runlevels and rethink the finer grained dependencies of whatever you are trying to achieve. If your service/process/whatever needs the presence of specific services you need to either explicitly mention them as dependency or try to make socket activation and automounts work for you. Then you have to find a way to block everything else that conflicts with your service/process/whatever to wait, until your actions are done. If it is well thought and well designed, it probably boils down to less work than you think it currently sounds like. In the end, systemd is much different to sysvinit in the sense of that you can actually rely on services/filesystems being ready to use the very moment you use them without bothering dependencies - because otherwise your process would simply block until systemd is ready to serve them. But trying to use targets as runlevels (in the spirit of sysvinit) is clearly the wrong road, causes headaches, and calls for trouble later. What you are looking for is probably something like a staged startup which has been discussed here before. I don't remember the outcome though, you have to research yourself. I'd just like to throw it in as a pointer while I remembered it, hope you can find some answers that way. Maybe you could also expect better help here if you just clearly tell why you need to wait on what to finish, and why you need to block what until your process is done with... which tasks anyway? I think people are really up to helping you but they cannot because you describe your problem, well... in a very fuzzy way. This only results in clueless people on both sides with one side thinking systemd is really bad design - but it is not. It is very well designed, at least according to my experience with it and solving problems with it. In a way, systemd works like pure magic for me. But magic is just a technology we're not yet fully understanding. And that said, I'd really like to just learn more about it. And in this sense, I'm interested in your exact problem. While I may not solve it, following its solution will help me understand better. ;-) I think other readers feel the same. Thanks. :-) -- Replies to list only preferred. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
