Unix-Socket im lokalen FS und 'rm'

[Jochen Luebbers]

Hallo,

ich habe hier eine einfache Client-Server Architektur, wo n Clients
einem Server Nachrichten über einen Unix-Socket -
socket(AF_UNIX, SOCK_DGRAM, 0) - zuschieben. der Server macht seinen
Socket mittels geeignetem bind()-Aufruf im Dateisystem sichtbar und
empfängt ab dann via recv() Datagramme.

Alles funktioniert soweit auch sehr nett. Wenn ich allerdings den
Eintrag im Dateisystem mittels 'rm <Name von meinem Socket>' lösche,
können die Clients nichts mehr senden, der Server bekommt aber nichts
davon mit. Ich stelle mit vor, dass er mit seinem Socket halt noch brav
auf dem nun "stale Filehandle" hängt.

Kann man das Verhalten ändern? So dass das Betriebssystem den Prozess
irgendwie informiert (SIGNAL?), wenn sein Socket unerreichbar wird?

Ich habe die man-Pages zu socket(), bind(), sendto() und revc() sowie
unix(7) gelesen, habe aber nichts gefunden (oder eben etwas übersehen),
was in die Richtung geht. Auch ein paar Versuche mit recv()-Optionen
haben an diesem Verhalten nichts ändern können (was mich nicht
überraschte).

Danke im Voraus für alle Hilfe
Jochen
--
"Who desire to give up freedom in order to gain security
will loose both in the end."

[Rainer Weikusat]

Jochen Luebbers <jo...@buerotiger.de> writes:
> ich habe hier eine einfache Client-Server Architektur, wo n Clients

> einem Server Nachrichten �ber einen Unix-Socket -

> socket(AF_UNIX, SOCK_DGRAM, 0) - zuschieben. der Server macht seinen
> Socket mittels geeignetem bind()-Aufruf im Dateisystem sichtbar und

> empf�ngt ab dann via recv() Datagramme.

>
> Alles funktioniert soweit auch sehr nett. Wenn ich allerdings den

> Eintrag im Dateisystem mittels 'rm <Name von meinem Socket>' l�sche,
> k�nnen die Clients nichts mehr senden, der Server bekommt aber nichts

> davon mit. Ich stelle mit vor, dass er mit seinem Socket halt noch brav

> auf dem nun "stale Filehandle" h�ngt.
>
> Kann man das Verhalten �ndern? So dass das Betriebssystem den Prozess

> irgendwie informiert (SIGNAL?), wenn sein Socket unerreichbar wird?

Meines Wissens nach nein. Falls Dein Zielsystem Dir ein API anbietet,
mit dessen Hilfe ein Prozess von Aenderungen im Dateisystem
unterrichtet werden kann (zB dnotify oder inotify fuer Linux)
koenntest Du das benutzen. Andernfalls bliebe nur die Moeglichkeit, in
regelmaessigen Abstaenden 'probe'-Nachrichten an die Socketaddresse zu
schicken und auf dabei auftretende Fehler oder auf das Phaenomen, dass
diese Nachrichten den Server-Teil nie erreichen (weil mittlerweile
'jemand anderes' eine neue Socket mit diesem Namen erzeugt hat)
entsprechend zu reagieren.

[Jochen Lübbers]

Rainer Weikusat <rwei...@mssgmbh.com> schrieb:
>> Kann man das Verhalten ändern? So dass das Betriebssystem den Prozess

>> irgendwie informiert (SIGNAL?), wenn sein Socket unerreichbar wird?
>
> Meines Wissens nach nein.

Das beruhigt mich in sofern, als dass ich nichts gröblich übersehen
habe.

> Falls Dein Zielsystem Dir ein API anbietet,
> mit dessen Hilfe ein Prozess von Aenderungen im Dateisystem
> unterrichtet werden kann (zB dnotify oder inotify fuer Linux)
> koenntest Du das benutzen.

Ja, ist zur Zeit ein Linux (CentOS 6), da gibt es 'inotify'.

> Andernfalls bliebe nur die Moeglichkeit, in
> regelmaessigen Abstaenden 'probe'-Nachrichten an die Socketaddresse zu
> schicken und auf dabei auftretende Fehler oder auf das Phaenomen, dass
> diese Nachrichten den Server-Teil nie erreichen (weil mittlerweile
> 'jemand anderes' eine neue Socket mit diesem Namen erzeugt hat)
> entsprechend zu reagieren.

So einen Weg hatte ich auch schon angedacht, dass der Server sich von
Zeit zu Zeit selbst eine "Testnachricht" sendet, und wenn er die nicht
mehr empfängt, dann einfach "den Löffel" abgibt.

Andererseits frisst so ein Server-Prozess, der in einem recv()-Aufruf
blockiert ist, auch nicht viele Resourcen. (Der Speicherbedarf ist
statisch und ohnehin sehr gering.) Und sowieso soll der Fall ja gar
nicht eintreten und überhaupt...

Ich mag es freilich, wenn Programme, für die ich die Verantwortung
(übernommen) habe, auch robust sind und auch in Betriebssituationen, von
denen ich fest überzeugt war, dass sie niemals auftreten werden, noch
sinnvoll agieren (z.B. Fehlermeldung und Tschüß).

Danke für Deine schnelle Antwort.
Jochen
--
"Wer die Freiheit aufgibt, um Sicherheit zu gewinnen,
der wird am Ende beides verlieren"

[Stefan Reuther]

Jochen Lübbers wrote:
> Rainer Weikusat <rwei...@mssgmbh.com> schrieb:

>>Andernfalls bliebe nur die Moeglichkeit, in
>>regelmaessigen Abstaenden 'probe'-Nachrichten an die Socketaddresse zu
>>schicken und auf dabei auftretende Fehler oder auf das Phaenomen, dass
>>diese Nachrichten den Server-Teil nie erreichen (weil mittlerweile
>>'jemand anderes' eine neue Socket mit diesem Namen erzeugt hat)
>>entsprechend zu reagieren.
>
> So einen Weg hatte ich auch schon angedacht, dass der Server sich von
> Zeit zu Zeit selbst eine "Testnachricht" sendet, und wenn er die nicht
> mehr empfängt, dann einfach "den Löffel" abgibt.

Du könntest auch einfach den Socket in einem Verzeichnis anlegen, in dem
nur der Serverprozess Schreibzugriff hat.


Stefan