Re: DSL Verbindung richtig beenden?

Heino Tiedemann <rotkaps_spam_trap(at)gmx.de> wrote:
> Andreas Braukmann <braukmann(at)tse-online.de> wrote:
> > Damit ist ein
> > "Unix Domain Socket" gemeint. "Unix Domain Sockets" sind
> > nicht an eine Netzwerk-Adresse gebunden, sondern werden
> > ueber eine (spezielle) Datei im lokalen Dateisystem ange-
> > sprochen.
>
> Also, sowas wie ein Handle, ein "grif" (im weitesten sinne eine ID),
> über dem man dann ppp ansprechen kann? Nicht socket im herkömmlichen,
> Netzwerksinn?

Es ist ein Socket im herkömmlichen Sinne. Sockets können
auf IP-Adressen gebunden werden (Internet-Domain-Sockets),
auf Pfadnamen im Dateisystem (UNIX-Domain-Sockets) oder
auch auf andere Dinge. Sie alle werden genau gleich ver-
wendet, d.h. mit den üblichen Systemcalls wird darauf zuge-
griffen (listen, accept, connect usw.). Details kann man
bei Stevens nachlesen.

> > LocalName; ein TcpPort waere entweder numerisch oder der
> > Name eines Netzwerk-Services (wie in /etc/services defi-
> > niert). Damit waere der ppp-Daemon dann auch uebers Netzwerk
> > fernbedienbar.
>
> Ah, die mapage sagt also:
>
> set server mit dem parameter
> socket:port ODER
> localName ODER
> none ODER
> open ODER
> closed, und wenn gewünscht ein Passwort?

Mir scheint, Du bist mit der üblichen Grammatik für Syntax
bzw. Synopsen nicht vertraut.

Mit eckigen Klammern "[]" werden optionale Teile bezeich-
net, und mit einem senkrechten Strich "|" werden alternati-
ve Teile getrennt. Die Synopsis

set server|socket TcpPort|LocalName|none|open|closed [password [mask]]

bedeutet also: Auf »set« folgt entweder »server« oder
»socket«, darauf folgt entweder ein TcpPort, ein Localname,
»none«, »open« oder »closed«. Optional kann anschließend
noch ein Paßwort angegeben werden, und danach -- wiederum
optional -- eine Maske für die Zugriffsrechte. Bei dem
konkreten Kommando

set server /var/run/internet "" 0177

ist "/var/run/internet" einleuchtenderweise ein LocalName
(das steht in der manpage auch noch ausführlicher), gefolgt
von einem leeren Paßwort, und schließlich 0177 als Maske.

Wenn das aus irgendeinem grund nicht klappt, schau doch mal
mit »ls -l /var/run« nach, ob er den Socket tatsächlich an-
gelegt hat. Der sollte so ähnlich aussehen:

srw------- 1 root wheel 0 Aug 17 12:33 internet

Gemäß den Zugriffsrechten (Maske 0177) kann natürlich nur
der Eigentümer darauf ein connect() machen, d.h. es geht
nur, wenn Du pppctl als root aufrufst.

> das Logfile sagt da auch nix. ein tail -f brachte zutage, das sich das
> Logfile nicht verändert.

Dann ist entweder der Loglevel von ppp nicht entsprechend
eingestellt, oder das pppctl konnte den laufenden ppp-Pro-
zeß gar nicht erst erreichen. Letzteres erscheint mir
wahrscheinlich, denn:

> einfach nur auf der Shell:
> pppctl: cannot connect to socket 3000: Connection refused

Wie sah der pppctl-Aufruf genau aus? Das sieht mir eigent-
lich danach aus, als wen Du versucht hast, auf den TCP-Port
3000 zuzugreifen, nicht auf den UNIX-Domain-Socket. Das
kann dann natürlich nicht gehen.

> wenn ich "ppp -forground" benutze, und es dann mit ^Z und "bg" in den
> hintergrund schicke - dann ist es noch lange keine daemon, oder?

Richtig. Der Prozess ist dann immer noch an Deine Shell-
Session gebunden, unterliegt deren Job-Control und hat de-
ren Dateideskriptoren (stdin, stdout, stderr). Ein Daemon
tut mehr, als nur im Hintergrund einer Shell zu laufen.

Wenn Du als Shell die zsh verwendest, kannst Du einen im
Hintergrund laufenden Prozeß mit »disown« von der Shell
abkoppeln (oder gleich mit »&!« starten) -- das kommt einem
Daemon dann schon etwas näher. Davon abgesehen gibt es un-
ter FreeBSD noch /usr/sbin/daemon, siehe die daemon(8) man-
page.

Mir ist allerdings nicht ganz klar, weshalb Du das bei ppp
brauchst. Bei -auto, -ddial und -background daemonifiziert
sich ppp selbständig.

> > > ich möchte ppp sauber benenden, ohne killall.
> >
> > Dann nimmst du halt nicht das "dreckige" killall, sondern
> > ein ganz sauberes "kill"

Das ist nur marginal sauberer. :-)

pppctl /var/run/internet close

Wobei es einem natürlich letztlich egal sein kann, wie sau-
ber eine Lösung ist, solange sie funktioniert und keine ne-
gativen Nebenwirkungen hat. Insbesondere mit killall soll-
te man sehr vorsichtig sein, da man damit schnell mal mehr
killen kann, als man beabsichtigt hatte.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message