I've tried netcfg, which worked, but prolonged the boot by 2s compared to the systemd/rc.conf combo of starting /etc/rc.d/network.
Just because systemd-analyze says that netcfg.service took 2 seconds longer than network.service, that doesn't neccessarily mean that boot actually took 2 seconds longer, because services are started in parallel. nevertheless I'm surprised that netcfg takes 2 seconds to set up a static ip, seems really a bit long for me.
In netcfg 2.8.5, the 2 second delay is turned into a polling timeout. For good hardware/drivers, this means the delay is gone. If your card is slow to come up, netcfg will calmly wait for it .
65kid was right about the parallel thing, though.
]]>You would get 3 ttys from this, the other ones are ignored. I do not now if it is safe to have less than that.
Try out 2 and tell me :-P
Startup finished in 8142ms (kernel) + 3425ms (userspace) = 11567ms
Which I'm happy with on my HDD. Since I'm using e4rat and autologin and starting some apps, which e4rat makes go into the kernel figure, it's really ok.
So, look out for unecessary lines in fstab, specifically tmpfiles.
]]>For example, Eee 1000, 8GB + 32GB original SSDs, 1.6Ghz Atom N270 with upgraded 2GB Crucial 667MHz DDR2.
Kernel Netbook:
Startup finished in 2319ms (kernel) + 2475ms (userspace) = 4795ms
Default Kernel is about 5700ms
979ms systemd-udev-trigger.service
923ms udisks2.service
658ms NetworkManager.service
645ms systemd-vconsole-setup.service
423ms sys-kernel-debug.mount
414ms dev-mqueue.mount
408ms dev-hugepages.mount
290ms systemd-logind.service
252ms home.mount
122ms systemd-udev.service
117ms dbus.service
111ms systemd-tmpfiles-setup.service
106ms systemd-sysctl.service
76ms console-kit-log-system-start.service
65ms systemd-remount-fs.service
48ms console-kit-daemon.service
41ms systemd-readahead-replay.service
37ms accounts-daemon.service
36ms systemd-readahead-collect.service
24ms systemd-user-sessions.service
21ms upower.service
7ms tmp.mount
7ms rtkit-daemon.service
5ms proc-sys-fs-binfmt_misc.mount
4ms sys-fs-fuse-connections.mount
GRUB2 Default command line: "quiet add_efi_memmap init=/bin/systemd root=/dev/sda1 rootfstype=ext4 ro logo.nologo raid=noautodetect libahci.ignore_sss=1"
I have no daemons in rc.conf. I don't need cron at the moment, syslog-ng isn't really required as systemd has journald. See if you can specify more of the config at the grub command prompt to avoid some detection routines. Module loading is taking about .5s which will delay anything requiring them, such as network drivers. Might be worth trying to build them in a custom kernel.
initrd doesn't seem to have much of an effect on the reported time, but if you can do without, it should speed up overall boot time.
]]>Startup finished in 7493ms (kernel) + 9859ms (userspace) = 17353ms
4606ms netcfg@eth0static.service
...
Startup finished in 7588ms (kernel) + 7314ms (userspace) = 14903ms
(snip)
46ms eth0-network.service
Concerning nfs; the long (70s) start time was with ... noauto,comment=systemd.automount ... in fstab. Thusly no *.mount file of my making (or Arch) was involved. I'll remove the 'syslog' references.
About console/tty1 ( ls /etc/systemd/system/getty.target.wants/
) ;
getty@tty1.service -> /usr/lib/systemd/system/getty@.service
->
[Unit]
Description=Getty on %I
BindTo=dev-%i.device
#After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
After=dev-%i.device systemd-user-sessions.service
#After=rc-local.service
# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
[Service]
Environment=TERM=linux
ExecStart=-/sbin/agetty %I 38400
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process
IgnoreSIGPIPE=no
# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIFICATION=
# Some login implementations ignore SIGTERM, so we send SIGHUP
# instead, to ensure that login terminates cleanly.
KillSignal=SIGHUP
[Install]
Alias=getty.target.wants/getty@tty1.service
The contents are not mine except two '#'. I followed the wiki here: https://wiki.archlinux.org/index.php/Sy … default.3F
I really only need one other tty except tty7 of course, so might there be simplifications done? (Slim is set to start on tty7 from /etc/slim.conf)
Really appreciate your time and knowledge! Thanks!
]]>I've tried netcfg, which worked, but prolonged the boot by 2s compared to the systemd/rc.conf combo of starting /etc/rc.d/network.
Just because systemd-analyze says that netcfg.service took 2 seconds longer than network.service, that doesn't neccessarily mean that boot actually took 2 seconds longer, because services are started in parallel. nevertheless I'm surprised that netcfg takes 2 seconds to set up a static ip, seems really a bit long for me.
And you can remove StandardError/StandardOutput from the NFS mount file. This doesn't make sense if you are not running syslog (may even cause problems, I don't know). Also remove the Wants=network.target. maybe that it what caused the long delay (70s). afaik network.target should only be pulled in by the service that actually sets up the network ( netcfg.service or your custom network service in this case).
Two other findings; in some unit files, like systemd-vconsole-setup.service, there are references to Plymouth and readahead, which you might not use.
if these references are just After/Before and readahead/plymouth are not actually enabled, this will not have any effect. So you don't have to worry that this might slow down things.
Not really sure what is going on with systemd-vconsole-setup, it takes 97ms on my system. have you some custom getty service files or just the single symlink in /etc/systemd/system/getty.target.wants/... ?
]]>Startup finished in 7588ms (kernel) + 7314ms (userspace) = 14903ms
4228ms systemd-vconsole-setup.service
2571ms systemd-remount-api-vfs.service
2010ms mnt-SERVER_NYTT.mount
1150ms dev-hugepages.mount
570ms udev.service
563ms udev-trigger.service
519ms systemd-sysctl.service
517ms sys-kernel-debug.mount
503ms systemd-modules-load.service
497ms dev-mqueue.mount
492ms sys-kernel-security.mount
490ms media.mount
476ms home.mount
367ms console-kit-daemon.service
326ms systemd-tmpfiles-setup.service
145ms sshdgenkeys.service
142ms systemd-logind.service
134ms dev-sda3.swap
110ms rpcbind.service
75ms rpc-statd.service
46ms eth0-network.service
35ms console-kit-log-system-start.service
30ms dbus.service
25ms crond.service
16ms remount-rootfs.service
14ms systemd-user-sessions.service
The recent adjustments I've made is to the nfs-client mount and to the static wired service. I've tried netcfg, which worked, but prolonged the boot by 2s compared to the systemd/rc.conf combo of starting /etc/rc.d/network. I made this more simple unit from a blueprint found in the big systemd thread, thanks to ron9;
[Unit]
Description=Network Connectivity
Requires=sys-devices-pci0000:00-0000:00:04.0-0000:01:06.0-net-eth0.device
After=sys-devices-pci0000:00-0000:00:04.0-0000:01:06.0-net-eth0.device
Wants=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set eth0 up ; /sbin/ip addr add 192.168.1.251/24 dev eth0 ; /sbin/ip route add default via 192.168.1.250
ExecStop=/sbin/ip link set eth0 down
[Install]
WantedBy=multi-user.target
This brought down the start time from about 2-4s for my static wired network to 46ms (eth0-network.service). Great!
Then my attention went to my nfs client mount (nfs4) which could take from 2s to 70s (!) to start depending on the systemd network services I used. But I thought it must be simple; start the network, maybe some rpc*.service and then mount it. Thanks to our Wiki I found a blueprint for mounting nfs shares which I edited like this;
[Unit]
Description=/mnt/SERVER_NYTT
Wants=network.target rpc-statd.service
After=network.target rpc-statd.service
[Mount]
What=192.168.1.250:/
Where=/mnt/SERVER_NYTT
Type=nfs4
Options=rw,hard,async,intr,rsize=49152,wsize=49152,proto=tcp
StandardOutput=syslog
StandardError=syslog
[Install]
WantedBy=multi-user.target
After googling, trial and error, comparing boot times, I finally understood what the wiki said. One key for me was to name the unit correctly, corresponding to my mount point. The mountpoint is /mnt/SERVER_NYTT so the unit name had to be mnt-SERVER_NYTT.mount.
Two other findings; in some unit files, like systemd-vconsole-setup.service, there are references to Plymouth and readahead, which you might not use. Another finding is that systemd is under rapid development and results you get from google are often outdated, and often Fedora specific.
But lucky us, we have 65kid and others to guide and cheer us along!
Now there's only one annyoing thing left; the systemd-vconsole-setup.service ! Why does it take so long to start? I ironed out some problem with not finding lat0-16 font, but that did nothing and journalctl has nothing to offer. Here's my /etc/vconsole.conf;
KEYMAP="sv-latin1"
FONT="lat0-16"
What's up with this? It shouldn't take 4228ms to initialize tty1? Are there other ways?
]]>Startup finished in 8080ms (kernel) + 6562ms (userspace) = 14642ms
2038ms mnt-SERVER_NYTT.mount
1197ms home.mount
894ms systemd-vconsole-setup.service
260ms console-kit-daemon.service
140ms systemd-tmpfiles-setup.service
135ms systemd-logind.service
104ms dev-hugepages.mount
87ms network.service
76ms systemd-modules-load.service
73ms udev-trigger.service
73ms sshdgenkeys.service
70ms udev.service
67ms systemd-remount-api-vfs.service
67ms dev-mqueue.mount
65ms sys-kernel-security.mount
64ms rpcbind.service
63ms systemd-sysctl.service
63ms udisks2.service
62ms sys-kernel-debug.mount
52ms media.mount
49ms rpc-statd.service
36ms console-kit-log-system-start.service
33ms systemd-user-sessions.service
23ms crond.service
19ms dbus.service
2ms remount-rootfs.service
0ms sys-fs-fuse-connections.mount
New record! Made loglevel down to 'emerg', reduced the settings for logfile size and reran e4rat.
]]>Concerning the network.service ; I see that the native one uses the command rc.d/network start (and stop), Would it be beneficial to try netcfg unit instead, for my single NIC wired interface? It would get one step closer to get rid of rc.conf as well.
well the fact that the network.service file uses the rc.d script IMHO doesn't really make it "native". Nevertheless, using netcfg may not neccessarily speed up boot but it's always better not to mix systemd with initscripts stuff like rc.d / rc.conf. The systemd-initscripts package will be dropped at some point, so why not get rid of it now?
If you only use DHCP on your wired interface you don't even need netcfg, see wiki: https://wiki.archlinux.org/index.php/Systemd#Network
see also: https://wiki.archlinux.org/index.php/Ne … md_support
]]>Concerning the network.service ; I see that the native one uses the command rc.d/network start (and stop), Would it be beneficial to try netcfg unit instead, for my single NIC wired interface? It would get one step closer to get rid of rc.conf as well.
]]> 2635ms systemd-modules-load.service
787ms console-kit-daemon.service
509ms systemd-vconsole-setup.service
358ms dev-hugepages.mount
340ms udev.service
244ms systemd-logind.service
212ms systemd-sysctl.service
211ms sys-kernel-debug.mount
196ms home.mount
144ms mnt-SERVER_NYTT.mount
142ms console-kit-log-system-start.service
119ms crond.service
105ms dbus.service
98ms rpcbind.service
96ms remount-rootfs.service
79ms systemd-user-sessions.service
33ms udev-trigger.service
26ms dev-mqueue.mount
25ms sys-kernel-security.mount
23ms network.service
22ms systemd-tmpfiles-setup.service
21ms sshdgenkeys.service
15ms systemd-remount-api-vfs.service
12ms media.mount
6ms rpc-statd.service
Good for now!
]]>systemd-analyze
Startup finished in 13785ms (kernel) + 62360ms (userspace) = 76146ms
systemd-analyze blame
2113ms mnt-SERVER_NYTT.mount
1772ms systemd-modules-load.service
1768ms home.mount
773ms console-kit-daemon.service
679ms network.service
546ms rpc-statd.service
351ms systemd-vconsole-setup.service
316ms systemd-logind.service
295ms console-kit-log-system-start.service
170ms sshdgenkeys.service
156ms dev-hugepages.mount
154ms udev.service
141ms rpcbind.service
91ms systemd-sysctl.service
81ms sys-kernel-debug.mount
74ms udev-trigger.service
50ms crond.service
31ms systemd-remount-api-vfs.service
28ms media.mount
26ms dbus.service
18ms remount-rootfs.service
18ms dev-mqueue.mount
17ms sys-kernel-security.mount
12ms systemd-user-sessions.service
2ms systemd-tmpfiles-setup.service
0ms sys-fs-fuse-connections.mount
The native unit looks like this;
cat /usr/lib/systemd/system/network.service
[Unit]
Description=Network Connectivity
Wants=network.target
Before=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rc.d/network start
ExecStop=/etc/rc.d/network stop
[Install]
WantedBy=multi-user.target
This is with only dbus in rc.conf. I know that with empty daemons in rc.conf systemd boots in somehing like 110s, so the transition from rc.conf to native systemd isn't going to well for me. Any ideas?
]]>