[gelöst] freetz-devel-5210: inetd-Dienste im GUI nicht stop-/startbar

[ao]

EDIT: Problem gelöst - siehe Changeset 5263
____________________________________

Hallo,

in meinem Freetz-GUI lassen sich inetd-Dienste nicht stoppen oder starten, weil die Knöpfe ausgegraut sind. Im Syslog finden sich zig Einträge der folgenden Art:

Jul 12 15:40:04 fb1 daemon.err inetd[1176]: 82/tcp: bind: Address already in use
Jul 12 15:40:04 fb1 daemon.err inetd[1176]: 22/tcp: bind: Address already in use
Jul 12 15:41:04 fb1 daemon.err inetd[1176]: 82/tcp: bind: Address already in use
Jul 12 15:41:04 fb1 daemon.err inetd[1176]: 22/tcp: bind: Address already in use

Ich nehme an, dass es damit zu tun hat, habe aber keine Ahnung, was da los ist.

Außerdem fällt mir auf, dass rrdstats und digitemp bei mir mit inetd-Unterstützung laufen (zumindest sind die beiden Kästchen dort entsprechend selektiert), aber auf der "Dienste"-Seite steht bei rrdstats nichts von inetd.
.

 

[olistudent]

Wieso sollten sich inetd-Dienst auch starten oder stoppen lassen? Es sind inetd Dienste...

Der Fehlermeldung sollte natürlich trotzdem auf den Grund gegangen werden. Was steht denn in deiner /etc/inetd.conf? Und was sagt "ps"?

Mfg Oliver

 

[ao]

Das stimmt schon, aber ich hatte gedacht, dass man die inetd-gesteuerten Dienste damit de-/reaktivieren kann.

Sorry, /etc/inetd.conf ist leer, da ich inzwischen die Dienste alle wieder auf "automatisch" (die vorher auf inetd liefen) gestellt habe.
Aber der ps-Output ist noch von vor der Umstellung:

root@fb1 /var/mod/root $ ps
  PID USER       VSZ STAT COMMAND
    1 root      1436 S    init
    2 root         0 SWN  [ksoftirqd/0]
    3 root         0 SW<  [events/0]
    4 root         0 SW<  [khelper]
    5 root         0 SW<  [kthread]
    6 root         0 SW<  [kblockd/0]
   23 root         0 SW<  [pdflush]
   24 root         0 SW<  [pdflush]
   26 root         0 SW<  [aio/0]
   25 root         0 SW   [kswapd0]
   62 root         0 SW   [pm_info]
   66 root         0 SW<  [CPMAC]
   70 root         0 SW   [mtdblockd]
   96 root         0 SW   [tffsd_mtd_0]
  355 root         0 SW<  [khubd]
  426 root         0 SWN  [jffs2_gcd_mtd6]
  449 root         0 SW<  [capi_oslib]
  450 root         0 SW<  [capi_oslib]
  451 root         0 SW   [capitransp]
  457 root         0 SW   [glob_codecs]
  531 root      7668 S N  ctlmgr
  551 root      3352 S    upnpd
  718 root      3776 S    dsld -i -n
  732 root         0 RWN  [kdsld_token]
  735 root      5704 S    telefon a127.0.0.1
  768 root      5032 S <  voipd
  777 root      3144 S    pbd
  780 root      3144 S    pbd
  783 root      3144 S    pbd
  784 root      3144 S    pbd
  785 root      3352 S    upnpd
  786 root      3352 S    upnpd
  787 root      3352 S    upnpd
  802 root      1116 S    /bin/run_clock -c /dev/tffs -d
  897 root      1436 S    crond -b
  911 root      1428 S    httpd -P /var/run/webcfg.pid -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r Freetz
  936 root      1440 S    syslogd -L -C
  938 root      1616 S    /sbin/klogd -c 4
 1176 root      1436 S    inetd
 1227 root      7668 S N  ctlmgr
 1229 root      7668 S N  ctlmgr
 1232 root      7668 S N  ctlmgr
 1240 root      1576 S    dropbear -p 22 -R
 1380 root      1428 S    httpd -P /var/run/webcfg-wol.pid -p 82 -c /mod/etc/httpd-wol.conf -h /mod/pkg/wol/usr/mww-wol/ -r Wake-on-LAN
 1383 root      1436 S    init
 3875 root      3372 S    multid
 3879 root      3372 S    multid
 4043 root      1460 S    /bin/sh /etc/default.rrdstats/rrdstats 60
  401 root      1124 S    ser2net -c /tmp/flash/ser2net.conf -P /var/run/ser2net.pid
 1593 nobody    1164 S    dnsmasq --pid-file=/var/run/dnsmasq/dnsmasq.pid -p 53
 1527 root         0 SW   [scsi_eh_1]
 1528 root         0 SW   [usb-storage]
  572 root      2028 S    dropbear -p 22 -R
  617 root      1448 S    -sh
 2289 root      1448 S    httpd -P /var/run/webcfg.pid -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r Freetz
 2290 root      1516 S    /bin/sh pkgstatus.cgi
 2353 root      3840 R N  rrdtool graph /tmp/rrdstats/tt0.png --title  --start now-1d --width 630 --height 252 --vertical-label values --color SHADEA#ffff
 2355 root      1432 R    ps

 

[hermann72pb]

@Oliver: Dienste über inetd kann man schon startbar und stopbar machen, wenn man sie nach unserem mit Ralf Vorschlag "dynamisiert". Ich komme aber leider nicht dazu modlibrc zu überarbeiten. Deswegen müssen alle leider wenigstens bis August gedulden.
In der derzeitigen Implementierung von inetd ist es tatsächlich nicht möglich, daher sind die Knöpfe ausgegraut. In der "dynamischen" Version ist es vorgesehen, dass als Reaktion auf "stop" das Austragen des betroffenen Programms aus der Liste von inetd mit dem reload von inetd passieren sollte. Als "start" soll dann andersrum in die Liste eingetragen werden mit dem reload von inetd.
Ein solches Verhalten erscheint mir etwas "transparenter" zu sein und würde solche Fragen minimieren, obwohl jedem natürlich wiederum die Unterschiede zwischen inetd- und daemon-Modus geläufig werden sollten.

Zum "ps". Es wird nur dann was angezeigt, wenn die Verbindung zu Stande kommt. Das ist die Besonderheit und der Hauptvorteil von inetd.

MfG

 

[olistudent]

Ich vermute, dass die Daemons "dropbear" und "wol-cgi" laufen, obwohl sie über inetd gestartet werden sollen. Warum deine /etc/inetd.conf leer sein soll verstehe ich daher nicht.
Das Verhalten kann ich bei dropbear provizieren indem ich ihn (während eine SSH Verbindung offen ist) im Webinterface auf inetd umstelle. Dann wird der Prozess nicht beendet.

MfG Oliver

 

[ao]

Hallo Ihr Beiden, oben habe ich zwischen rein geschrieben (nicht, dass es jemand übersieht ;-)).
Sorry, hatte diesen Beitrag eben gelöscht. Jetzt steht er halt unter Olivers Beitrag.

Das Verhalten kann ich bei dropbear provizieren indem ich ihn (während eine SSH Verbindung offen ist) im Webinterface auf inetd umstelle. Dann wird der Prozess nicht beendet.

Stimmt, es hatte mich auch schon gewundert, dass die (remote) ssh Verbindung stehen blieb.

Weshalb wird eigentlich rrdstats nicht mit "inetd" dargestellt (wie z.B. bei dropbear oder wol), wenn es mit inetd (wie auch digitemp) läuft?
Übrigens sind bei rrdstats die Knöpfe nie ausgegraut, auch wenn es als inetd läuft.
Wie würde rrdstats dargestellt werden, wenn zwar rrdstats mit inetd läuft, digitemp aber als gewöhnlicher Dienst (bzw. umgekehrt)?


Würde es Sinn machen, rrdstats und digitemp im GUI zu trennen?


Jetzt habe ich die o.g. "Dienste" wieder auf inetd gestellt, um die config zu posten:

root@fb1 /var/mod/root $ cat /etc/inetd.conf
22      stream  tcp     nowait  root    /usr/sbin/dropbear      dropbear  -i -s
85      stream  tcp     nowait  root    /usr/bin/webcfg-one      webcfg-one -i
86      stream  tcp     nowait  root    /usr/bin/webcfg-rrd      webcfg-rrd -i
82      stream  tcp     nowait  root    /usr/bin/webcfg-wol      webcfg-wol -i

Und schon erscheinen wieder diese Fehler im Syslog:

Jul 12 16:44:21 fb1 daemon.err inetd[707]: 82/tcp: bind: Address already  in use
Jul 12 16:44:21 fb1 daemon.err inetd[707]: 22/tcp: bind: Address already  in use
Jul 12 16:45:21 fb1 daemon.err inetd[707]: 82/tcp: bind: Address already  in use
Jul 12 16:45:21 fb1 daemon.err inetd[707]: 22/tcp: bind: Address already  in use
Jul 12 16:45:48 fb1 user.debug kernel: mcfw: group 0.0.0.0: query  cpmac:0 10sec
Jul 12 16:46:21 fb1 daemon.err inetd[707]: 82/tcp: bind: Address already  in use
Jul 12 16:46:21 fb1 daemon.err inetd[707]: 22/tcp: bind: Address already  in use
Jul 12 16:46:31 fb1 user.warn kernel: /proc/tffs: info request: success

Dazu noch einmal dies (EDIT: ok, das bringt wohl nicht so viel):

root@fb1 /var/mod/root $ ps
  PID USER       VSZ STAT COMMAND
    1 root      1436 S    init
    2 root         0 SWN  [ksoftirqd/0]
    3 root         0 SW<  [events/0]
    4 root         0 SW<  [khelper]
    5 root         0 SW<  [kthread]
    6 root         0 SW<  [kblockd/0]
   23 root         0 SW<  [pdflush]
   24 root         0 SW<  [pdflush]
   26 root         0 SW<  [aio/0]
   25 root         0 SW   [kswapd0]
   62 root         0 SW   [pm_info]
   66 root         0 SW<  [CPMAC]
   70 root         0 SW   [mtdblockd]
   96 root         0 SW   [tffsd_mtd_0]
  355 root         0 SW<  [khubd]
  426 root         0 SWN  [jffs2_gcd_mtd6]
  449 root         0 SW<  [capi_oslib]
  450 root         0 SW<  [capi_oslib]
  451 root         0 SW   [capitransp]
  457 root         0 SW   [glob_codecs]
  531 root      7668 S N  ctlmgr
  551 root      3352 S    upnpd
  718 root      3776 S    dsld -i -n
  732 root         0 RWN  [kdsld_token]
  735 root      5704 S    telefon a127.0.0.1
  768 root      5032 S <  voipd
  777 root      3144 S    pbd
  780 root      3144 S    pbd
  783 root      3144 S    pbd
  784 root      3144 S    pbd
  785 root      3352 S    upnpd
  786 root      3352 S    upnpd
  787 root      3352 S    upnpd
  802 root      1116 S    /bin/run_clock -c /dev/tffs -d
  897 root      1436 S    crond -b
  911 root      1428 S    httpd -P /var/run/webcfg.pid -p 81 -c  /mod/etc/httpd.conf -h /usr/mww/ -r Freetz
  936 root      1440 S    syslogd -L -C
  938 root      1616 S    /sbin/klogd -c 4
 1227 root      7668 S N  ctlmgr
 1229 root      7668 S N  ctlmgr
 1232 root      7668 S N  ctlmgr
 1240 root      1576 S    dropbear -p 22 -R
 1380 root      1428 S    httpd -P /var/run/webcfg-wol.pid -p 82 -c  /mod/etc/httpd-wol.conf -h /mod/pkg/wol/usr/mww-wol/ -r Wake-on-LAN
 1383 root      1436 S    init
 3875 root      3372 S    multid
 3879 root      3372 S    multid
  401 root      1124 S    ser2net -c /tmp/flash/ser2net.conf -P  /var/run/ser2net.pid
 1593 nobody    1164 S    dnsmasq  --pid-file=/var/run/dnsmasq/dnsmasq.pid -p 53
 1527 root         0 SW   [scsi_eh_1]
 1528 root         0 SW   [usb-storage]
  572 root      2200 S    dropbear -p 22 -R
  617 root      1456 S    -sh
  707 root      1436 S    inetd
  850 root      1460 S    /bin/sh /etc/default.rrdstats/rrdstats  60

Sobald ich wieder zurück auf echte Dienste stelle (statt inetd), kommen die o.g. Fehlermeldungen im Syslog nicht mehr.

Seltsamerweise scheint rrdstats bzw. digitemp auch nicht mehr richtig zu laufen (auch ohne inetd), denn die letzte Messung ist von heute 10:22 Uhr.
D.h. die rrd-Dateien haben diesen Zeitstempel, die Graphen werden nur bis zu dieser Zeit dargestellt, aber in der Legende stehen Werte (auch current).
Ich hatte es (zumindest bisher) so erlebt, dass keine Graphen dargestellt wurden und auch die Legende leer war, wenn die Dienste gestoppt waren.
Auch nach "restart" ändert sich nichts, obwohl die Dienste (rrdstats und digitemp - siehe "ps" oben) ja zu laufen scheinen:

root@fb1 /var/tmp/persistent $ ps | grep [r]rd
 1564 root      1460 S    /bin/sh /etc/default.rrdstats/rrdstats 60
 1758 root      1428 S    httpd -P /var/run/webcfg-rrd.pid -p 86 -c /mod/etc/httpd-rrd.conf -h /mod/pkg/rrdstats/usr/mww-rrd/ -r RRDstats
 1762 root      1428 S    httpd -P /var/run/webcfg-one.pid -p 85 -c /mod/etc/httpd-one.conf -h /mod/pkg/rrdstats/usr/mww-one/ -r DigiTemp

 

[olistudent]

Es werden nur die Webinterfaces über inetd gestartet. Nich die "normalen" Dienste. Port 85 und 86.

MfG Oliver

 

[ao]

Nochmal: Es werden nur die WebIFs für Ports 82, 85 und 86 mit inetd gestartet?
Ja, das erklärt mir dann doch einiges. Wobei, ein paar meiner oben eben noch eingefügten Beobachtungen (hast Du evtl. noch nicht lesen können, weil ich sie eben noch dazu geschrieben habe) verstehe ich damit trotzdem nicht.

OT:
Wie kann ich digitemp isoliert neu starten? Ich habe das Gefühl, dass bei mir zwar rrdstats läuft, nicht aber digitemp.
Sorry, dass ich hier evtl. doch ein persönliches Konfig-Problem habe. Aber ich möchte diese Diskussion hier nicht unnötig damit in die falsche Richtung lenken und wäre daher froh zu wissen, was ich tun kann, das Problem zu isolieren und dann ggf. noch ein paar sinnvolle Logs zu senden.

Ok, alles klar, ich habe ein digitemp Problem (aber sicherlich OT zum eigentlichen, hier beschriebenen Problem - erklärt aber evtl. die eine oder andere meiner Beobachtungen).
Nach einem initialize kommt nämlich diese Meldung:

owAcquire: failed to open device: No such device
Error 23: Failed to acquire a necessary system resource

Da ist wohl die Verdrahtung in die Brüche gegangen o.ä. Heute morgen lief es noch.
Wie bekommt man eigentlich zu dmesg noch Zeitstempel dazu?

root@fb1 /var/tmp/persistent $ dmesg | grep usb[COLOR=Red]
usb 1-1: USB disconnect, address 2
usb 1-1.2: USB disconnect, address 3[/COLOR]
usb 1-1.2: pl2303_read_int_callback - usb_submit_urb failed with result -19[COLOR=Red]
usb 1-1.4: USB disconnect, address 4[/COLOR]
usb 1-1: new full speed USB device using ahci and address 5
usb 1-1.2: new full speed USB device using ahci and address 6[COLOR=Blue]
usb 1-1.2: PL-2303 converter now attached to ttyUSB0[/COLOR]
usb 1-1.4: new full speed USB device using ahci and address 7
usb-storage: device found at 7
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete[COLOR=Red]
usb 1-1.2: USB disconnect, address 6[/COLOR]
usb 1-1.2: pl2303_read_int_callback - usb_submit_urb failed with result -19
usb 1-1.2: new full speed USB device using ahci and address 8[COLOR=Blue]
usb 1-1.2: PL-2303 converter now attached to ttyUSB1[/COLOR]

 

[hermann72pb]

Und hier nochmal etwas Salz zu eurer Diskussion: In meiner "dynamischen" Geschichte ist auch dies vorgesehen, Ports auf deren Belegung zu testen, bevor man überhaupt in den rc-Skripten startet. Damals wurden meine Sachen als etwas overkilled betrachtet und erstmal auf Eis gelegt. Hätten wir sie damals eingepflegt, wäre die Fehlersuche jetzt deutlich leichter gewesen. Aber sei es rum, jetzt müsst ihr warten, bis ich die modlibrc angepasst habe, oder jemand nimmt es sich vor.

Die meisten Fehler, die momentan hier im Forum auftauchen sind auf die Umstellung aller Skripte auf modlibrc mehr oder weniger zurückzuführen. Dieser Schritt war aber notwendig und es ist gut, dass cuma es vor ein Paar Wochen endlich gewaagt hat durchzuziehen. Hut ab! Wir müssen jetzt durch die Nachwirkungen dieser Umstellung durch.

MfG

 

[olistudent]

Ja, leider geht es nur durch User-Feedback. Uns fehlt da ein automatischer "Target-Tester", der überprüft ob alle Pakete bauen und in allen Einstellungen laufen...

MfG Oliver

 

[RalfFriedl]

Das Verhalten kann ich bei dropbear provizieren indem ich ihn (während eine SSH Verbindung offen ist) im Webinterface auf inetd umstelle. Dann wird der Prozess nicht beendet.

Es sollte reichen, wenn der Prozeß beendet wird, der auf Verbindungen wartet. Es kann aber sein, daß der sich nicht beendet, solange nicht alle Verbindungen beendet sind. Ich glaube nicht, daß wir deswegen größere Eingriffe im dropbear vornehmen wollen.

Wir müssen jetzt durch die Nachwirkungen dieser Umstellung durch.

Wer Trunk verwendet, sollte wissen, worauf er sich einläßt.

 

[ao]

Klar weiß ich, worauf ich mich einlasse. Ich sehe das alles sehr positiv und hoffe, mit meinem Feedback weiterzuhelfen.
Das ist das Mindeste, was ich beisteuern kann. ;-) Wenn Ihr noch Logs braucht etc., bitte melden.

 

[olistudent]

http://trac.freetz.org/ticket/893#comment:1

cuma beschreibt in dem Kommentar auch noch ein Problem, das momentan auftritt. Warte bitte mit weiteren Tests zu diesem Thema bis cuma das gefixed hat.

MfG Oliver

 

[ao]

Ok, danke für den Hinweis, Oliver!
Ist das mit Changeset 5263 inzwischen gelöst? Oder habe ich das im Trac falsch verstanden?

 

[olistudent]

Ja, sollte gefixt sein.

MfG Oliver

 

[ao]

Danke, Oliver, keine Probleme mehr. Kannst Du diesen Thread schließen?

 

[olistudent]

Gerne.

MfG Oliver