On Sat, 09.07.11 23:32, Steve Dickson (SteveD@xxxxxxxxxx) wrote: > >>> 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. > > > > Well, I doubt about the "many". In fact, I am aware of only one other > > occasion where people were wondering about this. And often the problems > > are only perceived problems, because people try to translate their sysv > > scripts 1:1 and are unwilling to normalize their scripts while doing > > so. > > So basically what you are saying is a service can never consist of > more than one system daemon. Well, it can, but we encourage you not to do this. The word "service" is mostly used synonymously with "daemon" in the systemd context, and we prefer if people write one service file for each daemon, as this is the easiest to understand for admins and users and makes sure supervision/monitoring works properly. > >>> 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. > > > > This is a misunderstanding. What I tried to say is that they should not > > be used to spawn off processes that fork and stay in the > > background. Processes in ExecStartPre= are executed synchronously: we > > wait for them to finish before we start the next one, and they should > > not try to play games with that and spawn stuff in the > > background. That's what I meant by saying "you should not spawn > > *forking* processes in ExecStartPre=". > > Maybe a better way to says is ExecStartPre= should not be used for > daemon process? Well, technically, not only daemon processes do this, but that's nitpicking, so let's not discuss this part further. > > There is synchronization. As I made clear a couple of times, we never > > start more than one ExecStartPre= process at a time. We start the next > > one only after the previous one finished. > Looking at https://bugzilla.redhat.com/show_bug.cgi?id=699040#c35 appears > this is not the case... I think this is a misunderstanding. "systemctl show foo.service" will show you the actual timestamps when we started/joined a process. > > Well, nothing stops you from reading the same configuration file from > > multiple services. We do that all the time, for example for > > /etc/resolv.conf. > > True... but the point is before systemd, an admin could tweak one > /etc/sysconfig file which define which daemon were started and > how they were configured... Unless I'm missing something that > is no longer the case... The admin will have to explicitly define > each an every daemon they need to run and how they are configured.. > all by hand... Well, I think it is much easier for admins if services can be enabled/disabled all the same way, instead of adding arbitrary numbers of service-specific ways to enable/disable them. Simplify things, have as many levels of disabling as necessary but as few as possible, and unify that across the different services. This is what we want to ensure by getting people to use "systemctl enable" instead of having service-specific sysconfig files for disabling/enabling services. > > By proper configuration files I mean configuration files read by the > > daemons themselves, instead of files that are actually a script that is > > interpreted by a programming language and some more scripts intrefacing > > with that. > > > > Or in other words: configuration via command line arguments or > > environment variables sucks. Much nicer are proper configuration > > files. And faking config files by parsing them in shell and then passing > > them of to daemons via env vars and cmdline args is not ideal. ^^^^^^^^^^^^ > So basically what you are is the way system daemon have been > started for the last.. say... twenty years or so is completely > wrong and systemd is here to change that! 8-) The point being... I used the word "not ideal", not "completely wrong". Amazing that you can misquote me like this even though these were the last three words of the paragraph you are responding to here! (Jon Masters is much better at reducing what I say to what he wants to believe I said... he just silently drops everything I write except the words that are handy to make his point. There's something to learn from him... ;-)) > That is your opinion which may or may not be held by the rest > of community... So please recognize it as such and please > be willing to accept dissenting views.... Oh, sure, everything I do and say just reflects my opinions. What else should it reflect? I am not the pope, and neither the pope's spokesperson. But I like to believe I have good reasons for what I propose, and I think particularly in this case I am not alone with this opinion. I mean, feel free to ignore me. But I'd be delighted if you didn't and we could get this normalized and make the NFS subsystem a bit nicer to use and more similar to the rest of the daemons we ship. There's really no need to make NFS as complex to use as it is. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
