[gelöst] SAMBA startet nicht

[hermann72pb]

Ich hatte gestern für meine 7390 den aktuellen Trunk generiert. Seitdem startet meine SAMBA nicht mehr.
Box: 7390
AVM: 84.06.23 rev29808; FREETZ: devel-13011; SAMBA: 3.6

console

root@BOX:/var/mod/root# /etc/init.d/rc.smbd start
Starting Samba-smbd ... done.
root@BOX:/var/mod/root# /etc/init.d/rc.smbd status
stopped
root@BOX:/var/mod/root# smbd -D -F -S -d 3
Aborted
root@BOX:/var/mod/root# /etc/init.d/rc.samba start
Starting Samba-nmbd ... done.
Starting Samba-smbd ... done.
root@BOX:/var/mod/root# /etc/init.d/rc.samba status
unavailable
root@BOX:/var/mod/root# /etc/init.d/rc.smbd status
stopped
root@BOX:/var/mod/root# /etc/init.d/rc.nmbd status
stopped

Syslog:

Mar 14 10:48:09 BOX daemon.err smbd[9326]: 
Mar 14 10:53:29 BOX daemon.err smbd[9576]:

SAMBA-Option: FREETZ_PACKAGE_SAMBA_MAX_DEBUG_LEVEL=-1

Meine Fragen:
1. Warum sind rc.smbd und rc.nmbd so doof, dass sie nicht erkennen, dass smbd bzw. nmbd nicht durchstarten? Ich würde erwarten, dass sie "failed" zurückliefern.
2. Warum ist smbd nicht so gesprächig (s. syslog). Liegt es an "max debug level"? Kann ich es nachträglich ändern oder muss ich neu kompilieren?
3. Meine Versuche smbd direkt im debugging-Mode zu starten bringen mich auch nicht besonders weiter. Mehr als "aborted" bekomme ich nicht zurück. Gibt es noch weitere Ideen / Vorschläge, wie ich SAMBA dazu bewegen kann, mir etwas mehr zu erzählen? Strace wäre natürlich die beste Methode, aber gäbe es etwas noch bevor man mit strace da tief in die Problematik eintaucht?
4. Gibt es generell Probleme mit der aktuellen Firmware und SAMBA? Ich verfolge letzte Zeit nicht so aktiv die Diskussion hier und im trac, daher kann es sein, dass ich was übersehen hatte...

MfG

 

[make]

War FREETZ_PACKAGE_SAMBA_MAX_DEBUG_LEVEL=-1 nicht die Option, die dir am wenigstens Ausgaben gibt? Ansonsten sollten die Logfiles an der üblichen Stelle angelegt werden, das war /var/log/smdb.log und /var/log/nmdb.log. Bei geeignetem Debug-Level sind die normalerweise auch nicht leer.

Ich hab - ganz selten - mal das Problem, dass nmdb nach einem Reboot nicht startet, allerdings verwende ich noch 3.0.37, der 3.6-Zweig hat bei mir nie zuverlässig mit meinem Client und in Zusammenhang mit großen Dateien funktioniert (Watchdog!).

 

[hermann72pb]

Danke für Hinweise! Ich kompiliere gerade für meine andere Box (7490) und beim menuconfig habe es gesehen mit dem debug_level. Es ist tatsächlich so, dass bei -1 alle debugging-Sachen aus dem binary gelöscht werden zwecks Größe in erster Linie. Ich sehe es aber auch generell so, dass man die Debug-Meldungen von SAMBA ausschalten sollte. Früher hatte ich öfter beobachtet, dass es mit den Meldungen die Logs überfüllt waren. Mit den separaten Logs für SAMBA war mir nicht bewußt. Danke für den Hinweis. Ich hatte sie im Syslog erwartet.
Ich werde mal nun für meine 7490 mit debug_level -1 durchkompilieren. Wenn dort SAMBA auch nicht durchstartet, dann gehe ich in debugging und aktiviere 1000. Und mit der 7390 werde ich es wohl so oder so machen müssen.
Ich vermute mal, dass der Fehler irgendwo in den Einstellungen liegt. Vielleicht Sicherheitseinstellungen mit dieser ewigen Diskussion zwischen share/user oder irgendwas Ähnliches. Schade ist nur, dass rc-Skripte doof sind und die Daemons anscheinend mit -1 so kastriert sind, dass sie kaum mal "a" sagen können.

MfG

EDIT: Nun SAMBA mit debugging erzeugt und auf die Box übertragen, mit "mount -o bind" eingebunden. Jetzt redet SAMBA mit mir endlich:

Mar 15 00:42:23 BOX daemon.err smbd[13727]:   open_sockets_smbd: No sockets available to bind to.
Mar 15 00:42:23 BOX daemon.err smbd[13727]: [2015/03/15 00:42:23.253656,  0] smbd/server_exit.c:184(exit_server_common)
Mar 15 00:42:23 BOX daemon.err smbd[13727]:   ===============================================================
Mar 15 00:42:23 BOX daemon.err smbd[13727]: [2015/03/15 00:42:23.254923,  0] smbd/server_exit.c:186(exit_server_common)
Mar 15 00:42:23 BOX daemon.err smbd[13727]:   Abnormal server exit: open_sockets_smbd() failed
Mar 15 00:42:23 BOX daemon.err smbd[13727]: [2015/03/15 00:42:23.256322,  0] smbd/server_exit.c:187(exit_server_common)
Mar 15 00:42:23 BOX daemon.err smbd[13727]:   ===============================================================
Mar 15 00:42:23 BOX daemon.err smbd[13727]: [2015/03/15 00:42:23.257485,  0] lib/util.c:1271(log_stack_trace)
Mar 15 00:42:23 BOX daemon.err smbd[13727]:   unable to produce a stack trace on this platform
Mar 15 00:42:23 BOX daemon.err smbd[13727]: [2015/03/15 00:42:23.258759,  0] lib/fault.c:372(dump_core)
Mar 15 00:42:23 BOX daemon.err smbd[13727]:   dumping core in /var/log/cores/smbd
Mar 15 00:42:23 BOX daemon.err smbd[13727]:

Allerdings sind es Syslog-Meldungen, in log.smbd steht noch weniger vom Nütlichen:

[2015/03/15 00:42:23,  0] smbd/server.c:1076(smbd_main)
  smbd version 3.6.25 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2011

Ehrlich gesagt, verstehe ich nicht, welche Sockets da fehlen. Ich versuche noch "make clean und distclean". Die 7390 war die Einzige, die durchkompiliert hat, andere brachten bei make ab und ich musste da cleanen.

EDIT 2: Nachdem meine dritte Box 7270 ähnliches Verhalten aufwies, wie die 7390, obwohl dort SAMBA nach dem "clean" und "distclean" kompiliert wurde, bin ich etwas stützig geworden. Der Hinweis mit dem Socket ging schon in die richtige Richtung, obwohl nicht so einfach zu verstehen war. Ich hatte mal die Boxen getauscht und sie hatten andere IPs bekommen. Bei SAMBA wird aber die IP nochmal eingetragen (wofür auch immer). Dort hatte ich die IP natürlich vergessen anzupassen. Wahrscheinlich hat SMBD versucht sich an der anderen Box einen Socket aufzumachen. Wo das genau gescheitert ist, und ob sowas überhaupt möglich ist (anderswo Socket aufzumachen), ist jetzt jetzt auch egal. Hauptsache: Fehler gefunden und beseitigt.
Also, was lernen wir daraus:
1. Option mit debug_level=-1 ist zwar schön für einen produktiven Einsatz, zur Fehlersuche ist sie nicht geeignet.
2. rc.smbd kann keinen Fehler beim Start erkennen. Vielleicht liegt der Fehler schon im smbd-daemon selbst. Weiß ich nicht.
3. Wenn man smbd zum Sprechen bringen will, sollte man mit debug_level=1000 nochmal durchkompilieren. Und zwar egal, ob "Image too big" (war bei mir nicht umsonst so). Hauptsache samba-Binary aus dem "builded" herausfischen, auf die Box bringen und mit "mount -o bind" einbinden.
4. Seine SAMBA-Einstellungen nochmal kritisch hinterfragen und ggf. ändern.