[systemd-devel] Services enabled by default?

Gustavo Sverzut Barbieri barbieri at profusion.mobi
Mon Sep 20 06:13:20 PDT 2010


On Mon, Sep 20, 2010 at 10:01 AM, Kay Sievers <kay.sievers at vrfy.org> wrote:
> On Mon, Sep 20, 2010 at 14:16, Gustavo Sverzut Barbieri
> <barbieri at profusion.mobi> wrote:
>>  - systemd-modules-load.service: why do we need this as a separated
>> service?
>
> What else would it be?

built-in systemd, just like locale setup?


>> Anyway, shouldn't it be in
>> /lib/systemd/system/sysinit.target.wants by default?
>
> It should, yes.
>
>>  - systemd-vconsole-setup.service: shouldn't it be in
>> /lib/systemd/system/sysinit.target.wants? Or maybe
>> /etc/systemd/system/sysinit.target.wants?
>
> Should be in /lib by default.
>
>>  - 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?
>
> Same here. Enabled by default
>
>>  - 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?
>
> Same.
>
>>  - 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?)
>
> We want native fsck here, I guess. This is not implemented at the
> moment, but will happen pretty soon, I expect.

ok, so fsck will happen to remount it rw? I guess you're calling
actual fsck process only if the mount failed (I use ext4 and don't
want fsck to run based on number of mounts and like).


>> while at it:
>>  - do we really need to install 6 getty services by default? can't we
>> just install one and people that don't like to use 1 + screen enable
>> more? It is a PITA to remove the links after every installation of
>> systemd :-/
>
> Yeah, I don't like them too. It's just the old stuff every inittab
> had. Michael Meeks asked for start-getty-on-vt-switch only, which
> sounds nice. Maybe we can do that when we move most of the
> session-tracking stuff from ConsoleKit into systemd and kill the
> ConsoleKit daemon.

that would be the best of both worlds. :-)


>>  - 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"...
>
> Yeah, usually only the .service is activated.

I just had the mount point in /etc/fstab, the .mount was
enabled/activated automatically.


> And the service for /var/run /var/lock should just be enabled by default in /lib.

really? maybe people don't want /var/run or /var/lock in tmpfs... but
yeah, these can go and rm those links... it's moot point to let it so
loose. Will add these two.


>>  - should we provide a "clean /tmp" service?
>
> Maybe. Using tmpwatch?

never used it, but seems like a solution.

Maybe integrate it into systemd? It's one single .c file as far as I
could check.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202


More information about the systemd-devel mailing list