[NUR ZUR INFO !] rc.custom und inetd

[sf3978]

Seit mind. trunk rev. 6130 kann ich keine Anwednungen (z. B. vtund, ngircd) die in Freetz integriert sind und deren Ordner "files" ich vor der Erstellung des Freetz-Images bereits gelöscht habe, mit Hilfe der rc.custom starten. Nach dem Start bzw. reboot erhalte ich folgende Meldung in der mod.log:

/etc/init.d/rc.S: /tmp/flash/mod/rc.custom: line 6: vtund: not found

Anwendungen die in Freetz nicht integriert sind, kann ich weiter über die rc.custom starten.

EDIT:
Anwendungen (aus Freetz mit gelöschtem files-Verzeichnis) die ich nicht mit der rc.custom starte, sondern mit inetd, brauchen mehrere Anläufe bis sie starten:

Nov  6 23:59:31 fritz daemon.err inetd[1714]: can't execute '/usr/bin/vtund': No such file or directory                                                                             
Nov  6 23:59:36 fritz daemon.err inetd[1725]: can't execute '/usr/bin/vtund': No such file or directory                                                                             
Nov  6 23:59:41 fritz daemon.err inetd[1736]: can't execute '/usr/bin/vtund': No such file or directory                                                                             
Nov  6 23:59:46 fritz daemon.err inetd[1747]: can't execute '/usr/bin/vtund': No such file or directory                                                                             
Nov  6 23:59:51 fritz daemon.err inetd[1758]: can't execute '/usr/bin/vtund': No such file or directory                                                                             
Nov  6 23:59:57 fritz daemon.err inetd[1769]: can't execute '/usr/bin/vtund': No such file or directory                                                                             
Nov  7 00:00:02 fritz daemon.err inetd[1785]: can't execute '/usr/bin/vtund': No such file or directory                                                                             
Nov  7 00:00:07 fritz daemon.info vtund[2061]: VTUN server ver 3.X 11/06/2010 (inetd)

 

[hermann72pb]

@sf3978: Poste bitte deine rc.custom, bzw. wenigstens die besagte Zeile 6. Dann geh mal auf die Box und schau da bitte mit "ls", ob die Datei, die du aus rc.custom starten willst wirklich da ist und auch ausführbar ist.
Hast du schon mit vollen Pfaden versucht? Ich meine, nicht nur vtund, sondern /usr/sbin/vtund (oder wo das Ding auch immer liegt).
Ist diese vtund nicht zufällig bei dir ausgelagert?

MfG

 

[olistudent]

Was ist mit /usr/bin/vtund?

ls -al /usr/bin/vtund

external?

Gruß
Oliver

 

[sf3978]

root@fritz:/var/mod/root# ls -la /usr/bin/vtund
lrwxrwxrwx    1 root     root            19 Nov  7 09:58 /usr/bin/vtund -> /mod/external/vtund

War aber schon immer externalisiert.

EDIT:
Box 1 (vtun-client) - Zeilen 5 und 6 aus der rc.custom:

sleep 90
/usr/bin/vtund -P ##### -f /var/tmp/flash/mod/vtund.conf tunxx #####.#####.net

Box 2 (vtun-server) - Zeile aus der Konfiguration von inetd:

#:vtund
*****	stream	tcp	nowait	root	/usr/bin/vtund	vtund -s -f /tmp/flash/mod/vtund.conf -i -P *****

 

[hermann72pb]

Ist da vielleicht diese neue Geschichte mit /mod/external als Symlink im Spiel? Deine Dateien sind auf jeden Fall nun später dran, als es vorher der Fall war. Es bleibt nun zu klären, warum. Bzw. besser gesagt, warum es früher funktioniert hat und jetzt nicht mehr. Denn ich glaube kaum, dass sich etwas am mount-Verhalten geändert hat. Eher vermute ich, dass diese neue Symlink-Geschichte (warum auch immer) etwas später dran ist als früher und zum Zeitpunkt, wo rc.custom ausgeführt wird noch nicht da ist.

@sf3978: Du kannst natürlich auf autorun.sh bzw. autoend.sh auf dem Medium ausweichen, wenigstens bis das Problem geklärt ist.

MfG

 

[sf3978]

...
Eher vermute ich, dass diese neue Symlink-Geschichte (warum auch immer) etwas später dran ist als früher und zum Zeitpunkt, wo rc.custom ausgeführt wird noch nicht da ist.
...

Ich hatte schon immer sleep 60 in der rc.custom, denn ganz ohne sleep hat es früher auch nicht funktioniert. Aber jetzt funktioniert es ja auch mit "sleep 300" nicht. Und auf Box 2 hat es von inetd, diese Meldungen nie gegeben.

 

[er13]

1000 werden auch nicht helfen ;-)

1, 2 und es sollte jedem hoffentlich alles klar sein? (rc.external wartet bis /tmp/.modstarted angelegt wird, dieses wird aber erst nach rc.custom angelegt, wieso auch immer)...

@sf3978: temporäre Abhilfe, leg' in Deiner rc.custom /mod/external symlink selbst an

 

[RalfFriedl]

Ich fände es sowieso eleganter, die externen Programm dann auszuführen, wenn der externe Speicher verfügbar ist. Nur gefällt mir autorun.sh nicht, das erinnert mich an ein anderes Betriebssystem, das ungefragt alles startet, was irgend jemand anschließt.

 

[sf3978]

ln -s /var/media/ftp/uStor01/external /mod/external

in der rc.custom, hat geholfen.
Danke er13.

 

[hermann72pb]

Nur gefällt mir autorun.sh nicht, das erinnert mich an ein anderes Betriebssystem, das ungefragt alles startet, was irgend jemand anschließt.

Deswegen hat cuma ziemlich viel Druck gemacht und es letztendlich selbst vollzogen, ohne auf mich zu warten, dass es per WebIF deaktiviert werden kann.
Fürher war es per menuconfig deaktiverbar, seit FREETZMOUNT hatte ich es zunächst permanent reingebracht mit der Idee es irgendwann mal per WebIF zu steuern.
Auch im besagten Betriebssystem kann man es irgendwo deaktivieren. Zumindest ist es bei meinem Win7 -warum auch immer- deaktiviert, was mich wiederum massiv stört, wenn ich irgendeine Installations-CD reinlege und dann per Explorer nach autorun.exe manuell suche.

MfG

 

[RalfFriedl]

Es geht mir darum, daß es gut wäre, wenn bei Verfügbarkeit des external-Datenträgers die entsprechenden Programme gestartet werden, ohne daß deswegen die autorun.sh von jedem (anderen) Datenträger auch gestartet wird. Dagegen hilft nicht eine Möglichkeit, das in menuconfig oder auf der Box für alle Datenträger ein oder aus zu schalten.

 

[olistudent]

Das autorun feature hat nichts mit dem Start von external zu tun.

@sf3978
Es sollte auch funktionieren, wenn du deine die Anweisungen in deiner rc.custom in einen Block packst und den (inklusive dem sleep) im Hintergrund startest.
Warum startest du vtund eigentlich aus der rc.custom? Es wird doch von external selbst gestartet oder?

Gruß
Oliver

 

[sf3978]

...
Warum startest du vtund eigentlich aus der rc.custom? Es wird doch von external selbst gestartet oder?
...

Ich habe ja geschrieben, dass ich bei einigen Paketen das files-Verzeichnis gelöscht habe.
Es geht auch nicht nur um die rc.custom. inetd hat auch Probleme.

 

[olistudent]

Wie kommt der vtund in die inetd.conf? Das hängt natürlich auch damit zusammen, dass du nicht den normalen Freetz Mechanismus nutzt.

Gruß
Oliver

 

[sf3978]

Manuell. Das ist richtig. Ich experimentiere.

 

[cuma]

Nur gefällt mir autorun.sh nicht, das erinnert mich an ein anderes Betriebssystem, das ungefragt alles startet, was irgend jemand anschließt.

Was gefällt dir an Linux nicht? http://www.google.de/search?q=autorun.sh Oder meinst du autorun.inf??

@sf3978:
Du könntest den Aufruf von rc.custom nach /tmp/flash/mod/rc.external verschieben. Diese wird nach dem Ausführen von external gestartet (damit nur wenn external aktiviert ist und die Partition gemountet ist). Du musst im Skript bei $1 zwischen "load" und "unload" unterscheiden

 

[RalfFriedl]

Bei der Box ist es autorun.sh, die automatisch ausgeführt wird, und bei Windows ist es autorun.inf. Mit Linux an sich hat beides nichts zu tun.

 

[cuma]

Offensichtlich eine Wissenslücke. Hast du den Link von mir mal angeklickt? Mein Windows 7 und Ubuntu 10irgendwas verhalten sich bei der autorun.sh/autorun.inf genau gleich. Beide Fragen ob sie das Skript ausführen sollen. Da die Box meist keinen Monitor angeschlossen hat gibt es nur dir Möglichkeit das Ausführen im Webinterface allgemein freizuschalten

 

[sf3978]

...
Du könntest den Aufruf von rc.custom nach /tmp/flash/mod/rc.external verschieben. ...

Ja das geht auch. Aber dann muss ich alle Aufrufe aus der rc.custum nach /tmp/flash/mod/rc.external verschieben. Und das Problem mit inetd ist dann auch nicht gelöst. Ich finde die Lösung mit dem symlink, wie von er13 vorgeschlagen, zielführender und eleganter. Danke für die Mitteilung.

 

[hermann72pb]

@sf3978: Die Lösung von er13 ist keine Lösung, das ist nur Workarround. Die Frage ist nur, ob da immer noch Handlungsbedarf besteht, da in #7 an eine unlogische Verkettung verwiesen wurde.

MfG