Hast du konkurrierende Netzwerkdienste am Laufen?

cups.path                                                       | multi-user.target.wants
cups.service                                                   | multi-user.target.wants
cups.service                                                   | printer.target.wants
cups.socket                                                    | sockets.target.wants
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service       | system
display-manager.service                                | system
fstrim.timer                                                    | timers.target.wants
gcr-ssh-agent.socket                                      | sockets.target.wants
getty@tty1.service                                         | getty.target.wants
gnome-keyring-daemon.socket                      | sockets.target.wants
NetworkManager.service                                | multi-user.target.wants
NetworkManager-wait-online.service              | network-online.target.wants
p11-kit-server.socket                                      | sockets.target.wants
pipewire-pulse.socket                                     | sockets.target.wants
pipewire-session-manager.service                  | user
pipewire.socket                                               | sockets.target.wants
remote-fs.target                                              | multi-user.target.wants
systemd-timesyncd.service                            | sysinit.target.wants
wireplumber.service                                       | pipewire.service.wants
xdg-user-dirs-update.service                          | default.target.wants

Du könntest mal mit $ systemd-analyze blame und $ systemd-analyze critical-chain schauen wo es hakt, und dann das jeweilige log anschauen

Zeigt sich nichts Auffälliges.

  • schard hat auf diesen Beitrag geantwortet.

    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.

        Gut, dann schauen wir doch mal, ich bitte um Beurteilung der Ergebnisse. Allerdings weiss ich nicht, was "sonstige Log-Dateien" sein sollen.

        1. 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
        1. 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.

          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.

              • Berni341 hat auf diesen Beitrag geantwortet.

                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).

                      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

                      • Berni341 hat auf diesen Beitrag geantwortet.

                          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

                                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

                                und weiter...

                                del
                                • brikler hat auf diesen Beitrag geantwortet.

                                  und weiter...

                                  del