On Wed, 27.06.12 12:18, Paul Menzel (paulepan...@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 > v...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel