Arch Linux wird immer langsamer

gelöschter Benutzer · 14 März 2014

Hey,

Ich installiere und bastle bei meinem System sehr viel rum und da ist es klar, dass es nicht immer rund läuft. Doch seit ein paar Wochen wird das System immer langsamer und ich kann keinen speziellen Grund ausmachen.

Code:

~ ❯❯❯ systemd-analyze blame

         17.323s NetworkManager.service
         12.446s dkms.service
          9.438s systemd-logind.service
          8.920s lightdm.service
          5.845s alsa-restore.service
          5.767s syslog-ng.service
          5.698s bluetooth.service
          5.606s avahi-daemon.service
          3.199s home.mount
          2.293s systemd-vconsole-setup.service
          1.640s systemd-fsck@dev-disk-by\x2duuid-e6105e48\x2db5a8\x2d4970\x2dbe
          1.559s mnt-WIN7.mount
          1.386s systemd-modules-load.service
          1.082s systemd-tmpfiles-setup-dev.service
          1.003s systemd-remount-fs.service
           955ms colord.service
           807ms dev-mqueue.mount
           754ms dev-hugepages.mount
           689ms systemd-binfmt.service
           607ms sys-kernel-debug.mount
           596ms systemd-udev-trigger.service
           590ms kmod-static-nodes.service
           565ms proc-sys-fs-binfmt_misc.mount
           449ms systemd-user-sessions.service
           437ms systemd-random-seed.service
           436ms wpa_supplicant.service
           432ms systemd-rfkill@rfkill1.service
           430ms systemd-rfkill@rfkill0.service
           428ms boot.mount
           427ms systemd-rfkill@rfkill2.service
           407ms systemd-backlight@backlight:intel_backlight.service
           406ms systemd-backlight@backlight:acpi_video0.service
           340ms systemd-sysctl.service
           263ms user@620.service
           255ms polkit.service
           255ms ntpd.service
           205ms sys-fs-fuse-connections.mount
           204ms systemd-update-utmp.service
           186ms dev-disk-by\x2duuid-7f2bd342\x2d9a4f\x2d4d92\x2da5b4\x2def58fc8
           177ms sys-kernel-config.mount
           162ms tmp.mount
           132ms systemd-tmpfiles-setup.service
            79ms systemd-journal-flush.service
            74ms systemd-hostnamed.service
            67ms user@1000.service
            39ms udisks2.service
            35ms systemd-udevd.service
            34ms accounts-daemon.service
             3ms upower.service
             2ms rtkit-daemon.service
             1ms systemd-rfkill@rfkill3.service

Ich editiere später noch weitere Infos rein.

mathmos · 14 März 2014

Anstelle von Networkmanager kannst du es mal mit netctl probieren. Ist oftmals performanter.

Die Ausgabe von journalctl -b -u NetworkManager.service könnte auch interessant sein. Mit dem Parameter -b wird nur der letzte Bootvorgang berücksichtigt, falls hier nichts auffälliges enthalten ist, kannst diesen mal um -1 erweitern. Somit wird der vorherige Bootvorgang berücksichtigt. Der Parameter -u dient dazu nur den Service des Networkmanagers zu berücksichtigen.

systemd-analyze critical-chain könnte auch weiterhelfen. Eventuell ist etwas anders daran schuld, dass Networkmanager so lange braucht.

Asseon · 14 März 2014

weitere alternative für den Networkmanager ist seit der neusten systemd version auch systemd-networkd bin damit sehr zufrieden.

brauchst du dkms wirklich?
ich habs ne Zeitlang benutzt aber inzwischen kompiliere ich die module die ich brauche einfach manuel wenn ich den Kernel update.

ohne weitere infos ist das ganze aber schwer einzuschätzen

eine frage hab ich allerdings noch:
warum last du syslog-ng noch mitlaufen?

gelöschter Benutzer · 14 März 2014

dkms hab ich für selbstgeschriebene Module und den Nvidia-Treiber. Hast aber Recht, die sind nicht essentiell zum Booten und dürfen auch gerne mal manuell kompiliert werden. Einfach den Systemd-Service mal manuell aufrufen ist ja schon komfortabel genug.

Syslog-ng hab ich, weil ich dieses blöde Binärformat von systemd nicht gut finde. Kein stabiler Output. Mag halt lieber das Linux-Paradigma "everything's a file". Wird wohl rausgeworfen, wenn ich mich an systemd gewöhnt habe.

Code:

~ ❯❯❯ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @30.485s
└─multi-user.target @30.484s
  └─ntpd.service @30.071s +413ms
    └─network.target @30.070s
      └─NetworkManager.service @11.973s +18.096s
        └─basic.target @11.945s
          └─timers.target @11.892s
            └─systemd-tmpfiles-clean.timer @11.865s
              └─sysinit.target @11.622s
                └─systemd-rfkill@rfkill3.service @16.927s +13ms
                  └─system-systemd\x2drfkill.slice @6.648s
                    └─system.slice @1.236s
                      └─-.slice @1.233s

Ui. Da scheint der NTPd, der NetworkManager und rfkill ziemlich lange zu brauchen. Haben sie bis vor einer Weile eigentlich nicht, vielleicht liegts an einem Update?

Code:

~ ❯❯❯ yaourt -Q rfkill networkmanager ntp
core/rfkill 0.5-1
extra/networkmanager 0.9.8.8-3
extra/ntp 4.2.6.p5-18

journalctl -b [-1] -u NetworkManager bringt gar keinen Output.

mathmos · 15 März 2014

phre4k schrieb:
journalctl -b [-1] -u NetworkManager bringt gar keinen Output.

Hast du den Befehl als Benutzer oder mit Rootrechten ausgeführt? Mit letzteren sollte es eigentlich klappen.

gelöschter Benutzer · 16 März 2014

Als Root passiert scheinbar gar nichts. Zumindest braucht das dann so lange, dass ich keine Ahnung habe, ob noch was passiert oder nicht.

EDIT: Nach laaaangem Warten immer noch kein Output aus journalctl -b [-1] -u NetworkManager[.service].

Code:

/v/log ❯❯❯ sudo tail -n 1000 daemon.log | grep Network
Mar 16 19:14:57 crunch-573g systemd[1]: Stopping Network Time Service...
Mar 16 19:15:51 crunch-573g avahi-daemon[382]: Network interface enumeration completed.
Mar 16 19:15:56 crunch-573g systemd[1]: Started Network Manager.
Mar 16 19:15:56 crunch-573g systemd[1]: Starting Network.
Mar 16 19:15:56 crunch-573g systemd[1]: Reached target Network.
Mar 16 19:15:56 crunch-573g systemd[1]: Starting Network Time Service...
Mar 16 19:15:56 crunch-573g systemd[1]: Started Network Time Service.
Mar 16 19:16:10 crunch-573g systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 16 19:16:10 crunch-573g systemd[1]: Started Network Manager Script Dispatcher Service.
Mar 16 20:53:23 crunch-573g systemd[1]: Started Network Manager.
Mar 16 20:53:23 crunch-573g systemd[1]: Starting Network.
Mar 16 20:53:23 crunch-573g systemd[1]: Reached target Network.
Mar 16 20:53:23 crunch-573g systemd[1]: Starting Network Time Service...
Mar 16 20:53:24 crunch-573g systemd[1]: Started Network Time Service.
Mar 16 20:53:35 crunch-573g systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 16 20:53:35 crunch-573g systemd[1]: Started Network Manager Script Dispatcher Service.

/v/log ❯❯❯ sudo tail -n 1000 errors.log | grep Network
Mar  6 11:46:56 crunch-573g NetworkManager[388]: stop: assertion 'priv->pid > 0' failed
Mar  6 11:48:21 crunch-573g NetworkManager[388]: stop: assertion 'priv->pid > 0' failed
Mar  6 12:07:16 crunch-573g NetworkManager[388]: stop: assertion 'priv->pid > 0' failed
Mar  6 12:27:37 crunch-573g NetworkManager[388]: stop: assertion 'priv->pid > 0' failed

/v/log ❯❯❯ sudo tail -n 1000 messages.log | grep Network
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> (wlp4s0): supplicant interface state: associating -> 4-way handshake
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> (wlp4s0): supplicant interface state: 4-way handshake -> completed
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to wireless network 'xxx'.
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 3 of 5 (IP Configure Start) scheduled.
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 3 of 5 (IP Configure Start) started...
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> (wlp4s0): device state change: config -> ip-config (reason 'none') [50 70 0]
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Beginning DHCPv4 transaction (timeout in 45 seconds)
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> dhcpcd started with pid 1411
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Beginning IP6 addrconf.
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 3 of 5 (IP Configure Start) complete.
Mar 16 20:53:28 crunch-573g NetworkManager[412]: <info> (wlp4s0): DHCPv4 state changed nbi -> preinit
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info> (wlp4s0): DHCPv4 state changed preinit -> bound
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info>   address 192.168.1.103
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info>   prefix 24 (255.255.255.0)
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info>   gateway 192.168.1.1
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info>   nameserver '192.168.1.1'
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info>   domain name 'private.lan'
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Mar 16 20:53:34 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 5 of 5 (IPv4 Commit) started...
Mar 16 20:53:35 crunch-573g NetworkManager[412]: <info> (wlp4s0): device state change: ip-config -> secondaries (reason 'none') [70 90 0]
Mar 16 20:53:35 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 5 of 5 (IPv4 Commit) complete.
Mar 16 20:53:35 crunch-573g NetworkManager[412]: <info> (wlp4s0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Mar 16 20:53:35 crunch-573g NetworkManager[412]: <info> NetworkManager state is now CONNECTED_GLOBAL
Mar 16 20:53:35 crunch-573g NetworkManager[412]: <info> Policy set 'xxx@xxx' (wlp4s0) as default for IPv4 routing and DNS.
Mar 16 20:53:35 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) successful, device activated.
Mar 16 20:53:35 crunch-573g systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 16 20:53:35 crunch-573g systemd[1]: Started Network Manager Script Dispatcher Service.
Mar 16 20:53:49 crunch-573g NetworkManager[412]: <info> (wlp4s0): IP6 addrconf timed out or failed.
Mar 16 20:53:49 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
Mar 16 20:53:49 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 4 of 5 (IPv6 Configure Timeout) started...
Mar 16 20:53:49 crunch-573g NetworkManager[412]: <info> Activation (wlp4s0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Mar 16 20:53:58 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 20:53:58 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 20:57:07 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 20:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 20:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:08:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:08:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:10:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:14:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:14:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:16:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:16:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:36:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:36:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:40:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:42:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:44:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:44:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:46:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:46:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:48:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:48:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:50:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:50:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:54:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 21:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:00:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:00:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:02:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:02:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:02:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:06:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:06:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:08:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:08:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:12:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:12:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:14:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:14:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:24:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:24:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:28:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:28:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:32:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:32:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:38:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:38:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:40:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:40:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:44:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:44:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 22:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:04:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:08:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:08:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:10:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:10:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:12:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:12:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:14:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:14:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:20:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:24:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:28:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:28:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:30:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:30:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:36:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:36:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:40:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:46:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:46:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:50:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:50:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:50:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:54:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:54:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:56:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:56:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:56:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 16 23:58:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:00:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:02:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:04:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:04:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:06:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:06:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:10:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:10:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted
Mar 17 00:18:50 crunch-573g NetworkManager[412]: <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted

EDIT: Habe das hier noch gefunden, aber noch nicht ausprobiert: https://bbs.archlinux.org/viewtopic.php?id=152968
wicd habt ihr ja schon vorgeschlagen, aber ich möchte eigentlich gerne den NetworkManager behalten. Hatte Wicd vor 1-2 Jahren mal eine Weile und bin aus irgendeinem Grund wieder zurück gewechselt. Ich hab eigentlich schon gute Gründe für sowas

Hier noch bisschen was aus dem Arch-Wiki-Artikel "maximizing performance":

Code:

~ ❯❯❯ sudo btrfs filesystem defragment /

~ ❯❯❯ sudo hdparm -t /dev/sda                                                 ⏎

/dev/sda:
 Timing buffered disk reads: 320 MB in  3.00 seconds = 106.54 MB/sec

EDIT2: Hm, Alsa braucht ja auch ewig. Kann ja eigentlich nicht sein... Menno. So viele Baustellen. Gehe jetzt pennen

EDIT3: Gibt wohl Leute mit einem ähnlichen Problem. Ich mag aber eigentlich nicht neu installieren

gelöschter Benutzer · 23 März 2014

So, habe jetzt mal btrfs richtig defragmentiert (erst die Dateidaten, dann die Metadaten):

Code:

# btrfs filesystem defragment -r -v /
# find / -xdev -type d -print -exec btrfs filesystem defragment '{}' \;

und dann sieht die Bootzeit etwas besser aus:

Code:

~ ❯❯❯ systemd-analyze blame
         16.268s NetworkManager.service
         13.543s alsa-restore.service
         13.490s bluetooth.service
         13.474s syslog-ng.service
         13.438s dkms.service
         13.406s avahi-daemon.service
          4.825s systemd-suspend.service
          3.188s home.mount
          2.250s systemd-vconsole-setup.service
          2.081s mnt-WIN7.mount
          1.684s systemd-fsck@dev-disk-by\x2duuid-e6105e48\x2db5a8\x2d4970\x2dbe
          1.570s systemd-modules-load.service
          1.043s systemd-binfmt.service
           970ms systemd-tmpfiles-setup-dev.service
           961ms polkit.service
           951ms dev-hugepages.mount
           947ms colord.service
           940ms systemd-remount-fs.service
           912ms dev-mqueue.mount
           901ms systemd-random-seed.service
           792ms lightdm.service
           647ms boot.mount
           638ms sys-kernel-debug.mount
           531ms systemd-udev-trigger.service
           525ms systemd-sysctl.service
           522ms tmp.mount
           373ms systemd-backlight@backlight:acpi_video0.service
           372ms systemd-backlight@backlight:intel_backlight.service
           364ms user@1000.service
           229ms user@620.service
           219ms systemd-hostnamed.service
           210ms wpa_supplicant.service
           193ms systemd-tmpfiles-clean.service
           184ms systemd-update-utmp.service
           184ms kmod-static-nodes.service
           179ms systemd-udevd.service
           174ms udisks.service
           164ms dev-disk-by\x2duuid-7f2bd342\x2d9a4f\x2d4d92\x2da5b4\x2def58fc8
           162ms systemd-logind.service
           150ms proc-sys-fs-binfmt_misc.mount
           146ms systemd-user-sessions.service
           146ms systemd-tmpfiles-setup.service
           138ms sys-kernel-config.mount
           130ms ntpd.service
            72ms sys-fs-fuse-connections.mount
            68ms systemd-rfkill@rfkill4.service
            64ms systemd-rfkill@rfkill1.service
            62ms systemd-rfkill@rfkill0.service
            59ms systemd-rfkill@rfkill2.service
            42ms systemd-journal-flush.service
            39ms accounts-daemon.service
            16ms udisks2.service
             4ms upower.service
             2ms rtkit-daemon.service
             1ms systemd-rfkill@rfkill3.service

Aber das dauert mir immer noch zu lange. Siehe auch die critical-chain:

Code:

~ ❯❯❯ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @28.477s
└─multi-user.target @28.475s
  └─ntpd.service @28.344s +130ms
    └─network.target @28.341s
      └─NetworkManager.service @12.070s +16.268s
        └─basic.target @12.028s
          └─timers.target @11.975s
            └─systemd-tmpfiles-clean.timer @11.948s
              └─sysinit.target @11.563s
                └─systemd-update-utmp.service @11.378s +184ms
                  └─systemd-tmpfiles-setup.service @11.232s +146ms
                    └─local-fs.target @11.231s
                      └─home.mount @8.042s +3.188s
                        └─local-fs-pre.target @2.778s
                          └─systemd-tmpfiles-setup-dev.service @1.806s +970ms
                            └─kmod-static-nodes.service @1.621s +184ms
                              └─system.slice @1.399s
                                └─-.slice @1.396s

Und den Boot-Plot:

Asseon · 30 Apr. 2014

Praktisch das selbe Thema wurde grad auf der Arch ML diskutiert.

Scheinbar dauert der Bootprozess länger wenn das Journal zu groß wird.
NetworkManager ist davon wohl besonders betroffen.

Einfachste Lösung ist in der Datei /etc/systemd/journald.conf die Option SystemMaxUse=64M setzen.
Die Größe ist sicherlich diskutierbar, aber ich bin damit bisher gut gefahren.
Idr ist es auf Desktop Systemen nicht nötig die logs von mehreren Monaten aufzubewahren.

vlt hilft das ja mal jemanden

oh und ja mir ist bewusst wie merkwürdig das klingt ^^

gelöschter Benutzer · 30 Apr. 2014

Dieses Huren-Journal. Bei mir loggt das eh noch in Syslog, dann kann ich das ja auf 32M setzen.

Proprietäre, binäre Log-Formate sind gaaaanz toll.

Asseon · 30 Apr. 2014

Ich denke nicht das dieses Problem mit der Wahl das Formats zusammenhängt.
Das wird irgendeine merkwürdige Wechselwirkung sein. Nicht schön aber kann passieren.

Zumal weder systemd noch das journald Format nach FSF Definition Proprietär sind

so das wollte mal gesagt sein

gelöschter Benutzer · 30 Apr. 2014

Ist halt echt das Einzige, was mich an systemd stört. Text-Logs funktionieren seit gefühlten Jahrhunderten, aktuelle Dateisysteme können damit super umgehen und journalctl ist imho einfach schrecklich zu bedienen.

Und das sage ich als jemand, der nicht mal Logs in ein Puppet-Setup eingebunden hat oder Log-Monitoring mit zusätzlichen Tools betreibt.

musv · 4 Mai 2014

Wollte nur mal anmerken, dass bei mir das Booten und vor allem auch das Runterfahren des Rechners immer länger gedauert hab. Allerdings hab ich kein Arch sondern Gentoo hier im Einsatz.

Seitdem ich die Log-Größe runtergeschraubt hab (10 M), klicke ich auf "Runterfahren" im KDM und der Rechner schaltet sich praktisch schon aus. Ich glaub, bei "journald" gibt's noch so einigen Optimierungsbedarf.

Systemd-Analyze find ich cool. Danke für die Infos:

Code:

systemd-analyze 
Startup finished in 3.121s (kernel) + 1.396s (userspace) = 4.517s

mathmos · 4 Mai 2014

Asseon schrieb:
Scheinbar dauert der Bootprozess länger wenn das Journal zu groß wird.
NetworkManager ist davon wohl besonders betroffen.

Kannst du bitte mal auf die Diskussion verlinken? Kann die spontan irgendwie nicht finden.

@phre4k:

Dann stell doch einfach journald so ein, dass an syslog weitergeleitet wird (ForwardToSyslog=yes in der journald.conf). Somit hast du wieder reine Textdateien.

Aber was an der Bedienung von journalctl ist bitte schrecklich? Gut, man muss an andere Befehle/Parameter gewöhnen. Aber dafür gibt es dann durchaus einige Vorteile. Z. B. kann man mittels --since=14:10 --until=14:20 die Ausgabe des Logs auf einen bestimmten Zeitraum einschränken. Mittels grep und Co. würde spontan jetzt nur RegEx einfallen. Das mag für einen Vollblut-Admin jetzt nicht das Problem sein. Ich bin allerdings froh, wenn ich mir solche Konstrukte nicht antun muss.

gelöschter Benutzer · 4 Mai 2014

Ach, so ein Regex geht mir schneller von der Hand als mir alle journald-Befehle zu merken, zumal die bei meinen Serversystemen dann auch wieder nicht funktionieren und ich doch wieder RegExes nehmen muss. ForwardToSyslog ist seit ner ganzen Weile wieder an, die Journalgröße auf 16M runter und so siehts jetzt aus:

Code:

~ ❯❯❯ systemd-analyze
Startup finished in 4.075s (kernel) + 35.043s (userspace) = 39.118s

Code:

         21.138s dkms.service
         10.316s NetworkManager.service
          3.321s alsa-restore.service
          3.149s systemd-logind.service
          3.118s avahi-daemon.service
          2.862s home.mount
          2.522s lightdm.service
          2.501s udisks2.service
          2.461s mnt-WIN7.mount
          2.236s systemd-vconsole-setup.service
          1.491s systemd-fsck@dev-disk-by\x2duuid-e6105e48\x2db5a8\x2d4970\x2dbe
          1.426s systemd-modules-load.service
          1.386s boot.mount
          1.160s colord.service
          1.073s systemd-tmpfiles-setup-dev.service
          1.050s polkit.service
           983ms systemd-tmpfiles-clean.service
           930ms syslog-ng.service
           751ms tmp.mount
           721ms accounts-daemon.service
           710ms sys-kernel-debug.mount
           709ms dev-mqueue.mount
           701ms dev-hugepages.mount
           638ms systemd-rfkill@rfkill1.service
           634ms systemd-rfkill@rfkill0.service
           622ms systemd-rfkill@rfkill2.service
           611ms systemd-backlight@backlight:acpi_video0.service
           604ms systemd-backlight@backlight:intel_backlight.service
           542ms systemd-sysctl.service
           517ms systemd-random-seed.service
           465ms upower.service
           452ms user@620.service
           353ms systemd-udev-trigger.service
           246ms dev-disk-by\x2duuid-7f2bd342\x2d9a4f\x2d4d92\x2da5b4\x2def58fc8
           215ms systemd-remount-fs.service
           212ms wpa_supplicant.service
           159ms user@1000.service
           159ms systemd-tmpfiles-setup.service
           154ms systemd-udevd.service
           153ms ntpd.service
            90ms kmod-static-nodes.service
            54ms sys-kernel-config.mount
            45ms systemd-journal-flush.service
            36ms sys-fs-fuse-connections.mount
            36ms systemd-update-utmp.service
            28ms systemd-user-sessions.service
             7ms rtkit-daemon.service
             3ms systemd-rfkill@rfkill3.service

Asseon · 4 Mai 2014

@mathmos:
hier fängt das ganze an
und hier wirds interessant.

gelöschter Benutzer · 18 Jan. 2015

So, das wäre noch einmal ich.

So sieht es derzeit bei mir aus:
[src=bash][phre4k@phre4k-573g ~]$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1.598s
└─multi-user.target @1.598s
└─ntpd.service @1.582s +16ms
└─network.target @1.581s
└─NetworkManager.service @1.316s +264ms
└─basic.target @1.291s
└─sockets.target @1.291s
└─org.cups.cupsd.socket @1.291s
└─sysinit.target @1.289s
└─systemd-rfkill@rfkill3.service @1.550s +1ms
└─system-systemd\x2drfkill.slice @558ms
└─system.slice @155ms
└─-.slice @147ms
[phre4k@phre4k-573g ~]$ systemd-analyze
Startup finished in 3.092s (firmware) + 2.020s (loader) + 2.249s (kernel) + 1.598s (userspace) = 8.960s[/src]

Kann ich CUPS und Co. irgendwie später laden lassen? Warum dauert "firmware" und "loader" so ewig?

Asseon · 18 Jan. 2015

Vorweg:
firmware=uefi
loader=bootloader, in diesem fall wahrscheinlich gummiboot

die firmware braucht bei mir teilweise sogar über 20 Sekunden ^^
also 3 sekunden ist eher kurz, darfst nicht vergessen da läuft die ganze Hardwareinitialisierung etc.
ich vermute da werkelt ein notebook?

und loader mit 2 Sekunden ist wahrscheinlich die zeit die du brauch um enter zu drücken, bzw den korrekten Eintrag auszuwählen.

cups startet bei dir btw bereits "später" nämlich, dank "socket activation", erst wenn es benötigt wird, und wie aus der output von "systemd-analyze critical-chain" eindeutig hervorgeht braucht "org.cups.cupsd.socket" beim boot praktisch keine zeit.
Die andere Sachen die da drin stehen, kann man entweder nicht wirklich "on demand" starten oder es macht kein Sinn.

darüber hinaus wo ist aktuell dein Problem? 9 sekunden ist doch mehr als in ordnung, wie bereits gesagt bis dahin ist bei mir meist nichtmal die Firmware durch …

gelöschter Benutzer · 18 Jan. 2015

Na ja, das Macbook meines Chefs startet relativ schnell. Habe mir zwar angewöhnt, meinen Laptop (richtig geraten) immer in den Standby zu schicken, aber ist eben auch eine Sache des Perfektionismus.

Warum UEFI länger als 1s brauchen sollte verstehe ich aber irgendwie nicht. Bei dem Desktop meiner Freundin dauerts vielleicht 0,3s, ist aber auch Windows – also nix mit systemd-analyze

Kann ich ntp und Networkmanager nicht später starten? Also am Besten direkt nach lightdm? So schnell werde ich mich ja nicht einloggen können, oder?

Asseon · 18 Jan. 2015

du unterschätzt glaube ich die zeit, die die gängigen dhcpc Implementierungen unter linux brauchen um ne ip zu bekommen …

Aber klar geht das.
Du must dafür die entsprechenden service files bearbeiten, ich werd das einmal exemplarisch für Network Manager erklären.

folgendermaßen sieht das service file für Network Manager per default aus.

/usr/lib/systemd/system/NetworkManager.service
[src=bash][Unit]
Description=Network Manager
Wants=network.target
Before=network.target

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/bin/NetworkManager --no-daemon
# NM doesn't want systemd to kill its children for it
KillMode=process

[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.NetworkManager.service
Also=NetworkManager-dispatcher.service[/src]

folgende Änderungen müssen durchgeführt werden:

In der Sektion unit muss "After=display-manager.service" eingefügt werden
In der Sektion install sollte "WantedBy=multi-user.target" durch "WantedBy=graphical.target" ersetzt werden, sonst kommt es zu Abhängigkeitsproblemen

das ganze sieht dann so aus:
[src=bash][Unit]
Description=Network Manager
Wants=network.target
Before=network.target
After=display-manager.service

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/bin/NetworkManager --no-daemon
# NM doesn't want systemd to kill its children for it
KillMode=process

[Install]
WantedBy=graphical.target
Alias=dbus-org.freedesktop.NetworkManager.service
Also=NetworkManager-dispatcher.service
[/src]

ein par hinweise dazu:

der service sollte vor der änderung "disabled" werden, kann danach dann aber wieder aktiviert werden
Ich habe das nicht getestet, da ich den network manager selber nicht benutze. Könnte also eure Haustiere töten
Vor jeglichen Veränderungen sollten die service files aus "/usr/lib/systemd/system/" nach "/etc/systemd/system" kopiert werden
nach erfolgen Änderungen sollten mittels "systemctl daemon-reload" die service files neu geladen werden
solltest du nach diesen Änderungen, aus welchen gründen auch immer, mal in den multi-user-mode booten wollen wirst du feststellen, dass du den network manager mabuell starten musst

Arch Linux wird immer langsamer

gelöschter Benutzer

Guest

mathmos

404

Asseon

Draic Kin

gelöschter Benutzer

Guest

mathmos

404

gelöschter Benutzer

Guest

gelöschter Benutzer

Guest

Asseon

Draic Kin

gelöschter Benutzer

Guest

Asseon

Draic Kin

gelöschter Benutzer

Guest

musv

Bekannter NGBler

mathmos

404

gelöschter Benutzer

Guest

Asseon

Draic Kin

gelöschter Benutzer

Guest

Asseon

Draic Kin

gelöschter Benutzer

Guest

Asseon

Draic Kin