Linux rc.local

[DragoRosso]

Salve a tutti.

Ho una domanda per gli appassionati di Linux: ho sempre usato /etc/rc.local per "lanciare" delle app alla partenza del sistema operativo.

Usando quasi sempre Linux su scheda proprietaria dove girava solo la mia app, problemi non ne ho mai riscontrati.

Ora invece, dovendo fare qualcosa su un sistema standard tipo PC dove girano altre applicazioni, usare rc.local è sempre lecito ?

rc.local è lo script chiamato al termine della catena di inizializzazione di Linux (da init, perchè sotto systemd praticamente non esiste, al massimo può diventare uno degli script che girano tra gli altri), e dovrebbe ritornare con uno 0 se tutto è andato bene o altri valori se qualcosa no và.

Se vengono lanciate app non grafiche che però mantengono lo script bloccato, è necessario usare il "fork" ?

Si possono lanciare app che usano il terminale per il "print" diagnostico ?

E le app grafiche ? Quando viene chiamato rc.local il sottositema grafico (gnome o altro) è già garantito sia operativo ? Anche se ho un sistema remoto con RDP ?

Sulle app grafiche il problema è minore e servirebbe solo ad agevolare una eventuale manutenzione. Non ho necessità per adesso di lanciare app grafiche all'avvio di Linux.

Bye

[bonmario]

Sia su Windows che su Linux, uso lo stesso metodo: ho un mio script da cui lancio tutto ciò che mi serve, ed è questo script che aggiungo alla "Esecuzione automatica" del relativo sistema operativo.
Tra un comando e l'altro, per evitare di imballare il tutto all'avvio, metto qualche "sleep 5s", amgari anche aumentando il numero di secondi in base a ciò che ho appena lanciato.
Quello su Ubuntu, l'ho fatto anni fa, tra l'altro in modalità grafica, quindi non so di preciso in quale file abbia scritto questa cosa.

Per provare a rispondere comunque alle tue domande:
- ad ogni comando lanciato all'avvio, aggiungo in fondo una "e commerciale", il carattere "&". In questo modo, il comando viene lanciato un maniera "asincrona", quindi subito dopo prosegue con l'esecuzione dello script
- da questo mio script, lancio sia comandi grafici che non. All'inizio filava tutto liscio, ma da un certo momento in poi, succedeva che mi lanciava i comandi grafici quando l'interfaccia grafica non era ancora stata caricata. Ho risolto alla bene e meglio, mettendo questa istruzione all'inizio del mi script:

Codice: [Seleziona]

sleep 40s

naturalmente a questa non ho messo la "&" alla fine. In questo modo, lo script parte, aspetta 40 secondi, dando così modo all'interfaccia grafica di caricarsi, e poi lancia tutto quello che devo lanciare

Ciao, Mario


Modifica delle 17:50

Per curiosità, ho visto che mi crea in "/home/bonmario/.config/autostart", un file di nome "EsecuzioneAutomatica.sh.desktop", che contiene questo:

Codice: [Seleziona]

[Desktop Entry]
Type=Application
Exec=/home/bonmario/uty/EsecuzioneAutomatica.sh
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[it_IT]=aa_BonMar_EsecuzioneAutomatica
Name=aa_BonMarEsecuzioneAutomatica
Comment[it_IT]=Mio script di EsecuzioneAutomatica
Comment=
X-GNOME-Autostart-Delay=0

[DragoRosso]

La problematica dello start automatico su Windows, con i servizi che non sono ancora disponibili, è di vecchia data e anche io l'ho risolta con gli sleep (in realtà io alla partenza uso un "lancher" che poi esegue la mia applicazione). Ciò mi consente di fare diverse cosette come riavvii software, aggiornamenti in linea ....
Poi in Windows imparai e verificare se i servizi di cui necessitavo era operativi, ma la rete è sempre stata una problematica.

In Linux, secondo me con sistemi "Init" non ci dovrebbero essere grossisimi problemi, forse eccetto l'interfaccia grafica in quanto uso normalmente RDP con server senza "monitor", in quanto viene eseguito tutto rigorosamente in sequenza sincrona, e rc.local da quello che ne sò è l'ultimo in coda.

- ad ogni comando lanciato all'avvio, aggiungo in fondo una "e commerciale", il carattere "&". In questo modo, il comando viene lanciato un maniera "asincrona", quindi subito dopo prosegue con l'esecuzione dello script

Grazie per il consiglio di cui sopra, che non conoscevo.

Quello che ti è successo è probabile sia dovuto all'avvento del nuovo "systemd" che sostisuisce l'"init". Systemd, a differenza di "Init" tra le altre cose, lavora in modalità asincrona stile Windows, quindi quando tocca il "tuo" turno non è detto che il SO sia pronto all'uso ..... odio queste cose.

Per quello che rigurda l'indicazione in "MODIFICA" ossia l'autostart del desktop, ritengo che venga eseguito quando "entra" in login un utente, anzi l'utente il cui profilo è indictao nell'autostart (/home/bonmario), quindi per me non è applicabile, uso sistemi non presidiati.

In rc.local userò, come mi hai suggerito, i "comandi" con la & in modo da lasciare inalterato il "flusso" logico di inizializzazione.

Ciao

[nomorelogic]

Ora invece, dovendo fare qualcosa su un sistema standard tipo PC dove girano altre applicazioni, usare rc.local è sempre lecito ?

diciamo che per lanciare qualcosa al boot, bisogna vedere quale sistema di init è in uso
se il sistema di init è OpenRc, va bene rc.local

però c'è anche un altro sistema che va bene ovunque: usare cron anteponendo @reboot
ad esempio (con delay di 300 ms):
@reboot sleep 300 && echo "ciao" >$HOME/saluto_al_boot.txt

Se vengono lanciate app non grafiche che però mantengono lo script bloccato, è necessario usare il "fork" ?

come ti hanno già consigliato, metti & alla fine del comando

Edit:
nel caso usi rc.local, per cron non serve