On Wed, 14.07.10 21:38, Bill Nottingham (notting@xxxxxxxxxx) wrote:
> > 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.
Well, you criticised that we use the term "unit" for this, which was
previously unused, that is unrelated to the installation directories for
them.
> 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)
Well, that is a hint whether the unit file was loaded properly. It can
happen that a running service has an invalid unit file (i.e. you started
service with a valid file, then edited and reloaded the config file), so
the "load" state is independendant of the runtime state. That said, we
probably could suppress this column for services which loaded fine
(which should be the usual case)
> - It says things like:
> '78 live units listed. Pass --all to see dead units, too.'
> when presumably, it should be talking active/inactive
Actually it shows active units and inactive units that failed. But
indeed the the term "live" for this is confusing and not used elsewhere
and I have removed it now.
> - IT has JOB column (which is always empty, in observation)
Well, its empty if there's nothing started or being stooped right now,
or is waiting for some dependencies to start/stop. It will be empty if
your systemd started up completely, because there is nothing to do.
> > 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
Well, funny you are asking for this, because the special units actually
include a line telling you where to find more information about what
makes them special.
Example: /lib/systemd/system/syslog.target has this line:
# See systemd.special(7) for details
I am not sure I want to duplicate all documentation in the man pages and
in the spec fails a second time. If you think a referal like that in the
unit files won't work then I don't think that anything will ever work.
> - not exist, and only be documented in the man page (with the
> understanding that certain targets/services/automounts are
> 'internal' to systemd.)
Well, it's kinda hard symlinking non-existing unit files. If we
remove let's say "multi-user.target" from /lib/systemd/units, and the
admin wants to create a new system 'profile' by adding a target that
pulls in 'multi-user' and adds a bit more on top, then he can just
achieve that with a .wants/ symlink onto multi-user.target.
> > > - why does everything need *both* mount and automount files?
> >
> > It doesn't. Dude, this is so not fair.
>
> ... all the shipped ones do.
That's actually not true. We ship var-run.mount and var-lock.mount
(which is not enabled), which comes without automount unit. There would
be no point in doing automounting for those dirs.
> 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.
Oh, the argument for the sockets actually applies even more on mount
points. Note that the ordering for mount points and automount points is
really key. I.e. you cannot mount /var/run before you mounted
/var. systemd implicitly creates all those dependencies for you. Also,
mounting /home might require rpcbind around or some uid mapping
daemon. Which means that the point in time an automount point is
established is very different from the point in time where it is
actually replaced by the mount itself -- in terms of dependencies. Both
automatic and explicitly configured dependencies that is. And that means
you want to treat them as seperate units, that live in different places
in the dependency tree.
Of course you could still encode all meta data for both units in the
same file, but this would be more confusing i guess, since you'd have to do:
<snip>
[Unit Mount]
After=foobar.service
...
[Unit Socket]
After=waldo.service
...
</snip>
Which is kinda confusing, especially since then one of the sexy things
in systemd would go away: that the runtime object name for everything we
maintain is actually identical to the file name. Because suddenly
foo.mount would create a runtime object foo.mount and another one
foo.automount. I think for simplicity reasons it is really nice to
always have a 1:1 relationship betwee the runtime objects and the files
they are configured in, and have them have the same names.
To visualize the dependencies between the units, and in particular the
automatically generated ones (i.e. the majority) I have now added a bit
of code to systemctl which can generate data suitable for graphviz. I*ll
publish an example garphic soon. Thanks to Mathias for the suggestion.
> > > - 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.
One example: a user creates his own target "my-special-boot.target". In
which he says, "I want local file systems, I want swaps, I don't want
remote file systems and I want these three services". He can now easily
do this like this:
<snip>
echo -e "[Unit]\nDescription=Lennart's awesome boot target" > /etc/systemd/system/my-special-boot.target
mkdir -p /etc/systemd/system/my-special-boot.target.wants
cd /etc/systemd/system/my-special-boot.target.wants
ln -sf /lib/systemd/system/swaps.target \
/lib/systemd/system/local-fs.target \
/lib/systemd/system/foo.service \
/lib/systemd/system/bar.service \
/lib/systemd/system/waldo.service .
</snip>
And done. Now he can boot into this mode by passing
systemd.unit=my-special-boot.target on the kernel cmdline, or switch for
and back to and from it by using "systemctl isolate
my-special-boot.target".
If the target files wouldn't exist, it would by difficult to create
those symlinks.
> > 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*.
Well, it's just there because the old fedora sysv system is a bit weird
and used both names at different places. And so we inherited that in a way.
> > 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.
See my further comments above on why having them seperate is nice.
Note that launchd actually has everything in one file for each
service. However they do much less than systemd, and they don't launchd
for early boot, where manual dependencies actually matter.
> > sshd.socket
> > sshd@xxxxxxxxxxx:22-127.0.0.1:46660.service
> > sshd@xxxxxxxxxxxxx: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...?)
They actually are. i.e. there is a template file both of those
connection services are instantiated from. It's called
sshd@.service. I.e. with the instance name removed (where the instance
name is everything from the first "@" to the last ".").
> 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.
Well, it's a link from one place to another place. And nothing forces
you to put that in getty.target.wants. We just thought it would be cool
to group the gettys under one target, but that's just our
taste. gettys.target is in no way special, other than we install that
target by default because we thought that was good style and because it
allows you to start up all gettys with a single command.
> 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 am sorry, but if you argue that an "ln -sf" line with two arguments is
as complex as this dbu-send line, then I don't think I follow anymore.
> Given that knowledge, it makes me then wonder what exactly 'systemd-install
> disable' is supposed to do. I'll check out git.
Currently it undos the suggested installation, but leaves everything you
manually added enabled. Might be worth extending to remove all symlinks,
i.e. for package uninstall. This is now on my todo list.
> > 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.
But that again is a matter of taste, isn't it?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
