Hallo Liste,
nach dem der Fileserver gestern abgestürzt war, will Samba nicht mehr. An der Konfiguration hat sich nichts verändert. Einfach ausschalten, einschalten, kaputt.
Hat schon mal so was gesehen und könnte einen Tipp geben, wie man das Samba schnellst möglich wiederbeleben kann? <------------------><8---------------------------->
Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(40) Jul 15 09:42:32 mlrfs1b smbd[7486]: =============================================================== Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(41) Jul 15 09:42:32 mlrfs1b smbd[7486]: INTERNAL ERROR: Signal 6 in pid 7486 (3.2.7-11.20.1-2373-SUSE-CODE11) Jul 15 09:42:32 mlrfs1b smbd[7486]: Please read the Trouble-Shooting section of the Samba3-HOWTO Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(43) Jul 15 09:42:32 mlrfs1b smbd[7486]: Jul 15 09:42:32 mlrfs1b smbd[7486]: From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(44) Jul 15 09:42:32 mlrfs1b smbd[7486]: =============================================================== Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/util.c:smb_panic(1671) Jul 15 09:42:32 mlrfs1b smbd[7486]: PANIC (pid 7486): internal error Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/util.c:log_stack_trace(1775) Jul 15 09:42:32 mlrfs1b smbd[7486]: BACKTRACE: 11 stack frames: Jul 15 09:42:32 mlrfs1b smbd[7486]: #0 /usr/sbin/smbd(log_stack_trace+0x1a) [0x7f2e06edbf9a] Jul 15 09:42:32 mlrfs1b smbd[7486]: #1 /usr/sbin/smbd(smb_panic+0x1f) [0x7f2e06edc06f] Jul 15 09:42:32 mlrfs1b smbd[7486]: #2 /usr/sbin/smbd [0x7f2e06ec6f20] Jul 15 09:42:32 mlrfs1b smbd[7486]: #3 /lib64/libpthread.so.0 [0x7f2e04a85a90] Jul 15 09:42:32 mlrfs1b smbd[7486]: #4 /lib64/libc.so.6(gsignal+0x35) [0x7f2e0305b645] Jul 15 09:42:32 mlrfs1b smbd[7486]: #5 /lib64/libc.so.6(abort+0x183) [0x7f2e0305cc33] Jul 15 09:42:32 mlrfs1b smbd[7486]: #6 /usr/sbin/smbd(talloc_free+0x1f1) [0x7f2e06eaea01] Jul 15 09:42:32 mlrfs1b smbd[7486]: #7 /usr/sbin/smbd(init_guest_info+0xc8) [0x7f2e06f24c28] Jul 15 09:42:32 mlrfs1b smbd[7486]: #8 /usr/sbin/smbd(main+0xa6a) [0x7f2e070d583a] Jul 15 09:42:32 mlrfs1b smbd[7486]: #9 /lib64/libc.so.6(__libc_start_main+0xe6) [0x7f2e03047586] Jul 15 09:42:32 mlrfs1b smbd[7486]: #10 /usr/sbin/smbd [0x7f2e06cdbe69] Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:dump_core(201) Jul 15 09:42:32 mlrfs1b smbd[7486]: dumping core in /var/log/samba/cores/smbd Jul 15 09:42:32 mlrfs1b smbd[7486]: <------------------><8---------------------------->
Jens
Jens Weiße jens.weisse@gmx.net (Do 15 Jul 2010 09:49:52 CEST):
Hallo Liste,
nach dem der Fileserver gestern abgestürzt war, will Samba nicht mehr. An der Konfiguration hat sich nichts verändert. Einfach ausschalten, einschalten, kaputt.
Einfach mal so ins Blaue: wir hatten schon mal Probleme, weil diese diversen TDB-Files, die Samba nutzt, kaputt waren. Denn *eigentlich* ist das ja das einzige, was von so einem Absturz betroffen sein könnte (wenn man mal davon ausgeht, daß nicht z.B. kaputter Speicher auch Grund für den Absturz war).
(Aber um ehrlich zu sein, so schlimm, wie bei Dir, habe ich das noch nicht gesehen.)
Vielleicht hilft's also, diese TDB-Files und diese ganze andere "Ameisenkacke" aus /var/run/samba oder /var/lib/samba oder /var/spool/samba, oder wo immer der das hinwirft…, mal wegzuräumen. Notfalls auch mal temporär diese "secrets".
Am Donnerstag 15 Juli 2010 schrieb Heiko Schlittermann:
Jens Weiße jens.weisse@gmx.net (Do 15 Jul 2010 09:49:52 CEST):
Hallo Liste,
nach dem der Fileserver gestern abgestürzt war, will Samba nicht mehr. An der Konfiguration hat sich nichts verändert. Einfach ausschalten, einschalten, kaputt.
Einfach mal so ins Blaue: wir hatten schon mal Probleme, weil diese diversen TDB-Files, die Samba nutzt, kaputt waren. Denn *eigentlich* ist das ja das einzige, was von so einem Absturz betroffen sein könnte (wenn man mal davon ausgeht, daß nicht z.B. kaputter Speicher auch Grund für den Absturz war).
Es betrifft zwei Server. Die Samba Konfiguration und das /var/lib/samba liegen auf einem drbd-Device. Der Speicher in einem Rechner kann eigentlich nicht das Problem sein. Die Panic tritt auch auf beiden Rechner auf.
(Aber um ehrlich zu sein, so schlimm, wie bei Dir, habe ich das noch nicht gesehen.)
Danke. Das baut einen wieder auf ;-)
Vielleicht hilft's also, diese TDB-Files und diese ganze andere "Ameisenkacke" aus /var/run/samba oder /var/lib/samba oder /var/spool/samba, oder wo immer der das hinwirft…, mal wegzuräumen. Notfalls auch mal temporär diese "secrets".
Das Zeug in /var/lib/samba habe ich mal komplett gelöscht. Viele Dateien legt beim abstürzen wieder an. Löscht man die secrets.tdb beschwert sich LDAP über das fehlende Passwort. Aber nach dem setzen des LDAP-Passworts (smbpasswd -W) bekommt man wieder die coredumps. Hab zur Probe soeben noch die Verzeichnise /etc/samba und /var/lib/samba aus dem Backup (24h vorm Absturz) gekratzt, aber er stürzt beharrlich ab.
Ciao
Jens
In response to Jens Weiße :
Hallo Liste,
nach dem der Fileserver gestern abgestürzt war, will Samba nicht mehr. An der Konfiguration hat sich nichts verändert. Einfach ausschalten, einschalten, kaputt.
Hat schon mal so was gesehen und könnte einen Tipp geben, wie man das Samba schnellst möglich wiederbeleben kann? <------------------><8---------------------------->
Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(40) Jul 15 09:42:32 mlrfs1b smbd[7486]: =============================================================== Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(41) Jul 15 09:42:32 mlrfs1b smbd[7486]: INTERNAL ERROR: Signal 6 in pid 7486
Das mal in Google gekippt? Da kommt u.a. http://www.linuxforums.org/forum/servers/10646-samba-internal-error-signal-6...
Andreas, viel Glück wünschend ...
Am Donnerstag 15 Juli 2010 schrieb A. Kretschmer:
In response to Jens Weiße :
Hallo Liste,
nach dem der Fileserver gestern abgestürzt war, will Samba nicht mehr. An der Konfiguration hat sich nichts verändert. Einfach ausschalten, einschalten, kaputt.
Hat schon mal so was gesehen und könnte einen Tipp geben, wie man das Samba schnellst möglich wiederbeleben kann? <------------------><8---------------------------->
Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(40) Jul 15 09:42:32 mlrfs1b smbd[7486]: =============================================================== Jul 15 09:42:32 mlrfs1b smbd[7486]: [2010/07/15 09:42:32, 0] lib/fault.c:fault_report(41) Jul 15 09:42:32 mlrfs1b smbd[7486]: INTERNAL ERROR: Signal 6 in pid 7486
Das mal in Google gekippt?
von gestern 14 bis 23 Uhr und heute seid 8. Dieses Signal 6 ist der * der Fehlermeldungen bei Samba. Da bekommt man alles. Von vorhandenem pid-file, kaputten LDAP bis ... . Unterscheiden tun sich die Fehler anscheinend immer nur in den Zeilen drunter.
Andreas, viel Glück wünschend ...
Danke. Kann man gut gebrauchen.
Moin *,
das samba stürzt auf dem Fileserver immer noch ab. Man ist ja kreativ und probiert Plan-B. Auf einem anderen Rechner läuft nun Samba und die Verzeichnisse sind per NFS gemounted. Samba muss nun die gemounteten Verzeichnisse breit streuen. Anscheinend gibt es dabei ein Problem beim "lock" von Dateien.
Die Benutzeranmeldung (Benutzername+Passwort) funktioniert. Windows zeigt die die Dateiberechtigungen auch korrekt an. Will man nun ein Datei z.B. in Excel öffnen, dann wird diese als "Wird vom Benutzer xyz verwendet ..." gemeldet. Man kann die Dateien nur schreibgeschützt öffnen und unter einem anderen Namen wieder abspeichern. Die neue Datei ist dann aber wieder "Schreibgeschützt"
Falls jemand Erfahrungen mit Samba auf NFS-Client hat, dann bitte melden.
Jens
<-----------------------------------------------------------> # auf dem Fileserver (Bitte nicht schlagen. Es ist NFSv3) root@fs1# cat /etc/exports /home/lft 141.30.156.117(rw,no_root_squash,sync)
<-----------------------------------------------------------> # auf dem NFS-Client und aktuellem Samba-Server root@fs1# cat /etc/fstab fs1:/home/lft /mnt/lft nfs rw,bg,hard,intr,nosuid,rsize=8192,wsize=8192,timeo=14 0 0
<-----------------------------------------------------------> # Und im log vom Samba findet sich dann folgendes (log level=10) smbd/trans2.c:2189(call_trans2findfirst) SMBtrans2 mask=Streubig_Uebersicht_Belegarbeiten.xls directory=Institut/Studienarbeiten dirtype=22 numentries=1 smbd/mangle_hash2.c:613(hash2_name_to_8_3) hash2_name_to_8_3: Streubig_Uebersicht_Belegarbeiten.xls -> 63814075 -> SRLXCV~P.XLS (cache=1) lib/util_sock.c:789(read_smb_length_return_keepalive) got smb length of 71 smbd/process.c:1456(process_smb) got message type 0x0 of len 0x47 smbd/process.c:1459(process_smb) Transaction 2543 of length 75 (0 toread) lib/util.c:632(show_msg) [...] smbd/process.c:1273(switch_message) switch message SMBlockingX (pid 28748) conn 0x7f2ca8dcca40 smbd/uid.c:256(change_to_user) change_to_user: Skipping user change - already user smbd/reply.c:7045(reply_lockingX) reply_lockingX: unlock start=2147483539, len=1 for pid 65279, file Institut/Studienarbeiten/Streubig_Uebersicht_Belegarbeiten.xls locking/locking.c:311(do_unlock) do_unlock: unlock start=2147483539 len=1 requested for fnum 4677 file Institut/Studienarbeiten/Streubig_Uebersicht_Belegarbeiten.xls lib/dbwrap_tdb.c:100(db_tdb_fetch_locked) Locking key 14000000000000000B00 lib/dbwrap_tdb.c:129(db_tdb_fetch_locked) Allocated locked data 0x0x7f2ca8e03900 locking/brlock.c:1849(brl_get_locks_internal) brl_get_locks_internal: 1 current locks on file_id 14:6c3000b:0 locking/brlock.c:48(print_lock_struct) [0]: smbpid = 65279, tid = 3, pid = 28748, start = 2147483539, size = 1, fnum = 4677, WRITE WINDOWS_LOCK locking/posix.c:1083(release_posix_lock_windows_flavour) release_posix_lock_windows_flavour: File Institut/Studienarbeiten/Streubig_Uebersicht_Belegarbeiten.xls, offset = 2147483539, count = 1 locking/posix.c:463(reduce_windows_lock_ref_count) reduce_windows_lock_ref_count for file now Institut/Studienarbeiten/Streubig_Uebersicht_Belegarbeiten.xls = 0 locking/posix.c:172(posix_lock_in_range) posix_lock_in_range: offset_out = 2147483539, count_out = 1 locking/posix.c:722(posix_lock_list) posix_lock_list: curr: start=2147483539,size=1 locking/posix.c:1165(release_posix_lock_windows_flavour) release_posix_lock_windows_flavour: Real unlock: offset = 2147483539, count = 1 locking/posix.c:189(posix_fcntl_lock) posix_fcntl_lock 32 6 2147483539 1 2 ../lib/util/util.c:243(fcntl_lock) fcntl_lock 32 6 2147483539 1 2 ../lib/util/util.c:278(fcntl_lock) fcntl_lock: Lock call successful locking/posix.c:219(posix_fcntl_lock) posix_fcntl_lock: Lock call successful lib/dbwrap_tdb.c:42(db_tdb_record_destr) Unlocking key 14000000000000000B00 smbd/reply.c:7055(reply_lockingX) reply_lockingX: unlock returned NT_STATUS_OK smbd/reply.c:7243(reply_lockingX) lockingX fnum=4677 type=16 num_locks=0 num_ulocks=1 lib/util_sock.c:789(read_smb_length_return_keepalive) got smb length of 41 smbd/process.c:1456(process_smb) got message type 0x0 of len 0x29 smbd/process.c:1459(process_smb) Transaction 2544 of length 45 (0 toread) lib/util.c:632(show_msg) [...] smbd/process.c:1273(switch_message) switch message SMBclose (pid 28748) conn 0x7f2ca8dcca40 smbd/uid.c:256(change_to_user) change_to_user: Skipping user change - already user smbd/reply.c:4483(reply_close) close fd=32 fnum=4677 (numopen=3) smbd/close.c:454(set_close_write_time) close_write_time: Sun Feb 7 07:28:15 2106 lib/dbwrap_tdb.c:100(db_tdb_fetch_locked) Locking key 14000000000000000B00 lib/dbwrap_tdb.c:129(db_tdb_fetch_locked) Allocated locked data 0x0x7f2ca8e03920 locking/locking.c:552(parse_share_modes) parse_share_modes: delete_on_close: 0, owrt: Mo 04 Jan 2010 08:36:37 CET CET, cwrt: Do 01 Jan 1970 01:00:00 CET CET, tok: 0, num_share_modes: 1 locking/locking.c:649(parse_share_modes) parse_share_modes: share_mode_entry[0]: pid = 28748, share_access = 0x3, private_options = 0x40, access_mask = 0x20089, mid = 0x0, type= 0x0, gen_id = 464, uid = 21113, flags = 0, file_id 14:6c3000b:0 lib/dbwrap_tdb.c:42(db_tdb_record_destr) Unlocking key 14000000000000000B00 locking/posix.c:495(get_windows_lock_ref_count) get_windows_lock_count for file Institut/Studienarbeiten/Streubig_Uebersicht_Belegarbeiten.xls = 0
[... Datei öffnen im Dialog abgebrochen ...] locking/posix.c:521(delete_windows_lock_ref_count) delete_windows_lock_ref_count for file Institut/Studienarbeiten/Streubig_Uebersicht_Belegarbeiten.xls smbd/close.c:612(close_normal_file) weisse closed file Institut/Studienarbeiten/Streubig_Uebersicht_Belegarbeiten.xls (numopen=2) NT_STATUS_OK smbd/files.c:476(file_free) freed files structure 4677 (2 used) lib/util.c:632(show_msg) lib/util.c:642(show_msg)
lug-dd@mailman.schlittermann.de
-
A. Kretschmer -
Heiko Schlittermann -
Jens Weiße