On 07/08/2011 08:23 AM, Lennart Poettering wrote: > On Thu, 07.07.11 22:57, Steve Dickson (SteveD@xxxxxxxxxx) wrote: > >> Hello, >> >> One of the maintainers of systemd and I have been working >> together on trying to convert the NFS SysV init scripts >> into systemd services. Here is the long trail... >> >> https://bugzilla.redhat.com/show_bug.cgi?id=699040 >> >> The point is this, with fairly complicated system, >> some events need to have happen, like loading modules, >> before other events happen, like setting parameters of >> those loaded modules. >> >> Currently the ExecStart commands can be started and end >> before the ExecStartPre even start. This means setting >> modules parameters within the same service file are >> impossible. >> >> I suggested that a boundary be set that all ExecStartPre >> commands finish before any ExecStart commands start, >> which would allow complicated subsystems, like NFS, >> to start in a very stable way... >> >> So is it wrong? Shouldn't there away to allow certain >> parts of a system to synchronously configure some >> things so other parts will come up as expected? > > I am pretty sure systemd-devel is the better place to discuss this. But > here are a few comments after reading throught the bug report: I didn't know it existed... > > Yes, we want that people place each service in an individual service > file. Only then we can supervise the services properly. It is possible > to spawn multiple high-level processes from a single service, but that > is mostly intended as compat kludge to support SysV init scripts where > this is possible. In general however, we want people to do have a 1:1 > mapping. Only then we can restart services if needed, we can catch > crashes, and show proper information about your service. > > So, I'd suggest strongly not to try starting all services from a single > file. There's a reason why we explicitly forbid having more than one > ExecStart= in a unit file (except for Type=oneshot services). Thank you for this explanation. It appears your definition of a service might be a bit too simple for many subsystems. You seem to think that on service will only start one system daemon, which is not the case in the more complex subsystems. > > Note that systemd unit files are not a programming language. And that > for a reason. If you want shell, then use shell, but don't try to misuse > the purposefully simple service file syntax for that. Boy... What I would give for a shell!! 8-) > > Also, you should not spawn forking processes in ExecStartPre=, that's > not what it is for. In fact I am pretty sure I will change systemd now > to kill off all remaining processes after each ExecStartPre= command now > that I am aware that people are misusing it like this. If they are not for forking off process, what are the for? It seems quite logical that one would use a number of ExecStartPre= commands to do some set up and then use the ExecStart= to start the daemon. > > ExecStartPre= is executed strictly in order, and in the order they > appear in the unit file. True, but there is no synchronization. Meaning first process can end after the second process, which think is a problem. > > I believe that services should be enabled/disabled at one place only, > and that is where you can use "systemctl enable" and "systemctl > disable". Adding a service-specific second-level of disabling in > /etc/sysconfig/ is confusing to the user, and not necessary. You'll do a > great service to your users if they can enable/disable all individual > services the same way. (And UI writers will be thankful for that too) In a simple subsystem maybe, but many subsystems have a large number of configuration knobs that are needed so the subsystem can function in a large number of different environments. So in the past its been very handy and straightforward to be able to tweak one file to set configurations on different, but related, subsystems. > > There's no point in ever unloading kernel modules, unless you do it for > debugging or testing reasons. No init script should ever include an > "rmmod" or "modprobe -r". And we try to make static module loading > unnecessary. There's nowadays auto-loading for most modules in one way > or another, using MODALIAS and similar constructs in the kernel > modules. If you really need to load a module statically, then please do > so via /etc/modules-load.d/ so that the user has centralized control on > this. I agree unloading modules is unnecessary, but, IMHO, its much similar to manage one start up file that loads multiple modules than one start up script and multiple modules-load.d files.. > > This is not going to work: > > ExecStart=$FOO bar waldo > > I.e. variable substitution for the binary path (it will work for the > arguments, just not for the binary path). This limitation is necessary > due to some SELinux innerworkings in systemd. It's a limitation we > probably could fix if we wanted to, but tbh I find it quite questionable > if you spawn two completely different binaries and still call it by the > same service file. Spawning different binaries to do set up, like exporting directories before the a system daemon is started seems very reasonable and expected practice. > > In general if services use a lot of /etc/sysconfig/ settings then this > is probably an indication that the service code should be fixed and > should just get proper configuration files. I don't understand this generalization. For a very long time subsystems have used /etc/sysconfig to store there configuration files and now they are broken because they do? Plus they are not "proper" configuration files? If you need to interpret > these files, outside of the daemon, and the simple variable substitution > is not sufficient, and you need a programming language to interpret the > settings, then use a programming language, for example shell. You can > start shell scripts from systemd, like any other executable, and then > exec the real binary in the end. Of course, these solutions are somewhat > hacky, and I think in the long run binaries should be stand-alone and > should be able to read their own configuration themselves. But if you > really need a shell script, then go for it, stick it in > /usr/lib/<yourpackage>/scripts/ or so, and execute that from ExecStart=. Perfect... I will used this "hacky" to do all the system setup and configuration that is needed... Thanks for taking the time.... steved. > > I will probably blog about sysconfig in a systemd world soon. > > Type=oneshot is for one shot services, not continously running > services. Type=oneshot is for stuff like fsck, that runs once at boot > and finishes, and only after it finished boot will continue. > > I am aware that some things I point out above are not how people used to > do things on SysV, but well, we want to get things right, and if you use > systemd natively, then we ask you to clean up things and not just > translate things 1:1. > > Lennart > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
