[systemd-devel] systemd numbers for Debian Sid/unstable system (was: How do I disable old init.d scripts?)

[Lennart Poettering]

On Wed, 27.06.12 12:18, Paul Menzel (paulepanter at users.sourceforge.net) wrote:

> > You should be able to pull this down to < 1s with some love... ;-)
> > 
> > Just for the sake of curiosity, could you post the output of
> > "systemd-analyze plot" somewhere?
> 
> I was hoping you will write that. Please find the files attached.
> 
> chrony and VDR still use the init.d scripts. For chrony I have not yet
> come around to try the service files [1]. For VDR I started a thread on
> vdr at linuxtv.org [2] (although this looks to be complicated thinking of
> all the use cases).
> 
> Looking at the `systemd-analyze plot` output I would think PulseAudio
> not depending on NetworkManager and GDM3 – maybe start in parallel to
> NetworkManager and then wait for network connection – could start
> earlier too.
> 
> And lastly the mainboard is an ASRock E350M1 (AMD Fusion E-350) and it
> is a crucial m4 256 GB SSD [3]. I added the GDM3 service file and
> disabled the init.d script motd. Everything else should be a standard
> Debian Sid/unstable system.
> 

A few suggestions:

> acpid.service                          static

Should be pretty much redundant with systemd logind from 185 and newer.

> checkroot.service                      static

Should be redundant, done by systemd-fsck-root.service

> kmod.service                           static

Should be redundant, done by systemd-modules-load.service, no?

> module-init-tools.service              static

Obsoleted by kmod, no?

> urandom.service                        static

Hmm, this is already done by systemd-random-load.service, no?

>    712ms systemd-logind.service
>    615ms console-kit-log-system-start.service

No need for CK anymore, gdm and friends should support logind just
fine.

>    580ms fglrx-atieventsd.service
>    540ms chrony.service
>    515ms rc.local.service

The rc-local generator should be smart enough to pull this in only if it
exists. It's a really slow service and most likely just a NOP anyway.

>    509ms vdr.service
>    487ms sysfsutils.service

What is this? This stuff sounds like something that can just go away...

>    484ms ssh.service
>    444ms cron.service
>    444ms udev.service
>    407ms systemd-user-sessions.service
>    360ms media.mount
>    359ms systemd-remount-api-vfs.service
>    328ms network-manager.service
>    328ms dev-mqueue.mount
>    319ms udev-trigger.service
>    319ms systemd-modules-load.service
>    300ms sys-kernel-debug.mount
>    288ms dev-hugepages.mount
>    287ms systemd-sysctl.service
>    256ms sys-kernel-security.mount
>    239ms networking.service
>    205ms gdm3.service
>    195ms hdparm.service

This really should go. It's relly unnecessary these days and if it is
really desired then should be done via a udev rule, not as a
service. (see other discussion on the ML)

>    191ms console-setup.service

Appears to be something that systemd-vconsole-setup should already handle.

>    191ms screen-cleanup.service

Something for tmpfiles?

>    167ms systemd-tmpfiles-setup.service
>    147ms pulseaudio.service

Hmm, as a system service? Meh..

>     87ms polkitd.service
>     79ms debian-fixup.service
>     71ms keyboard-setup.service

Also something systemd-vconsole-setup could do?

>     63ms remount-rootfs.service
>     44ms console-kit-daemon.service

Again, CK is obsolete.

>     40ms accounts-daemon.service
>     29ms boot-efi.mount

Hmm, just out of curiosity, what does Debian do here? they automatically
mount the EFI partition to /boot/efi? Is that listed in fstab? Can you
point me to some details on this?

>     28ms upower.service
>     25ms udisks.service
>     18ms rtkit-daemon.service

Otherwise looks good!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.