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

                    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?

                    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