• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]Leap 15.0: Langsamer Start und unnötige .timer

B

BeastXXL

Hallo,

ich habe heute Leap 15.0 neu installiert (/home wurde von 42.2 behalten). Nun sind mir zwei Dinge aufgefallen:
1. Leap 15.0 startet recht langsam
2. Einige .timer von systemctl wurden unnötiger Weise geladen

Fangen wir beim 2. Punkt an:
Code: 
beastxxl@localhost:~> systemctl list-timers
NEXT                          LEFT          LAST                          PASSED    UNIT                         ACTIVATES
Sat 2018-07-28 22:00:00 CEST  45min left    Sat 2018-07-28 21:00:32 CEST  13min ago snapper-timeline.timer       snapper-timeline.service
Sun 2018-07-29 00:00:00 CEST  2h 45min left Sat 2018-07-28 12:22:27 CEST  8h ago    logrotate.timer              logrotate.service
Sun 2018-07-29 00:13:22 CEST  2h 59min left Sat 2018-07-28 12:22:27 CEST  8h ago    check-battery.timer          check-battery.service
Sun 2018-07-29 00:34:09 CEST  3h 20min left Sat 2018-07-28 12:22:27 CEST  8h ago    backup-rpmdb.timer           backup-rpmdb.service
Sun 2018-07-29 01:52:53 CEST  4h 38min left Sat 2018-07-28 12:22:47 CEST  8h ago    backup-sysconfig.timer       backup-sysconfig.service
Sun 2018-07-29 20:30:25 CEST  23h left      Sat 2018-07-28 20:30:25 CEST  43min ago snapper-cleanup.timer        snapper-cleanup.service
Sun 2018-07-29 20:35:22 CEST  23h left      Sat 2018-07-28 20:35:22 CEST  38min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2018-07-30 00:00:00 CEST  1 day 2h left Sat 2018-07-28 12:22:27 CEST  8h ago    btrfs-balance.timer          btrfs-balance.service
Mon 2018-07-30 00:00:00 CEST  1 day 2h left Sat 2018-07-28 12:22:27 CEST  8h ago    fstrim.timer                 fstrim.service
Wed 2018-08-01 00:00:00 CEST  3 days left   Sat 2018-07-28 12:22:27 CEST  8h ago    btrfs-scrub.timer            btrfs-scrub.service

10 timers listed.
Pass --all to see loaded but inactive timers, too.
Unter Leap 42.2 war nur systemd-tmpfiles-clean.timer aktiv. Evtl. noch fstrim.timer.
Aber die anderen mit snapper und btrfs macht überhaupt keinen Sinn. Ich benutze ja gar kein Btrfs und snapper. Meine Partitionen sind ext4.
Auch check-battery finde ich komisch. Hab's doch nicht auf einem Labtop installiert.
Wie gehe ich am besten vor, um die unnötigen .timer zu deaktivieren? Reicht:(?)
Code: 
systemctl disable [unnötiger timer]
Oder übersehe ich irgendwas wichtiges?

Zu Punkt 1:
Code: 
eastxxl@localhost:~> systemd-analyze 
Startup finished in 2.502s (kernel) + 3.322s (initrd) + 39.864s (userspace) = 45.689s
beastxxl@localhost:~> sudo systemd-analyze blame
[sudo] Passwort für root: 
         30.758s display-manager.service
         30.233s plymouth-quit-wait.service
          6.846s wicked.service
          1.276s postfix.service
          1.252s btrfsmaintenance-refresh.service
           933ms ca-certificates.service
           871ms apparmor.service
           373ms initrd-switch-root.service
           370ms lvm2-monitor.service
           340ms rsyslog.service
           335ms kbdsettings.service
           141ms upower.service
           103ms alsa-restore.service
           102ms mcelog.service
           101ms nscd.service
            97ms initrd-parse-etc.service
            92ms udisks2.service
            86ms systemd-fsck@dev-disk-by\x2duuid-56cad4cc\x2d78d5\x2d4768\x2d8c76\x2dc81054dc4c19.service
            73ms systemd-udev-trigger.service
            66ms systemd-udevd.service
            62ms dracut-cmdline.service
            53ms systemd-vconsole-setup.service
            47ms user@1000.service
            45ms klog.service
            41ms auditd.service
            41ms iscsi.service
            40ms wickedd-dhcp6.service
            39ms chronyd.service
            37ms dev-mqueue.mount
            37ms wickedd-auto4.service
            36ms systemd-remount-fs.service
            35ms wickedd-dhcp4.service
            32ms dev-disk-by\x2duuid-96ec0ffe\x2d0578\x2d4f31\x2d96a9\x2d4dffa653244d.swap
            30ms plymouth-start.service
            28ms systemd-logind.service
            28ms avahi-daemon.service
            25ms systemd-tmpfiles-setup-dev.service
            25ms systemd-journal-flush.service
            24ms systemd-tmpfiles-setup.service
            23ms wickedd.service
            23ms sys-kernel-debug.mount
            21ms dev-hugepages.mount
            21ms systemd-fsck-root.service
            20ms plymouth-read-write.service
            19ms systemd-modules-load.service
            17ms systemd-sysctl.service
            16ms dracut-pre-trigger.service
            16ms systemd-random-seed.service
            16ms plymouth-switch-root.service
            15ms systemd-journald.service
            15ms wickedd-nanny.service
            14ms sysroot.mount
            13ms kmod-static-nodes.service
            13ms initrd-cleanup.service
            11ms systemd-update-utmp-runlevel.service
            10ms home.mount
             8ms dracut-shutdown.service
             7ms rtkit-daemon.service
             6ms systemd-update-utmp.service
             5ms systemd-user-sessions.service
             4ms sys-fs-fuse-connections.mount
             3ms initrd-udevadm-cleanup-db.service
Hier noch der systemd-analyze plot:
https://www.file-upload.net/download-13248493/1.svg.html
Hier noch der Status zu den beiden ersten Bremsklötzen:
Code: 
beastxxl@localhost:~> systemctl status plymouth-quit-wait.service 
● plymouth-quit-wait.service - Hold until boot process finishes up
   Loaded: loaded (/usr/lib/systemd/system/plymouth-quit-wait.service; static; vendor preset: disabled)
   Active: inactive (dead) since Sat 2018-07-28 20:20:36 CEST; 8min ago
  Process: 1733 ExecStart=/usr/bin/plymouth --wait (code=exited, status=0/SUCCESS)
 Main PID: 1733 (code=exited, status=0/SUCCESS)
 beastxxl@localhost:~> systemctl status display-manager.service                   
● display-manager.service - X Display Manager
   Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-07-28 20:20:36 CEST; 9min ago
  Process: 1734 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS)
 Main PID: 1842 (sddm)
    Tasks: 12 (limit: 4915)
   CGroup: /system.slice/display-manager.service
           ├─1842 /usr/bin/sddm
           └─1844 /usr/bin/X -nolisten tcp -auth /run/sddm/{4ada72f7-2ecb-48ae-86b0-1b7d45fe4fc6} -background none -noreset -displayfd 18 -seat s>
Im Plot sieht aber auch der ModemManager.service komisch aus. Und beim "systemd-analyze blame" Steht noch der btrfsmaintenance-refresh.service recht weit oben.

Könntet ihr mir bitte helfen, den Startvorgang zu beschleunigen und die ganzen unnötigen timer und services (btrfs etc.) abzustellen? Danke schon mal im voraus.
 
muck19

muck19

Zuerst mal würde ich von wicked auf networkmanager umstellen -

Dann in der Diensteverwaltung alles deaktivieren, was absolut nicht in Verwendung ist.

Neu starten ....

(alleine durch "aufräumen" in der Diensteverwaltung hab ich meinen Start (SSD-Platte) von 16 Sekunden auf 10 Sekunden beschleunigt :-D )
 
OP
B

BeastXXL

Hallo,

ich habe in der Zwischenzeit ein bisschen rumprobiert und nachgeforscht.
Zu Punkt 1:
@muck19: Damals bei Leap 42.2 habe ich mit Networkmanager und wicked experimentiert (auch wg. Bootbeschleunigung). Ja, mit NM geht es deutlich schneller, aber z.Zt. möchte ich lieber wicked benutzen. Von damals habe ich mir (durch einen gleichartigen Thread hier im Forum) gemerkt, dass man die DHCP Vers. auf "nur 4" setzen sollte. Dadurch war meine Kiste nur 4 Sek. langsamer als mit NM. Für Hardcore-Geschwindigkeits-Tuner ist das natürlich sehr lang, aber mir hatte es damals gereicht. Daher habe ich das diesmal gleich nach der Installation wieder so eingestellt.

Plymouth scheint diesmal der Bremsklotz zu sein. Im Grub-Eintrag im Bootmenü habe ich mal "splash=silent quiet" herausgenommen bzw. auch mal "noplymouth" anstelle dessen gesetzt. Die Ergebnisse sind ähnlich und in beiden Fällen eine deutliche Verbesserung:
Code: 
beastxxl@localhost:~> systemd-analyze 
Startup finished in 2.514s (kernel) + 3.723s (initrd) + 10.362s (userspace) = 16.600s
beastxxl@localhost:~> systemd-analyze blame
          6.906s wicked.service
          1.286s postfix.service
          1.258s btrfsmaintenance-refresh.service
           892ms ca-certificates.service
           870ms apparmor.service
           644ms display-manager.service
           621ms rsyslog.service
           483ms lvm2-monitor.service
           369ms initrd-switch-root.service
           341ms chronyd.service
           263ms kbdsettings.service
           229ms mcelog.service
           140ms upower.service
           120ms plymouth-quit-wait.service
           102ms udisks2.service
           100ms initrd-parse-etc.service
            82ms systemd-udev-trigger.service
            77ms wickedd-dhcp4.service
            74ms wickedd-auto4.service
            72ms systemd-vconsole-setup.service
            69ms avahi-daemon.service
            65ms systemd-udevd.service
            62ms dracut-cmdline.service
            57ms systemd-tmpfiles-clean.service
            47ms dev-disk-by\x2duuid-96ec0ffe\x2d0578\x2d4f31\x2d96a9\x2d4dffa653244d.swap
            44ms user@1000.service
            43ms klog.service
            43ms systemd-fsck@dev-disk-by\x2duuid-56cad4cc\x2d78d5\x2d4768\x2d8c76\x2dc81054dc4c19.service
            41ms wickedd-dhcp6.service
            38ms iscsi.service
            35ms nscd.service
            35ms auditd.service
            31ms systemd-logind.service
            31ms kmod-static-nodes.service
            31ms systemd-remount-fs.service
            30ms alsa-restore.service
            29ms systemd-sysctl.service
            29ms systemd-journald.service
            27ms systemd-modules-load.service
            26ms plymouth-start.service
            25ms systemd-tmpfiles-setup-dev.service
            23ms initrd-cleanup.service
            23ms wickedd-nanny.service
            20ms systemd-fsck-root.service
            19ms wickedd.service
            16ms systemd-journal-flush.service
            16ms dracut-pre-trigger.service
            16ms systemd-random-seed.service
            15ms dev-mqueue.mount
            15ms plymouth-switch-root.service
            14ms plymouth-read-write.service
            13ms systemd-tmpfiles-setup.service
            13ms sys-kernel-debug.mount
            12ms dev-hugepages.mount
            11ms sysroot.mount
             8ms home.mount
             8ms rtkit-daemon.service
             7ms dracut-shutdown.service
             7ms sys-fs-fuse-connections.mount
             7ms systemd-update-utmp.service
             6ms systemd-update-utmp-runlevel.service
             5ms systemd-user-sessions.service
             3ms initrd-udevadm-cleanup-db.service
Und noch der systemd-analyze plot dazu:
https://www.file-upload.net/download-13251416/2.svg.html
Knappe 30 Sek. gespart, nur indem Plymouth ausgeschaltet wurde finde ich schon beachtlich.

Das Einzige, was mich nun etwas stört, ist, dass ich die Bootmeldungen über den Bildschirm flitzen sehe. Ich habe nichts gegen einen Splash wärend des bootens, aber nicht, wenn es das ganze so in die Länge zieht. Was mich zu der Frage führt, ob das nun Plymouth als solches oder nur dieses Theme (von openSuse) betrifft?
Wäre schön, wenn jemand in diese Richtung Erfahrungen gesammelt hat und mir mitteilt, denn mein Forscherdrang in diese Richtung (unterschiedliche Themes ausprobieren) ist aufgebraucht.

Zu Punkt 2:
Bei der Diensteverwaltung habe ich mir jeden service/timer angesehen, den ich unter systemctl list-timers angezeigt bekomme. OK, die meisten dieser timer machen Sinn (soweit ich das herausbekommen habe). Aber die snapper- und btrfs-Teile eben nicht. Blöd nur, dass genau die Dinger als "Deaktiviert" und "Inaktiv" in der Diensteverwaltung angezeigt werden.
Wie deaktiviere ich die nun so, dass sie in der Liste nicht mehr auftauchen? Und wenn sie schon deaktiviert sind, warum erscheinen sie dann in der Liste?
Evtl. hilft es, wenn ich "btrfsmaintenance-refresh.service" (siehe Punkt 1) deaktiviere? Der wird als "Aktiviert" und "Inaktiv" angezeigt. Weiß jemand, welche Auswirkungen eine Deaktivierung hat?

Bin für für Ideen zu beiden Punkten dankbar. :)
 
muck19

muck19

Man kann in der Diensteverwaltung sicherlich noch einiges abknipsen.
Braucht! man die Firewall, bluetooth, dies, das, jenes?
In den Systemeinstellungen tummeln sich auch oft noch Autostarteinträge die sich ungefragt dort einnisten.
Ein Sekündchen hier, eins dort ..... summiert sich teilweise recht schnell.

Zu Plymouth kann ich nicht viel sagen, nur das es bei mir so ca. 1x im Monat beim Booten in die Suppe spuckt und booten dann statt 10 Sekunden >1 Minute braucht.
 
OP
B

BeastXXL

Hallo,

so, habe nun unter Diensteverwaltung den Dienst btrfsmaintenance-refresh.service deaktiviert und in /etc/default/grub als root
Code: 
GRUB_CMDLINE_LINUX_DEFAULT= "splash=silent quiet"
in
GRUB_CMDLINE_LINUX_DEFAULT= "quiet noplymouth"
und
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
in
SUSE_BTRFS_SNAPSHOT_BOOTING="false"
geändert.
Danach
Code: 
grub2-mkconfig -o /boot/grub2/grub.cfg
ausgeführt.
Ergebnis:
Code: 
beastxxl@localhost:~> systemd-analyze
Startup finished in 2.506s (kernel) + 3.313s (initrd) + 10.277s (userspace) = 16.098s
beastxxl@localhost:~> systemd-analyze blame
          6.977s wicked.service
          1.232s postfix.service
           880ms apparmor.service
           843ms firewalld.service
           777ms ca-certificates.service
           641ms display-manager.service
           636ms systemd-fsck-root.service
           574ms lvm2-monitor.service
           368ms initrd-switch-root.service
           223ms ModemManager.service
           157ms rsyslog.service
           138ms upower.service
           129ms polkit.service
           121ms plymouth-quit-wait.service
           102ms kbdsettings.service
           101ms udisks2.service
            94ms nscd.service
            92ms initrd-parse-etc.service
            66ms systemd-udev-trigger.service
            64ms systemd-udevd.service
            63ms wickedd-auto4.service
            63ms dracut-cmdline.service
            62ms klog.service
            61ms auditd.service
            59ms wickedd-dhcp6.service
            59ms wickedd-dhcp4.service
            57ms systemd-vconsole-setup.service
            48ms user@1000.service
            39ms iscsi.service
            37ms plymouth-start.service
            36ms chronyd.service
            35ms systemd-sysctl.service
            33ms avahi-daemon.service
            30ms systemd-fsck@dev-disk-by\x2duuid-56cad4cc\x2d78d5\x2d4768\x2d8c76\x2dc81054dc4c19.service
            29ms alsa-restore.service
            28ms mcelog.service
            (mit q abgebrochen)
Leider umfasst die systemctl list-timers noch immer alle ungewünschten .timer. Daher habe ich auf der Konsole versucht einen zu deaktivieren:
Code: 
beastxxl@localhost:~> sudo systemctl disable snapper-timeline.timer
[sudo] Passwort für root: 
Removed /etc/systemd/system/timers.target.wants/snapper-timeline.timer.
beastxxl@localhost:~> systemctl list-timers
NEXT                          LEFT          LAST                          PASSED       UNIT                         ACTIVATES
Tue 2018-07-31 20:57:44 CEST  2min 20s left n/a                           n/a          systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Tue 2018-07-31 21:00:00 CEST  4min 36s left n/a                           n/a          snapper-timeline.timer       snapper-timeline.service
Wed 2018-08-01 00:00:00 CEST  3h 4min left  Mon 2018-07-30 19:26:54 CEST  1 day 1h ago btrfs-balance.timer          btrfs-balance.service
Wed 2018-08-01 00:00:00 CEST  3h 4min left  Sat 2018-07-28 12:22:27 CEST  3 days ago   btrfs-scrub.timer            btrfs-scrub.service
Wed 2018-08-01 00:00:00 CEST  3h 4min left  Tue 2018-07-31 20:04:29 CEST  50min ago    logrotate.timer              logrotate.service
Wed 2018-08-01 00:15:05 CEST  3h 19min left Tue 2018-07-31 20:04:37 CEST  50min ago    backup-sysconfig.timer       backup-sysconfig.service
Wed 2018-08-01 00:48:22 CEST  3h 52min left Tue 2018-07-31 20:04:29 CEST  50min ago    check-battery.timer          check-battery.service
Wed 2018-08-01 01:22:38 CEST  4h 27min left Tue 2018-07-31 20:04:29 CEST  50min ago    backup-rpmdb.timer           backup-rpmdb.service
Wed 2018-08-01 20:52:59 CEST  23h left      Tue 2018-07-31 20:52:59 CEST  2min 24s ago snapper-cleanup.timer        snapper-cleanup.service
Mon 2018-08-06 00:00:00 CEST  5 days left   Mon 2018-07-30 19:26:54 CEST  1 day 1h ago fstrim.timer                 fstrim.service

10 timers listed.
Pass --all to see loaded but inactive timers, too.
Wie man sieht mit mäßigem Erfolg. Oder ist der .timer erst nach einem Neustart verschwunden? Werde ich mal beim nächsten Boot darauf achten.

Alles in allem ein gutes Ergebnis, v.a. da ich ohne Splash-Screen zwar nun Bootmeldungen sehe, aber durch "quiet" hält sich das noch im Rahmen. Und die Bootzeit hat sich drastisch verkürzt. Bin recht zufrieden. :)
Wenn mir jemand was zu der .timer-Problematik sagen kann, würde ich mich freuen.
 
OP
B

BeastXXL

Das .timer-Problem hat sich gerade gelöst: Die Dinger verschwinden erst nach einem Neustart. Daher habe ich die btrfs-...-timer auch gleich deaktiviert:
Code: 
beastxxl@localhost:~> systemctl list-timers 
NEXT                          LEFT          LAST                          PASSED       UNIT                         ACTIVATES
Tue 2018-07-31 21:46:16 CEST  14min left    n/a                           n/a          systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Wed 2018-08-01 00:00:00 CEST  2h 28min left Tue 2018-07-31 20:04:29 CEST  1h 27min ago logrotate.timer              logrotate.service
Wed 2018-08-01 00:48:23 CEST  3h 16min left Tue 2018-07-31 20:04:37 CEST  1h 27min ago backup-sysconfig.timer       backup-sysconfig.service
Wed 2018-08-01 01:43:02 CEST  4h 11min left Tue 2018-07-31 20:04:29 CEST  1h 27min ago check-battery.timer          check-battery.service
Wed 2018-08-01 01:43:10 CEST  4h 11min left Tue 2018-07-31 20:04:29 CEST  1h 27min ago backup-rpmdb.timer           backup-rpmdb.service
Mon 2018-08-06 00:00:00 CEST  5 days left   Mon 2018-07-30 19:26:54 CEST  1 day 2h ago fstrim.timer                 fstrim.service

6 timers listed.
Pass --all to see loaded but inactive timers, too.
beastxxl@localhost:~> systemd-analyze
Startup finished in 2.510s (kernel) + 3.338s (initrd) + 10.116s (userspace) = 15.965s
Es wundert mich nur, warum diese Dienste in der Dienste-Verwaltung als "Deaktiviert" und "Inaktiv" angezeigt wurden.
Egal, ich freu mich. :D Hoffentlich bleibt's so (oder wird noch besser)!
 
U

uhelp

systemd ist ein ziemlich komplexes Ding.

Man kann sehr fein granuliert Dienste definieren.
Jeder Dienst/Service hat eine Art Basiskonfiguration in seinem "Unitfile", das die Extension ".service" hat, z.B. mySystemdService.service
Wollen wir unseren mySystemdService.service periodisch starten, so schreiben wir uns einfach ein passendes .timer File ( man systemd.timer ).

Prinzipiell werden solche Dienste mit "systemctl enable someService" automatisch von systemd gestartet, also auch bei jedem Boot.
Ein "systemctl start someService" startet diesen Dienst tatsächlich, aber er würde nicht nach dem Booten ohne ein "enabled" nicht mehr gestartet werden.
So weit, so schlicht.

Was nicht so offensichtlich ist, ist dass jede Definition einer solchen "Unit", also eines "Dienstes" automatisch diverse und teils sehr komplexe Abhängigkeiten definiert, die dann auch die Ausführung direkt beeinflussen.

Ein Socket.service hat völlig andere Voraussetzungen, als ein Mount.service. Aber einen Socket ohne gemountetes Filesystem gibt es nicht. Eine implizite Abhängigkeitskette.

Und es gibt ziemlich verschiedene Arten von Programmen. Ein echter, "alter" Daemon, wie z.B. postfix, überwacht sich selbst, startet munter nach Gusto eine ganze Latte von verschiedenen Diensten und koordiniert die selbst.
Manche ändern die EUID (EffectiveUserIDentification). Die erledigen zuerst alle Jobs für die sie Root- Rechte brauchen und "droppen" dann diese Root-Rechte, um unter anderem Usernamen mit weniger Privilegien ihren Job zu erledigen. Auch eine komplexe Kette von Abhängigkeiten.

Schreibt man sich einen myBigBackup.service, der lediglich ein Shellscript mit rsync oder dergleichen ausführt, so hat dieser Kopierjob keine Vorstellung von seinen Voraussetzungen. Aber die komplexe Kette impliziter Abhängigkeiten existiert.

Und es gibt noch "moderne Daemons", die das systemd Gen schon in sich tragen.
Die kommunizieren mit systemd selbst.
Im Gegensatz zu schlichten Jobs oder alten Daemons, die systemd nur "indirekt" überwachen kann, um sie ggf. neu zu starten.
(was durch bestimmte Konfigurationsdirektiven von "man systemd.service" gesteuert wird.

So kommt es, dass manchen Dienste mit "systemctl status -l someSystemd.service" zeigen, sie wären selber tot, aber der grüne Punkt sagt: Das Ding rennt und tut. Dieser someSystemd.service kommuniziert also indirekt mit systemd und der Job, der diesen Dienst tatsächlich aufgerufen hat, ist längst tot und oft schon garbage-collected. Das Dingelchen tut aber dennoch brav seinen Dienst.
Das ist anfangs tatsächlich ziemlich verwirrend. Aber der Linuxer ist ja ein Gewohnheitstier...

Bei den systemd.timer Services schlagen all diese direkten oder indirekten Abhängigkeiten natürlich auch voll durch.
Aber jetzt verstehst du, was du gesehen hast, hoffe ich.

Und, wie schon gesagt: ein "systemctl disable someService" verhindert das Neustarten nach dem Booten, lässt die Dinge aber laufen. Ein "systemctl stop someService" hätte da dann sogar den Boot überflüssig gemacht. Er wäre weg gewesen.

Es gibt natürlich für "systemctl" noch diverse Subcommands, mit denen man da direkt reinschlagen kann:
reload
reload-or-restart
daemon-reload
daemon-reexec

Alles nachzulesen unter "man systemctl"

Und alle Subcommands anzeigen mit
Code: 
man systemctl | sed -rn '/COMMANDS/,${/^[[:blank:]]{0,7}[^ ]/p}' | less
 
S

spoensche

muck19 schrieb:
Man kann in der Diensteverwaltung sicherlich noch einiges abknipsen.
Braucht! man die Firewall?
Zum Vergrößern anklicken....

:schockiert: :zensur:

Wenn du jeden netzwerkbasierten Dienst im Internet bereitstellen willst natürlich nicht. Einen User test mit sudo Berechtigung und leerem Passwort erhöht das Sicherheitsniveau in nicht geahntem Ausmass.
[/quote]
 
OP
B

BeastXXL

Hallo,

vielen Dank uhelp für deinen umfangreichen Erklärungsversuch. Leider habe ich nur etwa die Hälfte verstanden, sorry. :eek:0:
Und ja, die Firewall will ich (wie immer) behalten, über bluetooth könnte man sich in meinem Fall natürlich streiten, aber da es beim booten nicht mein größtes Problem war, lasse ich es einfach so. Ich bin übrigens ein guter Vertreter der Gattung des Gewohnheitstieres, nicht nur bei Linux...
Wie gesagt: natürlich könnte man noch die eine oder andere Sekunde gewinnen, aber im Verhältnis zum bisherigen Ergebnis erscheint mir der dafür nötige Aufwand nicht wirklich gerechtfertigt. Zumal es nun anscheinend wieder so läuft, wie gewohnt und gewünscht. Never touch a running system. Wenn man zu viel will, kann das schnell in die Hose gehen; evtl. verschlimmbessert man es nur.
 
U

uhelp

Dann mach es einfach, wie ich:
Gar keine Bootzeiten optimieren.
Da ich morgens die Kiste einschalte,
ist es mir egal, wie lange sie braucht.

Ich koch' erst mal Kaffee, geh auf die Schüssel und bis die Tasse samt Kerl vor der Kiste sitzt, sind schon hunderttausend Fenster offen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben