[Fli4l_dev] syslogd "stirbt" bei 'killall -HUP syslogd'

[Hans Bachner]

Hallo Alex,

danke für deine ausführliche Analyse!

Alexander Dahl schrieb am 10.12.2019 um 09:18:
> Hallo Hans,
> 
> Hans Bachner schrieb Freitag,  6. Dezember 2019, 13:02 (CET):
>> Auf dem anderen (57037-testing x86) habe ich mir das jetzt näher
>> angesehen. Auf beiden Systemen läuft das cpmvrmlog Paket, das kurz vor
>> Mitternacht die Datei /var/log/syslog.log auf die Festplatte verschiebt
>> und wie schon zu v3.x Zeiten anschließend den syslogd mit "killall -HUP
>> syslogd" neu startet (der dann auch wieder eine neue /var/log/syslog.log
>> anlegt.
> 
> Ich benutze hier wohl zum rotieren und ablegen der syslogs die
> Funktionalität aus base:
> 
> OPT_SYSLOGD='yes'
> SYSLOGD_DEST_1='*.* /var/log/messages'
> SYSLOGD_DEST_N='1'
> SYSLOGD_ROTATE='yes'
> SYSLOGD_ROTATE_AT_SHUTDOWN='yes'
> SYSLOGD_ROTATE_DIR='/data/syslog'
> SYSLOGD_ROTATE_MAX='5'
> 
> (und ich frage mich gerade, ob SYSLOGD_ROTATE_DIR auch eine Option
> "auto" kennt um es über FLI4L_UUID passend abzulegen, aber das schau ich
> mir wann anders an)

Tja - das ist aber nur ein bescheidener Subset der Funktionen, die 
CPMVRMLOG bietet :-(

> btw: busybox hat hier ein feature, mit dem der syslogd selbständig sein
> logfile rotieren könnte, nutzen wir aber auch nicht … ^^
> 
>> In der steht aber dann nur drinnen:
>>
>>> Dec  5 23:59:01 fli-wwan user.notice cpmvrmlog: move_1.sh - execute killall -HUP syslogd
>>
>> bzw. auf dem zweiten, auf dem auch das Accounting-Paket mit einem
>> passenden cpmvrmlog Job läuft:
>>
>>> Dec  5 23:59:01 flitest user.notice cpmvrmlog: move_1.sh - execute killall -HUP syslogd
>>> Dec  5 23:59:01 flitest user.notice cpmvrmlog: backup_5.sh - removed directory tree /data/accounting
>>
>> Ab diesem Zeitpunkt gibt es den syslogd nicht mehr.
> 
> Ohne jetzt cpmvrmlog genauer angeschaut zu haben, ich habe folgendes
> probiert: dem syslogd auf der Konsole ein `kill -HUP <PID>` geschickt
> und danach ist der weg aus der Prozessliste. Das von Dir beobachtete
> Verhalten kann ich also bestätigen.

Danke, genau das ist das Problem.

>> Hat sich in der fli4l v4 Version etwas am verhalten des syslog Dämons
>> bezüglich des -HUP Signals geändert?
> 
> Der kommt bei fli4l 4.0 aktuell aus BusyBox v1.27.2, allerdings mit
> einigen Patches obendrauf. In einem sauberen BusyBox 1.27.2 ignoriert
> der syslogd ein SIGHUP einfach. Unser Patch
> package/busybox/9004-syslogd-pipe.patch ändert dieses Verhalten
> allerdings. Laut package/busybox/README.patches soll der folgendes
> machen:
> 
> 9004-syslogd-pipe.patch (kristov, Bug #5558) -> Update Roland for 1.23
> * Allows FIFOs (|<path>) as log destiniations in /etc/syslog.conf. Also, ignore
>    SIGPIPE signals which occur if the process reading the pipe disappears.
> 
> Diesen Patch haben wir drin seit r43370 (FFL-1553), aber wenn ich das
> richtig interpretiere hat der syslogd da auch vorher nicht auf das -HUP
> die Logdatei neu geöffnet, sondern wenn dann durch einen anderen
> Mechanismus? In upstream busybox ist das Verhalten jedenfalls seit 2002
> unverändert so:
> 
>      signal(SIGHUP, SIG_IGN);

ähh - sorry, das sagt mir nicht wirklich was (SIGHUP wird ignoriert?)

In fli4l 3.x hat sich der syslogd noch genau so verhalten, wie es z.B. 
in <https://linux.die.net/man/8/syslogd> festgehalten ist:

> SIGHUP
> 
> This lets syslogd perform a re-initialization. All open files are closed, the configuration file (default is /etc/syslog.conf) will be reread and the syslog(3) facility is started again. 

D.h. der verschobene alte syslog.log wird geschlossen und ein neuer 
angelegt - genau das, was ich brauche.

Wenn der syslogd in busybox völlig anders reagiert - warum greift ihr 
dann nciht auf den "original" syslogd zurück? Das Platzargument zeiht ja 
seit dem Ende der Diskettenzeit nicht mehr wirklich.

Das ist für mich ein (eben entdecktes) KO-Kriterium gegen die Umstellung 
der Produktionsrouter auf V4.

Danke + schöne Grüße,
Hans.

> Vielleicht kann Roland ja was dazu sagen?
> 
> Grüße
> Alex