Ubuntu 12.04'te, Upstart log mesajlarını içinde bulabilirim /var/log/syslog.

Komutlar:

# initctl log-priority info
# initctl emit hello

Log:

Apr  1 01:56:56 precise64 kernel: [ 8365.820425] init: Connection from private client
Apr  1 01:56:56 precise64 kernel: [ 8365.821130] init: Handling hello event

Ubuntu 13.10'da, beklendiği gibi çalışmasına rağmen , mesajlar dizinin syslogaltında veya başka bir yerde görünmüyor . Onları başka bir yerde aramalı mıyım? Bir yerde değiştirmem gereken bir yapılandırma ayarı var mı?/var/loglogger hello

Ubuntu 13.04'te aynı problemi yaşıyor gibi görünen birinden Sunucu Hatası ile ilgili bir soru var ve burada ve burada da aynı sorunu tanımlayan başka bir şey var. Ne yazık ki, bu sorular soruna yol açmamaktadır.

Düzenle 2016-06-02

Genelde "Başlat günlük iletilerini" bulmaya çalışıyorsanız, işaretleyin /var/log/upstart/. Upstart'ın kaydettiği stdoutve stderrUpstart hizmetlerinden burası . Leopard'ın bunu işaret ettiği cevabı sayesinde.

Upstart'ın kendisinden günlük mesajları arıyorsanız, bunlar tarafından yapılandırılmış initctl log-priorityve yayılmış initctl emit, okumaya devam edin!

Kısa versiyon

Günlük girişleri aslında dmesg'de görünmelidir. Buna rağmen, varsayılan olarak görünmüyorlar/var/log .

Bunları /var/logda istiyorsanız , $KLogPermitNonKernelFacility onrsyslogd'ın config dosyasına ekleyin . Dpkg tarafından yönetildiği /etc/rsyslog.d/60-custom.confiçin düzenlemeyi önlemek gibi bir özel dosya oluşturmanızı öneririm /etc/rsyslog.conf. Şimdi Sonradan görme mesajlar gösterilmesi gereken /var/log/syslogsize Sonradan görme en belirledikten sonra, log-priorityhiç infoya da öylesine.

Uzun versiyon

Bu izini gün sürdü, ama görünüşe Sonradan görme (1.5) yok değil syslog oturum olduğunu, bu glibc işlevini çağırmaz syslog(). Bunun yerine, Upstart, dmesg'in okuduğu çekirdek halka arabelleğine giriş yapar. Şimdi, kullanıcı alanı işlemlerinin bu ara belleğe yazmasının mümkün olduğunu düşünmedim , ancak görünüşe göre yazarak yapabilirler /dev/kmsgve bu tam olarak Upstart'ın yaptığı şeydi. Demek bulmacanın ilk kısmı bu.

İkinci bölüm, çekirdek halkası arabelleğine yazılan iletilerin çekirdek tarafından otomatik olarak syslog'a kopyalandığına dair bir inanç olduğudur (en azından hep düşündüğüm gibi). Bunun aslında, sloglog ile uyumlu çalışan geleneksel olarak klog olan bir kullanıcı alanı programı tarafından yapıldığı ortaya çıktı. Açıkçası rsyslogd, syslogd'un yerine geçiyor, fakat görünüşe göre, klogd'un yerini alıyor (tür: sonunda notlara bakınız).

Üçüncü bölüm, çekirdek halkası arabelleğine kullanıcı alanından yazılan iletilerin aslında çekirdek alandan yazılan iletilerden farklı göründüğüdür: farklı bir tesise sahiptirler. dmesg'in bununla etkileşime giren birkaç seçeneği var: -xtesisi gösterecek (ve önceliği) -uve -kdmesg'e sırasıyla kullanıcı tesis mesajlarını ve çekirdek tesis mesajlarını göstermesini söyleyecektir.

Şimdi burada kattığı: Varsayılan olarak, rsyslogd , çekirdek halkası arabelleğindeki mesajları okurken, çekirdek olmayan bir tesisteki mesajları yok sayar . İlgili yapılandırma seçeneği, $KLogPermitNonKernelFacilityvarsayılan olarak kapalıdır ve rysyslogd'un bu mesajları işlemesini istiyorsanız, açılması gerekir. Rsyslogd'ın config komutunun, çekirdek halkası arabelleğindeki özelliklerinden kernbağımsız olarak, çekirdek halkası arabelleğindeki tüm mesajları tesis olarak kabul edeceğini unutmayın .

Daha fazla bilgi

syslog

Kod syslog(), içinde açıklanan glibc işlevini çağırarak syslog'a yazabilir man 3 syslog. Görünüşe göre bu işlevler yazıyor /dev/log. Kod, syslog'dan okuyarak okuyabilir /dev/logve bu da syslogdonun yerine geçenlerin yaptığı şeydir . giriş modülünü kullanarak rsyslogdokur ./dev/logimuxsock

Çekirdek halkası tamponu

Çekirdek alanı, çekirdek işlevini çağırarak bu arabelleğe yazar, bu printk()nedenle bazen printk arabelleği denir. Kullanıcı alanı yazarak ona yazabilir /dev/kmsg. Kullanıcı alanı bu tampondan birkaç yöntemle okuyabilir: /proc/kmsg(varsayılan olarak dmesg'in yaptığı şeyi) okuyabilir /dev/kmsgveya okuyabilir veya syslog()açıklanan glibc işlevinde açıklanan man 2 syslogve tamamen farklı olan sistem çağrısını çağırabilir. syslog()içinde man 3 syslog. glibc aslında bu karışıklığı hafifletmeye yardımcı olmak için syslog()çağrılan sistem çağrısına bir sarmalayıcı sağlar klogctl().

Geleneksel olarak, klogdbu arayüzlerden birinden okur, ardından syslog()onları slog günlüğüne kopyalamak için glibc işlevini çağırır . rsyslogd bu arayüzlerden birini imkloggiriş modülünden okur, ancak AFAIK glibc'i çağırmaktan rahatsız olmaz syslog(), bu yüzden tam olarak klogd'a benzemiyor; sadece çıkış işleyen imklogherhangi bir başka giriş modülünden çıkış işlemleri gibi. Çekirdek halka tamponu içindeki tesis mesajlarından bağımsız olarak tüm imklogçıkışın kerntesise sahip olduğu ek bir uyarı vardır .

Referanslar

• http://upstart.ubuntu.com/cookbook/#initctl-log-priority (Yanlış bir şekilde Upstart’ın syslog’a giriş yaptığını belirtir)
• https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg
• http://www.gnu.org/software/libc/manual/html_node/Overview-of-Syslog.html
• http://www.rsyslog.com/doc/v5-stable/configuration/modules/imklog.html (bunun Ubuntu 12.04'te kullanılan v5 için olduğunu unutmayın. Bu seçenekler, son rsyslog sürümlerinde eski kabul edilir)

Benimkiyi buldum /var/log/upstart/