Ciao a tutti
visti i tempi troppo lunghi di boot
Startup finished in 5.430s (firmware) + 6.365s (loader) + 2.234s (kernel) + 8.140s (initrd) + 1min 3.326s (userspace) = 1min 25.497s
volevo eliminare qualche servizio inutile
19.822s gssproxy.service non credo mi serva anche perchè in ssh_config risulta disabilitato :
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
dite che posso fermarlo senza problemi in rete non trovo risposte esaurienti
ciao e grazie one
Ciao, si puoi disabilitare gssproxy; serve per autenticare utenti e applicazioni. Se usi il computer in maniera “casalinga”/classica, non ti serve.
Grazie per il chiarimento
Ciao, anche io vorrei disabilitare e stoppare il servizio gssproxy (23.657s +424ms) ma ho constatato che ad ogni riavvio del sistema il servizio si attiva automaticamente…come mai? come dovrei procedere?..qualcosa mi sfugge…
attendo notizie a riguardo.
Grazie
riporto di seguito l’output di:
[skiava@skiava-sdt ~]$ systemctl status gssproxy.service
● gssproxy.service - GSSAPI Proxy Daemon
Loaded: loaded (/usr/lib/systemd/system/gssproxy.service; disabled; vendor>
Active: active (running) since Tue 2021-02-16 08:53:52 CET; 1min 5s ago
Process: 933 ExecStart=/usr/sbin/gssproxy -D (code=exited, status=0/SUCCESS)
Main PID: 935 (gssproxy)
Tasks: 6 (limit: 9448)
Memory: 1.8M
CPU: 15ms
CGroup: /system.slice/gssproxy.service
└─935 /usr/sbin/gssproxy -D
Warning: journal has been rotated since unit was started, output may be incompl>
[skiava@skiava-sdt ~]$ systemd-analyze
Startup finished in 1.194s (kernel) + 4.118s (initrd) + 54.352s (userspace) = 59.665s
graphical.target reached after 54.338s in userspace
[skiava@skiava-sdt ~]$ 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 @54.338s
└─multi-user.target @54.338s
└─plymouth-quit-wait.service @24.258s +30.078s
└─systemd-user-sessions.service @24.087s +54ms
└─remote-fs.target @24.085s
└─remote-fs-pre.target @24.084s
└─nfs-client.target @24.084s
└─gssproxy.service @23.657s +424ms
└─network.target @23.652s
└─wpa_supplicant.service @47.538s +121ms
└─dbus-broker.service @16.906s +2.323s
└─dbus.socket @16.575s
└─sysinit.target @16.548s
└─systemd-update-utmp.service @16.518s +30ms
└─auditd.service @15.790s +726ms
└─systemd-tmpfiles-setup.service @14.619s +1.142s
└─local-fs.target @14.614s
└─home.mount @14.460s +153ms
└─systemd-fsck@dev-mapper-fedora_localhost\x2d\x2dlive\x2dh>
└─local-fs-pre.target @14.015s
└─lvm2-monitor.service @5.720s +4.593s
└─dm-event.socket @5.692s
└─system.slice
└─-.slice
[skiava@skiava-sdt ~]$ infine, c’è qualche altro servizio inutile che posso disabilitare oltre al gssproxy?
Ciao skiava,
vedo che il servizio e’ gia’ disabilitato, ma ho notato anche sulle mie macchine che viene comunque lanciato al reboot. Puoi forzarne la disabilitazione con:
# systemctl mask gssproxy
ma sembra che aggiunga solo 0.4 secondi al tuo avvio, non mi pare cosi’ impattante per il tuo avvio.
Non vedo altri servizi “opzionali” che potrebbero essere pesanti per il tuo avvio.
Ciao Bebo, da quello che ho postato con il comando: “systemd-analyze critical-chain” leggo che sono “gssproxy.service @23.657s +424ms” …scusa ma dove leggi 0.4 secondi?
…correggimi se sbaglio… 
Dal man di systemd-analyze:
systemd-analyze critical-chain [UNIT...] prints a tree of the time-critical chain of units (for each of
the specified UNITs or for the default target otherwise). 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. Note
that the output might be misleading as the initialization of one service might depend on socket activation
and because of the parallel execution of units.
Significa che il tempo effettivo richiesto per l’avvio del servizio e’ dato dal numero dopo il +, mentre il numero dopo @ e’ il tempo “totale” dall’inizio del caricamento dei servizi.
Questo perche’ il “timer” parte a contare dall’accensione del pc (approssimiamo), poi alcuni servizi hanno delle dipendenze da altri, in questo caso gssproxy probabilmente dipende da network, quindi viene fatto effettivamente partire solo quando network ha finito: in realta’ non sembra neanche che dipenda da network, perche’ se prendi il tempo @ di network e ci sommi il + di gssproxy non ottieni il tempo @ di gssproxy, ma chissa’ quale magia di parallelismo c’e’ sotto.
In ogni caso non dovresti vedere chissa’ che miglioramenti ecco.
systemd-analyze che dice adesso?
[skiava@skiava-sdt ~]$ systemd-analyze
Startup finished in 1.187s (kernel) + 4.260s (initrd) + 1min 10.724s (userspace) = 1min 16.172s
graphical.target reached after 1min 10.709s in userspace
[skiava@skiava-sdt ~]$ CVD, non ci sono miglioramenti, anzi.
Vediamo
$ systemd-analyze blame
$ systemd-analyze critical-chain
Ciao, riporto di seguito l’output di:
[skiava@skiava-sdt ~]$ systemd-analyze blame
31.333s plymouth-quit-wait.service >
30.609s fwupd.service >
16.509s abrtd.service >
9.453s systemd-udev-settle.service >
7.773s initrd-switch-root.service >
6.971s firewalld.service >
6.019s udisks2.service >
5.373s lvm2-monitor.service >
4.687s cups.service >
4.527s accounts-daemon.service >
2.716s systemd-resolved.service >
2.570s packagekit.service >
2.404s rtkit-daemon.service >
2.403s switcheroo-control.service >
2.401s systemd-logind.service >
2.400s thermald.service >
2.307s dbus-broker.service >
1.730s systemd-journal-flush.service >
1.593s systemd-udevd.service >
1.248s dracut-initqueue.service >
1.246s chronyd.service >
1.102s lm_sensors.service >
1.085s gssproxy.service >
[skiava@skiava-sdt ~]$ 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 @58.658s
└─multi-user.target @58.658s
└─plymouth-quit-wait.service @27.324s +31.333s
└─systemd-user-sessions.service @27.270s +20ms
└─remote-fs.target @27.268s
└─remote-fs-pre.target @27.268s
└─nfs-client.target @27.268s
└─gssproxy.service @26.181s +1.085s
└─network.target @26.177s
└─wpa_supplicant.service @51.984s +504ms
└─dbus-broker.service @18.722s +2.307s
└─dbus.socket @18.551s
└─sysinit.target @18.485s
└─systemd-update-utmp.service @18.345s +139ms
└─auditd.service @17.698s +644ms
└─systemd-tmpfiles-setup.service @16.619s +1.055s
└─local-fs.target @16.614s
└─home.mount @16.402s +212ms
└─systemd-fsck@dev-mapper-fedora_localhost\x2>
└─local-fs-pre.target @15.951s
└─lvm2-monitor.service @5.891s +5.373s
└─dm-event.socket @5.864s
└─system.slice
└─-.slice
[skiava@skiava-sdt ~]$ Vedo che gssproxy e’ ancora abilitato. Non hai voluto mask-erarlo?
Quel computer lo usi come computer personale, a casa? Se non hosti servizi probabilmente puoi disabilitare firewalld
E probabilmente anche abrtd
Prova prima con un systemctl disable, reboota, controlla i tempi di nuovo. Se vedi ancora i servizi apparire, prova con un systemctl mask
Per “smascherare” i servizi usa systemctl unmask
Anche questo, soprattutto se non hai firmware (es. il BIOS) supportato dal produttore nell’ambito di LVFS (https://fwupd.org/)
Prova a vedere con sudo fwupdmgr get-updates cosa dice.
Da quel che vedo lo posso disabilitare :
fwupdmgr get-updates
Dispositivi senza aggiornamenti firmware:
• ST1000DM010-2EP102
No updatable devices
E sì. Lo penso anche io. (Credo che quel fwupd.service sia il servizio che si occupa di notificare gnome-software che ci sono aggiornamenti per il BIOS, per esempio sul mio portatile funziona. Ovviamente dipende tutto dai produttori se vogliono facilitare la vita a chi usa Linux, oppure disinteressarsene e fornire gli aggiornamenti del BIOS nel solito classico modo funzionante solo se si ha Windows installato).
(Ah, oltre al BIOS, LVFS offrirebbe il supporto per l’aggiornamento del firmware di altri dispositivi: mi pare tastiere, dischi, lettori di impronte digitali, docking station, ecc. e vale sempre il discorso qui sopra).
Buono a sapersi lo terro attivo non si sà mai ( con il bios è una settimana che tribulo con gli aggiornamenti avanti è indietro perchè con gli ultimi kernel continua a darmi errori su hd ) l’ho anche cambiato perchè credevo guasto invece è propio il kernel sempre gli stessi errori blk_update è DRY driver quel tool se funzionava era veramente comodo anzichè copiare ogni volta il bios su chavetta è caricarlo da menu bios 