Hi,
ich hab letztens das kernelupdate von 3.13-7.towo-siduction-amd64 auf linux-image-3.14-3.towo-siduction-amd64 installiert (wegen root-bug) und mir fiel recht schnell auf, dass mein rechner danach merklich langsamer war.
ich verwende eine ssd und schon der systemstart ging verhältnismäßig träge, ebenso lief wine langsamer (ok schlechtes beispiel). ich muss dazu sagen, dass der leistungsabfall nicht extrem ist, aber doch merklich. Hat jemand ähnliches bemerkt?
Ich hab hier auch seit ein paar Tagen eine nervige Verzögerung beim booten mit meiner ssd.
vorher hatte ich ne bootzeit von 14 sec vom grub Schirm bis zum stehen des XFCE Desktop.
z.Zt. pausiert die Kiste mit der systemd Auskunft das die Partition sda4 sauber wäre sage und schreibe 50 sec. bis das booten weitergeht. Danach schein dann alles normal. Hab keine Ahnung woran das liegt.
Edit: war bei mir ein eintrag in /etc/interfaces für eth0 auf meinem Laptop. Da hat er sich dann nen Wolff gesucht,wo er kein Kabel an eth0 hatte.
Nu is alles wieder gut :)
@dieres: kannst du da genaueres aus dem Log von systemd posten?
Geht mir auch so. SysV hat von HDD schneller gebootet als Systemd von SSD. Und wo versteckt die Eier legende Wollmilschsau ihre Logs ?
oppa@oppa-hex-ssd:~$ ls /var/log
alternatives.log apt btmp.1 cups dmesg.0 dmesg.3.gz dpkg.log.1 fontconfig.log hp libvirt pm-powersave.log preload.log wtmp Xorg.0.log
alternatives.log.1 bootstrap.log chkrootkit dirmngr dmesg.1.gz dmesg.4.gz dpkg.log.2.gz fsck journal ntpstats pm-powersave.log.1 samba wtmp.1 Xorg.0.log.old
alternatives.log.2.gz btmp ConsoleKit dmesg dmesg.2.gz dpkg.log faillog gdm3 lastlog partimage pm-powersave.log.2.gz speech-dispatcher wvdialconf.log
Zeigt doch mal jeweils ein systemd-analyze blame mit den beiden Kernen
greetz
devil
Ah Bindestrich, das mit analyze blame hatte ich noch im Kopf. Aber der ist wohl vom letzten Wakeup. Ich hoffe, ich habe den Kernel noch...
root@oppa-hex-ssd:~# systemd-analyze blame
3.941s systemd-suspend.service
1.773s dnsmasq.service
Und das ist rot in journalctl -b
...
May 12 21:26:55 oppa-hex-ssd systemd-udevd[344]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:55 oppa-hex-ssd systemd-udevd[346]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:55 oppa-hex-ssd systemd-udevd[345]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
...
May 12 21:26:56 oppa-hex-ssd systemd-udevd[462]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:56 oppa-hex-ssd systemd-udevd[464]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
...
May 12 21:26:56 oppa-hex-ssd systemd-udevd[461]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
May 12 21:26:56 oppa-hex-ssd kernel: [drm] ring test on 0 succeeded in 1 usecs
May 12 21:26:56 oppa-hex-ssd kernel: [drm] ring test on 3 succeeded in 1 usecs
May 12 21:26:56 oppa-hex-ssd systemd-udevd[480]: failed to execute '/lib/udev/kmod' 'kmod sg': No such file or directory
...
May 12 21:26:58 oppa-hex-ssd libvirtd[979]: libvirt version: 1.2.4
May 12 21:26:58 oppa-hex-ssd libvirtd[979]: direct firewall backend requested, but /sbin/ebtables is not available: No such file or directory
...
May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 0.debian.pool.ntp.org
May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 1.debian.pool.ntp.org
May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 2.debian.pool.ntp.org
May 12 21:26:59 oppa-hex-ssd ntpd_intres[1170]: host name not found: 3.debian.pool.ntp.org
...
May 12 21:41:52 oppa-hex-ssd systemd[1]: Starting Cleanup of Temporary Directories...
May 12 21:41:52 oppa-hex-ssd systemd-tmpfiles[22496]: stat(/run/user/1000/gvfs) failed: Permission denied
May 12 21:41:52 oppa-hex-ssd systemd[1]: Started Cleanup of Temporary Directories.
Hmm, außer der Pause beim Booten fühlt sich alles Gesund an.
So, das ist der älteste Kernel den ich noch habe. Alles im Sub-Sekunden Bereich habe ich weggelassen. udev scheint ein wenig zu brauchen.
root@oppa-hex-ssd:~# systemd-analyze blame
30.278s systemd-udev-settle.service
1.365s systemd-fsck-root.service
1.079s acpi-fakekey.service
529ms virtualbox.service
...
root@oppa-hex-ssd:~# uname -r
3.13-7.towo-siduction-amd64
Hast du nfs-Shares gemountet?
Ich beobachte hier ähnliches. Während des Bootens erscheint zunächst beispielsweise:
systemd-fsck[690]: /dev/sdb8: sauber, 1520/9969664 Dateien, 6264458/39847216 Blöcke
systemd-fsck[703]: /dev/sdb5: sauber, 440/5238560 Dateien, 15441384/20972849 Blöcke
systemd-fsck[690]: linuxdata: sauber, 713/5242880 Dateien, 8659835/20971519 Blöcke
systemd-fsck[710]: linuxhome: sauber, 69386/1310720 Dateien, 2499914/5242880 Blöcke
Danach mitunter ziemlich lange Pause, dann geht's weiter.
Ich vermute, dass einige Einträge in meiner /etc/fstab schuld sind. Mein NAS (Synology DS 212+) stellt einige nfs Shares zur Verfügung, die ich via fstab mounte. Entsprechende Einträge bekamen mit dem Umstieg auf systemd eine andere Syntax:
nas:/volume1/photo /media/nasphoto nfs noauto,x-systemd.automount,x-systemd.device-timeout=10,defaults 0 0
Ein Reboot ist wesenlich schneller, wenn ich diese fstab-Einträge auskommentiere. Irgendwie blöd und ganz klar ein Komfortverlust. Eine andere Lösung habe ich noch nicht gefunden. Irgendwo las ich was über automount, da habe ich mich aber noch nicht reingefuchst.
/edit
$ systemd-analyze blame
30.468s systemd-udev-settle.service
1.037s acpi-fakekey.service
757ms acpi-support.service
606ms loadcpufreq.service
603ms ModemManager.service
590ms systemd-fsck@dev-disk-by\x2duuid-3a0c2dec\x2de3d2\x2d4672\x2daba1\x2d292333668013.service
515ms bootlogs.service
506ms systemd-fsck@dev-disk-by\x2duuid-14f17913\x2d5850\x2d440c\x2d8590\x2d2836dcf47bc4.service
499ms systemd-fsck@dev-disk-by\x2duuid-a8f2e75d\x2d36c2\x2d4578\x2db318\x2db8549ab65d05.service
497ms systemd-fsck-root.service
462ms systemd-fsck@dev-disk-by\x2duuid-6d0971d7\x2de467\x2d4254\x2d9fba\x2d46c46d39bf47.service
249ms dev-disk-by\x2duuid-6383399e\x2d45c3\x2d459e\x2da010\x2dd808dbf97481.swap
Hi,
mit den nfs-Shares habe ich kein Problem, d.h. sie werden auch nicht langsamer abgearbeitet als wie vorher.
# NFS-Mounts NAS Synology DS211
diskstation:/volume1/Exchange /mnt/import/dataexchange nfs rw,noauto,users,x-systemd.automount,vers=3 0 0
diskstation:/volume1/VM /mnt/import/vm nfs rw,noauto,users,x-systemd.automount,vers=3 0 0
diskstation:/volume1/Backup_Diskimages /mnt/import/diskdump nfs rw,noauto,users,x-systemd.automount,vers=3 0 0
diskstation:/volume2/Backup_Filesnapshots /mnt/import/rsnapshot nfs rw,noauto,users,x-systemd.automount,vers=3 0 0
diskstation:/volume2/Backup_Archive /mnt/import/archive nfs rw,noauto,users,x-systemd.automount,vers=3 0 0
Bewegt sich alles "normalen" Bereich.
# systemd-analyze blame|grep nfs
108ms nfs-kernel-server.service
82ms nfs-common.service
@BlueLupo: Auffällig ist halt, dass es hier mit aktiviertem fstab-Eintrag heftige Pausen hat, auskommentiert geht's fix.
Was es mit dem 30 Sekunden benötigenden systemd-udev-settle.service (s.o.) auf sich hat, weiß ich nicht. @OppaErich berichtet in diesem Thread ähnliches.
Wenn ich via systemd-analyze blame nach nfs greppe, bekomme ich ein recht ähnliches Ergebnis wie deins.
@pit: ist dein NAS vielleicht im Ruhezustand (Platten abgeschaltet) gewesen?
So schauts bei mir aus:
# systemd-analyze blame|grep systemd-udev-settle.service
1.220s systemd-udev-settle.service
Mit dem Parameter x-systemd.device-timeout=10 kann man spielen/weglassen/kürzen.
greetz
devil
D.h., zwischen meinem fstab-Eintrag u. dieser Meldung gibt es einen Zusammenhang?
5.176s systemd-udev-settle.service
Sieht auf jeden Fall jetzt besser aus. Habe in der fstab auf 500ms reduziert.
fstab ? Spielt der mit Partitionen rum die gar nicht gemounted werden sollen ?
root@oppa-hex-ssd:~# cat /etc/fstab
UUID=507AB7337AB71526 /media/disk1part1 ntfs noauto,users,ro,dmask=0022,fmask=0133,nls=utf8 0 0
UUID=46844C6B844C5F93 /media/disk1part2 ntfs noauto,users,ro,dmask=0022,fmask=0133,nls=utf8 0 0
UUID=40529CF71C3D6D3D /media/disk1part3 ntfs noauto,users,ro,dmask=0022,fmask=0133,nls=utf8 0 0
UUID=f92a89dc-1a40-46d6-a228-4e90e2206a5c /media/disk1part5 ext4 noauto,users,rw,exec,relatime 0 0
UUID=94f3f15c-2a10-4bdd-81e0-7fb0ba7a9f89 /media/disk1part6 ext4 noauto,users,rw,exec,relatime 0 0
UUID=1138dfcf-3e8b-4880-999f-b8a8381b3b1b /media/disk1part7 ext4 noauto,users,rw,exec,relatime 0 0
UUID=9e040c55-ffe5-4e81-a27e-dd02e01264dd none swap sw 0 0
UUID=40529CF71C3D6D3D /media/disk2part1 ntfs noauto,users,ro,dmask=0022,fmask=0133,nls=utf8 0 0
UUID=3b851ea5-2726-4cca-9d28-f2ea725f03e2 / ext4 discard,noatime,commit=600,defaults,errors=remount-ro 0 1
Hi OppaErich,
nimm die Mountpoints /media/disk?part? alle raus, wenn du sie nicht benötigst. Wenn du einzelne benötigst würde ich mir aussagekräftigere Einhängpunkte unter /media oder /mnt erstellen.
Ich bin mir fast sicher, dass das mit dem Kernel nix zu tun hat (bin ich jetzt off topic?), aber vielleicht hatte der Thread opener ja auch die falsche Vermutung bez. der Ursache für sein Problem. Der Reihe nach:
Jetzt hab ich's auf meinem Laptop(1) auch noch mal gewagt und auf systemd umgestellt. Läuft, aber sehr zäh: Bis der KDE Desktop steht, dauert's inakzeptabel lang. Einiges habe ich bereits bereinigt (fstab, bluetooth, privoxy, exim4, dmakms), aber es dauert noch immer zu lange:
systemd-analyze blame =>
Vorher: http://paste.siduction.org/20140517093914
Nachher: http://paste.siduction.org/20140517104314
Offensichtlich hängt z.B. bluetooth. Meine Versuche, das Laden des Moduls beim Start zu unterbinden(2) scheinen zu scheitern:$ /etc/init.d/bluetooth status
bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
Active: active (running) since Sa 2014-05-17 11:57:12 CEST; 3min 35s ago
Main PID: 896 (bluetoothd)
CGroup: name=systemd:/system/bluetooth.service
└─896 /usr/sbin/bluetoothd -n
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: Failed to init time plugin
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: Failed to init alert plugin
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: Failed to init thermometer plugin
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: Failed to init gatt_example plugin
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: Bluetooth Management interface initialized
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: sdp_extract_attr: Unknown data descriptor : 0xb1 terminating
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: sdp_extract_attr: Unknown data descriptor : 0x38 terminating
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: hci0: Load Long Term Keys (0x0013) failed: Not Supported (0x0c)
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: hci0: Set Discoverable (0x0006) failed: Not Powered (0x0f)
Mai 17 11:57:19 dell-notebook bluetoothd[896]: bluetoothd[896]: hci0: Set Powered (0x0005) failed: <unknown status> (0x12)
Da cron auch ziemlich viel Zeit beansprucht, habe ich mal nachgesehen u. in /etc/cron.daily diese Einträge entdeckt:
0anacron, apache2, apt, aptitude, apt-show-versions, bsdmainutils, debtags, dpkg, flash,
logrotate, man-db, mlocate, ntp, passwd, sysstat
Mich würde z.B. interessieren, welche dieser Einträge Siduction aktuell standardmäßig setzt. Ansonsten ist meine reine Auflistung der Scripts ja wenig aussagekräftig.
---
(1) Machine: Dell System Vostro 3450, Kernel 14-4.towo-siduction-amd64 x86_64 (64 bit), Desktop: KDE 4.13.1 Distro: aptosid 2011-01 Γῆρας - kde-full - (201102052200)
(2) In der Datei /etc/rc.local => rfkill block bluetooth; Variante 2, gleiche Datei => update-rc.d bluetooth remove
Wir haben mit anacron nichts am Hut - alle Einträge darin stammen aus debian-Paketen und sind auf das segensreiche Wirken der debian-Maintainer zurückzuführen :) - Manchmal sind diese Einträge auch sehr sinnvoll, genau wie der Einsatz von anacron.
Durch anacron kann ich sicherstellen, dass Jobs wirklich erledigt werden, wenn der Rechner zum geplanten Ausführungszeitpunkt des Jobs nicht an war. Das wird dann zum nächstmöglichen Termin erledigt - eigentlich eine sehr sinnvolle Sachen. Was allerdings mit anacron so alles gesteuert wird: Analysieren und gegebenenfalls disablen.
(Furchtbare Sprachverwirrung: Bin aktuell in einem englischen u. in einem deutschen Thread unterwegs u. hatte das im lokalen Editor falsch vorbereitet ...)
Following this (http://crunchbang.org/forums/viewtopic.php?pid=333392) I tried to temporaryly disable cron and bluetooth:
# systemctl disable cron.service
Synchronizing state for cron.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d cron defaults
Executing /usr/sbin/update-rc.d cron disable
insserv: warning: current start runlevel(s) (empty) of script `cron' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (2 3 4 5) of script `cron' overrides LSB defaults (empty).
# systemctl disable bluetooth.service
Synchronizing state for bluetooth.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d bluetooth defaults
Executing /usr/sbin/update-rc.d bluetooth disable
insserv: warning: current start runlevel(s) (empty) of script `bluetooth' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `bluetooth' overrides LSB defaults (0 1 6).
rm '/etc/systemd/system/dbus-org.bluez.service'
It worked:
$ systemd-analyze blame
5.867s systemd-udev-settle.service
4.770s loadcpufreq.service
3.471s lightdm.service
But afterall it is still much to slow until KDE is fully loaded.