Newsgroup: it.comp.os.linux.iniziare
Titolo: Mancata esecuzione script all'avvio

Ciao NG,
 
Ho un raspberry su cui ho un piccolo script, il quale 
chiede una password e la passa a veracrypt per montare il 
volume (so che potrei farlo da VC ma lo script fa anche 
diverse altre cose e poi è tutto allenamento).
 
Ho inserito il comando in /etc/rc.local appena prima di 
"exit". La linea nel file ha la forma
 
sudo /home/pi/altredirectories/script.sh
 
Se lo faccio girare aprendo finestra shell nella directory 
in cui sta, gira e funziona, ma rc.local sembra 
completamente ignorarlo.
 
Dove sbaglio? Prima di guardare nei logs (e non so 
nemmmeno quali) vorrei fare qualche tentativo standard; 
per conservare la micro SD ho disabilitato tutto il 
logging e se anche ci vuol poco a tornare indietro vorrei 
prima provare a capire cosa non va.
 
Thanks!
 
Apx
 
 
-- 
- Se scegli la pillola blu la tua vita
   continuerà a fare schifo.
- E se scelgo quella rossa?
- Lo stesso, ma è alla fragola.
 

 nemmmeno quali) vorrei fare qualche tentativo standard; 
 
Dopo aver tolto sudo, che come spiegato è un non senso in
rc.local...
Per vedere se lo script viene eseguito mettilo te un messaggio
nello script stesso, in modo che se viene eseguito lo scrive su
un file di log apposito.
 
echo "`date`    avvio script.sh" >> /var/log/script.log"
 
Così se lo script viene eseguito lo puoi sapere facilmente a
posteriori andando a controllare il file di log creato da te,
quindi facilmente consultabile.
 
Ci potrà essere il caso in cui lo script venga fatto girare, ma
poi non funzioni qualcosa e non faccia quello che ti aspetteresti,
in quel caso devi postare tutto lo script "as is".
 
Altra cosa, non dici su quale sistema sei.
Sinceramente rc.local non so come dovrebbe incastrarsi con systemd
nei sistemi che ne fanno uso, quindi riportare su che sistema stai
facendo quelle prove è il minimo sindacale prima di chiedere qui.
 
 
In sintesi, prima di tutto leva il sudo.
Poi ti tocca prevedere qualche piccolo log di controllo per
capire cosa gira e cosa no, anche direttamente in rc.local,
perché potrebbe anche esserci il caso che rc.local non venga
fatto neanche girare all'avvio.
A questo proposito controlla anche i permessi di rc.local in
particolare se ha quello di esecuzione.
 
-rwxr-xr-x 1 root root 467 mar  7  2019 /etc/rc.d/rc.local

 fatto neanche girare all'avvio.
 
Ultimamente, rc.local con systemd non viene più gestito, per cui come dici tu,
potrebbe essere che non venga eseguito.
Esiste tuttavia, un 'trucco' per riabilitarlo.
 
Io uso un rc.local piuttosto complesso e contorto, e creo ad ogni step una riga
di log per vedere se in qualche parte lo script si inceppa.
 
Alternativa, è mettere nella riga iniziale dello script incriminato un qualcosa tipo:
#!/bin/bash -x
 
e nella riga di rc.local fare:
path-script/script.sh > /tmp/rclocal.log
 
Per vedere se lo script si intoppa in qualcosa.
 

Pensando che il problema fosse ultra-banale non ho dato 
molte info. Adesso che ho fatto altri tentativi andati 
tutti a vuoto dettaglio un po'.
 
A) =================
 
Sistema:
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
 
B) =================
 
in una directory del tipo /home/pi/_dati ci sono i 
seguenti files. Riguardo al secondo, le directory VC 
esistono già tutte con relativi permessi. Forse ri-dare i 
permessi e far ripartire samba è inutile ma prima di 
rimediare in questo modo mi dava sempre grane per 
l'accesso da windows. Ecco files e contenuto:
 
f01.sh :
sudo python3  ./f_01_hw_shutdown.py   &
 
f02.sh :
echo "avvio script 1" >> ./script.log
read -p "Enter Password: " mypassword
echo "avvio script 2" >> ./script.log
veracrypt  -p  $mypassword   /media/pi/hdd/
file1.vc
 
[stessa linea qui sopra] /home/pi/loc_mnt/hd_01
echo "avvio script 3" >> ./script.log
sudo chmod -R 777 /home/pi/loc_mnt/hd_01/loc_home
sudo samba restart
 
f_01_hw_shutdown.py :
[comandi vari per soft shutdown via GPIO]
 
 
1) Tutti e tre i files hanno tutti i permessi abilitati; 
con ls  -l mi compare per tutti e tre:
 
-rwxrwxrwx
 
La directory in cui sono contenuti ha tutti i permessi 
come per i files.
 
2) I files sembrano corretti, se apro una shell e li 
lancio a mano funzionano. Unico problema me lo dà quello 
in cui chiamo python, il primo: crea due processi con lo 
stesso programma di cui uno "sudo" e l'altro che gli è 
figlio. se per prova killo il figlio muore anche il 
parent. Non so spiegarmi questo, non so se è normale che 
ci siano due istanze di un processo con privilegi diversi 
e nel caso come correggere l'errore.
 
C) =================
 
Tentativi fatti e falliti:
 
1) editare i vari /rc.local  /init.d, eccetera (sì, sto 
confondendo nomi e directory ma tutti i punti dove è 
possibile intervenire stando a google li ho tentati). Ho 
sempre inserito il percorso completo degli scripts.
 
2) Esiste una directory nascosta 
/home/pi/.config/autostart dove a quanto ho capito ogni 
file presente e che rispetti una data sintassi viene 
automaticamente eseguito. Ne ho creati uno per ciasuno 
script con la forma (è il primo: l'altro è del tutto simile):
 
[DeskTop Entry]
Type=Application
Name=sh01
Comment=soft shutdown
Exec=sh --working-directory=/home/pi/_dati/ -e ./f_01.sh
 
3) Esiste una GUI per le applicazioni in startup 
applications=>settings=>session and startup in cui è 
possibile creare delle entry che accettano il percorso di 
un comando. Gli ho dato in pasto i miei 2 .sh, come sopra, 
percorso completo, con nome ed estensione.
 
4) file /home/pi/.profile, stando a google anche lì c'è 
l'esecuzione automatica dei comandi, anche stavolta 
invano. Ho provato sia il normale percorso sia facendolo 
precedere da sudo.
 
4.bis) file /home/pi/.bashrc (mi pare, ma avevo seguito 
google e difatti nel file c'era già qualcosa). Stavolta 
funziona ma solo se apro una shell, come del resto era 
prevedibile. Ovviamente non è quello che vorrei.
 
D) =================
 
Temo di sentirmi dire di spostare i files in una directory 
tipo /etc/init.d ma vorrei evitarlo per due motivi. 1) Un 
workaround che non si è compreso è una mina vagante 2) Ho 
già perso diversi files utili in varie riformattazioni 
(colpa delle SD che sono delicate) e ancora non so come 
funziona il backup in linux. Vorrei tenere tutto il 
possibile nella mia home così posso fare salvataggi 
frequenti solo di quella.
 
Sono sicuro di aver provato ancora altre due strade ma non 
le ricordo, dato che a un certo punto ho iniziato a essere 
parecchio irritato. Anzi, diciamo inc....to :D
 
Come avrete visto ho inserito delle scritture in un file 
log; in nessuno dei tentativi elencati viene eseguito 
alcunché. Difatti, se apro una shell e digito i comandi a 
mano, i file di log magicamente compaiono.
 
Infine, credo esista una distinzione su come viene fatto 
partire uno script. Se faccio doppio click su quello che 
monta il volume VC, mi chiede se voglio solo eseguire o 
eseguire in terminale. Nel primo caso VC mi dà errore, nel 
secondo caso esegue. Credo che questo comporti dover 
premettere (forse) sh o bash prima del comando ma 
ovviamente non so cosa e non so dove e non so se.
 
Scusate la lunghezza, ho cercato di ricordare tutto quello 
che potrebbe essere utile.


 prima provare a capire cosa non va. 
 
rc.local era il "vecchio" init, con systemd non è più usato.
 
la cosa corretta da fare è eseguirlo come service oneshot e RemainAfterExit = true. questo è il modo giusto per eseguire alla partenza uno script con systemd che non rimane in background.
 
https://trstringer.com/simple-vs-oneshot-systemd-service/
 
 
il vantaggio è che lanciando 'systemctl status nomeservizio.service' hai direttamente la risposta se è stato eseguito o no e se è uscito con errore.
 
altra cosa: gli script di sistema non li tenere nella home degli utenti, c'è una directory apposta /usr/local/bin.
ah e non è necessario che tu faccia sudo, in assenza di istruzioni contrarie i servizi vengono eseguiti come root.
 
 

 percorso completo, con nome ed estensione.
 
<premessa>
Quando non riesci a trovare la soluzione ad un problema, di solito è una immane
cazzata che nemmeno col microscopio riesci a vedere.
Un grosso errore, lo vedi a caratteri cubitali con freccie luminose lampeggianti.
<\premessa>
 
Scusa quindi la pedanteria!
 
 
 
 
 
Primo, togli tutto quello che hai messo in autostart e compagnia bella, e
limitati a /etc/rc.local.
 
 
 
 
Verifica che ci siano:
-rw-r--r-- 1 root root  716 Apr  1 13:57 /lib/systemd/system/rc-local.service
lrwxrwxrwx 1 root root   16 Apr  1 13:57 /lib/systemd/system/rc.local.service -> rc-local.service
 
 
 
 
Una pagina per fare ciò:
 
https://www.troublenow.org/752/debian-10-add-rc-local/
 
 
 
 
 
Nel mio pi3:
 
cat /lib/systemd/system/rc-local.service
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
 
# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
Documentation=man:systemd-rc-local-generator(8)
ConditionFileIsExecutable=/etc/rc.local
After=network.target
 
[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no
 
 
 
 
 
 
Che in /etc/rc.local la direttiva:
    exit 0
sia SOLO alla FINE del file, e non all'inizio dove c'è la parte commentata.
 
 
 
 
 
 
Poi, come ti è stato detto, non usare la $HOME, ma la /usr/local/bin, che è li
apposta!
 
 
 
 
 
Poi, fai sapere....
 
 
-- 
--- MirEdit 1.21f [Supp]
 * Origin: Ho fatto l'amore con Control: domani provo CapsLock (2:335/317.0)

Ho provato a seguire i vostri suggerimenti; riesumare 
rc.local ha fallito, non so ovviamente come e perché. 
Visto che pare che il sistema up to date sia far partire 
tutto come se(r)vizio ho lavorato un po' più con quello.
 
Ho creato e registrato i due servizi ed eseguono 
regolarmente gli script associati (anzi uno). Il file .sh 
è in /usr/local/bin e i servizi sono in /etc/systemd/system.
 
Il primo non dà problemi e vedo il processo in esecuzione, 
il PID corrisponde. Il secondo invece viene eseguito tanto 
che il file log "casereccio" viene scritto, ma non chiede 
la password e non esegue veracrypt, tanto che dà errori 
nelle istruzioni successive relative ai permessi delle 
directory del container montato. Qualsiasi combinazione di 
qualificatori tipo "oneshot" o simili, viene rifiutato con 
un messaggio in rosso.
 
Ecco i rispettivi contenuti. Al primo non serve il file 
.sh Riguardo il secondo, ho provato a chiamare i comandi 
sia con che senza precedere da /bin/bash, non funziona mai.
 
1) ==============================
 
1.A)
 
[Unit]
Description=soft shutdown
After=network.target
 
[Service]
User=pi
WorkingDirectory=/home/pi/_rt/c_sys/data/scripts
ExecStart=/usr/bin/python3 
/home/pi/_rt/c_sys/data/scripts/f_01_hw_shutdown.py
Restart=on-failure
RestartSec=10
KillMode=process
 
[Install]
WantedBy=multi-user.target
 
2) ==============================
 
2.A)
 
[Unit]
Description=mount veracrypt volume
After=multi-user.target
 
[Service]
User=pi
ExecStart=/bin/bash  /usr/local/bin/f_02.sh
Restart=on-failure
RestartSec=10
KillMode=process
 
[Install]
WantedBy=custom.target
 
2.B)
 
#! /bin/sh
 
#file f_02.sh
 
echo "avvio script 1" > /home/pi/script.log
 
read -p "Enter Password: " mypassword
 
echo "avvio script 2" >> /home/pi/script.log
 
/usr/bin/veracrypt  -p  $mypassword 
/media/pi/variedir/
cont.tc
    /home/pi/_rt/mnt/hd_ext_01
 
echo "avvio script 3" >> /home/pi/script.log
 
sudo chmod -R 777 /home/pi/_rt/g_mnt/hd_ext_01
 
sudo samba restart
 
 
=============================== fine listato files
 
Il primo funziona suppongo perché non usa la shell. Invece 
di chiamare il file .sh chiama python e forse funziona per 
questo.
 
E' il secondo che non va, che venga eseguito non ho dubbi 
e se chiamo "systemctl status" mi dice semplicemente che 
chmod fallisce, ed è ovvio perché la relativa directory 
non c'è, a sua volta perché veracrypt non sembra essere 
stato chiamato. Ma non mi avvisa che non ha né chiesto la 
password né chiamato veracrypt "invano".
 
Sto impazzendo...
 
thanksssss
 
Apx.


 read -p "Enter Password: " mypassword
 
Non so, mai provato, ma, se ho capito bene, all'avvio non hai la
possibilità di editare la password.
 
Io proverei ad idagare in questa direzione:
https://unix.stackexchange.com/questions/443235/how-to-use-systemd-ask-password-console-service
 
 
-- 
echo <password> | sudo -S <command>

 Sto impazzendo...
 
   Lo sei sempre stato!  :-P
 
 
   Ciao,
 
 
Alessandro
 

 Lo sei sempre stato!  :-P
 
Grazie, ricevo così pochi complimenti e gratificazioni che
averne uno fa sempre piacere: sei una delle poche persone
che mi abbia compreso :) (non è ironia e tu lo sai).


 miei script è stato chiamarli da "cron".
 
   L'unicop terminale che nelle fasi preliminari di "vita" del sistema è 
garantito che c'è è /dev/console: serve per permettere l'output dei 
messaggi del boot su console e per l'eventuale input dell'utente (ad es. 
per inserire password per decrittare filesystem protetti oppure per 
conenttersi ad un server remoto dal quale montare la / via rete).
 
   La cosa più semplice è di reindirizzare esplicitamente l'I/O da e 
verso quel dispositivo:
 
... < /dev/console > /dev/console
 
   Prova e facci sapere.
 
 
   In bocca al lupo!
 
 
Alessandro
 
 

 
 
Non ci sono riuscito probabilmente perché non ho capito 
cosa scrivere e dove, ma in compenso ho scoperto che 
esiste il file di configurazione di xterm e l'ho editato.
 
Dopo parecchi tentativi perché a quanto pare non tutti i 
valori per la dimensione font producono risultati, alla 
fine ho potuto ingrandire il terminale quel tanto che basta.
 
Appena messo su il sistema sulle cose principali 
rispolvererò la tua soluzione.
 
Thanks :)
 
C.


 Thanks :)
 
   Happy hacking!  :-)
 
 
Alessandro
 
 
 

 ExecStart=/usr/local/bin/f_02.sh < /dev/console > /dev/console 2>&1
   Però, più ci penso più mi pare strano che sia necessario farlo a 
mano: systemd dovrebbe intercettare l'apertura di un terminale da parte 
del comando e fornirgliene uno apposta.
 
   Prova a mettere solo:
 
ExecStart=/usr/local/bin/f_02.sh
 
e nello script la prima riga:
 
#!/bin/sh -i
 
   Inoltre, cryptsetup non ha di questi problemi: se un filesystem da 
montare al boot ha bisogno di una password da inserire interattivamente 
la chiede, gestisce la cosa in automatico.  Strano che veracrypt non lo 
faccia.  Forse ti manca un pacchetto accessorio di veracrypt con gli 
script di inizializzazione?  Ma portebbe anche essere una limitazione 
dell'implementazione/compilazione che ne hanno fatto per i Raspberry.
   In effetti cryptsetup lo fa aggiungendo dei suoi script 
nell'initramfs, eseguiti prima che sia montata /, ma il boot dei 
Raspberry potrebbe non averli/avere altre limitazioni che non li rendono 
implementabili come sui PC.
 
 
   Ciao,
 
 
Alessandro
 

 miei script è stato chiamarli da "cron".
 
Secondo me il problema è a monte.
 
La gui impiega parecchio tempo prima di essere avviata tutta, e rc.local è più
veloce, quindi la "read" viene persa nel tragitto.
Infatti, usando cron che avvia il tuo giochetto a 'bocce ferme', ti funziona.
 
Ti consiglierei di mettere prima dell'istruzione "read" uno 'sleep 50' ossia un
ritardo di 50 secondi (od anche più, visto che un raspberry non è molto veloce).
 
In una chiavetta con una buster per eliminare da rc.local l'icona sul desktop
dell'installer ho dovuto appunto mettere un ritardo di 50 secondi, per essere
sicuro che la gui fosse tutta in tiro ed eliminare la suddetta icona.
 
Poi, fermo restando quello che ti ha detto Selli, io al posto della 'read',
installerei zenity (più professionale) e metterei una riga tipo:
 
sleep 50
password=$(zenity --title "Avvio VC" --timeout=30 --password)
 
 
-- 
... File non trovato. Devo inventarmelo? (S/N)
--- Blue Wave/Max v2.12 [NR]
 * Origin: Animal House Bank - Savona - [I.S.N.] (2:332/206)

 installerei zenity (più professionale) e metterei una riga tipo:
 
   Più "professionale"? LOL!
   Ad Archaeopteryx non serve nulla di più di quello che read sa fare e 
zenity avrebbe lo stesso identico problema di read: senza un terminale 
collegato alla shell non può leggere nulla dall'input.
   In più, read è un comando interno della shell ed è quindi sempre 
disponibile, zenity è invece un comando opzionale che richiede 
l'installazione di un pacchetto aggiuntivo (e su un Raspberry è bene 
installare il minimo necessario).
   E in ultimo, zenity richiede della GUI, rendendone l'uso sia più 
difficile (far dipendere i servizi di systemd dalla presenza di una GUI 
e dalla sessione grafica attiva di un certo utente è complesso) che 
inutilmente ristretto a situazioni specifiche (la crittografia sul 
filesystem non deve dipendere dalla presenza di una GUI, non c'è motivo 
di'introdurre manualmente questa dipendenza specialmente in un 
dispositivo come un Raspberry che potrebbe non avere per niente la GUI).
 
   Quindi, in breve: il solo problema che rimane è di far eseguire lo 
script al boot sotto systemd con un terminale associato per poter 
leggere la password dallo standard input.  Non so se systemd può fare 
lui questa operazione, ma redirigere esplicitamente l'I/O da e verso 
/dev/console dovrebbe funzionare.
 
   Archaeopteryx ha già scritto che lo script funziona se lanciato da un 
VC (Virtual Console, presumo).  Non c'è quindi bisogno di mettere su il 
carrozzone della GUI per risolvere un problema di I/O su terminale.
 
 
Alessandro
 

 To run VeraCrypt in text user interface, just type veracrypt and pass the -t/--text option.
 
   Se hai risolto il problema di read devi quindi evitare questo secondo 
problema, dire al comando veracrypt di non usare la GUI.
 
 
   Ciao,
 
 
Alessandro