[erledigt] 2 1/2 Minuten Bootzeit

[letzter3]

Hallo zusammen,
auf einem PC dauert der Start über 2 Minuten.
Hauptschuldiger ist network.service.
Aber was dort genau?
Wie kann ich das weiter eingrenzen?
IP-vergabe ist statisch (war vorher dhcp, kein Unterschied).

[man-draker]

Arbeitest du mit IPv4 oder IPv6?
Wenn nur mit IPv4: Ist IPv6 deaktiviert?
Es kann sein, dass nur die IPv4-Adresse statisch vergeben wird, der Rechner aber auf eine IPv6-Adresse wartet, die aber nie kommt. Also abschalten oder auch statisch vergeben.

[letzter3]

Mit IPv4.
Habe das 6-er deaktiviert, keine Änderung.

Code: Alles auswählen

[root@localhost ~]# ifconfig
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.6  netmask 255.255.255.0  broadcast 192.168.1.255
        ether a0:d3:c1:42:72:7a  txqueuelen 1000  (Ethernet)
        RX packets 24  bytes 3222 (3.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 60  bytes 14619 (14.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1  (Lokale Schleife)
        RX packets 145  bytes 15638 (15.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 145  bytes 15638 (15.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@localhost ~]#

[letzter3]

Wobei:

Code: Alles auswählen

[root@localhost ~]# systemctl status network.service
● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network)
   Active: active (running) since Sa 2016-07-23 10:50:24 CEST; 4min 9s ago
  Process: 901 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/network.service
           └─1068 /sbin/ifplugd -I -b -i enp2s0

Jul 23 10:50:24 localhost.localdomain network[901]: Aktivieren der Loopback-Schnittstelle:  [  OK  ]
Jul 23 10:50:24 localhost.localdomain ifplugd(enp2s0)[1068]: ifplugd 0.28 initializing.
Jul 23 10:50:24 localhost.localdomain network[901]: Schnittstelle »enp2s0« aktivieren:  [  OK  ]
Jul 23 10:50:24 localhost.localdomain systemd-sysctl[1081]: Overwriting earlier assignment of kernel/sysrq in file '/etc/sysctl.d/51-alt-sysrq.conf'.
Jul 23 10:51:24 localhost.localdomain ifplugd(enp2s0)[1068]: Using interface enp2s0/A0:D3:C1:42:72:7A with driver <r8169> (version: 2.3LK-NAPI)
Jul 23 10:51:24 localhost.localdomain ifplugd(enp2s0)[1068]: Using detection mode: SIOCETHTOOL
Jul 23 10:51:24 localhost.localdomain ifplugd(enp2s0)[1068]: Initialization complete, link beat not detected.
Jul 23 10:51:26 localhost.localdomain ifplugd(enp2s0)[1068]: Link beat detected.
Jul 23 10:51:27 localhost.localdomain ifplugd(enp2s0)[1068]: Executing '/etc/ifplugd/ifplugd.action enp2s0 up'.
Jul 23 10:51:30 localhost.localdomain ifplugd(enp2s0)[1068]: Program executed successfully.
[root@localhost ~]#


Hier sind keine Wartezeiten zu erkennen...

[letzter3]

Code: Alles auswählen

[root@localhost ~]# systemd-analyze blame
     1min 5.771s network-up.service
       1min 73ms systemd-resolved.service
         10.205s shorewall.service
          5.823s systemd-udev-settle.service
          5.604s systemd-journald.service
          4.122s shorewall6.service
          4.053s mandriva-everytime.service
          2.890s systemd-journal-flush.service
          2.000s cups.service
          1.972s plymouth-quit-wait.service
          1.894s chronyd.service
          1.805s upower.service
          1.789s mga-bg-res.service
          1.789s acpid.service
          1.702s systemd-logind.service
          1.690s media-windows.mount
          1.688s cpupower.service
          1.687s resolvconf.service
          1.687s nscd.service
          1.674s avahi-daemon.service
          1.617s fedora-readonly.service
          1.484s systemd-fsck@dev-disk-by\x2duuid-ded01b2c\x2da3a4\x2d4af3\x2dab8d\x2defcf134d5898.service
          1.421s systemd-vconsole-setup.service
          1.305s fedora-loadmodules.service
          1.012s mnt-windows.mount
....

[man-draker]

Normal ist das nicht. Bei mir dauert das 5.462s.
Da verstehen sich PC und Router wohl nicht so recht .
Du schriebst ja, du verwndest feste IP-Adressen.
Dir von dir gepostete liegt nicht zufällig im DHCP-Pool des Routers?
Wenn der Router ein Web-Interface hat, wären die dortigen Einstellungen interessant.

[letzter3]

Also im Moment liegt die statische IP tatsächlich im DHCP-Pool des Routers.

Der betreffende PC hängt im VLAN 2.

Ich schrieb aber, dass ich normalerweise per DHCP vergeben lasse und nur jetzt mal auf statisch umgestellt habe.

[unklar]

Mach' doch mal

Code: Alles auswählen

$ systemd-analyze critical-chain

da sieht man wenigstens, wieviel mehr Zeit welcher Dienst braucht. Das auch noch in Rot.
Mit blame ergibt sich dazu doch ganz unterschiedliche Zeit.

Code: Alles auswählen

[unklar@localhost ~]$ systemd-analyze blame | head
         10.698s systemd-udev-settle.service
          9.135s systemd-journal-flush.service
          6.323s network-up.service
          4.759s shorewall.service
          4.757s mandriva-everytime.service
          3.692s plymouth-quit-wait.service
          3.007s shorewall6.service
          2.889s resolvconf.service
          2.692s network.service
          2.305s mga-bg-res.service

und

Code: Alles auswählen

[unklar@localhost ~]$ 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 @35.332s
└─multi-user.target @35.332s
  └─mandi.service @35.332s
    └─shorewall.service @30.569s +4.759s
      └─network.target @30.549s
        └─network-up.service @24.206s +6.323s
          └─partmon.service @23.969s +233ms
            └─network.service @21.270s +2.692s
              └─resolvconf.service @18.376s +2.889s
                └─basic.target @18.324s
                  └─mandriva-everytime.service @13.567s +4.757s
                    └─local-fs.target @13.556s
                      └─fedora-storage-init-late.service @13.525s +30ms
                        └─fedora-storage-init.service @12.839s +679ms
                          └─fedora-wait-storage.service @12.827s +9ms
                            └─systemd-udev-settle.service @2.123s +10.698s
                              └─systemd-udev-trigger.service @1.704s +408ms
                                └─system.slice @1.527s


Was mich hier stutzig macht ist exakt diese Minute

...

Code: Alles auswählen

Jul 23 10:50:24 localhost.localdomain network[901]: Schnittstelle »enp2s0« aktivieren:  [  OK  ]
Jul 23 10:50:24 localhost.localdomain systemd-sysctl[1081]: Overwriting earlier assignment of kernel/sysrq in file '/etc/sysctl.d/51-alt-sysrq.conf'.
Jul 23 10:51:24 localhost.localdomain ifplugd(enp2s0)[1068]: Using interface enp2s0/A0:D3:C1:42:72:7A with driver <r8169> (version: 2.3LK-NAPI)

Das ist doch der sogenannte "Affengriff". Die Datei habe ich auch, jedoch nicht diese Meldung des Kernel bei mir.

[letzter3]

Code: Alles auswählen

graphical.target @1min 23.470s
└─multi-user.target @1min 23.470s
  └─cups-browsed.service @1min 23.470s
    └─cups.service @1min 21.667s +1.797s
      └─network.target @1min 21.657s
        └─network-up.service @16.148s +1min 5.486s
          └─numlock.service @15.991s +150ms
            └─partmon.service @15.730s +253ms
              └─network.service @14.851s +862ms
                └─resolvconf.service @13.046s +1.786s
                  └─basic.target @12.929s
                    └─mandriva-everytime.service @7.843s +5.085s
                      └─local-fs.target @7.836s
                        └─run-user-1000.mount @17.615s
                          └─local-fs-pre.target @2.681s
                            └─systemd-tmpfiles-setup-dev.service @2.009s +665ms
                              └─kmod-static-nodes.service @1.778s +224ms
                                └─system.slice @1.363s
                                  └─-.slice @1.362s


Okay, nächstes Untersuchungsobjekt ist cups.
Hat jemand eine Idee?

[doktor5000]

Nicht cups, sondern cups-browsed. Einfach mal deaktivieren?
Der ist nur für autom. Erkennung von Bonjour/Zeroconf/DNS-SD (Avahi)-Druckerwarteschlangen da, braucht man in der Regel nicht.

Läuft bei dir avahi irgendwo im Netzwerk? Und dauert es beim Herunterfahren auch länger beim Stoppen?
Siehe auch https://bugs.debian.org/cgi-bin/bugrepo ... bug=759348 und http://ec-cwang.github.io/system/The-An ... owsed.html

[letzter3]

Alles sehr seltsam.
cups.browsed deaktiviert und avahi gleich mit.

Nächster Start dauert genauso lange
Nun braucht der ganze nfs-Kram so lange. Dabei hatte ich den im Vorfeld auf Fehlersuche schon mal deaktiviert.
Wer hat den denn wieder aktiviert????
Na egal: nfs-utils gelöscht, nun passt das wieder.....