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

[Alexander Dahl]

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)

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.

> 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);

Vielleicht kann Roland ja was dazu sagen?

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6