Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
A proc se v momente, kdy to je vytuhle, nepodivas pomoci GDB, na cem to visi v tom libssh?Asi proto, že mě to buď nenapadne nebo to neumim :-)
ssh_disconnect(session); Toto sice session uzavře, ale neuvolňuje to paměť kterou přiřadila funkce session = ssh_new();. Pravděpodobně je po tomto nutné zavolat ještě funkci ssh_free(session); Toto mi v celém kódu unikalo a důsledky jsou asi zřejmé. Je zvláštní, že mi ten program sám od sebe vůbec nepadá a jen zatuhne.Nemůže dojít k blokování v tom pracovním vlákně?Domnívám se, že nikoliv. Vede mě k tomu fakt, že v tom pracovním vlákně běží obsluha dalších filedeskriptorů, které mi normálně komunikují. Současně každou sekundu si na konzoli vypisuji krátký text, že toto pracovní vlákno žije. V podstatě proto jsem se tímto celým začal zabývat, protože v pracovním vlákně se dělo všechno podle očekávání a jen jakoby vlákno na příjem SSH stálo.
==48106==
==48106== HEAP SUMMARY:
==48106== in use at exit: 6,740 bytes in 42 blocks
==48106== total heap usage: 383,119 allocs, 383,077 frees, 104,143,130 bytes allocated
==48106==
==48106== 3,406 (32 direct, 3,374 indirect) bytes in 1 blocks are definitely lost in loss record 42 of 42
==48106== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==48106== by 0x49FE9AB: ssh_new (in /usr/lib/x86_64-linux-gnu/libssh.so.4.8.7)
==48106== by 0x10CAC4: handle_init_accept_sshbind (server_ssh.c:432)
==48106== by 0x4DAEB42: start_thread (pthread_create.c:442)
==48106== by 0x4E3FBB3: clone (clone.S:100)
==48106==
==48106== LEAK SUMMARY:
==48106== definitely lost: 32 bytes in 1 blocks
==48106== indirectly lost: 3,374 bytes in 26 blocks
==48106== possibly lost: 0 bytes in 0 blocks
==48106== still reachable: 3,334 bytes in 15 blocks
==48106== suppressed: 0 bytes in 0 blocks
==48106== Reachable blocks (those to which a pointer was found) are not shown.
==48106== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==48106==
==48106== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)==48106== by 0x49FE9AB: ssh_new (in /usr/lib/x86_64-linux-gnu/libssh.so.4.8.7)Jste si jistý tím, že „zatuhne“ ssh_bind_accept()Jsem si tím jistej, ale nerad bych něco přehlížel takže to ještě jednou ověřím. Nejsem v tomto vůbec kovanej takže všechno je čistě amatérské a někdy ani nevím jak bych měl správně postupovat. Zdrojových příkladů na SSH server jsem nikde moc nenašel, takže takže je to hodně velkej pokus omyl....doufám, že se za to na mě nikdo nebude zlobit a že právě pro takovéto účely vznikají tato fóra. K ladění používám funkci printf a snažím se prokousat těmi hroznými výpisy, ale v případě více vláken možná tato metoda selhává :-)
Ten současný kód máte udělaný tak, že se serverem může komunikovat vždy jen jeden klient.Toto není pravda i když to tak na první pohled vypadá. Pokud Vás to zajímá tak trošku víc popíšu jak to je udělané a proč.
ssh_bind_accept(sshbind, session)je pro mě blokující. Jakmile jí tedy zavolám tak neskončí dokud se žádnej klient nepokusí navázat spojení. To je pokud chcete komunikovat s více zařízeními dost omezující nemyslíte? Nevím jak to dělá někdo kdo to umí ale já to řeším tak, že celý příjem SSH spojení běží ve vlastním vlákně. Jakmile je spojení přijato, předávám přes mutex deskriptor navázaného spojení hlavnímu vláknu. Jakmile je deskriptor předaný tak se vracím opět k
ssh_bind_accept(sshbind, session)a čekám na další spojení. Vlákno tedy jen čeká v blokující funkci a jakmile vrátí příjem, předá ukazatel a opakuje se. Veškeré odbavení spojení jako příjem, odeslání a ukončení je už řešeno jako neblokující v jiném vlákně. Tenhle princip mi funguje a zkoušel jsem i takové experimenty, že jsem si na úplně jiném počítači vytvořil tisíce SSH klientů, které se trvale jen připojovali a odpojovali. Veškeré mé pokusy a omyly vždy vedly ke stejnému závěru. Tím je právě ta blokující funkce, takže se furt točím dokola.
zkontrolovat to valgrindem je první věcToto jsem opakovaně zkoušel, ale nikdy jsem na nic nepřišel. Asi se k tomu s odstupem času opět vrátím.
sss_bind_set_blocking(sshbind,0), ale ta podle mě nefunguje nebo jsem na to nepřišel.static void *handle_init_accept_sshbind(void *arg){
ssh_session session;
uint8_t pom;
ssh_bind sshbind = (ssh_bind)arg;
while(1){
session = ssh_new();
if(session != NULL){
ssh_set_message_callback(session, nc_sshcb_msg, session);
if(ssh_bind_accept(sshbind, session) != SSH_OK){
ssh_disconnect(session);
}
else{
if(ssh_handle_key_exchange(session) != SSH_OK){
ssh_disconnect(session);
}
else{
//spojeni prijato
}
}
}
}
ssh_bind_free(sshbind);
ssh_finalize();
return NULL;
}
if(ssh_bind_accept(sshbind, session) != SSH_OK){ssh_bind_accept(sshbind, session), tak bych očekával, že ta funkce někdy skončí. V tomto případě ta funkce skončí jen v případě, že příjde SSH spojení jinak neznám jediný způsob jak jí ukončit. V momentě kdy to vytuhne, tak už žádné spojení nepřijme a nikdy tedy neskončí. Přiznám se, že nechápu kde by v tomto případě mohl být problém s pamětí, protože jakmile tu funkci zavolám, tak se celá další obsluha programu předává OS dokud ten funkci neukončí a neumožní pokračovat v programu.ssh_bind_accept(sshbind, session)má pouze blokující volání. To se mi nikdy nepovedlo vyřešit, ale s tímto umím žít.pokud mi neco neunika, tak ten find odstavec resit normalne=obracene :-)Kód: [Vybrat]while read file; do
dir=${file%/*}
echo "${dir}"
/home/irma/database_sort_new "${dir}"
OPAKOVAT=1
done < <(find /opt/databaze_pracovni -name "database.db")
#!/bin/bash
exit_status=0
while true; do
OPAKOVAT=0
find /opt/databaze_pracovni -name "database.db" -exec sh -c '
for file do
dir=${file%/*}
echo "$dir"
/home/irma/database_sort_new "$dir"
OPAKOVAT=1
done' sh {} +
echo $OPAKOVAT
if [ $OPAKOVAT -eq 1 ]; then
echo "nebude se uspavat"
continue
fi
echo "sleep"
sleep 300s
doneTen můj nezabezpečenej webserver podle logu příjme nové spojení a odpoví na něj. Do prohlížeče už se ale nic nedostane. Pokud udělám to stejné přes VPNku tak to funguje jak z praku vždy.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2024 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.