Lo script di avvio non si avvia


33

Ubuntu 10.04

Ho creato questo script upstart ( /etc/init/pure-ftpd.conf ):

# pure-ftpd - FTP server

description "Pure-FTPd server"

start on filesystem
stop on runlevel S

respawn
respawn limit 10 5
pid file /var/run/pure-ftpd.pid
console output

pre-start script
    test -x /usr/local/sbin/pure-ftpd || { stop; exit 0; }
end script

exec /usr/local/sbin/pure-ftpd --maxclientsnumber 2 --maxclientsperip 10 --prohibitdotfileswrite --prohibitdotfilesread --noanonymous --chrooteveryone --dontresolve --nochmod --pidfile /var/run/pure-ftpd.pid

Ma...

# start pure-ftpd
start: Unknown job: pure-ftpd

e

# service pure-ftpd start
start: Unknown job: pure-ftpd


Qual è il problema?
È necessario fare qualcosa di più?
È necessario creare uno script anche in /etc/init.d?


Ho incontrato lo stesso problema. Prova il comando initctl sulla console. Per accedere alla sessione della console, premere Ctrl + ALT + F1 e accedere. (Non riesco a capire perché, ma ci sono riuscito in questo modo)

Risposte:


26

Di solito significa che hai un errore nel .conffile - per esempio non sono sicuro che la pidstanza sia supportata in 10.04, stopnon possa essere usata nello script ecc.

Proverei ad avviare il file da zero (con solo start, stopecc.) E poi a costruirlo lentamente aggiungendo sempre più righe e testandolo tramite start pure-ftpd.

Per esempio:

# cat pure-ftpd.conf 
start on filesystem
stop on runlevel S

respawn
respawn limit 10 5

# start pure-ftpd
pure-ftpd start/running

# cat pure-ftpd.conf 
start on filesystem
stop on runlevel S

respawn
respawn limit 10 5
pid file /var/run/pure-ftpd.pid

# start pure-ftpd
start: Unknown job: pure-ftpd

Le informazioni nel wiki sono molto obsolete ( upstart.ubuntu.com/wiki ). Dall'altro lato, la versione upstart in Lucid è 0.6.5-8 e il file pid dovrebbe essere supportato: upstart.ubuntu.com/wiki/…
Juan Simón

1
AFAIK la pidstanza è stata rimossa dalla versione 0.5.0 2008-08-12 "One of those deaf-mutes". Non usarlo.
organizza il

Qualcuno sa dove si trova la documentazione aggiornata?
Juan Simón,

46

Puoi anche eseguire init-checkconfper verificare la sintassi

init-checkconf /etc/init/job.conf
File /etc/init/job.conf: syntax ok

1
Il comando non esiste in 10.04, ma esiste in 12.04.
Mark Stosberg,

6
Ma non funziona su un server Ubuntu 12.04 senza testa (ancora). Vedi bugs.launchpad.net/upstart/+bug/881885
FvD

1
Trovato subito il problema! - Dovrebbe essere integrato nel startcomando in modo che ti dia un messaggio di errore più informativo ...
AL

26

Innanzitutto, puoi verificare che il tuo lavoro sia effettivamente noto per l'avvio:

sudo initctl list | grep your_job_name

... dov'è your_job_nameil nome del tuo script upstart meno l' .confestensione.

Se non viene trovato, puoi provare a ricaricare la configurazione e quindi a ricontrollare:

sudo initctl reload-configuration

# re-check
sudo initctl list | grep your_job_name

Quindi riprovare per iniziare il lavoro:

sudo start your_job_name

Se non hai effettuato l'accesso /var/log/daemon.logo /var/log/syslogprima, potresti averne alcuni adesso.


1
E se ciò dimostra che il lavoro non è noto per l'avvio, anche se la sintassi è corretta e risiede in / etc / init?
FvD,

1
Hai provato "sudo initctl reload-configuration" come suggerito? Hai controllato autorizzazioni, registri, documenti?
Mark Stosberg,

L'ho fatto e l'ho fatto di nuovo dopo aver letto il tuo commento. Si è anche assicurato che l'utente fosse un utente di sistema (useradd -r). Forse potrebbe esserci qualcos'altro di sbagliato, non correlato all'avvio, quindi ho inviato un problema agli sviluppatori del servizio che sto cercando di avviare (è il server lucido che sto cercando di avviare all'avvio).
FvD,

1
E dopo tutto erano permessi! anche se tutto sembrava esagerato quando si elencava la directory, solo dopo che chmod 644 ha iniziato a prendere lo script. Grazie ancora.
FvD,

1
Ricorda, your_job_name è senza la fine .conf del file. Mi ci è voluta un'ora per scoprirlo.
Marcel,

6

Il riferimento più rilevante per la sintassi del file di lavoro sarà disponibile quando si esegue il comando:

man 5 init

sul tuo sistema. Per Ubuntu 10.04, come hai trovato nella risposta precedente, la sintassi del file pid non è corretta.

Ogni volta che viene restituito l'errore "Lavoro sconosciuto", è una buona idea controllare i registri (pre 11.04, /var/log/daemon.log, 11.04 e versioni successive, tutto va in / var / log / syslog)

È possibile che venga visualizzato un errore come questo:

init: /etc/init/test.conf:2: Unknown stanza

3

Comunque sono qui perché ho avuto lo stesso problema, ma la mia sintassi era corretta al 100%.

Dopo un po 'di debug ho scoperto un altro problema che può causare questo errore " Lavoro sconosciuto" :

upstarts utilizza inotify per monitorare le modifiche ai file .conf e i lavori di installazione automatica, questo è molto interessante (per questo non hai bisogno di qualcosa come update.rc con upstart!) ma può non essere perfetto se (come me in quel caso) usi alcuni programmi GUI FTP / SCP per caricare e modificare configurazioni su server remoti, il lavoro può essere disinstallato silenziosamente da start up quando si modifica il file in quel modo.

per risolvere semplicemente farlo (che mi ha salvato)

touch /etc/init/*

genererà eventi inotify per aggiornare tutte le configurazioni di avvio.


2

Ho avuto lo stesso problema nei miei contenitori Docker Ubuntu 14.04. A quanto pare, l'immagine Ubuntu 14.04 (se non altre) per Docker non supporta Upstart come farebbe una macchina virtuale completa.

Per rispondere a questa domanda, perché il servizio non si avvia, è perché initctl non è un vero programma Upstart: è mappato su / bin / true.

Per verificare eseguire quanto segue su un contenitore Docker Ubuntu 14.04 rispetto a Vagrant e rispetto a una goccia DigitalOcean

$ ls -al /sbin/initctl

Vedrai che initctl non è lo stesso in Docker rispetto agli altri.

Un link che potrebbe favorire la tua comprensione. Https://github.com/docker/docker/issues/1024


2
Si è imbattuto nello stesso problema con la finestra mobile: in breve e per riassumere, la finestra mobile esegue solo un processo alla volta, quindi non può avviarsi e qualcos'altro. Per essere sicuro di riavviare il servizio se / quando muore, ho finito per usare Supervord. PS: non dovresti eseguire più servizi in un container: il punto centrale dell'uso dei container è costruire micro servizi, quindi costruisci i pezzi in contenitori separati e
riuniscili

1
Ho appena incontrato questo articolo e questo mi dà ottimi consigli su come separare le preoccupazioni: blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker che è probabilmente anche strategia migliore da utilizzare rispetto a quella del supervisore
MrE
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.