Başlangıç ​​betiği başlamıyor


33

Ubuntu 10,04

Bu başlangıç ​​betiğini ( /etc/init/pure-ftpd.conf ) oluşturdum:

# 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

Fakat...

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

ve

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


Sorun ne?
Daha fazla bir şey yapmak gerekli midir?
/Etc/init.d içinde bir tane script oluşturmak gerekli midir?


Ben de aynı sıkıntıyla karşılaştım. Lütfen konsolda initctl komutunu deneyin. Konsol oturumuna girmek için Ctrl + ALT + F1 tuşlarına basın ve giriş yapın. (Nedenini anlayamıyorum, ancak bu şekilde

Yanıtlar:


26

Bu genellikle .confdosyada bir hata olduğu anlamına gelir - örneğin pidstanza'nın 10.04'te desteklendiğinden emin değilim stop, komut dosyasında kullanılamaz.

Dosyayı sıfırdan başlatmayı (yalnızca start, stopvb. İle) ve daha sonra daha fazla satır ekleyerek ve test ederek yavaşça oluşturmayı denerdim start pure-ftpd.

Örneğin:

# 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

Vikideki bilgiler çok eski ( upstart.ubuntu.com/wiki ). Diğer taraftan, Lucid'deki başlangıç ​​sürümü 0.6.5-8 ve pid dosyasının desteklenmesi gerekiyor: upstart.ubuntu.com/wiki/…
Juan Simón

1
AFAIK pidstanza sürümünden bu yana kaldırıldı 0.5.0 2008-08-12 "One of those deaf-mutes". Kullanmayın.
düzenleme

Birisi güncellenmiş belgelerin nerede olduğunu biliyor mu?
Juan Simón

46

Ayrıca init-checkconfsözdizimini kontrol etmek için de çalıştırabilirsiniz .

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

1
Komut 10.04'te mevcut değil ancak 12.04'te mevcut.
Mark Stosberg

6
Ancak henüz başsız bir Ubuntu 12.04 sunucusunda çalışmaz. Bkz bugs.launchpad.net/upstart/+bug/881885
FVD

1
Derhal sorunu buldum! - yerleşik olmalı starto ... size daha bilgilendirici hata mesajı verir, böylece komuta
AT

26

Öncelikle, işinizin gerçekten işe başladığını bildiğini kontrol edebilirsiniz:

sudo initctl list | grep your_job_name

... your_job_namebaşlangıç ​​betiğinizin adı eksi eksidir .conf.

Bulunamadıysa, yapılandırmayı yeniden yüklemeyi ve ardından tekrar kontrol etmeyi deneyebilirsiniz:

sudo initctl reload-configuration

# re-check
sudo initctl list | grep your_job_name

Ardından işinize başlamak için tekrar deneyin:

sudo start your_job_name

Giriş yapmadan /var/log/daemon.logveya giriş /var/log/syslogyapmamışsanız, şimdi bazılarınız olabilir.


1
Ve bu, sözdiziminin doğru olmasına ve / etc / init konumunda olmasına rağmen, işin başlangıçta bilinmediğini gösteriyorsa?
FvD

1
Önerildiği gibi "sudo initctl reload-configuration" denediniz mi? İzinleri, kayıtları ve belgeleri kontrol ettin mi?
Mark Stosberg

Yorumunuzu okuduktan sonra tekrar yaptım. Hatta kullanıcının bir sistem kullanıcısı olduğundan emin olmuştu (useradd -r). Belki de başlangıçta ilgisiz başka bir şey olabilir - bu yüzden başlatmaya çalıştığım hizmetin geliştiricilerine bir sorun gönderdim (açılışta başlatmaya çalıştığım parlak sunucudur).
FvD

1
Ve sonuçta izinlerdi! Her ne kadar dir listelenirken her şey çok güzel görünse de, sadece bir chmod 644'ten sonra senaryoyu başlattı. Tekrar teşekkürler.
FvD

1
Unutmayın, your_job_name dosyanın .conf sonu değil. Öğrenmek bir saatimi aldı.
Marcel

6

İş dosyası sözdizimi için en uygun başvuru, komutu çalıştırdığınızda geçerli olacaktır:

man 5 init

sisteminizde. Ubuntu 10.04 için, önceki yanıtta bulduğunuz gibi, pid dosyası sözdizimi hatalı.

Bu 'bilinmeyen iş' hatasını geri aldığınızda, günlükleri kontrol etmek iyi bir fikirdir (11.04 öncesi, /var/log/daemon.log, 11.04 öncesi ve üstü her şey / var / log / syslog'a gider)

Bunun gibi bir hata görebilirsiniz:

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

3

Her neyse buradayım çünkü aynı problem vardı ama sözdizimim% 100 doğruydu.

Bazı hata ayıklamalardan sonra bu "Bilinmeyen iş" hatasına neden olabilecek başka bir sorun keşfettim :

upstarts .conf dosya değişikliklerini izlemek ve otomatik yükleme işlerini izlemek için inotify özelliğini kullanır , bu çok havalı (bunun için upstart ile update.rc gibi bir şeye ihtiyacınız yok!), ancak (bu durumda benim gibi) kullanmanız durumunda mükemmel olamaz Uzak sunuculardaki yapılandırmaları yüklemek ve düzenlemek için bazı FTP / SCP GUI programlarında, dosyayı bu şekilde düzenlediğinizde iş başlangıçta sessizce kaldırılabilir.

basitçe bunu düzeltmek için (beni kurtardı)

touch /etc/init/*

tüm başlangıç ​​onaylama işlemlerini yenilemek için inotify olayları oluşturur.


2

Ubuntu 14.04 Docker konteynerlerimde de aynı problem vardı. Görünüşe göre, Docker'ın Ubuntu 14.04 görüntüsü (diğerleri değilse), tam bir sanal makinenin yaptığı gibi Upstart'ı desteklemiyor.

Bu soruyu cevaplamak için, hizmet neden başlamıyor? Bunun nedeni initctl'nin gerçek bir Upstart programı olmamasıdır:

Bir Ubuntu 14.04 Docker konteyneri - Vagrant ve vs.

$ ls -al /sbin/initctl

İnitctl’nin Docker’da diğerlerinde aynı olmadığını göreceksiniz.

Anlayışınızı ilerletebilecek bir bağlantı .. https://github.com/docker/docker/issues/1024


2
Liman işçisi ile aynı sorunu yaşadık: Kısacası ve özetlemek gerekirse, liman işçisi bir seferde yalnızca bir işlem yürütüyor, bu yüzden de start-up ve başka bir şey yapamıyor. Hizmeti öldüğünde / ne zaman yeniden başlattığınızdan emin olmak için süpervizör kullandım. Not: bir konteynırda birden fazla servis çalıştırmamalısınız: konteynırları kullanmanın tek amacı mikro servisler inşa etmektir, bu yüzden parçaları ayrı konteynırlarda inşa etmek ve Docker-Compose ile bir araya getirmek
MrE

1
Sadece bu yazıda karşılaştım ve bu endişeleri ayırmak konusunda çok iyi bir tavsiye verir: blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker belki de olduğunu süpervizör kullanmaktan daha iyi bir strateji
MrE
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.