Perché uno script di spegnimento NON dovrebbe essere eseguito?

Ho installato uno script di spegnimento su un sistema Ubuntu che non viene eseguito. È un'istanza di Amazon EC2. Non sono sicuro che abbia a che fare con questo fatto, volevo solo evidenziarlo.

Lo script dovrebbe inviare alcuni file di registro su un bucket Amazon S3, quindi deve essere eseguito mentre la rete è attiva.

Ecco come ho installato lo script:

1) Creato il file /etc/init.d/push-apache-logs-to-s3.shcon i comandi richiesti.

2) Reso eseguibile con sudo chmod +x push-apache-logs-to-s3.sh

3) Eseguito sudo update-rc.d push-apache-logs-to-s3.sh start 0 0 .

L'output di quanto sopra è stato:

update-rc.d: warning: /etc/init.d/push-apache-logs-to-s3.sh missing LSB information
update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
 Adding system startup for /etc/init.d/push-apache-logs-to-s3.sh ...
   /etc/rc0.d/S00push-apache-logs-to-s3.sh -> ../init.d/push-apache-logs-to-s3.sh

Il contenuto di /etc/rc0.d/è ora:

lrwxrwxrwx  1 root root   17 Jul 31  2012 K09apache2 -> ../init.d/apache2
lrwxrwxrwx  1 root root   29 Jun 16  2012 K10unattended-upgrades -> ../init.d/unattended-upgrades
lrwxrwxrwx  1 root root   26 Jun 16  2012 K15landscape-client -> ../init.d/landscape-client
lrwxrwxrwx  1 root root   19 Apr 10 11:11 K20memcached -> ../init.d/memcached
-rw-r--r--  1 root root  353 Jul 26  2012 README
lrwxrwxrwx  1 root root   35 Jul 10 12:01 S00push-apache-logs-to-s3.sh -> ../init.d/push-apache-logs-to-s3.sh
lrwxrwxrwx  1 root root   18 Jun 16  2012 S20sendsigs -> ../init.d/sendsigs
lrwxrwxrwx  1 root root   17 Jun 16  2012 S30urandom -> ../init.d/urandom
lrwxrwxrwx  1 root root   22 Jun 16  2012 S31umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx  1 root root   20 Jun 16  2012 S35networking -> ../init.d/networking
lrwxrwxrwx  1 root root   18 Jun 16  2012 S40umountfs -> ../init.d/umountfs
lrwxrwxrwx  1 root root   20 Jun 16  2012 S60umountroot -> ../init.d/umountroot
lrwxrwxrwx  1 root root   14 Jun 16  2012 S90halt -> ../init.d/halt

Quando eseguo manualmente lo script con sudo ./push-apache-logs-to-s3.sh, fa il lavoro previsto.

Questi script sono eseguiti da root? Cosa mi sto perdendo?

debian amazon-ec2 init-script

— marekful
fonte

Questo tipo di problemi sono generalmente causati da qualcosa che manca dalle variabili di ambiente quando eseguito in modo non interattivo. Presumo che tu abbia preso la precauzione di non usare percorsi relativi sui tuoi script, quindi forse una dipendenza da una variabile d'ambiente che non è disponibile. Potresti aggiungere lo script alla tua domanda?

— GnP,

@gnp Ho pubblicato un'altra domanda a riguardo con maggiori dettagli e il contenuto dello script. Si prega di controllare qui: superuser.com/questions/617957/lsb-init-script-not-executed

— marekful

Penso che ora cosa c'è che non va. s3cmdè stato configurato con un altro utente, rootquindi lo script init che viene eseguito rootnon riesce a eseguire il s3cmdcomando. Proverò a configurarlo sotto l'utente root e vedrò se questo aiuta.

— marekful,

No, non ha aiutato. Quando eseguo lo script con uno dei due utenti, sta facendo ciò che dovrebbe, quindi s3cmdPOSSO accedere alla sua configurazione. Tuttavia, apparentemente lo script di init non viene eseguito allo spegnimento ...

— marekful

Risposte:

Si desidera eseguire lo script all'arresto. Sostituire start con stop come segue:

sudo update-rc.d push-apache-logs-to-s3.sh stop 0 0 .

Nota che otterrà una K anteposta invece di una S

— PNL
fonte

L'ho provato prima ma ancora nessun segno di esecuzione.

— marekful,

Non è quello stopche startfanno e non hanno nulla a che fare con l'arresto, che è definito dai livelli di esecuzione indicati. Vedere man update-rc.d.

— terdon,

Hai ragione, verrà eseguito quando si passa al runlevel 0, l'arresto e l'avvio cambiano solo il parametro passato ad esso, che nel caso OP non fa alcuna differenza.

— GnP,

I stope startsono lì per specificare a quali runlevel inizierà e finirà. stop 0 1 6significa fermarsi ai runlevel 0,1 e 6 per esempio.

— terdon,

Qual è il comportamento previsto quando si imposta lo script per l'esecuzione S00? Non ho script con S00sul mio sistema, potrebbe essere necessario un minimo di 1? Inoltre non hai impostato esplicitamente start / stop, forse questo sta causando problemi. Per ogni evenienza, prova

sudo update-rc.d push-apache-logs-to-s3.sh start 01 2 3 4 5 . stop 01 0 1 6 .

Se il problema persiste, aggiorna la tua domanda a chi è il tuo script (o almeno alle sue intestazioni), potrebbe esserci qualcosa che non va.

MODIFICARE

Dopo aver visto lo script che hai pubblicato nell'altra tua domanda , vedo due possibili problemi. Innanzitutto, hai uno spazio nella tua linea shebang !# /bin/shinvece di #!/bin/sh.

Ancora più importante, perché stai usando shinvece di bash? shnon supporta source, figuriamoci .come alias per la fonte. Cambia invece lo script con cui eseguire bash, che dovrebbe risolverlo. In realtà non capisco perché funzioni quando lo esegui manualmente, .dovrebbe generare un errore:

$ sh
$ source foo
sh: 1: source: not found
$ bash
$ source foo
bash: foo: No such file or directory

Scratch che, ho sbagliato, come sottolineato da @gnp, in dashrealtà supporta ..

— terdon
fonte

Ho provato il tuo suggerimento ma non ho ancora avuto fortuna. Inoltre, ora ho modificato lo script in /etc/init.d/ per renderlo uno script LSB corretto come tutti gli altri. Non viene ancora chiamato ...

— Marekful,

@ MarcellFülöp ed /etc/init.d/push-apache-logs-to-s3.shè di proprietà di root, giusto?

— terdon,

Sì, è-rwxr-xr-x 1 root root

— marekful il

Sulla maggior parte dei sistemi Ubuntu sh è un link simbolico a bash o dash lrwxrwxrwx 1 root root 4 mar 29 2012 /bin/sh -> dash. Inoltre la maggior parte degli script che ho su /etc/init.d hanno lo spazio dopo lo shebang e usano sh come shell.

— GnP,

Ri: EDIT. Punti buoni. Nella prima versione che avevo #!/bin/bash. Quindi ho copiato uno degli script init esistenti e l'ho modificato in modo che #! /bin/shprovenisse da lì, quindi presumo che sia OK. Proverò a cambiarlo di nuovo in #!/bin/bashperò.

— marekful

La radice del problema è che s3cmdnon è in grado di leggere il suo file di configurazione. Per qualche ragione sconosciuta a me, durante il cambio di runlevel (0), quando initesegue init-script, apparentemente l' rootutente che esegue quegli script non conta come un utente "reale", quindi non ha una directory "home" da dove s3cmdprova a leggere la configurazione.

Specificare esplicitamente la posizione del file di configurazione usando --config=...risolve questo problema.

Grazie per l'aiuto e il contributo di tutti!

— marekful
fonte