[Linuxtrent] Re: systemd default su debian?
- From: Lele Gaifax <lele@xxxxxxxxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Tue, 21 Oct 2014 19:20:35 +0200
Michele Bert <micbert75@xxxxxxxxx> writes:
> Inoltre non essendo riuscito a farmi un'opinione degli argomenti delle
> due fazioni, essendo troppo ignorante in materia, ed ero curioso di
> sentire le opinioni di qualcuno che conosco.
È già da qualche mese che ho montato systemd sulla mia Debian sid a
casa.
Dopo l'iniziale entusiasmo perché alcuni problemini di startup dei
servizi si sono risolti, e secondariamente trovandolo ben più veloce
nell'avviare la macchina (a ancor più nello spegnimento!), sono ora
sbilanciato verso chi lo considera una cosa... non positiva: dopo
qualche settimana, ad un aggiornamento successivo, per non so quale
ragione ora il mio sistema non si spegne più praticamente
immediatamente, ma ci mette grosso modo un minuto e mezzo, e l'unico
"appiglio" è nel "journal", cioè nel log di systemd:
ott 21 10:08:46 nautilus virtualbox[28559]: Stopping VirtualBox kernel modules.
ott 21 10:08:46 nautilus systemd[2086]: Received SIGRTMIN+24 from PID 28503
(kill).
ott 21 10:08:46 nautilus systemd[1186]: Received SIGRTMIN+24 from PID 28500
(kill).
ott 21 10:08:46 nautilus systemd[2087]: pam_unix(systemd-user:session): session
closed for user lele
ott 21 10:08:46 nautilus systemd[1192]: pam_unix(systemd-user:session): session
closed for user lightdm
ott 21 10:10:16 nautilus systemd[1]: user@117.service stop-sigterm timed out.
Killing.
ott 21 10:10:16 nautilus systemd[1]: Unit user@117.service entered failed state.
ott 21 10:10:16 nautilus systemd-udevd[294]: Network interface NamePolicy=
disabled on kernel commandline, ignoring.
ott 21 10:10:16 nautilus networking[28622]: Deconfiguring network
interfaces...done.
ott 21 10:10:16 nautilus lvm[28706]: 5 logical volume(s) in volume group
"system" unmonitored
ott 21 10:10:16 nautilus umount[28721]: umount: /var: target is busy
ott 21 10:10:16 nautilus umount[28721]: (In some cases useful info about
processes that
ott 21 10:10:16 nautilus umount[28721]: use the device is found by lsof(8) or
fuser(1).)
ott 21 10:10:16 nautilus systemd[1]: var.mount mount process exited,
code=exited status=32
ott 21 10:10:16 nautilus systemd[1]: Failed unmounting /var.
ott 21 10:10:17 nautilus systemd[1]: Shutting down.
ott 21 10:10:17 nautilus systemd-journal[267]: Journal stopped
dove dice che, tentando di smontare la /var, la trova "occupata" e
quindi aspetta un bel po' prima di proseguire comunque e spegnere
fisicamente la macchina. Dalle ricerche, probabilmente è lui stesso che
la tiene occupata, proprio per scriverci il journal... E dal momento
che già pochi istanti dopo aver iniziato lo shutdown, tutti i normali
"servizi" sono già bellamente spenti (in primis tutte le console
virtuali, così come il server ssh), non c'è praticamente modo di
eseguire quel benedetto lsof per capire *chi* tiene occupata la
partizione!
Fatto sta che, pur non essendo l'ultimo arrivato, è dannatamente
difficile "metterci il naso" e cercare di capire qualcosa, vuoi per
l'approccio "monolitico" (e comunque binario) della sua implementazione,
vuoi perché la documentazione è praticamente assente. Pur avendoci speso
qualche oretta, non ho cavato un ragno dal buco, e mi rodo il fegato
ogni volta che spengo la macchina!
La cosa veramente negativa è proprio systemd è la causa, diretta o
indiretta, sia dei problemi iniziali (che mi hanno fatto passare a
systemd), sia di questi ultimi: è molto invasivo e molti sottosistemi
ormai dipendono da systemd per funzionare (molte cose GNOME ad
esempio... e tieni conto che di GNOME uso in pratica solo il
settings-daemon, necessario per avere la applet di gestione dei suoni!),
ma soprattutto è imperscrutabile (già la scelta di avere un log binario,
ispezionabile solo col suo strumento, "journalctl", mi lascia mooolto
perplesso...) e pervasivo (uno strumento solo che pensa a inizializzare
tutto, dai device, ai bus tra le applicazioni, ai mount dei dischi...).
Per riassumere, fottere in questo modo la vecchia e saggia filosofia di
"uno strumento che una sola cosa, e la fa bene, e che coopera in maniera
duttile con il resto del mondo", be', vien da dire "allora monto la cosa
vera, window$" :-)
Vedi:
-
http://linux.slashdot.org/story/14/10/20/1944226/debians-systemd-adoption-inspires-threat-of-fork
- http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html
- http://tanguy.ortolo.eu/blog/article132/trying-systemd-back-to-sysv
- http://changelog.complete.org/archives/9241-update-on-the-systemd-issue
e credo che uno dei prossimi giorni proverò la ricetta descritta dal
secondo link, che peraltro conferma:
In fact, with wheezy, sysvinit was essential. In the words of trolls,
Debian "forced" you to install SysV init!
With jessie, it will become easier to choose the init system, because
neither init system is essential now. Instead, there is an essential
meta-package "init", which requires you to install one of systemd-sysv
| sysvinit-core | upstart. In other words, you have more choice than
ever before.
Again: don't listen to trolls.
However, notice that there are some programs such as login managers
(e.g. gdm3) which have an upstream dependency on systemd. gdm3 links
against libsystemd0 and depends on libpam-systemd; and the latter
depends on systemd-sysv | systemd-shim so it is in fact a software
such as GNOME that is pulling systemd onto your computer.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@xxxxxxxxxxxxxxx | -- Fortunato Depero, 1929.
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
