Stepping back, this is the situation I started with that led me to these observations:
Incoming knowledge: - Upstart and init experience - A reading of the initial 'why I did systemd, and what it intends to support' document Testing methodology: - Install it - Boot it - Poke around Is this the best way to approach it? Probably not. But, realistically, people are going to just try things and kick the tires before reading manuals. It's human nature. So, that's where I'm coming from. The idea was to determine how much of its behavior, configuration, and user interface could be logically intuited. Ideally, the administrator should not have to read the man pages to figure out beforehand how the software works... the man pages would be for reference. Now, I realize that this software is still in the fairly early stages, and I'm likely to hit warts. So some of this criticism may not be fair. But I did/do feel that the learning curve I hit when trying this out was higher than when going from sysv -> upstart. Perhaps this can be solved with more guides/faqs. Lennart Poettering (mzerq...@0pointer.de) said: > systemd uses "job", and introduces "unit". Wow. New software uses > different terms. > > And that comparison is not even fair. The thing that was called service > file in sysv is called service file in systemd too (it even has .service > is suffix, how obvious!). However since in contrast to sysv we not only > maintain services, but also mount points, devices, yadda yadda, we came > up with a more generic term for all these kinds of things, where > "service" is one kind of, and that term is "unit". How else would you > have done this? As stated below, I'd probably have separated them in the layout. Dumping all services/mounts/sockets/etc. in one place seemed overkill. > The chkconfig man page uses the term enable/disable the same way > as we do: > > enable/disable is used to say whether a service or other unit shall be > started during boot. > > active/inactive is just a more generic term for started/stopped, simply > because you cannot really say a device is "started", can you? I think some of this is just the tools being inconsistent in terminology. Take systemctl: - It has a LOAD column (which is always 'loaded', in observation) - It says things like: '78 live units listed. Pass --all to see dead units, too.' when presumably, it should be talking active/inactive - It has JOB column (which is always empty, in observation) etc. (re: 60-odd service files) I think part of my confusion stems from (as we discussed on IRC) some of the shipped units aren't wired up to anything that runs/starts something yet, and would be to work with .service, etc. files that you're intending to push into other packages. > Well, but the systemd unit files are trivial to understand. If you > honestly claim that the systemd unit files are harder to understand than > shell monsters you find ind /etc/init.d then I'll go and shoot myself. They are not easier to understand *in isolation*. For example, even though I may not understand it all, it's fairly easy to understand what /etc/init.d/iptables' purpose in life is from reading it. I can't say that about any of the 'special' task files, as they contain no data in and of themselves. Honestly, it's probably better for them just to be either: - self-documenting and contain the relevant man page segment - not exist, and only be documented in the man page (with the understanding that certain targets/services/automounts are 'internal' to systemd.) > > - why does everything need *both* mount and automount files? > > It doesn't. Dude, this is so not fair. ... all the shipped ones do. Perhaps I'm being obtuse, but it seems a matter of design to me. I'm not seeing why we just don't have Automount=yes (or OnDemand=yes, or whatever) in the .mount files, rather than another separate file that requires a matching .mount file, much like how bluetooth has 'StopWhenUnneeded'. While you describe below the reasoning for separate entries for socket & service, I'm not seeing an obvious reason for the separation here. > > - if swap, local-fs, etc. are all bookkept internally, what's the point of > > having a target file? > > Well, it's called "compatiblity". Because we keep compat with existing > stuff we automatically populate swap.target, local-fs.target and > remote-fs.target with the data from /etc/fstab. How amazing is that? We > treat the existing configuration just as another source of configurationn > that is used alongside native configuration, and then make it appear as > if it was natively configured. Yes, that I understand. I'm just not understanding why the swap.target *file* exists. I may be being overly picky, but if the 'meat' of the file is only automatically determined by the daemon itself, I'm not sure the file itself serves much purpose. > > - why does setting of Alias *also* require a symlink? (It may not, but > > local vs. rc.local seems to imply it might.) > > Well, in systemd we only read files that are requested, for perfomance > reasons. if something or somebody requests "foo.service" we load that > file. And if we then find an alias configured in that file we install > that alias too. However, if somebody looks up things under the alias > first then he will only end up with the unit file if there's a symlink > for it. OK, I was missing a detail here - I was conflating alias with name. What I was noticing was the local.service -> rc.local.service link in /lib/systemd. This is actually just bookkeeping to make sure it overrides the /etc/init.d/ service, if I'm now reading this right. I wonder if there's a better way to handle this case other than just creating more Name entries/symlinks (have the daemon do this without the symlink?), but... *shrug*. > > I do wonder if perhaps this could be simplified by: > > > > - Keeping services and targets separate on the filesystem > > Well, we have 10 types of units. If you say every type should get its > own dir then the next guy will come and say "oh, my god, this > complexity, wouldn't one dir suffice?" > > I think this is mostly a matter of taste. Yeah, likely. Although I think that targets may be different enough that they qualify. > > - Merging services and sockets into the same file where appropriate... given > > that they're tied together inherently anyway, I'm not sure why they > > need to be separate. > > Well, they have different lifecycles and dependencies and can be started > and stopped independently. > > Example: Service "dbus.service" wants to be started after > "syslog.service". The former is a socket-activated service (i.e. as in > current Rawhide), the latter is a not socket-activated (i.e. as in > current Rawhide). The dbus socket can be established very early, before > syslog is started, but dbus can only be started if syslog is actually > around and has established its socket itself. Establishing the dbus > socket early has numerous advantages, in particular since everybody can > then just go and use it (it's part if the whole idea of socket > activation). > > That's why you want to have independent entities here for sockets and > services: they can be independently activated and when one eventually > triggers activation of the other that can even pull a completely > different slew of dependencies. OK. My taste preference is to have that be configured in two sections in one file rather than two separate-but-dependent files, but I can also see the benefits of separation for consistency. > Also, there is not even a 1:1 relation between services and sockets. For > example, for ssh we probably should run one sshd instance per > connection. This results in units like these appearing in the system: > > sshd.socket > s...@2-127.0.0.1:22-127.0.0.1:46660.service > s...@3-172.31.0.50:22-172.31.0.4:43289.service Sure, but those service entries wouldn't be files in the system (unless you're planning to write them on demand somewhere...?) > > - systemd > > > > Use systemd-install to add or delete the > > /etc/systemd/system/getty.target.wants/ge...@tty4.service (or whatever) > > symlink. > > Well systemd-install will install the *suggested* configuration for you, > that's all. > > If you deviate from that you can just create or remove > symlinks as you wish. > > I.e. to remove a tty from tty4: > > $ rm /etc/systemd/system/gettys.target/wants/ge...@tty4.service > > To add one for tty9: > > $ ln -sf /lib/systemd/ge...@.service > /etc/systemd/system/gettys.target/wants/ge...@tty9.service > > And you can easily figure that out simply by duplicating what is already > there for the other ttys. Sure, but there's a lot of syntatical noise in the pathname that's important (it needs to be under getty.target.wants, it needs to be of that form), that to explain opens up a much bigger can of worms. I just wonder if that sort of long path will lead to more people cut-and-pasting than actually understanding why it's that way. (It's along the lines of why I dislike things like 'dbus-send --system --print-reply \ --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager \ org.freedesktop.ConsoleKit.Manager.CanRestart' - it feels that it's more baroque than it needs to be.) > I think you are misunderstand what systemd-install is about. I have now > added an additional sentence to the man page that explains that > systemd-install is for the *suggested* installation only, and that you > are always welcome to deviate from that. Given that knowledge, it makes me then wonder what exactly 'systemd-install disable' is supposed to do. I'll check out git. > And also, if we ship an inittab that points people to creating those > symlinks your criticism would go away and things would be the same or > even simpler then with Upstart, right? Well, I like what we have with upstart in that it just requires changing a variable in a config file, rather than filesystem-level changes. Perhaps there's a way to hack that in. More later, maybe, Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
