Systemd tarafından yönetilen hizmet günlüklerinin logrotate logrotate `file: 'config

Aug 19 2020

Aşağıdaki systemd yapılandırmasına sahip systemd tarafından yönetilen bir hizmetim var, systemd'ye günlükleri doğrudan bir dosyaya yazmasını söylüyorum (syslog veya başka bir şey yok)

StandardOutput=file:/var/log/foo/my.log

Logrotate kuralım var

/var/log/foo/*.log
{
        rotate 31
        daily
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
}

Olan şey, günlükler döndürülüyor, ancak hizmet hala eski döndürülmüş dosyaya yazıyor ve yeni günlük dosyası boş kalıyor.

Hizmetin bunun yerine syslog'a yazdığı benzer bir çalışma kurulumum var. Bu iyi çalışıyor çünkü logrotate yapılandırması

postrotate
                invoke-rc.d rsyslog rotate > /dev/null

, syslog'a günlüğünün döndürüldüğünü bildirir.

Sorun şu ki benim sorunlu durumumda günlüğün doğrudan dosyaya gitmesi, bu nedenle systemd'ye veya gerçek hizmet sürecine benzer bir sinyal göndermem gerekip gerekmediğini (veya hangisinin) bilmemem.

copytruncateLogrotate'te sorunumu çözeceğinden oldukça emin olduğum seçeneği buldum, ancak bunun bunu yapmanın ideal yolu olmadığı, aksi takdirde copytruncatelogrotate'in varsayılan davranışı olacağı hissine kapılıyorum .

Bu sorunu nasıl çözerim? systemd'ye biraz sinyal göndermem gerekiyor mu? servis sürecine sinyal göndermem gerekiyor mu? copytruncatebunun yerine logrotate'de kullanmak zorunda mıyım?
Önemliyse, hizmet, standart çıktıya yazmak için logback kullanan bir java işlemidir.

Yanıtlar

eleventyone Aug 18 2020 at 22:32

copytruncatebu durumda doğru cevaptır. Varsayılan değildir çünkü ihtiyaç duyulması daha az yaygındır, çünkü günlük dosyasını yeniden açmak için sinyal verebileceğiniz uygun bir arka plan programına sahip olursunuz.

Alternatif, dönüş sonrası komut dosyasında hizmeti yeniden başlatmaktır, ancak bu uygun veya arzu edilmeyebilir.