Auch wenn der nmbd nur wenige Kilobyte groß ist, erstellt der nmbd ein Log wodurch der Speicher belegt wird.
Ich will ja den Leuten von AVM nicht zu nahe treten und der nmbd hat tatsächlich einen "memory footprint", der bei wirklich voll ausgelasteter Box (die 7390 hat eben bei nur 108 MB verfügbarem RAM auch den größten Funktionsumfang, die 7490 mit demselben Angebot hat dann bereits 256 MB eingebaut) der entscheidende "Kick" sein könnte, um sie über die Klippe des "zu wenig freier Hauptspeicher" zu schubsen. Andererseits ist inzwischen auch der telnetd nicht mehr aktiv (VMPeak 1304 kB, VmHWM 332 kB) und auch sonst wird wohl eine Box nur sehr selten wirklich
jedes Feature ausreizen (z.B. braucht es den l2tpv3d eben nur, wenn die Box mit einem WLAN-Repeater zu tun hat) - es wird aber geradezu blindwütig alles gestartet, was geht. Auch der Prozess mit dem "tail"-Kommando für die /nohup.out (VMSize ebenfalls 1,3 MB) ist auf einer Produktiv-Box irgendwie vollkommen überflüssig und wohl nur ein Blinddarm der Produktionstests.
Wenn man sich auf der anderen Seite ansieht, was einige Leute an Zusatzsoftware auf ihrer Box laufen lassen (können), ist da auch noch Luft nach oben. OpenVPN dürfte der Box weit mehr abverlangen als der nmbd. Das war eben ein bequemer Weg, einen praktisch ständig laufenden Daemon (der Start über den inetd macht bei dem nun nicht wirklich Sinn, dafür ist in einem LAN einfach zuviel los auf UDP 137) aus dem System zu entfernen.
Auch muß die Idee mit der "Log-Datei" irgendwie falsch von den Programmierern zum Support übermittelt worden sein ... wie man leicht feststellen kann. Irgendwie fehlt die Ansage, welche Log-Datei das sein soll ...
nmbd per Telnet-Session vom NAND-Storage gestartet und auf einem Windows-PC die Netzwerk-Umgebung aktualisiert, damit der nmbd auch schon mal auf einen Broadcast-Request reagieren mußte - alles auf einer unmodifizierten 84.06.23:
Code:
# /var/media/ftp/bin/busybox lsof | grep nmbd
1114 /var/media/ftp/nmbd /dev/null
1114 /var/media/ftp/nmbd /dev/null
1114 /var/media/ftp/nmbd /var/tmp/samba/var/log.nmbd
1114 /var/media/ftp/nmbd /var/tmp/samba/var/log.nmbd
1114 /var/media/ftp/nmbd /var/tmp/samba/var/locks/nmbd.pid
1114 /var/media/ftp/nmbd /var/tmp/samba/var/locks/messages.tdb
1114 /var/media/ftp/nmbd socket:[3856]
1114 /var/media/ftp/nmbd socket:[3857]
1114 /var/media/ftp/nmbd socket:[3859]
1114 /var/media/ftp/nmbd socket:[3860]
1114 /var/media/ftp/nmbd pipe:[3861]
1114 /var/media/ftp/nmbd pipe:[3861]
Wollen wir hoffen, dass AVM das Logfile abschalten, oder auf den USB-Stick umlenken kann.
Wollen wir mal hoffen, daß sie das Logfile oder auch die richtige Option bei der Kompilierung finden, irgendwie wird bei der Version, die mit der 06.20 ausgeliefert wurde, auch so nichts protokolliert:
Code:
diff -Naur include/debug.h ../7390-GPL/samba-3.0.37/source/include/debug.h
--- include/debug.h 2009-09-30 14:21:56.000000000 +0200
+++ ../7390-GPL/samba-3.0.37/source/include/debug.h 2012-09-12 17:54:53.000000000 +0200
@@ -162,6 +162,22 @@
* will remove the extra conditional test.
*/
+#ifndef SAMBA_DEBUG // AVM
+
+#define DEBUGLVL( level ) (0)
+#define DEBUGLVLC( dbgc_class, level ) (0)
+#define DEBUG( level, body ) (0)
+#define DEBUGADD( level, body ) (0)
+#define DEBUGC( dbgc_class, level, body ) (0)
+#define DEBUGADDC( dbgc_class, level, body ) (0)
+
+#define Log(x) while(0)
+
+#else
+
+#define Log(x) _fLog x
+void _fLog(char *fmt, ...);
+
#define DEBUGLVL( level ) \
( ((level) <= MAX_DEBUG_LEVEL) && \
((DEBUGLEVEL_CLASS[ DBGC_CLASS ] >= (level))|| \
@@ -208,6 +224,9 @@
DEBUGLEVEL_CLASS[ DBGC_ALL ] >= (level)) ) \
&& (dbgtext body) )
+#endif /* AR7 */
+
+
/* Print a separator to the debug log. */
#define DEBUGSEP(level)\
DEBUG((level),("===============================================================\n"))
diff -Naur lib/debug.c ../7390-GPL/samba-3.0.37/source/lib/debug.c
--- lib/debug.c 2009-09-30 14:21:56.000000000 +0200
+++ ../7390-GPL/samba-3.0.37/source/lib/debug.c 2012-09-12 17:54:53.000000000 +0200
@@ -22,6 +22,28 @@
#include "includes.h"
+#if 0
+#ifdef SAMBA_DEBUG
+#define Log(x) _Log x
+
+#include <stdarg.h>
+static void _Log(char *fmt, ...) {
+
[COLOR="#FF0000"]+ FILE * fp = fopen("/dev/console", "w");[/COLOR]
+ if (fp) {
+ va_arg ap;
+ va_start(ap, fmt);
+ vfprintf(fp, fmt, ap);
+ fprintf(fp, "\n");
+ va_end(ap);
+ fclose(fp);
+ }
+}
+#else
+#define Log(x) while(0)
+#endif
+#endif
+
/* -------------------------------------------------------------------------- **
* Defines...
*
@@ -419,6 +441,7 @@
DEBUGLEVEL_CLASS[DBGC_ALL] = atoi(params[0]);
DEBUGLEVEL_CLASS_ISSET[DBGC_ALL] = True;
i = 1; /* start processing at the next params */
+Log(("Overall Debug Level set to %d", DEBUGLEVEL_CLASS[DBGC_ALL]));
} else {
i = 0; /* DBGC_ALL not specified OR class name was included */
}
@@ -430,6 +453,7 @@
((ndx = debug_lookup_classname(class_name)) != -1)) {
DEBUGLEVEL_CLASS[ndx] = atoi(class_level);
DEBUGLEVEL_CLASS_ISSET[ndx] = True;
+Log(("Debug Level of class %s set to %d", class_name, DEBUGLEVEL_CLASS[ndx]));
} else {
DEBUG(0,("debug_parse_params: unrecognized debug class name or format [%s]\n", params[i]));
return False;
@@ -452,16 +476,20 @@
/* Just in case */
debug_init();
- if (AllowDebugChange == False)
+ if (AllowDebugChange == False) {
+Log(("debug_parse_levels Change not allowed"));
return True;
+ }
params = str_list_make(params_str, NULL);
if (debug_parse_params(params)) {
+Log(("debug_parse_levels debug_parse_params True"));
debug_dump_status(5);
str_list_free(¶ms);
return True;
} else {
+Log(("debug_parse_levels debug_parse_params False"));
str_list_free(¶ms);
return False;
}
Ausgehend davon, daß /dev/console schon mal
nichtnie bei den offenen Dateien des nmbd oben auftaucht (und auch nichts auf /dev/console protokolliert wird, der FD ist ja nur für die Dauer des Aufrufs benutzt), ist da wohl nicht mit "SAMBA_DEBUG" übersetzt worden und mit welcher Rasanz die oben gezeigten offenen Dateien des nmbd wachsen, kann jeder mit einer alten Firmware (oder einem von Hand gestarteten nmbd) ja auch selbst in einem Langzeittest ermitteln (auch ob da irgendwie in interne Buffer protokolliert wird, die nur nicht geflusht werden, dann müßte die VmSize ja im Laufe der Zeit wachsen).
So sieht es jedenfalls nach ca. 30 Minuten beim oben beobachteten nmbd aus:
Code:
# cat /proc/$(pidof nmbd)/status
Name: nmbd
State: S (sleeping)
Tgid: 1114
Pid: 1114
PPid: 1
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
NetMark: 0
FDSize: 32
Groups:
VmPeak: 2704 kB
VmSize: 2704 kB
VmLck: 0 kB
VmHWM: 1260 kB
VmRSS: 1260 kB
VmData: 872 kB
VmStk: 88 kB
VmExe: 76 kB
VmLib: 1572 kB
VmPTE: 16 kB
Threads: 1
SigQ: 0/475
SigPnd: 00000000000000000000000000000000
ShdPnd: 00000000000000000000000000000000
SigBlk: 00000000000000000000000000011080
SigIgn: 00000000000000000000000000000000
SigCgt: 0000000000000000000000018000c621
CapInh: 0000000000000000
CapPrm: fffffffffffffeff
CapEff: fffffffffffffeff
CapBnd: fffffffffffffeff
voluntary_ctxt_switches: 227
nonvoluntary_ctxt_switches: 4
Ich lasse das jetzt mal ein paar Tage laufen (5 Windows-PCs im Netzwerk, die oft genug auf Port 137 Traffic verursachen, neben weiteren Samba-Instanzen (Vu+ Ultimo, 2x openSuSE, 1xKodiBuntu), die auch ab und an mal nachfragen ... Kodi sogar ständig wg. der Suche nach Media-Servern mit SMB-Zugriff. Die Größte der /var/tmp/samba/var/log.nmbd ist jedenfalls schon so lange ich das FRITZ!OS kenne immer genau 0 Byte, manchmal auch 10% mehr, aber eher selten.
Da stellt sich dann nun wieder die Frage, welche Datei das vom Support erwähnte Log eigentlich sein soll ... wie gesagt, den Hauptspeicherbedarf kann man nicht wegdiskutieren, der ist leider vorhanden, da die Samba-Quellen da keine Beschränkung des nmbd auf "local responder" vorsehen und dann immer das komplette Paket (master browser, elections, usw. - einfach mal in source/nmbd/*.c schauen in den Samba-Quellen) genommen werden muß. Das erfordert also wirklich "Handarbeit", da einen kleinen und handlichen Responder zu erzeugen, der nur genau auf die Broadcast-Anfragen des Windows-Netzwerks seine Anwesenheit bekanntgibt und sich ansonsten aus dem Windows-Netzwerk heraushält.
Aber bei den "wachsenden Log-Dateien" ist so gar keine dabei, die vom nmbd benutzt wird:
Code:
# find /var -xdev -exec stat -c "%s %n" '{}' \; | sort -nr | sed -n -e "1,50p"
211980 /var/.voipd_statsimple
123584 /var/.dsld_statsimple
25251 /var/tmp/wlan_dynamic.cfg
17352 /var/tmp/samba/var/locks/sessionid.tdb
16384 /var/.srb_sip
15890 /var/tmp/samba/var/locks/locking.tdb
10789 /var/tmp/tr64desc.xml
9952 /var/tmp/samba/var/locks/connections.tdb
9161 /var/env.cache
9054 /var/post_install
8192 /var/dsl/echotest/calibrate.bin
8192 /var/.srb_l2tpv3
6628 /var/tmp/samba/private/secrets.tdb
6062 /var/config.def
5258 /var/tmp/upnpwebsrv/MediaServerConnectionManager.xml
4096 /var/.srb_dnsd
3932 /var/tmp/samba/var/locks/unexpected.tdb
3173 /var/tmp/MediaServerDevDesc.xml
3146 /var/tmp/igddesc.xml
2708 /var/tmp/MediaServerDevDesc-xbox.xml
2480 /var/tmp/samba/var/locks/brlock.tdb
2184 /var/.SHMUSBDEVICES
2048 /var/media/ftp
2034 /var/tmp/upnpwebsrv/MediaReceiverRegistrar.xml
1842 /var/tmp/samba/var/locks/share_info.tdb
1842 /var/tmp/samba/var/locks/group_mapping.tdb
1842 /var/tmp/samba/var/locks/account_policy.tdb
1520 /var/tmp
1298 /var/tmp/websrv_ssl_cert.pem
1255 /var/tmp/wlan_roles
1204 /var/tmp/phonebook.xml
1099 /var/tmp/fboxdesc.xml
1076 /var/tmp/l2tpv3.xml
1000 /var/flash
968 /var/tmp/usbdevices
966 /var/env
960 /var
930 /var/wan-wan.tc
731 /var/tmp/dnsddebug.txt
696 /var/tmp/samba/var/locks/notify.tdb
696 /var/tmp/samba/var/locks/messages.tdb
696 /var/tmp/samba/var/locks/gencache.tdb
628 /var/tmp/samba/lib/smb.conf
618 /var/tmp/cloudcds.log
596 /var/.umtsstat
566 /var/tmp/wland_support.log
560 /var/tmp/csem
527 /var/tmp/passwd
477 /var/tmp/ddnslog_1.txt
418 /var/tmp/load_userman_mod.sh
Ich kann die Einschätzung, daß die Begründung mit dem Logfile plausibler wäre, also nur begrenzt teilen ... vielleicht findet ja jemand diese Log-Datei (oder auch deren InMemory-Buffer, wenn schon nichts "in der Datei" landet) und kann mir erklären, welches File der Support dabei im Auge hat. Da müßte ja dann nach einiger Zeit der Speicherbedarf des nmbd wachsen und nach einem manuellen Neustart des nmbd signifikant sinken, wenn das tatsächlich ein Logfile des nmbd sein sollte (das nicht fortgeschrieben wird, aber ein Fortschreiben müßte man ja dann wieder im Filesystem (und sei es im tmpfs) feststellen können), das da solche Probleme verursacht. Wenn es eine fortgeschriebene Protokollierung in irgendein allgemeines Log ist (deshalb das "diff" für die debug-Funktion des nmbd oben), dann müßte das ja auch irgendwo zu sehen sein (/dev/debug ist es jedenfalls auch nicht und was in /dev/console passiert, sieht man in der ersten Telnet-Session). Auch die Kernel-Messages (dmesg) wachsen nicht signifikant, wenn der nmbd aktiv ist.
Eventuell wachsen ja wirklich irgendwelche Log-Dateien, wenn die FRITZ!Box bei einer Wahl zum "master browser" auserkoren wird (auch das ist eine eher ungewöhnliche Situation, bei einer 3.0.37-Samba-Installation). Das ist aber auch ganz einfach durch
passende Einstellungen in der smb.conf zu verhindern ... daran dürfte es nun erst recht nicht scheitern.
