Segmentation fault: Samba spadne po 35 minutách

Segmentation fault: Samba spadne po 35 minutách
« kdy: 16. 09. 2020, 14:38:26 »
Dobrý den,

instalace:
Proxmox 6.2.11  - Turnkey Fileserver - Samba server
systém je aktualizovaný Samba 4.9.5

Vše mám nastavené a funkční, Samba po cca 35 minutách spadne, pokud jí restartuji tak opět běží, v logu je toto:

Kód: [Vybrat]
[2020/09/16 11:13:38.923861,  0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
  *****
 
  Samba name server STORAGE is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.11
 
  *****
[2020/09/16 11:13:38.923982,  0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
  find_domain_master_name_query_fail:
  Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
  Unable to sync browse lists in this workgroup.
[2020/09/16 11:28:46.936402,  0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
  find_domain_master_name_query_fail:
  Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
  Unable to sync browse lists in this workgroup.
free(): corrupted unsorted chunks
[2020/09/16 11:37:26.329862,  0] ../lib/util/fault.c:79(fault_report)
  ===============================================================
[2020/09/16 11:37:26.329892,  0] ../lib/util/fault.c:80(fault_report)
  INTERNAL ERROR: Signal 6 in pid 10891 (4.9.5-Debian)
  Please read the Trouble-Shooting section of the Samba HOWTO
[2020/09/16 11:37:26.329905,  0] ../lib/util/fault.c:82(fault_report)
  ===============================================================
[2020/09/16 11:37:26.329915,  0] ../source3/lib/util.c:816(smb_panic_s3)
  PANIC (pid 10891): internal error
[2020/09/16 11:37:26.330300,  0] ../lib/util/fault.c:261(log_stack_trace)
  BACKTRACE: 13 stack frames:
   #0 /lib/x86_64-linux-gnu/libsamba-util.so.0(log_stack_trace+0x32) [0x7f888e5c88d2]
   #1 /lib/x86_64-linux-gnu/libsmbconf.so.0(smb_panic_s3+0x20) [0x7f888e1e81c0]
   #2 /lib/x86_64-linux-gnu/libsamba-util.so.0(smb_panic+0x2f) [0x7f888e5c89df]
   #3 /lib/x86_64-linux-gnu/libsamba-util.so.0(+0x24c16) [0x7f888e5c8c16]
   #4 /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730) [0x7f888e636730]
   #5 /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b) [0x7f888d8d17bb]
   #6 /lib/x86_64-linux-gnu/libc.so.6(abort+0x121) [0x7f888d8bc535]
   #7 /lib/x86_64-linux-gnu/libc.so.6(+0x79508) [0x7f888d913508]
   #8 /lib/x86_64-linux-gnu/libc.so.6(+0x7fc1a) [0x7f888d919c1a]
   #9 /lib/x86_64-linux-gnu/libc.so.6(+0x818a2) [0x7f888d91b8a2]
   #10 /lib/x86_64-linux-gnu/libc.so.6(+0x84af3) [0x7f888d91eaf3]
   #11 /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fc9) [0x7f888e62bfc9]
   #12 /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f888d9934cf]
[2020/09/16 11:37:26.330360,  0] ../source3/lib/util.c:828(smb_panic_s3)
  smb_panic(): calling panic action [/usr/share/samba/panic-action 10891]
[2020/09/16 11:37:27.116264,  0] ../source3/lib/util.c:836(smb_panic_s3)
  smb_panic(): action returned status 0
[2020/09/16 11:37:27.116320,  0] ../source3/lib/dumpcore.c:315(dump_core)
  dumping core in /var/log/samba/cores/smbd
[2020/09/16 11:43:55.955699,  0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
  find_domain_master_name_query_fail:
  Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
  Unable to sync browse lists in this workgroup.
[2020/09/16 11:58:53.168396,  0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
  find_domain_master_name_query_fail:
  Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
  Unable to sync browse lists in this workgroup.
munmap_chunk(): invalid pointer
[2020/09/16 12:00:26.104780,  0] ../lib/util/fault.c:79(fault_report)
  ===============================================================
[2020/09/16 12:00:26.104825,  0] ../lib/util/fault.c:80(fault_report)
  INTERNAL ERROR: Signal 6 in pid 12640 (4.9.5-Debian)
  Please read the Trouble-Shooting section of the Samba HOWTO
[2020/09/16 12:00:26.104848,  0] ../lib/util/fault.c:82(fault_report)
  ===============================================================
[2020/09/16 12:00:26.104864,  0] ../source3/lib/util.c:816(smb_panic_s3)
  PANIC (pid 12640): internal error
malloc(): invalid size (unsorted)
free(): corrupted unsorted chunks
[2020/09/16 12:04:21.754496,  0] ../lib/util/fault.c:79(fault_report)

Samba konfigurace je vygererovaná z webového rozhraní v TurnKey Fileserver
hlavní část konfigurace:
Kód: [Vybrat]

[global]
netbios name = Storage
add group script = /usr/sbin/groupadd '%g'
pam password change = yes
recycle:exclude_dir = tmp quarantine
delete group script = /usr/sbin/groupdel '%g'
panic action = /usr/share/samba/panic-action %d
restrict anonymous = 2
encrypt passwords = true
security = user
delete user script = /usr/sbin/userdel -r '%u'
recycle:touch = yes
admin users = root
recycle:versions = yes
passwd program = /usr/bin/passwd %u
add user to group script = /usr/sbin/usermod -G '%g' '%u'
syslog = 0
wins support = true
vfs object = recycle
unix password sync = yes
obey pam restrictions = yes
preferred master = yes
max log size = 1000
os level = 20
log file = /var/log/samba/samba.log
server string =
recycle:keeptree = yes
add user script = /usr/sbin/useradd -m '%u' -g users -G users
dns proxy = no
socket options = TCP_NODELAY
passdb backend = tdbsam
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
guest account = nobody


[martin.sync]
writeable = yes
path = /mnt/1/martin.sync


Máte někdo nějaký nápad co s tím?
Takto je to zcela nepoužitelné. Prohledal jsem web a našel jsem nějaké rady na podobné problémy v nastavení
smb.conf , ale nic nepomohlo.

Díky za rady
Martin
« Poslední změna: 17. 09. 2020, 09:21:17 od Petr Krčmář »


Ahoj,

takže jsem se rozhodnul vše přeinstalovat a zatím Samba běží cca 1 hodinu bez pádu.
Zatím jsem nic neaktualizoval.
Mám podezření, že za chybu by mohl moci nesoulad verzí. Server je jen ve vnitřní síti, tak to takto nějakou dobu vydrží než nastuduji jak správně aktualizovat Proxmox a kontejnery.


Martin

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #2 kdy: 21. 09. 2020, 16:58:11 »
Zravím všechny,

Takže nová instalace Proxmox + Turnkey Fileserver bez jakékoliv aktualizace se chová úplně stejně. Doba běhu je někdy delší.
Vyzkoušel jsem do Proxmox místo Turnkey Fileserve (kontejner) jako VM spustit OpenVault media jako file server - bezva se nastavuje - líbí se mi. I v něm Samba často padá.

Už si opravdu nevím rady.

Konfigurace je vždy vytvořená jen naklikáním v nástroji OpenVault nebo Turnkey FileServer bez úprav.  Vizuálně jsou konfigurace OK.

Konfigurace je jednoduchá cca 5 uživatelů a 12 shares.

Provozujete někdo Sambu ve verzi v Debian Buster a běží Vás spolehlivě? Myslím tím průtok dat denně alespoň 20GB po dobu alespoň 10 dnů bez pádu?

Možná je chyba v mých datech, dlouhé názvy a občas jiné kódové stránky. Ale ta data jsem tam byl schopen přes Samba share vždy nahrát. Pády se neopakují na určitých souborech.

Stroj je DELL PowerEdge T110v2 s E3-1270v2 a 4GB ECC RAM, disky SATA WD Enterprice (různé). Vše ostatní běží bez problémů.

Uvítám libovolný nápad i typ na spolehlivé řešení úložiště jako CT nebo VM v Proxmox, který umí smb sdílení.

Díky všem za pomoc.

k3dAR

  • *****
  • 2 838
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #3 kdy: 21. 09. 2020, 17:36:42 »
dival ses do /var/log/samba ?

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #4 kdy: 21. 09. 2020, 17:49:39 »
Ano,  část  logu s pádem je v prvním příspěvku.
To je v kombinaci Proxmox + CT TurnKey FileServer (aktuální verze). 

Ani pomocí googlu jsem nic kloudného nenašel.

V kombinaci Proxmox + VT Openmediavault musím ještě přijít na to jak logování zapnout na dostatečné úrovni a pak uvidím co se děje tam.

Pokud by to běželo tak jsem s možnostmi a chováním naprosto spojen.  Můj starý Dlink NAS-320 dělal běžně uptime 200 dnů bez jediného záseku.

Díky
Martin



Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #5 kdy: 21. 09. 2020, 17:55:47 »
Ahoj, začalo se mi to chovat stejně jako tobě na CentOSu. Ale zatím jsem neměl čas se tomu věnovat.

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #6 kdy: 21. 09. 2020, 19:39:49 »
Ahoj,

v obou problematických systémech je Samba 4.9.5. 
Co je v CentOS?

Martin

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #7 kdy: 21. 09. 2020, 20:08:21 »
4.10.4

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #8 kdy: 21. 09. 2020, 21:13:39 »
ten konkrétní SW neznám, ale obecné možnosti debugování segmentation fault:

po spuštění příkazu

Kód: [Vybrat]
ulimit -c unlimited
se hláška "segmentation fault" změní na "segmentation fault (core dumped)" a člověk z toho vytříská soubor "core", který se dá využít v debuggeru gdb, třeba pro stack trace nebo zjistít místo chyby ve zdrojovém kódu

další možností jsou nástroje strace a ltrace

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #9 kdy: 21. 09. 2020, 23:12:21 »
Jako nejjednodussi me prijde tam dat jinou verzi, kdyz je tam 4.9 tak zkuste 4.8, 4.7 a pod.. treba to co tam mate je nejak vadny a u vas se problem projevuje protoze mate treba klienty s urcitou delkou nazvu stroje a pod :) Rozhodne nemate posledni verzi.. (4.12, resp. 4.13 rc) takze chyby tam byt muzou.

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #10 kdy: 22. 09. 2020, 08:05:07 »
Zkusil bych otestovat hardware, zejména RAM, zda není vadná. Pokud by to byla chyby v softwaru, je divné, že byste se s ní setkal jenom vy. Předpokládám tedy, že jste se díval do release notes novějších verzí, že tam ta vaše chyba není opravená.

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #11 kdy: 22. 09. 2020, 08:48:27 »
Díky za typy,

ram je ECC (a prověřená memtestem) a na stroji běží cca 4 další kontejnery. Nic jiného nepadá.
Zkoumání důvodů je bohužel mimo mé časové možnosti a trochu i aktuální znalosti. Roky jsem to nedělal.

Co se týká aktuání verze Samba, tak to vím, ale nerad opouštím verze z reporozitory distribuce, jsou s tím jen problémy (alespoň to je moje zkušenost). Prošel jsem bugy na Samba foru, ale nic podobného jsem nenašel, ale to nic neznamená.

Můj problém možná vzniká tím, že mám dlouhé názvy souborů a to včetně některých v azbuce a podobně.
Ale neděje se to na konkrétních souborech nebo adresářích, nebo jsem si toho nevšimnul.
Interval padání je nakonec po reinstalaci spíš náhodný a delší než 35 minut, třeba i pár hodin. Ale rozhodně není běh stabilní.

Zatím jsem nasadil jako alternativní úložiště VM s OpenMediaVault, což je Samba stejné verze 4.9.5 a zdá se mi to trochu stabilnější. A rozhodně má lepší nastavování přístupových práv, to je opravdu pěkně udělané a i to funguje.
Takže zatím řešení pomocí TurnKey FileServer odkládám jako nevyřešené.
Pokud OMV bude také často padat, tak přeložím aktuální Sambu a zkusím to znovu v kontejneru.

Všem moc díky za rady.


Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #12 kdy: 22. 09. 2020, 09:16:16 »
Zdravím,

a zkoušel jsi nepoužívat TurnKey kontejnery (mám s nimi osobně špatné zkušenosti ohledně stability a výkonu) ale udělat čistý kontejner a vše nastavit od začátku sám?

Chová se to stejně i když to samé uděláš v KVMku?
Když chceš, dokážeš vše!

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #13 kdy: 22. 09. 2020, 17:31:08 »
Budu to dál zkoumat a dám sem výsledek nebo zajímavá průběžná zjištění.

Ostatní TurnKey contejnery co mám běží spolehlivě, zatím. Ale budu tedy k nim přistupovat s větší obezřetností než jsem si původně myslel.

Re:Segmentation fault: Samba spadne po 35 minutách
« Odpověď #14 kdy: 24. 09. 2020, 22:05:37 »
Ahoj,

takže ve VM puštěný OpenMediaVault (stejná verze Samba jako v TurnKey v CT) už běží více než 24 hodin.
Asi pomohlo vypnutý WINS a zkrácení hostname s odstraněním teček v /etc/hostname
Našel jsem někde, že to může způsobovat problémy, tak jsem to zkusil.
Zatím dobré a už u VM s OMV zůstanu - výkon je dostatečný pro moje aplikace.

Díky všem za rady a pomoc.

M.