Hallo zusammen,
ich habe ein Problem mit IPC auf einem Linux Ubuntu 16.04 64bit (kernel
4.4.0-75-generic).
Ein third party Programm benutzt IPCs. Das Programm ist vom Kunden
gestellt. Wenn ich den Rechner neustarte, funktioniert das Programm aber
nicht richtig. Ich muss zuerst mit
1
ipcrm -a
alle IPCs loeschen.
Jedoch sehe ich mit
1
ipcs
keinen Unterschied bevor und nach dem Loeschen. Die einzigen Ressourcen
(Shared Memory), die nach einem Neustart gelistet werden wurden vom X
angelegt/genutzt (xfwm4, Xorg, xfdesktop).
Wenn ich die IPCs geloescht habe, kann ich das Programm beliebig oft
neustarten/stoppen und es funktioniert solange bis ich den Rechner
neustarte.
Mit ipcrm -a --verbose sehe ich auch nicht, was da noch geloescht werden
koennte.
Ich bin eigentlich davon ausgegangen, dass die IPC Ressourcen einen
Neustart nicht "ueberleben". Aber anscheinend ist da trotzdem noch
irgendwo etwas, das von ipcrm auch geloescht wird. Habt ihr eine Idee?
Vielen Dank und viele Gruesse
Lutz
Lutz schrieb:> Ich bin eigentlich davon ausgegangen, dass die IPC Ressourcen einen> Neustart nicht "ueberleben".
So sollte es sein.
Lass das Programm doch mal mit strace laufen und schaun nach, worüber es
stolpern könnte. Oder frag den Kunden nach einer ordentlichen
Fehlermeldung …
Was sein könnte: irgend einer der IPC-Resourcen ist erschöpft. Die
hängen evtl noch rum, auch wenn der Prozess beendet wurde, bis sie
explizit gelöscht werden, z.B. durch ein "ipcrm -a". Dadurch wird
wieder was frei und das Programm läuft.
>> Was sein könnte: irgend einer der IPC-Resourcen ist erschöpft.>> Nach einem Reboot?
Nun ja, er hat dX schon laufen und Resourcen sind bereits belegt. Da
reicht ein blödes Programm, dass das IPC_RMID vergessen hat ...
Jörg W. schrieb:> Oder frag den Kunden nach einer ordentlichen Fehlermeldung …
Schon passiert :P Aber man kennt die Kunden ja... ;)
Das mit strace schaue ich Montag an. Das "Problem" dabei ist, dass das
"Program" eigentlich eine shared-Library ist, die von einem komplexen
Framework geladen wird. Mal schauen, ob ich da irgendwas sehen/zuordnen
kann..
Vielen Dank schonmal!
Das interessante ist auch, dass bei einem Neustart vom Programm alles
funktioniert, obwohl ressourcen eventuell nicht freigegeben wurden (das
sehe ich auch mit ipcs).
Ich hätte es verstanden, wenn das Programm streikt, wenn nicht
aufgeräumt wurde. Aber bei einem "jungfräulichen" Start vom PC streikt
es...
foobar schrieb:> Da reicht ein blödes Programm, dass das IPC_RMID vergessen hat ...
Das sollte dann allerdings auch mit ipcs -a zu sehen sein.
Wenn ipcs -a vor und nach dem ipcrm keinen Unterschied zeigt, es aber
danach dann geht, ist das schon außerordentlich seltsam.
Ups, der Post von "Icke" ist auch von mir (TO). Bin an einem anderen
PC...
foobar schrieb:>>> Was sein könnte: irgend einer der IPC-Resourcen ist erschöpft.>>>> Nach einem Reboot?>> Nun ja, er hat dX schon laufen und Resourcen sind bereits belegt. Da> reicht ein blödes Programm, dass das IPC_RMID vergessen hat ...
Aber ich sehe vor und nach "ipcrm -a" das gleiche Resultat in "ipcs"
(auch mit den unterscheidlichen Optionen -c -t -p).
Die Ressourcen werden laut "ipcs" auch nach dem Start vom Rechner nicht
mehr geändert ("ipcs -t" zeigt kein geändertes "changed" an).
> Das sollte dann allerdings auch mit ipcs -a zu sehen sein.
Jo.
> Wenn ipcs -a vor und nach dem ipcrm keinen Unterschied zeigt, es aber> danach dann geht, ist das schon außerordentlich seltsam.
Genau - deshalb vermute ich eher ein Problem beim Tester ;-)
Lutz schrieb:> InterProcessCommunication, also Shared Memory, Semaphoren oder Message> Queues
Genau genommen, die von ihrer Semantik her nicht wirklich ins
Unix-Konzept passende SysV-IPC. Braucht man eigentlich nicht (lässt sich
auch alles anders erreichen), aber wenn das ein Kundenprogramm ist,
kannst du daran nichts ändern.
foobar schrieb:>> Das sollte dann allerdings auch mit ipcs -a zu sehen sein.>> Jo.>>> Wenn ipcs -a vor und nach dem ipcrm keinen Unterschied zeigt, es aber>> danach dann geht, ist das schon außerordentlich seltsam.>> Genau - deshalb vermute ich eher ein Problem beim Tester ;-)
Den vermute ich fast auch, bzw. kann es mir halt nicht erklären :P
Deswegen hab ich auch erst eine Nacht drüber geschlafen und das heute
nochmal probiert mit dem gleichen Ergebnis.
Eventuell ist es der Einfluss aus dem Gesamtsystem...
Die Server sind diskless und bekommen ihr OS über PXE (read-only).
Zusätzlich wird ein RW filesystem gemountet (~/home/, /var/log, etc.).
Den Rechner reboote ich mit einem einfachen "sudo reboot".
So, nach dem Wochenende habe ich es mir nochmal angeschaut.
Es ist anscheinend kein Problem vom IPC nach dem Reboot (wie zu erwarten
war).
Das Programm macht anscheinend irgendwas komisches beim Initialisieren.
Es startet naemlich auch nicht, wenn ich "ipcrm -a" VOR dem reboot
mache.
Es sieht so aus, als ob es einfach zwei Anlaeufe braucht bis alles
initialisiert ist...
Nach dem ersten Anlauf ist aber eine Ressource geblockt und deswegen ist
ein "ipcrm -a" noetig. Ich sehe dass es nach dem ersten Anlauf
Aenderungen im SHM vom X gab.
Dann geht das jetzt zurueck an den, der das verbrochen hat, da ich hier
nichts weiter machen kann.
Ich danke euch vielmals fuer die Hilfe!
