IPC nach Reboot

[Lutz (Gast)]

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

ipcrm -a

alle IPCs loeschen.

Jedoch sehe ich mit

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

[Jörg W. (dl8dtl) (Moderator)]

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 …

[foobar (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

foobar schrieb:
> Was sein könnte: irgend einer der IPC-Resourcen ist erschöpft.

Nach einem Reboot?

[foobar (Gast)]

>> 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 ...

[Icke (Gast)]

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...

[Schmittchen (Gast)]

Lutz schrieb:
> ich habe ein Problem mit IPC

Was genau ist ein IPC? Meinst du damit einen Industrie-PC:

https://www.distrelec.de/de/simatic-ipc127e-industrie-box-pc-6ghz-atom-e3940-4gb-siemens-6ag4021-0ab11-1ba0/p/30149310?channel=b2c&price_gs=1412.53&source=googleps&ext_cid=shgooaqdede-na&kw=%7Bkeyword%7D&gclid=EAIaIQobChMIqKqxpOGf6gIVE0MYCh3FJA-xEAQYAyABEgKpnPD_BwE

[Jörg W. (dl8dtl) (Moderator)]

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.

[Jörg W. (dl8dtl) (Moderator)]

Schmittchen schrieb:
> Was genau ist ein IPC?

Im Gegensatz zu dir haben das alle anderen im Thread verstanden - also 
halt dich am besten raus.

[Lutz (Gast)]

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).

[foobar (Gast)]

> 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 (Gast)]

Schmittchen schrieb:
> Lutz schrieb:
>> ich habe ein Problem mit IPC
>
> Was genau ist ein IPC? Meinst du damit einen Industrie-PC:

InterProcessCommunication, also Shared Memory, Semaphoren oder Message 
Queues
https://de.wikipedia.org/wiki/Interprozesskommunikation

[Jörg W. (dl8dtl) (Moderator)]

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.

[Lutz (Gast)]

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".

[foobar (Gast)]

> Aber ich sehe vor und nach "ipcrm -a" das gleiche Resultat in "ipcs"

Man übersieht schnell was.  Ich würd es so angehen:

$ cat /proc/sysvipc/* >a
$ programm  # abbruch mit Fehler
$ cat /proc/sysvipc/* >b
$ ipcrm -a
$ cat /proc/sysvipc/* >c
$ programm # läuft jetzt
$ diff -u b c
$ diff -u a b
$ diff -u a c

[Lutz (Gast)]

foobar schrieb:
>> Aber ich sehe vor und nach "ipcrm -a" das gleiche Resultat in "ipcs"
>
> Man übersieht schnell was.  Ich würd es so angehen:
>
>

> $ cat /proc/sysvipc/* >a
> $ programm  # abbruch mit Fehler
> $ cat /proc/sysvipc/* >b
> $ ipcrm -a
> $ cat /proc/sysvipc/* >c
> $ programm # läuft jetzt
> $ diff -u b c
> $ diff -u a b
> $ diff -u a c
>

Das hört sich gut an! Wird am Montag geprüft :)

[Rolf M. (rmagnus)]

Oder gleich ein threeway-diff mit meld oder kdiff3 oder so, falls 
verfügbar.
meld a b c

[Lutz (Gast)]

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!