[systemd-devel] Services enabled by default?

[Lennart Poettering]

On Mon, 20.09.10 09:16, Gustavo Sverzut Barbieri (barbieri at profusion.mobi) wrote:

> Hi all,
> 
> I was asking Lennart at #systemd, but as some questions were not
> answered I'm asking them here as well: which services should be
> enabled by default, and how? After these answers are agreed I'll
> provide a patch to Makefile.am install rules.
> 
>  - systemd-modules-load.service: why do we need this as a separated
> service? Anyway, shouldn't it be in
> /lib/systemd/system/sysinit.target.wants by default?

It's a sperate service, because it is slow. This way we can paralellize
its execution with other units in userspace.

Yes, this should be in /lib/systemd/system/sysinit.target.wants by
default. If the distros decide not to use it they can remove it again
after "make install". But I do believe we'd be smart if we'd install the
suggested installation on "make install", and when people really want to
deviate from that they can do so, but on their own burden.

>  - systemd-vconsole-setup.service: shouldn't it be in
> /lib/systemd/system/sysinit.target.wants? Or maybe
> /etc/systemd/system/sysinit.target.wants?

Yes, this too should be linked to
/lib/systemd/system/sysinit.target.wants.

>  - systemd-random-seed-load.service: why do we need this as a
> separated service? Anyway, shouldn't it be in
> /lib/systemd/system/sysinit.target.wants by default?

This should be a seprate service since dealing with /dev/random is
actually slow. More importantly however this rquires writable /var. And
ordering things is much easier if they are normal services. Because then
all you need to place is an After=local-fs.target or so.

>  - systemd-random-seed-save.service: why do we need this as a
> separated service? Anyway, shouldn't it be in
> /lib/systemd/system/shutdown.target.wants by default?

Similar reasons as s-r-s-l.service.

>   - remount-rootfs.service: shouldn't it be in
> /lib/systemd/system/sysinit.target.wants? Or maybe
> /etc/systemd/system/sysinit.target.wants? People that do not use
> initramfs/initrd will need this anyway, and AFAIK this is not a
> problem if it is already mounted. Or just have it builtin in systemd
> main process (detect ro / and if so remounts rw unless /etc/fstab says
> otherwise?)

/lib/systemd/system/sysinit.target.wants is the right choice.

>   - why do  xyz.mount does not automatically enables its xyz.service?
> I've noticed that although I have /var/lock and /var/run in /etc/fstab
> and systemd recognizes them to var-lock.mount and var-run.mount, the
> setup done by their .services is not being pulled... then I had to
> manually "systemctl enable $MOUNTPOINT.service"...

I think these mount points should be enabled via
/lib/systemd/system/local-fs.target.wants, and hence should not carry an
[Install] section at all.

Whether /var/run and /var/lib is tmpfs or not should not be a choice of
the user but of the distro.

(This is unlike /tmp, where tmpfs makes a lot of sense too, but isn't
realistic because many apps are borked in put gigabytes of data in those dirs).

>   - should we provide a "clean /tmp" service?

Ideally, we'd just mount tmpfs there, bug I guess given that we don't do
that we might want to add a tool for this, indeed.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.