Samba Logs

[Marcus Röckrath]

Hallo,

weil es mit dem letzten Release des samba-Paketes zwei Unschönheiten gibt,
die aber nicht kritisch sind, möchte ich hier etwas zur Diskussion stellen.

Durch einen kleinen blöden Gedanken/Codefehler, wsammeln die gerade einige
unnötige Logs iun /var/log an, die ihr an mehrfachen
<number>.xz.<number>.xz erkennt.

Die räume ich mit dem nächsten Update ab.

Sie entstehen, weil ich im "Zusand geistiger Abwesenheit" im logrotate-File
dachte mit Wildcards arbeiten zu können.

Bei mir finde ich zudem vereinzelt samba-Logdateien, die auf .backup enden.

Äuffällig, dass die vermutlich beim logrotate-Prozess entstehen, denn ein
gepacktes samba-log fehlt für den Tag dann.

Samba wird schon immer nach dem Rotieren der Logs in postrotate dazu
veranlasst, seine Konfiguration neu einzulesen (SigHUP).

Denkbar, dass manchmal während des Rotierens zu einem Schreibzugriff ins Log
kommt und dann das Rotieren scheitert.

Habt ihr auch *.backup-Dateien in /var/log?

Wie löst man das am besten?

Zunächst frage ich mich, ob überhaupt ein tägliches Rotieren nötig ist, denn
die Logs sind hier sehr klein. Mindestens weekly hielte ich für besser.

Zudem könnte ich vor dem Rotieren in prerotate samba stoppen und dann in
prerotate wieder starten, so dass samba für einen kurzen Moment nicht zur
Verfügung steht.

Bitte um Meinungen.

--
Gruß Marcus
[eisfair-Team]

[Johannes Hinteregger]

Hallo Marcus,

ich kann hier nichts beitragen außer

>
> Habt ihr auch *.backup-Dateien in /var/log?

eis # cd /var/log
eis # ls *.backup
log.nmbd.1-2023080800.backup log.rpcd_classic.1-2023080800.backup
log.rpcd_winreg.1-2023080800.backup log.samba-dcerpcd.1-2023080800.backup
eis #


VG
Johannes

[Stefan H.]

Hi Marcus,

> Habt ihr auch *.backup-Dateien in /var/log?

nicht nur die, sondern seit dem letzten Update auch noch eine Reihe
anderer Dateien:

/var/log/log.rpcd_classic
/var/log/log.rpcd_classic.1
/var/log/log.rpcd_classic.1.1
/var/log/log.rpcd_classic.1.1.1
/var/log/log.rpcd_classic.1.1.1.1
/var/log/log.rpcd_classic.1.1.1.1.xz.1.xz
/var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz.1.1.1
/var/log/log.rpcd_classic.1.1.1-2023080600.backup
/var/log/log.rpcd_classic.1.1.1.2.xz
/var/log/log.rpcd_classic.1.1-2023072600.backup
/var/log/log.rpcd_classic.1.1-2023080800.backup
/var/log/log.rpcd_classic.1.1.xz.1.xz
/var/log/log.rpcd_classic.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1.1.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_classic.1.1.xz.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_classic.1-2023072300.backup
/var/log/log.rpcd_classic.1-2023072300.backup.1
/var/log/log.rpcd_classic.1-2023072300.backup.1.1.xz
/var/log/log.rpcd_classic.1-2023072300.backup.1.1.xz.1.xz
/var/log/log.rpcd_classic.1-2023072300.backup.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1-2023072300.backup.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1-2023072300.backup.1.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_classic.1-2023072300.backup.1.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_classic.1-2023072300.backup.1.1.xz.1.xz.1.xz.1.xz.1.1.1
/var/log/log.rpcd_classic.1-2023072500.backup
/var/log/log.rpcd_classic.1-2023072800.backup
/var/log/log.rpcd_classic.1-2023080500.backup
/var/log/log.rpcd_classic.1-2023080500.backup.1
/var/log/log.rpcd_classic.1-2023080700.backup
/var/log/log.rpcd_classic.1.3.xz
/var/log/log.rpcd_classic.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_classic.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_classic.1.xz.1.xz.1.xz.3.xz
/var/log/log.rpcd_classic.1.xz.1.xz.1.xz.3.xz.1
/var/log/log.rpcd_classic.1.xz.1.xz.2.xz
/var/log/log.rpcd_classic.1.xz.2.xz
/var/log/log.rpcd_classic.1.xz.3.xz
/var/log/log.rpcd_classic.2.xz.1
/var/log/log.rpcd_classic.2.xz.1.1
/var/log/log.rpcd_classic.2.xz.1.1.1.xz
/var/log/log.rpcd_classic.2.xz.1.1.1.xz.1.xz
/var/log/log.rpcd_classic.2.xz.1.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.2.xz.1.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.2.xz.1.1.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.2.xz.1.1.1.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_classic.2.xz.1.1.1.xz.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_classic.3.xz.1
/var/log/log.rpcd_classic.3.xz.1.1
/var/log/log.rpcd_classic.3.xz.1-2023080600.backup
/var/log/log.rpcd_classic.4.xz
/var/log/log.rpcd_classic.4.xz.1
/var/log/log.rpcd_classic.5.xz
/var/log/log.rpcd_classic.5.xz.1.xz
/var/log/log.rpcd_classic.5.xz.1.xz.1.xz
/var/log/log.rpcd_classic.5.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.5.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_classic.5.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_classic.5.xz.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_classic.6.xz
/var/log/log.rpcd_epmapper
/var/log/log.rpcd_fsrvp
/var/log/log.rpcd_lsad
/var/log/log.rpcd_mdssvc
/var/log/log.rpcd_rpcecho
/var/log/log.rpcd_spoolss
/var/log/log.rpcd_winreg
/var/log/log.rpcd_winreg.1
/var/log/log.rpcd_winreg.1.1
/var/log/log.rpcd_winreg.1.1.1
/var/log/log.rpcd_winreg.1.1.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.1.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_winreg.1.1.1.xz.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_winreg.1.1-2023072600.backup
/var/log/log.rpcd_winreg.1.1-2023072600.backup.1.xz
/var/log/log.rpcd_winreg.1.1-2023072600.backup.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1-2023072600.backup.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1-2023072600.backup.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1-2023072600.backup.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_winreg.1.1-2023072600.backup.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_winreg.1.1.2.xz
/var/log/log.rpcd_winreg.1.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.1.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_winreg.1.1.xz.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_winreg.1-2023072300.backup
/var/log/log.rpcd_winreg.1-2023072300.backup.1
/var/log/log.rpcd_winreg.1-2023072300.backup.1.1.xz
/var/log/log.rpcd_winreg.1-2023072300.backup.1.1.xz.1.xz
/var/log/log.rpcd_winreg.1-2023072300.backup.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1-2023072300.backup.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1-2023072300.backup.1.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_winreg.1-2023072300.backup.1.1.xz.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_winreg.1-2023072500.backup
/var/log/log.rpcd_winreg.1-2023072800.backup
/var/log/log.rpcd_winreg.1-2023080700.backup
/var/log/log.rpcd_winreg.1.2.xz
/var/log/log.rpcd_winreg.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_winreg.1.xz.1.xz.1.xz.1.1
/var/log/log.rpcd_winreg.1.xz.1.xz.1.xz.4.xz
/var/log/log.rpcd_winreg.1.xz.1.xz.1.xz.4.xz.1
/var/log/log.rpcd_winreg.1.xz.1.xz.2.xz
/var/log/log.rpcd_winreg.1.xz.2.xz
/var/log/log.rpcd_winreg.1.xz.3.xz
/var/log/log.rpcd_winreg.4.xz.1
/var/log/log.rpcd_winreg.4.xz.1.1.xz
/var/log/log.rpcd_winreg.4.xz.1.1.xz.1.xz
/var/log/log.rpcd_winreg.4.xz.1.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.4.xz.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.4.xz.1.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.4.xz.1.1.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_winreg.5.xz
/var/log/log.rpcd_winreg.5.xz.1
/var/log/log.rpcd_winreg.5.xz.1-2023080800.backup
/var/log/log.rpcd_winreg.6.xz
/var/log/log.rpcd_winreg.6.xz.1.xz
/var/log/log.rpcd_winreg.6.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.6.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.6.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.rpcd_winreg.6.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.rpcd_winreg.7.xz
/var/log/log.samba-bgqd
/var/log/log.samba-bgqd.1.xz
/var/log/log.samba-bgqd.1.xz.1
/var/log/log.samba-bgqd.1.xz.1.1.xz
/var/log/log.samba-bgqd.1.xz.1.1.xz.1.xz
/var/log/log.samba-bgqd.1.xz.1.1.xz.1.xz.1.xz
/var/log/log.samba-bgqd.1.xz.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.samba-bgqd.1.xz.1.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.samba-bgqd.1.xz.1.1.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.samba-dcerpcd
/var/log/log.samba-dcerpcd.1
/var/log/log.samba-dcerpcd.1.1.xz
/var/log/log.samba-dcerpcd.1.1.xz.1.xz
/var/log/log.samba-dcerpcd.1.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.1.1.xz.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.1.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.1.1.xz.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.samba-dcerpcd.1-2023072500.backup
/var/log/log.samba-dcerpcd.1-2023072500.backup.1.xz
/var/log/log.samba-dcerpcd.1-2023072500.backup.1.xz.1.xz
/var/log/log.samba-dcerpcd.1-2023072500.backup.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.1-2023072500.backup.1.xz.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.1-2023072500.backup.1.xz.1.xz.1.xz.1.xz.1
/var/log/log.samba-dcerpcd.1-2023072800.backup
/var/log/log.samba-dcerpcd.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.1.xz.1.xz.1.xz.1
/var/log/log.samba-dcerpcd.1.xz.1.xz.1.xz.6.xz
/var/log/log.samba-dcerpcd.1.xz.1.xz.2.xz
/var/log/log.samba-dcerpcd.1.xz.2.xz
/var/log/log.samba-dcerpcd.1.xz.3.xz
/var/log/log.samba-dcerpcd.6.xz
/var/log/log.samba-dcerpcd.6.xz.1.xz
/var/log/log.samba-dcerpcd.6.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.6.xz.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.6.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.6.xz.1.xz.1.xz.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.7.xz
/var/log/log.samba-dcerpcd.7.xz.1.xz
/var/log/log.samba-dcerpcd.7.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.7.xz.1.xz.1.xz.1.xz
/var/log/log.samba-dcerpcd.7.xz.1.xz.1.xz.1.xz.1.xz


Mir würde ein Log im Bedarfsfall und, wenn schon dauerhaftes Log, dann
ein rotate einmal im Monat reichen. :-)

Viele Grüße
Stefan

[Marcus Röckrath]

Hallo Stefan,

Stefan H. wrote:

>> Habt ihr auch *.backup-Dateien in /var/log?
> nicht nur die, sondern seit dem letzten Update auch noch eine Reihe
> anderer Dateien:
>
> /var/log/log.rpcd_classic
> /var/log/log.rpcd_classic.1
> /var/log/log.rpcd_classic.1.1
> /var/log/log.rpcd_classic.1.1.1
> /var/log/log.rpcd_classic.1.1.1.1
> /var/log/log.rpcd_classic.1.1.1.1.xz.1.xz
> /var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz

Von denen mit mehrfachem xz hatte ich auch gesprochen, aber deren Ursache
ist klar. Die mit Ziffer.Ziffer.Ziffer hatte ich hier nicht.

Mal sehen, wie ich die alle abgeräumt bekomme.

> /var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz
> /var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz.1
> /var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz.1.1
> /var/log/log.rpcd_classic.1.1.1.1.xz.1.xz.1.xz.1.xz.1.1.1

> Mir würde ein Log im Bedarfsfall und, wenn schon dauerhaftes Log, dann
> ein rotate einmal im Monat reichen. :-)

Die Logs legt sama an, bei denen mit der 4.16/17 einige hinzugekommen sind.

Ich bin aber auch deiner Meinung das Rotationsinterval deutlich zu
vergrößern.

Logs nutzen nur etwas, wenn man auch ein älteres Problem nachvollziehen
kann, da scheinen mir 6 tage zurück nicht sinnvoll.

Zudem steht nur so wenig pro Tag in den Logs drin, dass ein Rotieren
ziemlich fehl am Platze erscheint.

Wenn andere auch der Meinung sind, kann das gerne auf monthly gehen.

--
Gruß Marcus
[eisfair-Team]

[Juergen Edner]

Hallo Marcus,

> Habt ihr auch *.backup-Dateien in /var/log?
>
> Wie löst man das am besten?

ja, solche Dateien finden sich auch in meinem Logverzeichnis.

> Zunächst frage ich mich, ob überhaupt ein tägliches Rotieren nötig ist, denn
> die Logs sind hier sehr klein. Mindestens weekly hielte ich für besser.
>
> Zudem könnte ich vor dem Rotieren in prerotate samba stoppen und dann in
> prerotate wieder starten, so dass samba für einen kurzen Moment nicht zur
> Verfügung steht.
>
> Bitte um Meinungen.

Damit hätte ich des nachts kein Problem.

Gruß Jürgen

--
Mail: jue...@eisfair.org

[Peter Bäumer]

Am 08.08.2023 um 13:07 schrieb Marcus Röckrath:
> Hallo,
>
> weil es mit dem letzten Release des samba-Paketes zwei Unschönheiten gibt,
> die aber nicht kritisch sind, möchte ich hier etwas zur Diskussion stellen.



>

> Samba wird schon immer nach dem Rotieren der Logs in postrotate dazu
> veranlasst, seine Konfiguration neu einzulesen (SigHUP).
>
> Denkbar, dass manchmal während des Rotierens zu einem Schreibzugriff ins Log
> kommt und dann das Rotieren scheitert.

Angefangene Schreibvorgänge werden ins Log zu ende geschrieben, auch wenn die Logdatei umbenannt wurde.
Der Schreibvorgänge erfolgt auf die INODE, nicht mit Hilfe des Dateinamens... (in der Hoffnung das das jetzt nicht völlig verkehrt ist...)

Bei der Verwendung der Option copytruncate ist das anders, da können Logeinträge verloren gehen...

> Habt ihr auch *.backup-Dateien in /var/log?
>
> Wie löst man das am besten?
>
> Zunächst frage ich mich, ob überhaupt ein tägliches Rotieren nötig ist, denn
> die Logs sind hier sehr klein. Mindestens weekly hielte ich für besser.

Eine Konfigurationsmöglichkeit im setup wäre auch schön ;)

> Zudem könnte ich vor dem Rotieren in prerotate samba stoppen und dann in
> prerotate wieder starten, so dass samba für einen kurzen Moment nicht zur
> Verfügung steht.

ein Restart des Dienst halte ich für unnötig, da ich davon ausgehen das samba mit einem Sig Hub umgehen kann.
Also nach den Rotieren die alte Logdatei schließt und die neue Logdatei zum schreiben öffnet.

Siehe auch: https://serverfault.com/questions/1080334/how-does-logrotate-work



Auf einem Debian Server sieht die conf so aus:
/var/log/samba/log.smbd {
weekly
missingok
rotate 7
postrotate
[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/smbd.pid ] || /usr/bin/smbcontrol smbd reload-config
endscript
compress
delaycompress
notifempty
}

/var/log/samba/log.nmbd {
weekly
missingok
rotate 7
postrotate
[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config
endscript
compress
delaycompress
notifempty
}

/var/log/samba/log.samba {
weekly
missingok
rotate 7
postrotate
if [ -d /run/systemd/system ] && command systemctl >/dev/null 2>&1 && systemctl is-active --quiet samba-ad-dc; then
systemctl kill --kill-who all --signal=SIGHUP samba-ad-dc
elif [ -f /run/samba/samba.pid ]; then
# This only sends to main pid, See #803924
kill -HUP `cat /run/samba/samba.pid`
fi
endscript
compress
delaycompress
notifempty
}

> Bitte um Meinungen.

MfG
Peter B.

[Marcus Röckrath]

Hallo Peter,

Peter Bäumer wrote:

>> Zudem könnte ich vor dem Rotieren in prerotate samba stoppen und dann in
>> prerotate wieder starten, so dass samba für einen kurzen Moment nicht zur
>> Verfügung steht.
>
> ein Restart des Dienst halte ich für unnötig, da ich davon ausgehen das
> samba mit einem Sig Hub umgehen kann. Also nach den Rotieren die alte
> Logdatei schließt und die neue Logdatei zum schreiben öffnet.

Ich frage mich halt, wieso es nicht nur bei mir Samba-Logs gibt, die
auf .backup ennden und genau zum Rotationszeitpunkt entstanden sind,
während für den gleichen Zeitpunkt ein archiviertes Log fehlt.

> /var/log/samba/log.samba {

Gibt es also auf Debian genau ein /var/log/samba?

Auf eis gibt es zwei verschiedene:

log.samba-bgqd
log.samba-dcerpcd

--
Gruß Marcus
[eisfair-Team]

[Peter Bäumer]

Am 08.08.2023 um 19:37 schrieb Marcus Röckrath:
> Hallo Peter,
>
> Peter Bäumer wrote:
>
>>> Zudem könnte ich vor dem Rotieren in prerotate samba stoppen und dann in
>>> prerotate wieder starten, so dass samba für einen kurzen Moment nicht zur
>>> Verfügung steht.
>>
>> ein Restart des Dienst halte ich für unnötig, da ich davon ausgehen das
>> samba mit einem Sig Hub umgehen kann. Also nach den Rotieren die alte
>> Logdatei schließt und die neue Logdatei zum schreiben öffnet.
>
> Ich frage mich halt, wieso es nicht nur bei mir Samba-Logs gibt, die
> auf .backup ennden und genau zum Rotationszeitpunkt entstanden sind,
> während für den gleichen Zeitpunkt ein archiviertes Log fehlt.

.backup wird vom logrotate angelegt wenn beim rotieren der neue Filename schon vorhanden ist.

ggf. hilft der Befehl es besser zu verstehen
(-d, --debug Don't do anything, just test and print debug messages)

logrotate --debug --force /etc/logrotate.d/samba

>> /var/log/samba/log.samba {
>
> Gibt es also auf Debian genau ein /var/log/samba?

ja/nein
das sieht so aus:
log.
log.172.31.0.110
log.172.31.1.1
log.io
log.neptun
log.nmbd
log.nmbd.1
log.nmbd.2.gz
log.smbd
log.smbd.1
log.smbd.2.gz


kommt durch Debugging/Accounting:

#### Debugging/Accounting ####

# This tells Samba to use a separate log file for each machine
# that connects
log file = /var/log/samba/log.%m

# Cap the size of the individual log files (in KiB).
max log size = 1000

# We want Samba to only log to /var/log/samba/log.{smbd,nmbd}.
# Append syslog@1 if you want important messages to be sent to syslog too.
logging = file


Da muss ich in den Files log. , log.172.31.0.110 , log.172.31.1.1 , log.io , log.neptun mal schauen was ich da zum debuggen habe :(

[Kay Martinen]

Am 08.08.23 um 15:14 schrieb Stefan H.:

>> Habt ihr auch *.backup-Dateien in /var/log?

Vermutlich nicht weil ich den Fileserver noch nicht mal auf systemd
umgezogen hab. Aber...

> Mir würde ein Log im Bedarfsfall und, wenn schon dauerhaftes Log, dann
> ein rotate einmal im Monat reichen. :-)

Mir würde auch ein einzelnes log für den samba reichen. Wenn es denn
unter /var/log/samba läge. Aber hier liegt das komischerweise alles
unter /var/log/ und dazu oft noch weitere für winbindd smbd und nmbd und
dazu oft noch nach dem schema 'log.<ip-Adresse>' und 'log.<stationsname>'

Ich bin jetzt grad zu faul um nach zu sehen ob ich den log/debuglevel
erhöht hätte, erinneren kann ich mich daran nicht.

Aber ich weiß das samba solche separat-logs schon immer schreiben konnte
nach IP oder wins-name der Station. Und ich bin der meinung das der
Übersichtlichkeit halber alle samba-bezüglichen logs auch in dessen
eigenem logordner liegen sollten. In dem aber hier meist große leere
herrscht und AFAIR nur ein core-unterordner liegt den man IMO
bestenfalls beim debugging bräuchte. Wenn ich nicht irre schmeist samba
dort seinen coredump ab wenn er crashen sollte.

Generell sollte m.E. ein zentrales log für samba reichen und je nach
loglevel eben nur komponentenlogs dazu oder eben stations-spezifisches.
Finde grad keine Definitionen dazu und was wiki.samba.org dazu hergibt
ist eher ein Witz aber keine auflistung.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Thomas Bork]

Am 08.08.2023 um 13:07 schrieb Marcus Röckrath:

> Äuffällig, dass die vermutlich beim logrotate-Prozess entstehen, denn ein
> gepacktes samba-log fehlt für den Tag dann.

Nicht vermutlich, sondern ganz sicher. Schon vorhandene Dateinamen
führen zu Fehlern bei Start von logrotate:

nvme # systemctl status logrotate.service
× logrotate.service - Rotate log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static)
Active: failed (Result: exit-code) since Fri 2023-08-11 10:35:23
CEST; 2min 13s ago
TriggeredBy: ● logrotate.timer
Docs: man:logrotate(8)
man:logrotate.conf(5)
Process: 512 ExecStart=/usr/sbin/logrotate-all (code=exited,
status=1/FAILURE)
Main PID: 512 (code=exited, status=1/FAILURE)
CPU: 66ms

Aug 11 10:35:22 nvme systemd[1]: Starting Rotate log files...
Aug 11 10:35:22 nvme logrotate-all[528]: error: destination
/var/log/log.smbd.1 already exists, renaming to
/var/log/log.smbd.1-2023081110.backup
Aug 11 10:35:22 nvme logrotate-all[528]: error: destination
/var/log/log.nmbd.1 already exists, renaming to
/var/log/log.nmbd.1-2023081110.backup
Aug 11 10:35:22 nvme logrotate-all[528]: error: destination
/var/log/log.rpcd_classic.1 already exists, renaming to
/var/log/log.rpcd_classic.1-2023081110.backup
Aug 11 10:35:22 nvme logrotate-all[528]: error: error opening
/var/log/log.rpcd_classic.2.xz: No such file or directory
Aug 11 10:35:23 nvme systemd[1]: logrotate.service: Main process exited,
code=exited, status=1/FAILURE
Aug 11 10:35:23 nvme systemd[1]: logrotate.service: Failed with result
'exit-code'.
Aug 11 10:35:23 nvme systemd[1]: Failed to start Rotate log files.


nvme # ls -l /var/log/* | egrep 'nmbd|smbd|samba|rpcd'
-rw-r--r-- 1 root root 33602 Aug 11 10:42 /var/log/log.nmbd
-rw-r--r-- 1 root root 34734 Aug 11 10:35 /var/log/log.nmbd.1
-rw-r--r-- 1 root root 19281 Aug 7 08:50
/var/log/log.nmbd.1-2023081110.backup
-rw-r--r-- 1 root root 2436 Jul 21 19:53
/var/log/log.nmbd.3.xz
-rw-r--r-- 1 root root 2592 Jul 19 21:33
/var/log/log.nmbd.4.xz
-rw-r--r-- 1 root root 2492 Jul 18 17:00
/var/log/log.nmbd.5.xz
-rw-r--r-- 1 root root 304 Jul 17 11:43
/var/log/log.nmbd.6.xz
-rw-r--r-- 1 root root 812 Jul 6 20:37
/var/log/log.nmbd.7.xz
-rw-r--r-- 1 root root 456 Aug 11 10:35
/var/log/log.rpcd_classic
-rw-r--r-- 1 root root 912 Aug 11 10:35
/var/log/log.rpcd_classic.1
-rw-r--r-- 1 root root 456 Aug 7 08:50
/var/log/log.rpcd_classic.1-2023081110.backup
-rw-r--r-- 1 root root 248 Jul 21 19:53
/var/log/log.rpcd_classic.3.xz
-rw-r--r-- 1 root root 256 Jul 19 21:02
/var/log/log.rpcd_classic.4.xz
-rw-r--r-- 1 root root 1824 Aug 11 10:35
/var/log/log.rpcd_epmapper
-rw-r--r-- 1 root root 248 Jul 21 19:53
/var/log/log.rpcd_epmapper.3.xz
-rw-r--r-- 1 root root 256 Jul 19 21:02
/var/log/log.rpcd_epmapper.4.xz
-rw-r--r-- 1 root root 1824 Aug 11 10:35
/var/log/log.rpcd_fsrvp
-rw-r--r-- 1 root root 248 Jul 21 19:53
/var/log/log.rpcd_fsrvp.3.xz
-rw-r--r-- 1 root root 256 Jul 19 21:02
/var/log/log.rpcd_fsrvp.4.xz
-rw-r--r-- 1 root root 17326 Aug 11 10:36
/var/log/log.rpcd_lsad
-rw-r--r-- 1 root root 912 Jul 21 19:53
/var/log/log.rpcd_lsad.3.xz
-rw-r--r-- 1 root root 1052 Jul 19 21:02
/var/log/log.rpcd_lsad.4.xz
-rw-r--r-- 1 root root 1824 Aug 11 10:35
/var/log/log.rpcd_mdssvc
-rw-r--r-- 1 root root 248 Jul 21 19:53
/var/log/log.rpcd_mdssvc.3.xz
-rw-r--r-- 1 root root 256 Jul 19 21:02
/var/log/log.rpcd_mdssvc.4.xz
-rw-r--r-- 1 root root 1824 Aug 11 10:35
/var/log/log.rpcd_rpcecho
-rw-r--r-- 1 root root 248 Jul 21 19:53
/var/log/log.rpcd_rpcecho.3.xz
-rw-r--r-- 1 root root 256 Jul 19 21:02
/var/log/log.rpcd_rpcecho.4.xz
-rw-r--r-- 1 root root 1824 Aug 11 10:35
/var/log/log.rpcd_spoolss
-rw-r--r-- 1 root root 248 Jul 21 19:53
/var/log/log.rpcd_spoolss.3.xz
-rw-r--r-- 1 root root 256 Jul 19 21:02
/var/log/log.rpcd_spoolss.4.xz
-rw-r--r-- 1 root root 1824 Aug 11 10:35
/var/log/log.rpcd_winreg
-rw-r--r-- 1 root root 248 Jul 21 19:53
/var/log/log.rpcd_winreg.3.xz
-rw-r--r-- 1 root root 256 Jul 19 21:02
/var/log/log.rpcd_winreg.4.xz
-rw-r--r-- 1 root root 0 Jul 19 20:59
/var/log/log.samba-bgqd
-rw-r--r-- 1 root root 0 Jul 30 09:38
/var/log/log.samba-bgqd.1.xz
-rw-r--r-- 1 root root 420 Jul 6 20:14
/var/log/log.samba-bgqd.1.xz.1.xz
-rw-r--r-- 1 root root 7478 Aug 11 10:35
/var/log/log.samba-dcerpcd
-rw-r--r-- 1 root root 800 Jul 21 19:53
/var/log/log.samba-dcerpcd.3.xz
-rw-r--r-- 1 root root 804 Jul 19 21:02
/var/log/log.samba-dcerpcd.4.xz
-rw-r--r-- 1 root root 3371 Aug 11 10:35 /var/log/log.smbd
-rw-r--r-- 1 root root 6992 Aug 11 10:35 /var/log/log.smbd.1
-rw-r--r-- 1 root root 3496 Aug 7 08:50
/var/log/log.smbd.1-2023081110.backup
-rw-r--r-- 1 root root 1144 Jul 21 19:53
/var/log/log.smbd.3.xz
-rw-r--r-- 1 root root 1352 Jul 19 21:33
/var/log/log.smbd.4.xz
-rw-r--r-- 1 root root 1276 Jul 18 17:00
/var/log/log.smbd.5.xz
-rw-r--r-- 1 root root 240 Jul 17 11:42
/var/log/log.smbd.6.xz
-rw-r--r-- 1 root root 432 Jul 6 20:36
/var/log/log.smbd.7.xz
drwx------ 2 root root 4096 Nov 28 2022 nmbd
drwx------ 2 root root 4096 Jul 18 15:42 rpcd_lsad
drwx------ 2 root root 4096 Nov 28 2022 samba-bgqd
drwx------ 2 root root 4096 Jul 18 15:42 samba-dcerpcd
drwx------ 2 root root 4096 Nov 28 2022 smbd

--
der tom

[Marcus Röckrath]

Hallo Thomas,

Thomas Bork wrote:

>> Äuffällig, dass die vermutlich beim logrotate-Prozess entstehen, denn ein
>> gepacktes samba-log fehlt für den Tag dann.
>
> Nicht vermutlich, sondern ganz sicher. Schon vorhandene Dateinamen
> führen zu Fehlern bei Start von logrotate:
>
> nvme # systemctl status logrotate.service
>

> /var/log/log.smbd.1 already exists, renaming to
> /var/log/log.smbd.1-2023081110.backup

Bei forciertem manuellen Aufrufen von logrotate sind mir gestern auch diese
Meldungen um die Ohren geflogen.

Zudem gibt es Rotationsprobleme, wenn das nummerierte archivierte Logfiles
über der Rotationszahl liegen bzw. in den nummerierten archivierten Logs
Lücken sind.

Zudem fing er da plötzlich an, mit gz statt xz zu archivieren.

Ich werden mit dem kurzfristig erscheinenden Paketupdate alle archivierten
und falsch benamten Logs entfernen müssen.

So hat es heute Nacht bei mir problemlos funktioniert und zwar mit SIGHUP.

Mal sehen, was heute Nacht passiert. Wenn das wieder glatt geht, belasse ich
es bei SIPHUP im postrotate, so wie es bisher immer war.

--
Gruß Marcus
[eisfair-Team]

[Kay Martinen]

Am 08.08.23 um 13:07 schrieb Marcus Röckrath:

> weil es mit dem letzten Release des samba-Paketes zwei Unschönheiten gibt,
> die aber nicht kritisch sind, möchte ich hier etwas zur Diskussion stellen.
>
> Durch einen kleinen blöden Gedanken/Codefehler, wsammeln die gerade einige
> unnötige Logs iun /var/log an, die ihr an mehrfachen
> <number>.xz.<number>.xz erkennt.
>
> Die räume ich mit dem nächsten Update ab.

> Zunächst frage ich mich, ob überhaupt ein tägliches Rotieren nötig ist, denn
> die Logs sind hier sehr klein. Mindestens weekly hielte ich für besser.

Hab ich; auch auf einem anderen; auf monthly.

> Bitte um Meinungen.
>

/var/log/cores/ ist offenbar für samba vorgesehen, dem inhalt nach. Das
hätte ich pers. lieber als /var/log/samba. Da steht aber kaum was
sondern eher im hauptlog dir. Besser fände ich wenn man das
zusammenführt. Samba logs nur in /var/log/smb/ z.b.

log.IPxyz oder log.stationsname finde ich total unintuitiv. M.E. haben
logdateien die lesbar sind die endung .log zu haben. Und nicht sonst
außer sie sind bereits rotiert und komprimiert.

testparm listet keine logdatei location auf. In der syslog Einrichtung
ist auch nichts und IMO auch in der samba-konfig nicht.

WO zum Geier kann man denn dem Samba beim Eis das logdir und format
vorgeben? Ich weiß das es geht/ging aber ich finde es nicht.

[Marcus Röckrath]

Hallo Kay,

Kay Martinen wrote:

>> Zunächst frage ich mich, ob überhaupt ein tägliches Rotieren nötig ist,
>> denn die Logs sind hier sehr klein. Mindestens weekly hielte ich für
>> besser.
>
> Hab ich; auch auf einem anderen; auf monthly.

Ist im aktuellen Paket erstmal auf weekly hoch geschraubt, mal sehen,
vielleicht gehe ich später mal auf monthly.

> /var/log/cores/ ist offenbar für samba vorgesehen, dem inhalt nach. Das
> hätte ich pers. lieber als /var/log/samba. Da steht aber kaum was
> sondern eher im hauptlog dir. Besser fände ich wenn man das
> zusammenführt. Samba logs nur in /var/log/smb/ z.b.
>
> log.IPxyz oder log.stationsname finde ich total unintuitiv. M.E. haben
> logdateien die lesbar sind die endung .log zu haben. Und nicht sonst
> außer sie sind bereits rotiert und komprimiert.

Wieso müssen logfile auf .log enden?

Dafür gibt es keinerlei Festlegung, das wäre höchstens persönliche Vorliebe.

In /var/log gibt es z. B. auch die messages, also ohne jede Endung.

Wie schon Thomas benutze ich im Kompilierprozess die Defaults der Source,
also der Machen von Samba. Ich sehe auch keinen Grund, hier vom
vorgesehenen Standards abzuweichen.

Einzig das Basisverzeichnis der Logs wird hier mit /var/log festgelegt.

Was z. B. eine Änderung auf /var/log/samba bewirkt, müsste man schauen. Ich
vermute dass das, was gerade in /var/log liegt, dann ich /var/log/samba zu
Liegen kommt und aus /var/log/cores /var/log/samba/cores wird.

Das könnte ich ausprobieren.

> testparm listet keine logdatei location auf. In der syslog Einrichtung
> ist auch nichts und IMO auch in der samba-konfig nicht.
>
> WO zum Geier kann man denn dem Samba beim Eis das logdir und format
> vorgeben? Ich weiß das es geht/ging aber ich finde es nicht.

Wie macht das Debian, SuSE, ....

--
Gruß Marcus
[eisfair-Team]