Was steckt hinter /var/tmp/me_logic.ctl & Co.?

kriegaex · 2 Okt 2007

Das hier taucht andauernd im Log des ctlmgr auf, wenn ich ihn mit -fv starte und beobachte:

Code:

ctlmgr: 4(/var/tmp/me_logic.ctl) (fd 4): failed to send message to webcm0 - No such file or directory (2)

Die Frage wurde dort vom Benutzer vpe schon einmal gestellt, aber nicht beantwortet. Weiß jemand mehr darüber? Es gibt einen Haufen ähnlicher Dateien, ich nehme an, sie dienen der Inter-Prozeß-Kommunikation:

Code:

$ ls -l /var/tmp/me_*
srwxr-xr-x    1 root     root            0 Oct  1 22:45 /var/tmp/me_ctlmgr.ctl
srwxr-xr-x    1 root     root            0 Jan  1  2000 /var/tmp/me_dsld.ctl
srwxr-xr-x    1 root     root            0 Oct  2 00:28 /var/tmp/me_logic.ctl
srwxr-xr-x    1 root     root            0 Oct  2 00:32 /var/tmp/me_multid.ctl
srwxr-xr-x    1 root     root            0 Jan  1  2000 /var/tmp/me_usermand.ctl
srwxr-xr-x    1 root     root            0 Jan  1  2000 /var/tmp/me_voipd.ctl
srwxr-xr-x    1 root     root            0 Oct  2 01:10 /var/tmp/me_webcm0.ctl

wichard · 2 Okt 2007

Auf meiner (kaum gemoddeten) 7170 mit fast schon uralter Firmware habe ich nur eine solche Datei:

Code:

# ls -l /var/tmp/me_*
srwxr-xr-x    1 root     root            0 Sep  8  2002 /var/tmp/me_dsld.ctl

HTH,
Wichard

bodega · 2 Okt 2007

Bei mir (.39 Firmware) fehlt die Datei me_webcm0.ctl.

Code:

[B]s[/B]rwxr-xr-x

Was hat 's' für eine Bedeutung? Manchmal auch 'l' (link) habe ich irgendwo gelesen?

McNetic · 2 Okt 2007

Das 1. (Typ-)Feld kann folgendes beinhalten:

d = directory
l = symbolic link
s = socket
p = named pipe
- = regular file
c = character (unbuffered) device file special
b = block (buffered) device file special

RalfFriedl · 2 Okt 2007

Ein 's' steht für Socket, ein 'l' steht für Link.
Außerdem '-' normale Datei, 'd' Direktory, 'c' Character Device, 'b' Block Device, 'p' Pipe. Ich hoffen ich habe keines vergessen.

Ein 'l' steht für einen symbolischen Link (Symlink), man erkennt diese außerdem daran, daß nach dem Dateinamen noch ein Pfeil auf das Ziel des Links angezeigt wird. Beispiel: "/bin/sh -> busybox".

Ein 's' steht für einen Socket, einen sogenannten UNIX-Socket, im Gegensatz zu den Netzwerk-Sockets. Ein Socket (wörtlich Buchse oder Steckdose) ist ein Kommunikations-Endpunkt für die Interprozeß-Kommunikation.

IP4 und IP6 Sockets haben als Identifikation eine IP-Adresse und einen Port, UNIX-Sockets haben als Identifikation einen Pfadnamen. Dieser Name wird im Dateisystem angelegt, kann aber nicht als reguläre Datei geöffnet werden.

Der Eintrag im Dateisystem wird erstellt, wenn ein Server-Prozeß

Code:

bind ("/pfad/datei")

aufruft. Das einzige, was man mit dem Eintrag machen kann, ist vom Client aus

Code:

connect ("/pfad/datei")

aufzurufen. Mit open kann man nicht darauf zugreifen.

Die Aufrufe von bind und connect sind hier nur um das Prinzip zu erklären, die korrekten Aufrufe sehen etwas anders aus.

Im Gegensatz zu den IP-Sockets ist eine Kommunikation über UNIX-Sockets nicht über Netzwerk, sondern nur auf den lokalen System möglich. Auch ein NFS-Zugriff auf Sockets eines anderen Rechners funktioniert nicht.

Manchmal ist es auch ein Vorteil, wenn die Kommunikation nur lokal geht, man muß sich nicht darüber Gedanken machen, den Socket vor Zugriffen von außen zu schützen. Außerdem könnte die lokale Kommunikation effizienter sein als über die allgemeinen Netzwerk-Sockets, wobei Linux in dem Bereich auch sehr gut sein soll.

Zur Frage von kriegaex:
Der Eintrag für /var/tmp/me_logic.ctl existiert zwar, aber daß muß nicht viel heißen. Die Socket-Einträge werden zwar mit bind angelegt, aber nicht entfernt, wenn der dazugehörende Socket geschlossen wird.

Zunächst einmal wäre es interessant zu wissen, welches Programm diesen Socket angelegt hat.
Vom ctlmgr könnte ein strace weiterhelfen. Dies sollte anzeigen, was kurz vor der Ausgabe der Fehlermeldung passiert.

bodega · 2 Okt 2007

Danke! 's' für Socket war mir jetzt neu.

kriegaex · 2 Okt 2007

Danke für die gute Erklärung lokaler Socket Links, Ralf. Ich lag also richtig mit meiner Vermutung der Verwendung für Interprozeß-Kommunikation. So weit hatte ich mich ja schon vorgearbeitet, aber nicht daran gedacht, entsprechende Textseiten zum Lesen anzubieten:

man ls (1) - dort nach "socket link" suchen
man bind (2) - anonymen Socket "taufen"
man getsocketname (2) - Namen eines Sockets herausfinden

Die Sockets selbst sind schon geöffnet, das sehe ich auch ohne strace:

Code:

$ ls /var/tmp/me_* | xargs lsof
COMMAND   PID USER   FD   TYPE     DEVICE SIZE   NODE NAME
dsld      720 root    6u  unix 0x95189b60        1360 /var/tmp/me_dsld.ctl
voipd     736 root    9u  unix 0x95189060        1880 /var/tmp/me_voipd.ctl
usermand  901 root    6u  unix 0x951895e0        4326 /var/tmp/me_usermand.ctl
ctlmgr   2033 root    4u  unix 0x953cf4a0      170962 /var/tmp/me_logic.ctl
ctlmgr   2033 root    5u  unix 0x953cf600      170964 /var/tmp/me_ctlmgr.ctl
multid   3116 root   11u  unix 0x953cf8c0      509293 /var/tmp/me_multid.ctl

olistudent · 2 Okt 2007

Die nächste Frage wäre jetzt also wie man die Sockets "abhören" kann?

MfG Oliver

bodega · 2 Okt 2007

Wenn sich der Unix-Socket wie ein normaler TCP/IP Socket verhält, dann vielleicht so:

Code:

  // RAW-Socket - Sniffer !
  //sock = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

  // Unix-Socket - Sniffer ?
  sock = socket(AF_UNIX, SOCK_RAW, htons(ETH_P_ALL));
  if(sock<0) 
  {
    printf("Socket create error!\nExit!\n");
    exit(1);
  }

  for(;;) 
  {  
	if(recv(sock, &packet, sizeof(packet), 0) < 0) 
	{
		printf("Packet receive error!\nExit!\n");
		close(sock);
		exit(1);	  
	}  	
  }

  close(sock);

Getestet mit Unix-Sockets habe ich es nicht, aber normale Sockets lassen sich so abhören.
Hier steht mehr dazu.

kriegaex · 2 Okt 2007

Mein Problem besteht inzwischen nicht mehr. Es kam wohl irgendwie dadurch zustande, daß ich den ctlmgr angehalten und zu Debugging-Zwecken mit -fv (wie oben erwähnt) neu gestartet hatte. Daraufhin hatte ich, wie ich vorhin erst bemerkte, plötzlich viel zu viele Callmonitor-Prozesse (keine Zombies!). Offenbar mochte Callmonitor es gar nicht, daß man ihm ctlmgr unter dem Hintern wegzog. Nach einem beherzten killall callmonitor und anschließendem rc.callmonitor start sieht es nun normal aus.

Trotzdem danke an alle für Euren Input. Ich denke, wir haben alle etwas gelernt, von Ralf vielleicht mal angesehen.

Edit: Gerade wollte ich das Thema in "gelöst" umbenennen, aber die Frage, wozu genau diese und ähnliche Sockets dienen bzw. wie man durch lesen/schreiben der Sockets Dinge beeinflussen kann, ist ja weiterhin interessant. Also lasse ich das Thema mal offen für die weitere Diskussion.

RalfFriedl · 2 Okt 2007

Damit ist schon mal klar, daß /var/tmp/me_logic.ctl vom ctlmgr selbst geöffnet wird und ctlmgr anscheinend der Server zu diesem Socket ist. Ich hätte noch dazu schreiben sollen, daß sich lsof dafür anbietet.

Die Frage ist aber immer noch, was die Fehlermeldung verursacht. Dafür ist strace sinnvoll.
Da ctlmgr der Server hierzu ist und nicht der Client könnte es sein, daß eine Anforderung hereinkommt und ctlmgr die Antwort zurückschicken will, aber die Gegenseite die Verbindung bereits geschlossen hat. Seltsam an der Fehlermeldung ist aber, daß es heißt "No such file or directory" (ENOENT). Die Datei ist ja offensichtlich da. Es kann aber auch sein, daß ENOENT in diesem Zusammenhang eine andere Bedeutung hat.

Auch zum Abhören der Sockets ist strace gut geeignet, sofern man einen der beteiligten Kommunikationspartner kennt. Besser ist es, wenn man beide kennt, wobei das nicht notwendig ist, um die Übertragenen Daten herauszubekommen, da diese ja auf beiden Seiten vorhanden sind.

Die andere Seite zu kennen wäre in diesem Fall hilfreich, weil anscheinend etwas mit der Kommunikation nicht so klappt wie es soll, und da könnte das Verhalten der Gegenseite schon von Bedeutung sein.

Da es nicht normalerweise so viele Prozesse auf einer Box gibt, die dafür in Frage kommen, kann man auch (nacheinander oder gleichzeitig) ein strace an alle hängen und die Ausgabe nach dem Namen des Sockets durchsuchen.

Wenn man das hat, dann strace auf ctlmgr und den Client und abwarten, bis wieder die Meldung kommt, danach schauen was kurz vorher geschehen ist und die Ursache dafür sein kann.

kriegaex · 2 Okt 2007

Zu früh gefreut: Nachdem ctlmgr -fv nun ein Weilchen durchlief, fällt mir gerade auf, daß die viellen Callmonitor-Prozesse wieder da sind, und drei davon lasten die Box zusammen maximal aus. :-(

Update: Auch ohne -fw, also bei normalem Daemon-Hintergrundbetrieb spinnt Callmonitor herum, so langsam glaube ich nicht mehr nur an ein ctlmgr-Problem. Es wird immer heftiger. Top sagt:

Code:

CPU:  32% usr  66% sys   0% nice   0% idle   0% io   0% irq   0% softirq
Load average: 29.04 27.24 18
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  627     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  637     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  673     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  697     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  706     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  721     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  806     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  819     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  832     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  844     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  915     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  936     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  927     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  946     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  964     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  979     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  958     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  997     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
 1027     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
 1034     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
 1051     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  853     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
  906     1 root     R     1560   5%   4% /bin/ash /usr/sbin/callmonitor
 1091  2060 root     R     1448   5%   3% top
  856     1 root     R     1560   5%   2% /bin/ash /usr/sbin/callmonitor
  873     1 root     R     1560   5%   2% /bin/ash /usr/sbin/callmonitor
  883     1 root     R     1560   5%   2% /bin/ash /usr/sbin/callmonitor
  894     1 root     R     1560   5%   2% /bin/ash /usr/sbin/callmonitor
 2059  1112 root     S     1220   4%   1% dropbear -p 22
 3783     1 root     R N  11316  37%   0% ctlmgr
  736     1 root     S <   9592  32%   0% voipd
  720     1 root     S     6472  21%   0% dsld -i -n -g
 3116     1 root     S     5900  19%   0% multid -u
  901     1 root     S     5692  19%   0% usermand
  825     1 root     S     4020  13%   0% capiotcp_server -p5031 -m1
  732     1 root     S     3364  11%   0% telefon a127.0.0.1
 1183     1 root     S     2104   7%   0% smbd -D -o
 1667     1 root     S     1724   6%   0% /bin/sh /var/tmp/tsb/tsbdaemon.sh
  816     1 root     S     1640   5%   0% syslogd -L -C200 -R 192.168.178.21
 1179     1 root     S     1636   5%   0% nmbd -D -o -H /tmp/flash/samba/lmhosts
 3859  3845 root     S     1560   5%   0% /bin/ash /usr/sbin/callmonitor
 3845     1 root     S     1560   5%   0% /bin/ash /usr/sbin/callmonitor
 3858  3845 root     S     1560   5%   0% /bin/ash /usr/sbin/callmonitor
 3856  3845 root     S     1560   5%   0% /bin/ash /usr/sbin/callmonitor

Ps sagt:

Code:

  PID  Uid        VSZ Stat Command
    1 root       1444 S   init
    2 root            SWN [ksoftirqd/0]
    3 root            SW< [events/0]
    4 root            SW< [khelper]
    5 root            SW< [kthread]
    6 root            SW< [kblockd/0]
   23 root            SW< [pdflush]
   24 root            SW< [pdflush]
   26 root            SW< [aio/0]
   25 root            SW  [kswapd0]
   69 root            SW  [mtdblockd]
   95 root            SW  [tffsd_mtd_0]
  473 root       1436 S   cat /dev/debug
  477 root            SW< [capi_oslib]
  478 root            SW< [capi_oslib]
  479 root            SW  [capitransp]
  491 root            SW< [khubd]
  720 root       6472 S   dsld -i -n -g
  731 root       1440 S   telnetd -l /sbin/ar7login
  732 root       3364 S   telefon a127.0.0.1
  736 root       9592 S < voipd
  742 root        964 S   /bin/run_clock -c /dev/tffs -d
  788 root       1448 S   httpd -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r DS-MOD (user:admin)
  816 root       1640 S   syslogd -L -C200 -R 192.168.178.21
  818 root       1440 S   /sbin/klogd
  825 root       4020 S   capiotcp_server -p5031 -m1
  901 root       5692 S   usermand
  973 root            RWN [kdsld_token]
 1112 root       1144 S   dropbear -p 22
 1179 root       1636 S   nmbd -D -o -H /tmp/flash/samba/lmhosts
 1183 root       2104 S   smbd -D -o
 1197 root       1448 S   httpd -p 82 -c /mod/etc/httpd-wol.conf -h /mod/pkg/wol/usr/mww-wol/ -r Wake-On-LAN
 1214 root       1464 S   -sh
 1477 root       1444 S   httpd -p 80 -h /usr/www/all
 1667 root       1724 S   /bin/sh /var/tmp/tsb/tsbdaemon.sh
 1858 root       1464 S   -sh
 2059 root       1220 S   dropbear -p 22
 2060 root       1468 S   -sh
 3116 root       5900 S   multid -u
 1288 root       1444 S   logger -t callmonitor -p daemon.info
 1299 root       1436 S   sleep 20000d
 3783 root      11408 R N ctlmgr
 3845 root       1560 S   /bin/ash /usr/sbin/callmonitor
 3846 root       1444 S   logger -t callmonitor -p daemon.info
 3856 root       1560 S   /bin/ash /usr/sbin/callmonitor
 3857 root       1436 S   sleep 20000d
 3858 root       1560 S   /bin/ash /usr/sbin/callmonitor
 3859 root       1560 S   /bin/ash /usr/sbin/callmonitor
 3860 root       1440 S   busybox nc 127.0.0.1 1012
  627 root       1560 R   /bin/ash /usr/sbin/callmonitor
  637 root       1560 R   /bin/ash /usr/sbin/callmonitor
  673 root       1560 R   /bin/ash /usr/sbin/callmonitor
  697 root       1560 R   /bin/ash /usr/sbin/callmonitor
  706 root       1560 R   /bin/ash /usr/sbin/callmonitor
  721 root       1560 R   /bin/ash /usr/sbin/callmonitor
  806 root       1560 R   /bin/ash /usr/sbin/callmonitor
  819 root       1560 R   /bin/ash /usr/sbin/callmonitor
  832 root       1560 R   /bin/ash /usr/sbin/callmonitor
  844 root       1560 R   /bin/ash /usr/sbin/callmonitor
  853 root       1560 R   /bin/ash /usr/sbin/callmonitor
  856 root       1560 R   /bin/ash /usr/sbin/callmonitor
  873 root       1560 R   /bin/ash /usr/sbin/callmonitor
  883 root       1560 R   /bin/ash /usr/sbin/callmonitor
  894 root       1560 R   /bin/ash /usr/sbin/callmonitor
  906 root       1560 R   /bin/ash /usr/sbin/callmonitor
  915 root       1560 R   /bin/ash /usr/sbin/callmonitor
  927 root       1560 R   /bin/ash /usr/sbin/callmonitor
  936 root       1560 R   /bin/ash /usr/sbin/callmonitor
  946 root       1560 R   /bin/ash /usr/sbin/callmonitor
  958 root       1560 R   /bin/ash /usr/sbin/callmonitor
  964 root       1560 R   /bin/ash /usr/sbin/callmonitor
  979 root       1560 R   /bin/ash /usr/sbin/callmonitor
  997 root       1560 R   /bin/ash /usr/sbin/callmonitor
 1027 root       1560 R   /bin/ash /usr/sbin/callmonitor
 1034 root       1560 R   /bin/ash /usr/sbin/callmonitor
 1051 root       1560 R   /bin/ash /usr/sbin/callmonitor
 1119 root       1436 S   sleep 10
 1120 root       1444 R   ps

So, und zum Schluß noch wie PPIDs aller Callmonitor-Prozesse:

Code:

$ for pid in $(pidof callmonitor); do echo -n "$pid  ->  "; cat /proc/$pid/status | grep PPid; done
1051  ->  PPid: 1
1034  ->  PPid: 1
1027  ->  PPid: 1
997  ->  PPid:  1
979  ->  PPid:  1
964  ->  PPid:  1
958  ->  PPid:  1
946  ->  PPid:  1
936  ->  PPid:  1
927  ->  PPid:  1
915  ->  PPid:  1
906  ->  PPid:  1
894  ->  PPid:  1
883  ->  PPid:  1
873  ->  PPid:  1
856  ->  PPid:  1
853  ->  PPid:  1
844  ->  PPid:  1
832  ->  PPid:  1
819  ->  PPid:  1
806  ->  PPid:  1
721  ->  PPid:  1
706  ->  PPid:  1
697  ->  PPid:  1
673  ->  PPid:  1
637  ->  PPid:  1
627  ->  PPid:  1
3859  ->  PPid: 3845
3858  ->  PPid: 3845
3856  ->  PPid: 3845
3845  ->  PPid: 1

RalfFriedl · 2 Okt 2007

Die meisten von den callmanager Prozessen verbrauchen nicht nur Speicher, sondern auch noch CPU-Zeit.

Was tuen die denn? Normalerweise sollte callmanager ja nur auf Anrufe reagieren. Und die andere Frage, warum werden so viele erzeugt.

Wenn die Box ans Telefon angeschlossen ist, kannst Du versuchen, bei einer frisch gestarteten Box die Prozeß-Liste zu speichern, einen Anruf zu machen und schauen, ob es mehr callmanager Prozesse geworden sind.

Wenn ja, ist noch die Frage zu klären, warum das passiert. Fehler im Call-Manager, Fehler im Zusammenspiel mit der neuen Firmware?

Die laufenden Prozesse werden auf jeden Fall in den Hintergrund gestartet (PPID=1)

kriegaex · 2 Okt 2007

Wenn ich wüßte, was sie tun, müßte ich nicht fragen...

RalfFriedl · 2 Okt 2007

Brauchst Du den callmanager auf der Box? Wenn nicht, schalte ihn erstmal aus.

Es geht Dir doch zunächst darum, zu sehen, warum der ctlmgr nicht so will wie er soll?

kriegaex · 2 Okt 2007

Ja, ich brauche ihn für Wake-on-Call. Wenn er ausgeschaltet ist, funktioniert alles sauber. Darum tippe ich auf ein Problem im Callmonitor selbst. Wenn ich mich übrigens selbst anrufe, kann ich sehr schön immer neue Instanzen von Callmonitor provozieren, bemerke ich gerade, während ich dies schreibe.

Edit: Genauer gesagt, sind es zwei Instanzen pro Anruf, egal ob ein- oder ausgehend.

RalfFriedl · 2 Okt 2007

Strate strace -f auf den callmonitor bzw. auf alle Prozesse, die dazu gehören, direkt nach dem Start, wenn es noch wenige sind. Damit sollte sich herausfinden lassen, was die machen.

Das Aufrufen der Prozesse ist vermutlich normal. Die frage ist warum sie sich nicht beenden.

kriegaex · 2 Okt 2007

Trace-Log per E-Mail unterwegs. Wir schreiben dann das Ergebnis hier später hinein, falls eines vorliegen sollte.

Update: Es sieht stark nach Callmonitor aus, gar nicht mehr nach gelöschter Kindersicherung (usermand) oder ctlmgr inzwischen, deshalb geht es auch mit meinem ursprünglichen Problem weiter im Callmonitor-Thema. Hier können wir ja weiter über die UNIX-Sockets unter /var/tmp/me_* sprechen.

Was steckt hinter /var/tmp/me_logic.ctl & Co.?

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

Mitglied

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Statistik des Forums