Newsgroup: it.comp.os.linux.iniziare
Titolo: Eseguire comando all'avvio di Linux su Mageia

Dovrei far eseguire un comando con relative opzioni alla partenza di linux, 
magari come root sarebbe anche meglio.
 
Lo so che e' una domanda pluripostata, ma da una ricerca su google, mi sono 
uscite una miriade di info che penso non vadano bene perche' vecchie, in 
quanto ultimamente il sistema di boot è variato e dipende anche dalla 
distribuzione in uso.
 
Il uso Mageia 4 e spero presto di usare la 5. Sareste cosi' gentili da dirmi 
quale file (e percorso) devo modificare per aggungere la riga di comando 
desiderata?
O se devo creare un nuovo file .sh e dove piazzarlo?
 
grazie.

 magari come root sarebbe anche meglio.
 
AFAIK /etc/rc.local o /etc/rc.d/rc.local
dovrebbero essere ancora disponibili (per
mettervi un comando).
 
Attenzione ai path, terminazioni, etc.
 
bye,
 
-- 
 
piergiorgio


Non esiste rc.local nella mia Mageia 4.
 
Da quello che ho capito, la Mageia usa il nuovo sistema Systemd.
 
Chi mi sa' aiutare?

 Da quello che ho capito, la Mageia usa il nuovo sistema Systemd.
 
Anche Fedora, ma rc.local c'e` comunque.
 
Sei sicuro che rc.local non ci sia ovvero
che, se ci fosse, non venga utilizzato?
 
Perche` systemd ha un service proprio per
rc.local, mi pare.
 
bye,
 
pg
 
-- 
 
piergiorgio

 
http://alexiobash.com/il-vecchio-rc-local-su-systemd/
 

 
http://alexiobash.com/il-vecchio-rc-local-su-systemd/
 
 
Ottimo link. Su Fedora c'e` gia` di serie:
 
/usr/lib/systemd/system/rc-local.service
 
bye,
 
-- 
 
piergiorgio

 /usr/lib/systemd/system/rc-local.service
 
Anche Debian testing da qualche mese ha di default systemd ma il
percorso
/usr/lib/systemd/system/rc-local.service
e` diverso:
 
# find / -iname rc-local.service
/lib/systemd/system/rc-local.service
/sys/fs/cgroup/devices/system.slice/rc-local.service
/sys/fs/cgroup/systemd/system.slice/rc-local.service
/run/systemd/generator/multi-user.target.wants/rc-local.service
 
Ogni volta che mi e` capitato di provare una Fedora ho sempre notato
questo genere di piccole ma fastidiose diversita`.
 
Fedora usa systemd gia` da diverso tempo, credo dalla versione 9,
infatti a pag. 19 di questo PDF
http://doc.fedoraonline.it/folio/folio_00.pdf
 
c'e` un articolo (Servizi di sistema (demoni) in proposito.
 
All'atto pratico, dal mio punto di vista di semplice utente domestico,
non apprezzo molto systemd: e` vero che il tempo d'avvio si e`
notevolmente ridotto ma ora non ho piu` la possibilita` di leggere tutte
quelle righe di messaggi che Debian scriveva in fase di boot, cosa che
svariate volte mi era tornata utile per mantenere "in salute" il
sistema.
 
Non ho fatto prove pratiche ma studiando un po' mi e` parso di capire
che si potrebbe procedere anche per una strada diversa da rc.local
Provo a fare un esempio:
 
Creo un nuovo servizio, ad es. "myscriptservice.service" in
/etc/systemd/system
contenente:
-------------------------------
[Unit]
Description=myscript Service
 
[Service]
User=nobody
ExecStart=/usr/bin/myscript.sh
 
[Install]
WantedBy=multi-user.target
------------------------------
 
Ricarico i servizi:
systemctl daemon-reload
 
ed abilito il nuovo servizio perche` parta al boot:
systemctl enable myscriptservice.service
 
Per avviare/stoppare il servizio:
 
systemctl start myscriptservice
systemctl stop myscriptservice
 

 
 
 
-- 
 
piergiorgio

 Ti da il log corrente di oggi.
 
Non conoscevo quel comando, grazie.
Provandolo purtroppo noto che restituisce anche diverse righe di colore
rosso, segno di errori. :-(
 

 rosso, segno di errori. :-(
 
Si, ma devi controllarli uno per uno, a
volte non sono cose serie.
 
Per es. io mi trovo in rosso:
 
... systemd-modules-load[146]: Failed to find module 'vboxdrv'
... systemd-modules-load[146]: Failed to find module 'vboxnetflt'
... systemd-modules-load[146]: Failed to find module 'vboxnetadp'
 
Forse anche un paio di volte, eppure i moduli,
alla fine, sono caricati.
 
bye,
 
-- 
 
piergiorgio

   Process: 1803 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)
 
Passerò anch'io alla 5 ma mi trovo così bene con la 4 che aspetterò un
po' ;)
-- 
Sandro kensan 
www.kensan.it
 & 
www.qiqi.it
 geek site
Saluto gli agenti della NSA - Hello NSA - 
www.nsa.gov
 

 e` diverso:
 
Non ho seguito il thread, ma ti do un indizio: symlink
 
Enrico

 journalctl --since=today
 
Journalctl deve morire. E male.
 
Enrico

 
 
 
-- 
 
piergiorgio

 al momento, perche` sarebbe male?
 
Perche` e` in formato binario, perche` salva al suo interno i coredump, 
perche` e` locale alla macchina (anche se ci stanno lavorando), perche` se 
si corrompe il journal non c'e` modo di recuperarlo (se non cancellando il 
file)
 
Enrico
P.S. in effetti il mio "NO" e` per tutto systemd, ma l'insensatezza di 
journalctl e` molto piu` palese rispetto al resto

 P.S. in effetti il mio "NO" e` per tutto systemd, ma l'insensatezza di 
 
Spiegami.
 
Io trovi il *concetto* di systemd sicuramente
interessante.
Puo` essere che l'attuale implementazione non
sia (ancora) all'altezza.
 
bye,
 
-- 
 
piergiorgio

 sia (ancora) all'altezza.
 
L'attuale implementazione non e` decisamente all'altezza, ma perche` chi lo 
sviluppa e` piu` interessato a comportarsi da bambino che da professionista
 
Enrico

 Lo sviluppo e` portato avanti da degli incompetenti
 
Mi sa che questo ultimo punto e` una
triste situazione, ma reale...
 
Devo dire che molte cose di systemd, come
per es. il sistema automatico di dipendenze
o il socket activation, sono *necessarie*
in un sistema moderno.
 
D'altro canto, leggo anche io troppo spesso
di situazioni dove "noi sappiamo meglio (di
voi)" e` la risposta degli sviluppatori.
 
bye,
 
-- 
 
piergiorgio

 /lib/systemd/system/rc-local.service
 
  Questo ï¿½ quello vero, l'equivalente del
/usr/lib/systemd/system/rc-local.service della Fedora.  La fedora vi ha
aggiunto lo /usr iniziale per via dell'unificazione che hanno computo
dei filesystem /bin, /sbin e /lib con quelli /usr/bin, /usr/sbin e
/usr/lib.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 /usr/lib.
 
Si lo so, perche` le settimane scorse ho letto un paio di vostri thread
in proposito ma qui volevo solo rimarcare quanto gia` affermato in
precedenza da altri, circa il reperimento di informazioni non
propriamente esatte per la propria distribuzione; si tratta spesso non
solo di percorsi di file ma anche di nomi di comandi ed applicazioni;
penso ad esempio al browser Firefox di Fedora che in Debian e` chiamato
Iceweasel e al comando gksu in Debian che in Fedora, se non sbaglio, si
chiama beesu, e che mentre Debian e Fedora usano systemd, ad es. Ubuntu
usa upstream.
Piccolezze che pero` possono risultare fastidiose se si e` costretti a
passare da una distribuzione ad un'altra, IMHO.
 
 
 
 


Si infatti stavo pensando a passare Kubuntu, l'ultima versione 14.10 uscita 
qualche giorno fa per usare Plasma 5.
In questo caso dove metto mano per inserire un comando all'avvio?

 
forse dentro:
 
/home/<utente>/.kde4/Autostart


Fermo restando che non so quale sia il comando, nella /home/golinux o 
come ti chiami quando fai il login, esiste un file .xinitrc di solito 
sia che usi systemd che il vecchio.
Di solito si mettono i comandi che si vogliono eseguire prima di exec 
strartkde, oppure, startxfce4 o qualunque sia il tuo desktop.
Questo sempre che tu non abbia qualche desktop che scavalca .xinitrc
 
Esempio:
// ultime righe del mio .xinitrc
export BROWSER=chromium
./hdmi.sh &
alias one="./onescreen.sh"
   exec openbox-session
# exec  /usr/bin/jwm
 
hdmi attiva lo schermo grande attaccato via hdmi al notebook
onescreen disattiva lo schermo del notebook.
 
exec openbox-session
attiva il desktop, anzi il window manager nudo senza desktop
 
spero che questo faccia da toppa o panacea finchè non crei un .service 
di systemd o non fai altro.
 
potresti chiederti a cosa serva & e se vale la pena metterlo o no, fai 
delle prove e vedi se e come ti serve.
 
ciao e buon linux


systemd fa un boot multi thread, usando la macchina in maniera più 
efficente e veloce (sarà vero? Non lo so) quindi può capitaare che un 
service necessario al tuo caricamento modula non sia ancora stato 
esguito e quindi, c'èo un delay e poi altri tentativi. Oppure hai 
generato il servizio con una priorità troppo alta prima di altri servizi 
necessari al caricamento dei moduli di virtualbox.
 
se risolvi la catena dei servizi il tuo boot sarà più veloce, magari di 
un millesimo di secondo? (Non lo so).
Prova a dare i comandi:
systemd-analyze
e
systemd-analyze blame
e guarda se qualcosa blocca il tuo boot
 
journalctl -b
e
systemctl --failed
 
possono essere utili.
 
Poi vabe' se fai il boot una volta l'anno... :)
 
ciao e buon linux

 ciao e buon linux
 
bye,
 
-- 
 
piergiorgio

 al momento, perche` sarebbe male?
 
Perche` e` in formato binario, perche` salva al suo interno i coredump, 
perche` e` locale alla macchina (anche se ci stanno lavorando), perche` se 
si corrompe il journal non c'e` modo di recuperarlo (se non cancellando il 
file)
 
Enrico
P.S. in effetti il mio "NO" e` per tutto systemd, ma l'insensatezza di 
