[gelöst]ansible 20.04 bootzeit

pille2011 · Jun 24th 2020

Mir ist augefallen das "nmbd" bim Systemstert fast 6s braucht,ist das normal?

Code

frank@stube:~$ systemd-analyze blame
7.281s systemd-udev-settle.service
5.768s nmbd.service
4.389s systemd-logind.service
4.197s vdr.service
4.159s dev-sda1.device
2.663s systemd-journald.service
2.601s udisks2.service
2.556s x@vt7.service
2.410s systemd-networkd.service
2.121s accounts-daemon.service
2.025s systemd-timesyncd.service
2.024s systemd-resolved.service
1.910s snapd.service
1.900s networkd-dispatcher.service
1.533s nfs-server.service
1.445s avahi-daemon.service
1.379s proftpd.service
1.163s user@666.service
1.041s smbd.service
781ms systemd-rfkill.service
775ms apport.service
754ms etc-setserial.service
731ms grub-common.service
645ms keyboard-setup.service
633ms setserial.service
585ms systemd-udev-trigger.service
584ms user@1000.service
575ms alsa-restore.service
566ms hddtemp.service
552ms snapd.seeded.service
548ms ssh.service
545ms autofs.service
542ms wpa_supplicant.service
516ms nfs-mountd.service
487ms rsyslog.service
443ms lm-sensors.service
408ms e2scrub_reap.service
397ms grub-initrd-fallback.service
311ms atd.service
308ms proc-fs-nfsd.mount
302ms apparmor.service
280ms systemd-journal-flush.service
265ms blk-availability.service
224ms lvm2-monitor.service
219ms systemd-fsck@dev-disk-by\x2duuid-e236e91c\x2de649\x2d4c36\x2d86eb\x2d3157cce52bca.service
190ms plymouth-quit-wait.service
189ms plymouth-quit.service
189ms systemd-udevd.service
181ms polkit.service

Display More

wmautner · Jun 24th 2020

Nein, aber was sagt /var/log/samba/log.nmbd? Ich kann mir nur ein Problem mit dem "Workgroup name" vorstellen ...

seahawk1986 · Jun 24th 2020

Was liefert denn systemd-analyze critical-chain bzw. wie sieht das im Gesamtzusammenhang aus, wenn du den Bootvorgang plotten lässt? systemd-analyze plot > boot.svg

davie2000 · Jun 24th 2020

Das ist definitiv nicht normal - bei mir braucht der gerade mal 159 ms - frisch gebootet von SSD:

Code

systemd-analyze blame
3.885s epgd.service
3.798s dev-sdb1.device
2.595s vdr.service
2.348s mariadb.service
1.911s postfix@-.service
1.508s systemd-networkd-wait-online.service
1.291s systemd-journal-flush.service
1.286s x@vt7.service
944ms networkd-dispatcher.service
857ms udisks2.service
744ms lircd-setup.service
569ms lvm2-monitor.service
564ms snapd.service
532ms keyboard-setup.service
464ms smbd.service
418ms systemd-modules-load.service
375ms accounts-daemon.service
313ms grub-common.service
312ms apparmor.service
297ms nfs-server.service
282ms systemd-tmpfiles-setup-dev.service
250ms oscam.service
213ms preload.service
208ms systemd-fsck@dev-disk-by\x2duuid-87a6fe9e\x2dd135\x2d4bfc\x2d906c\x2da4cf854d0206.service
204ms apport.service
204ms systemd-sysctl.service
198ms systemd-logind.service
177ms systemd-journald.service
174ms systemd-udevd.service
159ms nmbd.service
155ms proc-fs-nfsd.mount
154ms lxd-containers.service
146ms systemd-udev-trigger.service
143ms systemd-resolved.service
138ms systemd-timesyncd.service
130ms autofs.service
118ms rsyslog.service
117ms user@666.service
112ms user@1000.service
107ms polkit.service
101ms snapd.seeded.service
93ms kmod-static-nodes.service
90ms dev-mqueue.mount
90ms ufw.service
87ms nfs-blkmap.service
81ms systemd-random-seed.service
76ms wpa_supplicant.service
75ms lm-sensors.service
74ms run-rpc_pipefs.mount
73ms sys-kernel-debug.mount
71ms avahi-daemon.service
67ms systemd-remount-fs.service
67ms ebtables.service
66ms ssh.service
61ms plymouth-quit-wait.service
59ms systemd-tmpfiles-setup.service
59ms plymouth-quit.service
56ms dev-hugepages.mount
56ms systemd-tmpfiles-clean.service
50ms alsa-restore.service
45ms systemd-update-utmp.service
45ms srv.mount
44ms systemd-networkd.service
39ms nfs-idmapd.service
38ms nfs-mountd.service
25ms epghttpd.service
25ms console-setup.service
25ms rpcbind.service
22ms systemd-user-sessions.service
20ms nfs-config.service
17ms dev-disk-by\x2duuid-7465d9bf\x2dbdf6\x2d4d0e\x2d846d\x2d1f4231df5e43.swap
16ms plymouth-start.service
15ms ureadahead-stop.service
13ms plymouth-read-write.service
12ms blk-availability.service
8ms setvtrgb.service
8ms systemd-update-utmp-runlevel.service
6ms nvidia-persistenced.service
5ms yavdr-xorg.service
5ms lxd.socket
5ms wait-for-dvb@1.service
4ms sys-fs-fuse-connections.mount
4ms sys-kernel-config.mount
4ms postfix.service
3ms wait-for-dvb@0.service
2ms snapd.socket

Display More

pille2011 · Jun 25th 2020

Code

frank@stube:~$ sudo su
[sudo] Passwort für frank:
root@stube:/home/frank# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @20.062s
└─multi-user.target @20.055s
└─vdr-net-monitor.service @20.040s
└─vdr.service @15.989s +4.030s
└─x@vt7.service @13.617s +2.359s
└─basic.target @11.331s
└─sockets.target @11.331s
└─snapd.socket @11.325s +5ms
└─sysinit.target @11.305s
└─systemd-timesyncd.service @9.284s +2.019s
└─systemd-tmpfiles-setup.service @9.113s +122ms
└─local-fs.target @9.029s
└─run-user-666.mount @16.298s
└─local-fs-pre.target @8.671s
└─multipathd.service @8.512s +157ms
└─systemd-udev-settle.service @1.539s +6.967s
└─systemd-udev-trigger.service @942ms +580ms
└─systemd-udevd-kernel.socket @796ms
└─system.slice @757ms
└─-.slice @757ms
root@stube:/home/frank#

Display More

Code

root@stube:/home/frank# nano boot.svg
GNU nano 4.8 boot.svg
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="2669px" height="6770px" version="1.1" xmlns="http://www.w3.org/2000/svg">
<defs>
<style type="text/css">
<![CDATA[
rect { stroke-width: 1; stroke-opacity: 0; }
rect.background { fill: rgb(255,255,255); }
rect.activating { fill: rgb(255,0,0); fill-opacity: 0.7; }
rect.active { fill: rgb(200,150,150); fill-opacity: 0.7; }
rect.deactivating { fill: rgb(150,100,100); fill-opacity: 0.7; }
rect.kernel { fill: rgb(150,150,150); fill-opacity: 0.7; }
rect.initrd { fill: rgb(150,150,150); fill-opacity: 0.7; }
rect.firmware { fill: rgb(150,150,150); fill-opacity: 0.7; }
rect.loader { fill: rgb(150,150,150); fill-opacity: 0.7; }
rect.userspace { fill: rgb(150,150,150); fill-opacity: 0.7; }
rect.security { fill: rgb(144,238,144); fill-opacity: 0.7; }
rect.generators { fill: rgb(102,204,255); fill-opacity: 0.7; }
rect.unitsload { fill: rgb( 82,184,255); fill-opacity: 0.7; }
rect.box { fill: rgb(240,240,240); stroke: rgb(192,192,192); }
line { stroke: rgb(64,64,64); stroke-width: 1; }
// line.sec1 { }
line.sec5 { stroke-width: 2; }
line.sec01 { stroke: rgb(224,224,224); stroke-width: 1; }
text { font-family: Verdana, Helvetica; font-size: 14px; }
text.left { font-family: Verdana, Helvetica; font-size: 14px; text-anchor: start; }
text.right { font-family: Verdana, Helvetica; font-size: 14px; text-anchor: end; }
text.sec { font-size: 10px; }
]]>
</style>
</defs>

Display More

seahawk1986 · Jun 25th 2020

Also spielt das Warten auf den Start von nmbd keine Rolle bei der Verzögerung des Bootvorgangs und 20 Sekunden sind für ein ION-System nicht schlecht.

Die multipath-tools, die die multipathd.service installieren, sind wie es aussieht eine Abhängigkeit des Pakets ubuntu-server, das man prinzipiell deinstallieren kann, wenn man es nicht braucht - damit sollte man sich das Warten auf systemd-udev-settle.service sparen können. Man sollte dabei nur aufpassen welche automatisch installierten Pakete dann bei einem apt-autoremove vom System geworfen werden und die noch benötigten als manuell installiert markieren.

PS: Häng die boot.svg einfach an, vom Kopf der Datei in dem Ausschnitt, den du mit nano siehst, hat niemand etwas.

pille2011 · Jun 25th 2020

seahawk1986 wrote:

Also spielt das Warten auf den Start von nmbd keine Rolle bei der Verzögerung des Bootvorgangs und 20 Sekunden sind für ein ION-System nicht schlecht.

Die multipath-tools, die die multipathd.service installieren, sind wie es aussieht eine Abhängigkeit des Pakets ubuntu-server, das man prinzipiell deinstallieren kann, wenn man es nicht braucht - damit sollte man sich das Warten auf systemd-udev-settle.service sparen können. Man sollte dabei nur aufpassen welche automatisch installierten Pakete dann bei einem apt-autoremove vom System geworfen werden und die noch benötigten als manuell installiert markieren.

PS: Häng die boot.svg einfach an, vom Kopf der Datei in dem Ausschnitt, den du mit nano siehst, hat niemand etwas.

OK.vielen Dank

[gelöst]ansible 20.04 bootzeit

Share

Similar Threads

yavdr ansible

[yaVDR-Ansible] "Umfrage" Bootzeiten ...