Systemd ünitem neden yüklü ama etkin değil (ölü)?


29

Sunucumda Grafit kurmaya çalışıyorum . Karbon Önbellek arka plan planını hiçbir sorunla başlatabilirim sudo /opt/graphite/bin/carbon-cache.py start, ancak bir Systemd birimi olarak çalıştırmak için mücadele ediyorum.

Servis dosyamda şu var graphite.service:

[Unit]
Description=Carbon for Graphite

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py start

[Install]
WantedBy=multi-user.target

Ancak birimi başlattığımda aşağıdaki durumu alıyorum:

$ systemctl status graphite.service            
* graphite.service - Carbon for Graphite
   Loaded: loaded (/etc/systemd/system/graphite.service; enabled)
   Active: inactive (dead) since Fri 2014-06-13 18:44:11 UTC; 2s ago
  Process: 4525 ExecStart=/opt/graphite/bin/carbon-cache.py start (code=exited, status=0/SUCCESS)
 Main PID: 4525 (code=exited, status=0/SUCCESS)

Jun 13 18:44:11 MEADOW systemd[1]: Started Carbon for Graphite.

Journalctl daha fazla bilgi vermez.

"Etkin değil (ölü) ... (kod = çıkıldı, durum = 0 / BAŞARI)" durumundaki birimleri nasıl yorumlamalı ve hata ayıklamalıyım? Daha önce başarısız birimler görmüştüm, ancak bu başarıyla yüklendi ancak henüz çalışmıyor. Bunun ne anlama geldiğini bilmiyorum.


4
Sistemin işini tamamladığı anlamına geliyor. Bir Type=seçenek olmamalı mı ? man systemd.serviceUygun bir tip için bakınız .
jasonwryan

1
Bu mantıklı. Tek yapmam Type=forkinggereken [Service]bölüme eklemekti .
Ryne Everett,

Yanıtlar:


26

Jasonwryan'ın yorumuna göre, varsayılan Type=simplebirçok Systemd servis dosyası için çalışsa da, komut dosyası ExecStartbaşka bir işlemi başlattığında ve grafitin carbon-cache.py dosyasındaki gibi tamamladığında çalışmaz. Bu durumlarda açıkça belirtmek gerekir Type=forkingyılında [Service]systemd kökenli süreci yerine ilk baştaki bir bakmak gerektiğini anlaması bölüm.

Açıklandığı gibi man systemd.service:

Çatal bıçak takımı olarak ayarlanmışsa, ExecStart = ile yapılandırılan işlemin başlangıcının bir parçası olarak fork () çağırması beklenir. Başlatma işlemi tamamlandığında ve tüm iletişim kanalları kurulduğunda ana işlemin çıkması bekleniyor. Çocuk ana daemon süreci olarak koşmaya devam ediyor. Bu, geleneksel UNIX görevlilerinin davranışıdır. Bu ayar kullanılırsa, PIDFile = seçeneğinin de kullanılması önerilir, böylece systemd daemon'un ana işlemini tanımlayabilir. Sistem ana sistemden çıkar çıkmaz takip ünitelerini başlatarak devam edecektir.

Grafite Özel Cevap

Yukarıdakiler Systemd sorunumu çözerken hızlıca grafite özgü sorunlara rastladım (Twisted ile) ve varsayılan ayarlara geri döndüm Type.

Grafit <0.9.12

Grafit'in önceki sürümlerinde, yalnızca bu --debugseçeneği kullanarak çatal kullanmaktan kaçınabilirsiniz :

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --debug start

Grafit> = 0.9.13

Gelen bu çekme isteği bir --no-daemonseçenek birleştirilmiştir:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --no-daemon start
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.