Forum Debian Users Gang

ethanak · 2014-08-09 14:49:17

Akurat temat podobny do poprzedniego wątku, ale monitorowanie polega nie na podniesieniu zdechłego demona tylko na ubiciu tego który działa źle.

Akurat mam Ubuntu, ale skrypty gogoca (kod źródłowy plus wszelkie patche też) są takie same w Debianie więc nie ma co szukać różnic.

Sytuacja taka:

gogoc w momencie kiedy zdechnie mu połączenie z bramą powinien grzecznie zdownować tunel i spróbować nawiązać połączenie ponownie aż do skutku. Niestety - mniej więcej raz na tydzień zdarza się sytuacja taka, że tunel ginie, gogoc grzecznie robi teardown... a następnie wchodzi w jakąś durną pętlę, żre 100% procka i nie ma najmniejszego zamiaru zdychać (pomaga kill -9)

Pomyślałem o czymś takim:
a) sprawdzam, czy mam właściwy adres ipv6 na interfejsie tun0. Jeśli tak, to OK
b) sprawdzam, czy uruchomiony jest gogoc. Jeśli nie to pewnie ktoś go z jakichś przyczyn zatrzymał i jest OK.
c) sprawdzam, czy gogoc zżera mi całą dostępną moc procesora. Jeśli nie - pewnie sobie nawiązuje połączenie bo zdechło i za chwilę ruszy, czyli jest OK
d) killall -9 gogoc;sleep 10;service gogoc restart

Wszystko pięknie - tylko jak zrobić sprawdzenie z punktu c?

Ewentualnie jakieś inne pomysły mile widziane.

Niestety - o ile w firmie mogę liczyć na podpięcie do sieci IPv6, o tyle w domu na razie mi tylko gogoc zostaje :(

Jacekalex · 2014-08-09 16:53:37

Gotowego sposobu na pkt c. nie znam, ale radziłbym rzucić okiem na pliczek cpulimit.c w źródełkach cpulimita.
Z tego, co widzę, on czyta /proc/$pid/stat, w źródełkach masz gotową funkcję, która wylicza obciążenie.

Można tez zajrzeć do źródełek top/htop.

PS.
Połączenie ipv6 to raczej przez ping6 bym sprawdzał, albo zatrudnił jakiś program, który trzyma stałe połączenie i komunikuje status np przez dbusa (klient jabbera?), a w zżeranie procka się nie zagłębiał, od procka, to ja mam cgroup/cpu i czasami cpulimita. :D

Ostatnio edytowany przez Jacekalex (2014-08-09 19:02:06)

ethanak · 2014-08-09 17:07:13

No właśnie czytania z /proc/*/stat chciałem uniknąć, ale widzę że się bez tego nie obejdzie :(
W sumie zajrzę w te źródełka, może mi się uda zrobić coś interesującego trzema klawiszami :)
W każdym razie dzięki.
Tematpozostawiam owarty - może ktoś ma inny pomysł?

mati75 · 2014-08-19 17:56:01

Zacząłem testować gogocia i widzę ten sam problem. Wpadłem na pomysł jednolinijkowca do crona

Kod:

*/1 * * * while ! ping6 -W 1 -c 1 google.com >&/dev/null; do /etc/init.d/gogoc restart; done >> /dev/null 2>&1

Ostatnio edytowany przez mati75 (2014-08-19 17:57:52)

Jacekalex · 2014-08-19 19:50:07

@up

Co minutę, to raczej nie warto angażować Crona, ten loguje, mailuje, i jest w ogóle do ważniejszych rzeczy.

IMHO starczy

Kod:

sleep 60

w pętli.

Ostatnio edytowany przez Jacekalex (2014-08-19 20:26:15)

mati75 · 2014-08-19 20:38:15

W sumie można walnąć co 15 minut i też spełni zadanie.

ethanak · 2014-08-20 10:35:47

restart nie wystarczy jeśli gogoc się zapętli, trzeba kill -9
btw. ostatnio amsterdam leżał przez ponad dwie godziny i gogoc na obu maszynach zgłupiał - po wstaniu amsterdamu nie chciał sam podnieść tunelu

Time (s)	Query
0.00014	SET CHARSET latin2
0.00005	SET NAMES latin2
0.00104	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.116.12.7' WHERE u.id=1
0.00061	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.116.12.7', 1732553188)
0.00043	SELECT * FROM punbb_online WHERE logged<1732552888
0.00070	SELECT topic_id FROM punbb_posts WHERE id=272865
0.00004	SELECT id FROM punbb_posts WHERE topic_id=26237 ORDER BY posted
0.00071	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=26237 AND t.moved_to IS NULL
0.00008	SELECT search_for, replace_with FROM punbb_censoring
0.00148	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=26237 ORDER BY p.id LIMIT 0,25
0.00075	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=26237
Total query time: 0.00603 s

Forum Debian Users Gang

Ogłoszenie

#1 2014-08-09 14:49:17

ethanak - Użytkownik

sposób na gogoca czyli monitorowanie demona inaczej

#2 2014-08-09 16:53:37

Jacekalex - Podobno człowiek...;)

Re: sposób na gogoca czyli monitorowanie demona inaczej

#3 2014-08-09 17:07:13

ethanak - Użytkownik

Re: sposób na gogoca czyli monitorowanie demona inaczej

#4 2014-08-19 17:56:01

mati75 - Psuj

Re: sposób na gogoca czyli monitorowanie demona inaczej

Kod:

#5 2014-08-19 19:50:07

Jacekalex - Podobno człowiek...;)

Re: sposób na gogoca czyli monitorowanie demona inaczej

Kod:

#6 2014-08-19 20:38:15

mati75 - Psuj

Re: sposób na gogoca czyli monitorowanie demona inaczej

#7 2014-08-20 10:35:47

ethanak - Użytkownik

Re: sposób na gogoca czyli monitorowanie demona inaczej

Stopka forum

Informacje debugowania