Zeigt sich nichts Auffälliges.
Netzwerk dauert nach Boot lange bis aktiv
- Bearbeitet
Eher nicht. Wäre ziemlich merkwürdig für ArchLinux oder muss man davon ausgehen, das ist bei euch auch so und als normal anzusehen?
Berni341 muss man davon ausgehen, das ist bei euch auch so und als normal anzusehen?
Nein, ist bei uns nicht so. Wenn es so wäre würden wir - falls wir bei systemd-analyze nichts Auffälliges sehen - die Ausgabe plus sonstige Log-Dateien hier posten um zu schauen, ob jemand anderem etwas auffällt. Da du diese Infos für dich behältst kannst auch nur du dir helfen.
- Bearbeitet
Gut, dann schauen wir doch mal, ich bitte um Beurteilung der Ergebnisse. Allerdings weiss ich nicht, was "sonstige Log-Dateien" sein sollen.
- systemd-analyze blame
2.098s systemd-rfkill.service
809ms dev-sda2.device
555ms ldconfig.service
363ms systemd-journal-catalog-update.service
235ms user@1000.service
228ms systemd-journal-flush.service
224ms systemd-udev-trigger.service
200ms udisks2.service
181ms systemd-tmpfiles-setup.service
160ms systemd-tmpfiles-setup-dev.service
148ms systemd-remount-fs.service
140ms systemd-modules-load.service
132ms systemd-udevd.service
127ms modprobe@loop.service
118ms upower.service
118ms modprobe@fuse.service
117ms systemd-timesyncd.service
111ms modprobe@drm.service
103ms systemd-boot-random-seed.service
102ms modprobe@dm_mod.service
95ms systemd-vconsole-setup.service
91ms modprobe@configfs.service
89ms kmod-static-nodes.service
86ms cups.service
85ms systemd-update-utmp.service
83ms polkit.service
82ms systemd-sysusers.service
81ms dev-hugepages.mount
78ms systemd-tmpfiles-clean.service
78ms dev-mqueue.mount
75ms systemd-journald.service
73ms sys-kernel-debug.mount
70ms sys-kernel-tracing.mount
63ms systemd-zram-setup@zram0.service
61ms accounts-daemon.service
59ms systemd-sysctl.service
46ms dbus.service
46ms NetworkManager.service
45ms dev-zram0.swap
39ms systemd-update-done.service
39ms systemd-logind.service
32ms user-runtime-dir@1000.service
29ms systemd-random-seed.service
26ms boot.mount
25ms sys-fs-fuse-connections.mount
23ms systemd-user-sessions.service
17ms sys-kernel-config.mount
12ms rtkit-daemon.service
6ms tmp.mount
- 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 @3.009s
└─multi-user.target @3.008s
└─cups.service @2.921s +86ms
└─network.target @2.920s
└─NetworkManager.service @2.873s +46ms
└─dbus.service @2.800s +46ms
└─basic.target @2.766s
└─sockets.target @2.766s
└─dbus.socket @2.766s
└─sysinit.target @2.761s
└─systemd-vconsole-setup.service @3.711s +95ms
└─systemd-journald.socket @997ms
└─system.slice @940ms
└─-.slice @940ms
Das Aktivieren der Netzwerkverbindung dauerte in diesem, wie in jedem Fall wie oben im ersten Beitrag beschrieben, so lange.
- Bearbeitet
Berni341 Allerdings weiss ich nicht, was "sonstige Log-Dateien" sein sollen.
zB die gewünschte Ausgabe vonjounalctl -h
Und setze diese Ausgaben bitte in Code-Tags (unter dem Schreibfenster entweder direkt </> anklicken und zwischen die Tags schreiben oder besser den Teil markieren und dann auf </> klicken)
Zudem wäre für obige Ausgaben noch interessant ob das aktivieren wieder so lange gedauert hat
Ist das ein Laptop? Brauchst du den rfkill-Service? Sonst diable den doch mal und versuche, das Problem nachzustellen.
- Bearbeitet
Josephus Miller
Ausgabe von journalctl -h:
journalctl [OPTIONS...] [MATCHES...]
del
- Bearbeitet
stefanhusmann
Bitte den Befehl gleich mit dazu schreiben. Habe (Arch)Linux erst installiert und kenne es bis dato kaum.
Es handelt sich um einen Mini-PC von HP.
Josephus Miller
Das war bestimmt nicht, was du sagen/sehen wolltest. Ich würde mal journalctl -b probieren (vorausgesetzt, die Netzwerkverbindung wird nicht erst nach dem Boot manuell hergestellt).
- Bearbeitet
Berni341 Habe (Arch)Linux erst installiert und kenne es bis dato kaum.
Beim Installieren sollte dir dann aber systemctl enable <service>
begegnet sein, logischerweise heißt es dann
sudo systemctl disable systemd-rfkill.service
Die Option -h oder --help zeigt dir die Kurzform der manpage eines Befehls oder Programms. Daher hast du dir die Optionen zeigen lassen. ;-) Du könntest zB neustarten und dann alles nach dem aktuellen boot mit journalctl -b
anzeigen lassen
- Bearbeitet
Josephus Miller
Das sind bei "journalctl -b" über 1500 Zeilen und wie ich gerade sah, sind oben in der Konsole bereits Zeilen abgeschnitten. Sind alle nötig und, wenn ja, wie kann das Abschneiden oben verhindert werden?
Berni341 Sind alle nötig und, wenn ja, wie kann das Abschneiden oben verhindert werden?
Wenn du die Verbindung nicht nach dem booten manuell herstellst sind alle nötig. Und das Abschneiden verhinderst du über die Einstellung der verwendeten Konsole
- Bearbeitet
Forum meldet:
content darf maximal 65535 Zeichen enthalten.
Kann man den erforderlichen Inhalt nicht irgendwie filtern?
Ok, verteile die Zeilen über mehrere Beiträge. Ab hier vor Netzwerkzugriff:
del
- Bearbeitet
und weiter...
del
- Bearbeitet
und weiter...
del
- Bearbeitet
del
Ich sehe da keine Fehler, wenn ich das nicht falsch lese braucht deine Netzwerkkarte nach dem Start aber ca 90 sec bis sie aktiv ist. Allerdings stellt sich mir die Frage, wozu du bei ner kabelgebundenen Verbindung den NetworkManager brauchst. Und den rfkill-service hattest du nicht wie von Stefan empfohlen deaktiviert, oder?
- Bearbeitet
Danke fürs Drübergucken. Die Daten sind natürlich alle ohne Fehlerbehandlung ausgelesen. Den Networkmanager habe ich für KDE (siehe erster Post). Jetzt kann es dann daran gehen, in der Hoffnung, es ändert sich was. Falls noch jemand Vorschläge hat, bitte reinschreiben.
Wenn ich sudo systemctl disable systemd-rfkill.service
ausführen will, bekomme ich das:
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). This means they are not meant to be enabled or disabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Ich starte meine Netzwerkverbindung unter Plasma/KDE mit systemct start dhcpcd@enp5s0.service
, ohne Networkmanager. Bei dir wäre das wohl dhcpcd@eno1.service, Sicherheit gibt ein Blick auf die Ausgabe von ip link
. Du müsstest dann aber den NetworkManager.service deaktivieren.
Eventuell erledigt sich dann auch das Starten von rfkill