Skrypt uruchamiania nie uruchamia się


33

Ubuntu 10.04

Utworzyłem ten skrypt wstępny ( /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

Ale...

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

i

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


Jaki jest problem?
Czy trzeba zrobić coś więcej?
Czy konieczne jest również utworzenie jednego skryptu w /etc/init.d?


Napotkałem ten sam problem. Spróbuj wykonać komendę initctl na konsoli. Aby przejść do sesji konsoli, naciśnij Ctrl + ALT + F1 i zaloguj się. (Nie rozumiem dlaczego, ale udało mi się w ten sposób)

Odpowiedzi:


26

Zwykle oznacza to błąd w .confpliku - na przykład nie jestem pewien, czy pidsekcja jest obsługiwana w 10.04, stopnie można jej użyć w skrypcie itp.

Chciałbym spróbować uruchomić plik od podstaw (z tylko start, stopetc), a następnie powoli budując go poprzez dodawanie coraz więcej linii i sprawdzając je za pomocą start pure-ftpd.

Na przykład:

# 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

Informacje na wiki są bardzo nieaktualne ( upstart.ubuntu.com/wiki ). Z drugiej strony, wersja upstart w Lucid to 0.6.5-8, a plik pid powinien być obsługiwany: upstart.ubuntu.com/wiki/…
Juan Simón

1
AFAIK pidzwrotka została usunięta od wersji 0.5.0 2008-08-12 "One of those deaf-mutes". Nie używaj tego.
umów się

Ktoś wie, gdzie jest zaktualizowana dokumentacja?
Juan Simón

46

Możesz także uruchomić, init-checkconfaby sprawdzić składnię

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

1
Polecenie nie istnieje w 10.04, ale istnieje w 12.04.
Mark Stosberg

6
Ale to nie działa na bezgłowym serwerze Ubuntu 12.04 (jeszcze). Zobacz bugs.launchpad.net/upstart/+bug/881885
FvD

1
Znalazłem problem od razu! - Powinien być wbudowany w startkomendę, aby wyświetlał bardziej pouczający komunikat o błędzie ...
AT

26

Po pierwsze, możesz sprawdzić, czy Twoja praca jest rzeczywiście znana:

sudo initctl list | grep your_job_name

... gdzie your_job_namejest nazwa twojego skryptu początkowego minus .confrozszerzenie.

Jeśli nie zostanie znaleziony, możesz spróbować ponownie załadować konfigurację, a następnie ponownie sprawdzić:

sudo initctl reload-configuration

# re-check
sudo initctl list | grep your_job_name

Następnie spróbuj ponownie, aby rozpocząć pracę:

sudo start your_job_name

Jeśli nie dostawali żadnego rejestrowania się /var/log/daemon.loglub /var/log/syslogwcześniej, może mieć pewne teraz.


1
A co, jeśli to pokazuje, że zadanie nie jest znane z uruchomienia, nawet jeśli składnia jest poprawna i znajduje się w / etc / init?
FvD,

1
Czy próbowałeś „sudo initctl reload-configuration” zgodnie z sugestią? Czy sprawdziłeś uprawnienia, dzienniki, dokumenty?
Mark Stosberg

Zrobiłem to i zrobiłem ponownie po przeczytaniu twojego komentarza. Upewniłem się nawet, że użytkownik jest użytkownikiem systemu (useradd -r). Być może coś innego jest nie tak - niezwiązane z upstartowaniem - dlatego wysłałem problem do programistów usługi, którą próbuję uruchomić (jest to błyszczący serwer, który próbuję uruchomić przy starcie systemu).
FvD

1
I w końcu to były uprawnienia! mimo że wszystko wyglądało na brzoskwiniowe podczas wyświetlania katalogu, dopiero po chmod 644 initctl podniósł skrypt. Dzięki jeszcze raz.
FvD,

1
Pamiętaj, że twoja_nazwa_objawy nie ma końca pliku .conf. Zajęło mi godzinę, żeby się dowiedzieć.
Marcel

6

Najbardziej odpowiednie odniesienie do składni pliku zadania będzie dostępne po uruchomieniu polecenia:

man 5 init

w twoim systemie. W przypadku Ubuntu 10.04, jak stwierdzono w poprzedniej odpowiedzi, składnia pliku pid jest nieprawidłowa.

Za każdym razem, gdy pojawia się błąd „nieznane zadanie”, warto sprawdzić dzienniki (przed 11.04, /var/log/daemon.log, 11.04 i więcej, wszystko jest w / var / log / syslog)

Może pojawić się taki błąd:

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

3

W każdym razie jestem tutaj, ponieważ miałem ten sam problem, ale moja składnia była w 100% poprawna.

Po debugowaniu odkryłem inny problem, który może powodować błąd „Nieznane zadanie” :

upstarts używa inotify do monitorowania zmian plików .conf i zadań automatycznej instalacji, jest to bardzo fajne (do tego nie potrzebujesz czegoś takiego jak update.rc z upstart!), ale może nie być idealne, jeśli (podobnie jak ja w tym przypadku) używasz niektóre programy GUI FTP / SCP do wysyłania i edytowania konfiguracji na zdalnych serwerach, zadanie może zostać dyskretnie odinstalowane przez upstart podczas edycji pliku w ten sposób.

naprawić po prostu zrób to (to mnie uratowało)

touch /etc/init/*

wygeneruje zdarzenia inotify, aby odświeżyć wszystkie początkowe konf.


2

Miałem ten sam problem w moich kontenerach Docker Ubuntu 14.04. Jak się okazuje, obraz Ubuntu 14.04 (jeśli nie inne) dla Dockera nie obsługuje Upstart w taki sam sposób jak pełna maszyna wirtualna.

Aby odpowiedzieć na to pytanie, dlaczego usługa się nie uruchamia, to dlatego, że initctl nie jest rzeczywistym programem Upstart: jest odwzorowany na / bin / true.

Aby zweryfikować, uruchom następujące czynności na kontenerze Ubuntu 14.04 vs. Vagrant i na kropli DigitalOcean

$ ls -al /sbin/initctl

Zobaczysz, że initctl nie jest taki sam w Docker vs.

Link, który może pomóc Ci zrozumieć. https://github.com/docker/docker/issues/1024


2
Napotkał ten sam problem z dokerem: w skrócie i podsumowując, doker uruchamia tylko jeden proces na raz, więc nie może uruchomić się na początku i coś innego. Aby upewnić się, aby ponownie uruchomić usługę, jeśli / kiedy ona umrze, skończyło się na użyciu superwizora. PS: nie powinieneś uruchamiać wielu usług w kontenerze: celem korzystania z kontenerów jest budowanie
mikrousług

1
Właśnie natknąłem się na ten artykuł, który daje bardzo dobrą radę na temat oddzielania problemów: blog.docker.com/2014/06/hy-you-dont-need-to-run-sshd-in-docker, który prawdopodobnie jest parzysty lepsza strategia użycia niż użycie opiekuna
MrE
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.