Mehrmaliges Starten von Paketen

[cuma]

Mir ist heut aufgefallen, dass bei einigen Paketen mehrmaliges Starten mit /etc/init.d/rc.$PKG start möglich ist, zB knockd, inadyn-mt, nfsd

Abfangen in der modlibrc hilft aber momentan nur bei einigen die modlib_start nutzen

Changeset r4935

[cuma]

(In [4936]) revert r4935 * does not work as expected * starts daemon with "rc.$PKG start" even if it is "inetd"

(refs #834)

[oliver]

Viele Skripte sehen zur Zeit so aus (rc.dropbear):

echo -n "Starting $DAEMON_LONG_NAME..."
	if modlib_check_running; then
		echo 'already running.'
		exit 0
	fi

	modlib_startdaemon $DAEMON $Parameter
	exitval=$?
	if [ "$exitval" -eq 0 ]; then
		echo 'done.'
	else
		echo 'failed.'
		exit $exitval
	fi

Vielleicht sollten wir die modlib_startdaemon Funktion so erweitern oder eine neue Funktion dafür einführen. Die von dir gewählte Stelle in modlib_start ist nicht okay, da man die Dienste trotzdem noch mit "rc.dienst start" mehrmals starten könnte. Wobei auch modlib_check_running im inetd Fall versagt.

[cuma]

Dieses Abfragen von $? sollte man auch noch vereinfachen, nur wie kann man den Returnwert an die modlibrc weitergeben? Ist eine weitere Funktion (zB modlib_start_return) nötig?

Die Abfrage auf "running" und auf "inetd" kann man sich nun mit meinem Patch für modlibrc sparen. Ich hab im Patch noch die Pakete dnsmasq, cron, openntpd und knockd angepasst, die man vorher mehrmals starten konnte.

[cuma]

Neue Version. Sie behebt auch das von oliver angesprochene Problem. Außerdem wird sichergestellt dass jeder daemon eine .pid anlegt. Die in der rc.vsftpd auskommentierten Zeilen sind noch dem modlibrc-Patch nicht mehr nötig! Habe auch noch die komplette modlibrc angehängt zum besseren Lesen.
hat noch jemand lust zum Testen?

[Whoopie]

Im modlibrc.patch erwähnst Du "return 3", aber es wird "return 4" ausgeführt (Zeile 274, wenn man sich den Patch im Trac anschaut).

[cuma]

Wenn die modlib_status "return 3" macht, bedeuted es dass der daemon "stopped" ist. Hab das halt so gelassen wie es vorher war. nur hab ich nicth verstanden weshald die "3"

[hermann]

3 ist schon korrekt, cuma. Das hatten wir hier irgendwo bereits diskutiert. Es gibt unter Linux eine Vereinbarung, welche Rückgabewerte die rc-Skripte liefern. "3" steht tatsächlich für "stopped".

[hermann]

Übrigens, ich habe in modlibrc eine Funktion eingeführt gehabt, mit der man auch unter inetd laufende Dienste testen kann, ob sie denn laufen (besser gesagt eingetragen sind). Man benötigt dafür allerdings Portnummer und den Namen des Daemons. Die Nutzung von dieser Funktion wäre die sicherste Methode festzustellen, ob ein Dienst läuft oder nicht (auch unter inetd). Ich hatte es bereits in rc.ftpd realisiert und könnte es hierher (nach modlibrc) portieren. Man würde dann die Rückgabewerte von modlib_status, modlib_running usw. etwas anpassen müssen. Das wäre aber machbar.

[cuma]

Passt abe rnciht ganz, bei  http://www.linuxbase.org/~gk4/wip-sys-init.html ist zu lesen:

If the status command is given, the init script will return the following exit status codes. 
0	program is running or service is OK
1	program is dead and /var/run pid file exists
2	program is dead and /var/lock lock file exists
3	program is not running
4	program or service status is unknown
5-99	reserved for future LSB use
100-149	reserved for distribution use
150-199	reserved for application use
200-254	reserved

Es gibt also nichts für "inetd". Somit müsste man für Freetz was eigenes erfinden. Ich definiere kurzerhand mal die 5 und hänge später einen neuen Patch an).

PS: Ist aber nicht nett dass du mir das Ticket klaust…

[hermann]

@cuma: Mit "reassign to" war nicht so gemeint. Ich hatte nicht darauf geachtet, was unten gewählt war. Normalerweise steht da "leave as signed". Warum es plötzlich umgesprungen war, keine Ahnung. Vielleicht wegen des doppelten postings. Übernimm bitte die Zugehörigkeit wieder an dich zurück. Ich kann es leider nicht machen.

Zu deinen inetd-Änderungen. Du arbeitest leider immer noch auf die alte bewahrte Methode weiter, wie es bis jetzt realisiert war. Wir hatten mit Ralf jedoch eine neue "dynamische" Methode für inetd ausgedacht, die ich teilweise mit rc.ftpd ausprobiert hatte. Diese Methode geht etwas anders vor als die alte und ist nicht so kompliziert. Bezogen auf die start, stop und status Skripte bedeutet es, dass nicht nur "inetd" als Status gibt, sondern "intetd running" und "inetd stopped". Im Unterschied zur alten Methode erlauben wir auch das starten und das stoppen von den Paketen, selbst wenn sie über inetd laufen. In der alten Methode war das nicht so. "starten" bedeutet, dass wir dieses Paket unter inetd registrieren und inetd HUPen. Beim "stoppen" wird das Paket aus der inetd-config ausgetragen und inetd wird geHUPt. Dazu hatte ich die Dienste-cgi-Seite bereits etwas geändert, sodass sie solche Status-Anzeigen beherrscht.
Wie gesagt, "5" ist schon ok, aber lass uns dann bitte auch noch "6" einführen. Und deine Behandlung der herkömmlichen inetd-Methode ist auch gut, um Kompatibilität der bereits existierenden Pakete zu gewährleisten. Ich werde aber deine Modifizierungen noch etwas erweitern, um die dynamische Behandlung von inetd da reinzubringen, wenn du natürlich nichts dagegen hast.

[hermann]

@oliver: Danke fürs Ändern vom owner. @cuma: Deine Änderung in modlibrc läuft leider nicht ganz sauber, wenn mehrere Dienste auf einem Port lauschen wollen. Ich hatte die Behandlung von solchen Fällen mit den letzten Änderungen in rc.inetd halbwegs abgefangen gehabt und es hat damals funktioniert. Mit deiner letzten Änderung läuft irgendwas schief mit der Erkennung vom Status, wenn man z.B. AVM-ftpd laufen hat und in dem Moment vsftpd über inetd aktivieren will (soll heißen eintragen und neu starten). In diesem Fall wird anscheinend von modlib_check_running 3 geliefert (warum auch immer). Und wenn du 3 siehst, sagst du ihm, dass er "start" ausführen soll. Die Funktion "start" von vsftpd scheint jedoch den Aufruf von modlib_start zu beinhalten. Folge: start → modlib_start → start → modlib_start … (endlose Schleife). Die Box rebootet dann irgendwann und alle meinen "mount -o bind" sind weg.
Lass mich bitte etwas genauer drüber schauen und meine dynamischen inetd-Auswertungen da einbringen. Ich werde heute oder morgen hier etwas posten, sobald ich was lauffähiges habe. ok?

[cuma]

Dieses "inetd (stopped)" ist mir schon aufgefallen, wusste aber ehrlich gesagt damit nichts anzufangen. Wie findest du es wann man die "Dienste" Seite lässt wie sie ist, und dem Package "inetd" eine cgi spendiert wo man dann der Status der Dienste angezeigt wird und man konfigurieren kann?
Es war eigentlich angedacht, "modlib_start" analog zu "modlib_stop", "modlib_status" und "modlib_reload" in den rc-Skripte genutzt werden. Dann braucht man nicht in jedem rc-Skript auf "running", "enabled" usw zu testen. Bin ehrlich gesagt noch nie auf die Idee gekommen, 2 verschieden FTP-Server zu starten. Wusste ja vorher schon, dass es nicht funktionieren kann :] Da müsste man wohl nochmal reinschauen
Nicht verwirren lassen, rc.vsftpd update ich gleich noch. Allerdings wegen einem anderen Fehler, also unabhängig von diesem Ticket und ohne modlib_start.

[hermann]

@cuma: nene, unsere Ideen mit Ralf gingen etwas weiter. Deswegen war diese "dynamische" Modifikation von inetd. Im Unterschied zur alten Methode kümmert sich nicht inetd um die einzelnen Pakete, sondern die Pakete machen es für sich selbst und schreiben einfach in eine Datei namens package.inetd ihre Zeile mit den Startparametern. inetd sammelt dann diese inetd-config-Dateien zu einer, wenn er geHUPt wird. Das ist die Hauptidee dahinter.
Zur modlib-Zenralisierung bin ich voll bei dir. Ich versuche es aber noch etwas weiter verallgemeinen. Einiges läuft bei mir schon, an einigen Stellen gibt es noch was zu tun. Ich melde mich, sobald es halbwegs rund wird.
Zur Modifizierung der Seite mit den Diensten würde ich es doch vorziehen. Neben dem running/stopped/inetd kommen bei mir da noch einige weiteren Variationen. Lass euch überraschen.

[hermann]

@cuma: Ich habe den Übeltäter in deinem Patch gefunden. Wozu hast du bei modlib_reload eine Zeile irgendwo in der Mitte hinzugefügt:

config 2>/dev/null

???
Dadurch kommt es bei rc.inetd zu einer endlosen Schleife. Ich hatte bei mir die Zeile erstmal rauskommentiert.

[cuma]

Das ruft die config der rc auf ("if available runs "config" of rc.$DAEMON "). Das hab ich eingebaut, da bei einem neuen starten manche Daemons vorher noch ein config (was auch immer da drinnen ist) brauchen.

Hab mir das mit dem inetd nochmal angeschaut und verstehe es nicht so ganz was dir da noch fehlt. Momentan läuft es so:
Beispiel wol-cgi:
cat /etc/default.wol/wol.inetd

. /mod/etc/conf/wol.cfg
inetdcfg_desc="WOL web interface"
inetdcfg_port=$WOL_PORT
inetdcfg_sock=stream
inetdcfg_proto=tcp
inetdcfg_flags=nowait
inetdcfg_user=root
inetdcfg_exe=/usr/bin/webcfg-wol
inetdcfg_arg0=webcfg-wol
inetdcfg_args="-i"

daraus entsteht dies:
cat /tmp/flash/inetd.conf |grep wol

#:wol: WOL web interface
82      stream  tcp     nowait  root    /usr/bin/webcfg-wol     webcfg-wol -i

und daraus wird /etc/inetd.conf generiert:
cat /etc/inetd.conf |grep wol

82      stream  tcp     nowait  root    /usr/bin/webcfg-wol     webcfg-wol -i

Wenn ich nun im Webinterfce WOL von "inetd" auf "disabled" stelle:
cat /tmp/flash/inetd.conf /etc/inetd.conf |grep wol

Also kann man einen Daemon doch ganz einfach ausschalten

[hermann]

Wenn mehrere Daemons über inetd laufen, kann man sie mit dieser alten Methode nicht so bequem starten und stoppen. Die start- und stop- Knöpfe sind in diesem Fall auch deaktiviert. Nach der neuen Methode kannst du Daemons separat starten und stoppen, ohne, dass du jedes Mal auf die Einstellungsseite von dem Daemon gehen musst. Die Behandlung ist ebenfalls deutlich einfacher und bedarf lediglich Anpassung an modlibrc und einiger speziellen Abschnitte in rc-Skripten (s. rc.ftpd)
Wie gesagt, wir hatten mit Ralf diese inetd-Methode ausführlich diskutiert und eine bessere Behandlung dafür ausgedacht, als diese mit modinetd-Binary, Tausenden config-Dateien und einem komplizierten Sammeldienst. Das hatte ich bereits anhand ftpd erfolgreich ausprobiert und werde hier meine Lösung für modlibrc und andere Daemons posten. Die neue Methode bleibt mit der alten auch kompatibel, keine Sorgen
Das Laden vom config in modlib_reload ist für inetd auf jeden Fall tödlich. Lass bitte die Pakete selbst dafür sorge tragen, dass die configs neu eingelesen werden, wenn es denn erforderlich ist.

[hermann]

Irgendwas ist da mit dem Updaten von inetd über cgi faul. Das war wahrscheinlich der Grund, warum cuma in die reload-Sektion diese config-Zeile eingebaut hat. Die Frage ist, ob es denn immer so faul war, oder ob wir durch irgendeine Änderung was zerschossen haben.
Beobachten hatte ich es z.B. an WOL-CGI. Dort wird z.B. rc.wol gar nicht neu gestartet, wenn man zwischen Automatisch/Manuell/Inetd umstellt. Bei vsftpd wird nur dann rc.vsftpd reload durchgeführt, wenn man nach "Automatisch" oder nach "Inetd" wechselt. In beiden Fällen werden dann inetd-Sachen nicht upgedatet. Und das ist das, was mich stört. Man kann nicht sauber zwischen inetd- und daemon-Modis hin und her wechseln. Wenigstens nach dem Verlassen von inetd-Modus bleibt z.B. vsftpd immer noch über inetd eingetragen und lässt sich nicht nativ als daemon starten. War das schon immer so?

[oliver]

Wenn ich im Webinterface beim vsftpd von inetd auf Automatisch umstelle, dann bekomme ich folgendes:

Saving settings...done.
Saving vsftpd.cfg...done.

Updating inetd config for vsftpd: inactive.
Reloading inetd...done.
Starting ftp server...done.

Writing /var/flash/freetz...done.
80896 bytes written.

Sieht doch soweit richtig aus? Und der Daemon läuft danach auch.

[hermann]

Ich habe den Fehler bei mir gefunden. Wie ich bereits angekündigt hatte, erweitere ich modlibrc um weitere Statusmeldungen. Ich hatte da z.B. "started (inetd)" reingenommen. Es sieht aber so aus, dass inetd-cgis irgendwo in ihren Tiefen diesen Status abfragen und ein blankes "inetd" erwarten. Ich hatte meine Änderungen nun abwärtskompatibel gemacht in dem ich einen "extended"-Modus für z.B. modlib_status spendiert hatte. Ruft man jetzt modlib_status ohne Parameter, verhält er sich wie erwartet, ruft man ihn als

modlib_status extended

dann liefert er bei mir eine erweiterte Ausgabe. Somit wird man bei den noch unveränderten Paketen kompatibel bleiben und bei den umgeänderten bekommt man etwas mehr zu sehen und zu steuern.

[cuma]

Genau, auch einige Pakete prüfen den Rückgabe-String weshalb man ihn nicht ändern sollte. Wenn beim Umschalten zwischen automatisch, manuell und inetd ein Fehler ist, muss man den halt finden und beheben. Dann bräuchte man die angesprochene Rückgabestring-Erweiterung auch nicht.
Häng doch mal deinen Patch an damit man sich davon ein besseres Bild machen kann

[hermann]

"extended"-Funktionen für modlibrc

[hermann]

"extended" modlibrc komplett

[hermann]

Wie versprochen, habe ich meine "extended" modlibrc angehängt. Änderungen von cuma sind drinne bis auf besagte config-Zeile, die ich rauskommentiert habe. Bilder und weitere Motivationen poste ich am besten in IPPF, sonst geht es hier schon ziemlich am eigentlichen Thema vorbei.

[oliver]

Hast du mal die Zeit der Dienste Seite und beim Boxstart gemessen. Ändert sich da merklich was mit diesem Patch?

[hermann]

Nein, die Zeiten habe ich nicht gemessen. Durch die mehrfachen Überprüfungen wird sich da sicherlich was ändern, ich glaube aber nicht, dass es sich so gravierend störend auswirken würde.
Man könnte sicherlich noch versuchen was an den Abläufen optimieren. Das könnte die Zeit etwas verkürzen. Aber ob man es wirklich bis zur letzten Millisekunde schnell braucht, mag ich zu bezweifeln.
Außerdem glaube ich, man könnte und sollte einige Einbusse an Performance in Kauf nehmen, um dafür vernünftige Meldungen beim starten/stoppen der Dienste zu bekommen. So, wie es bis jetzt realisiert gewesen ist, war es eine totale Katastrophe, wo man sich kaum Gedanken darüber gemacht hat, Rückgabewerte vernünftig durchzureichen, geschweige sie auszuwerten. Ich hatte mich dazu motiviert gefühlt, als ich mehrfach über "Starting vsftpd…done" gestolpert bin, obwohl es kaum "done" war. rc.vsftpd verhält sich zwar auch jetzt noch genau so, man kann ihm aber mit meinem Patch leicht beibringen sich vernünftig (wie rc.ftpd) zu den Fehlern zu äußern.

[cuma]

Wenn viele Pakete es beim starten mehrfach aufrufen könnte das schon einiges ausmachen.
Ich finde es schwer deine und meine Änderungen auseinander zu halten und zu lesen. Da dieses inetd nicht so wirklich in dieses Ticket passt schlage ich mal vor:
1) falls keine weiteren Einwände kommen nehmen wird vorerst die modlibrc wie oben. Dadurch wird das mehrmalige Starten von daemons und und das immer gleich Abfragen der Rückgabewerte behoben. Dazu schaue ich mir noch die Pakete an die molib_xxx nutzen (sind nicht allzu viele).
2) Dann kannst du schauen wo inetd genau ein Problem hat. Ob man die erweiterte Status-Anzeige wirklich braucht wird sich dann zeigen wenn der Fehler gefunden ist (wie gesagt, ich kann problemlos ohne Blockierungen von inetd zu automatisch und zurück wechseln, bei Oliver scheint es auch keine Probleme zu machen). Das ganze ist dann aber unabhängig von diesem Ticket.
3) Gleichzeitig zu 2) kann dann schon begonnen werden die Pakete mir Fehlern im rc-Skript (mehrfach aufrufbar) geändert werden

Wie findest du das?
Gibt es sonst noch Stimmen zu dem modlibrc oben?

[hermann]

@cuma: Kannst du gerne machen. Allerdings seid bitte gewarnt: config beim reload macht Probleme.
Mit dem erweiterten Status hast du wahrscheinlich falsch verstanden. Es war nicht dafür da irgendwelche Probleme zu beheben, sondern dient dazu den aktuellen Status von Diensten besser darzustellen und deren Starts/Stops besser zu verfolgen. Die Erweiterung zielt in erster Linie an Dienste, die irgendwelche Ports belegen und womöglich inetd nutzen. Es wird unter anderem vor dem Start geprüft, ob der Port belegt ist und es wird auch eine Meldung ausgegeben (sobald und soweit möglich) durch was es belegt ist.
Weiterhin zielt es auf die Behandlung unserer mit Ralf Idee über den "dynamischen" inetd. Der "dynamische" inetd ist ein Schritt in die Richtung näher an die AVM-Implementierung von inetd und erlaubt zusätzlich noch über inetd gestartete Pakete auch bequem per start/stop-Knöpfe zu aktivieren/zu deaktivieren. Also, dem Benutzer sollte es so vorkommen, als ob es richtige Dienste sind und kein inetd. Das ist neu und ist bei der bisherigen Implementierung von inetd nicht drin. Die Idee dabei ist, dass die Pakete sich selbst um ihre inetd-Sachen kümmern und nicht wie bisher, dass inetd rumläuft und nach den Configs umständig und abhängig von inetd-Aktivierung der Pakete sucht.
Aber das ist auf jeden Fall ein anderes Thema und gehört nicht hierher. Wenn du deine Implementierung eincheckst, kann hier zu gemacht werden. Ich schaue dann, ob ich meine Lösung nachher im IPPF diskutiere oder hier ein separates Ticket aufmache.

[cuma]

(In [5003]) modlibrc updated (refs #834)

• modlib_status now supports "inetd"
• modlib_startdaemon takes care of the returnvalue, creates pid-file & writes "Starting…"
• modlib_start checks if the daemon is yet started or disabled
• modlib_reload & modlib_startdaemon executes "config"-function of parent rc-skript (if available)
• modlib_stop kills daemon with "stop" of parent rc.$DAEMON (if available)

all modlib_* using .rc-scripts revised (except xmail), some are really wired!

[cuma]

Wenn ich nichts übersehen hab funktioniert alles wie vorher Falls sich nach ein paar Tagen zeigt dass es so gut läuft, schau ich mir die mehrfach aufrufbaren Pakete noch an

[cuma]

(In [5005]) openssh: more using of modlibrc (refs #834)

[cuma]

(In [5007]) modlibrc: (refs #834)

• renamed variable CONF_PREFIX in modlibrc to avoid problems
• changed 3 depending packages too

[cuma]

(In [5013]) modlibrc (refs #834): changed meaning of CONF_PREFIX and inherits again for freetz-basic-services (MOD_${DAEMON} instead of ${DAEMON}_ENABLED)

[cuma]

(In [5022]) basic rc-scripts adapted to modlibrc (refs #834)

• rc.dsld untouched (because #856)
• rc.websrv untested (no hardware available)

[cuma]

(In [5082]) rc.dsld:

• preservers cmdargs now
• uses modlib functions
• modlib_startdaemon not usable because dsld needs env!?

modlibrc

• another fail-check added

(refs #834)

[hermann]

@cuma: Kannst du bitte in 2-3 Sätzen erklären, was diese CONF_PREFIX und CONF_ENABLED sollen und wofür sie dienen? Ich komme langsam nicht mehr hinterher. Früher gab es doch lediglich DAEMON_ENABLED und es konnte auch "inetd" heißen. Wie funktioniert es denn jetzt? Meine erweiterte Statusanzeige samt dynamischer inetd-Geschichte hat letztens nicht ganz so funktioniert, wie ich es mir vorstellte. Und ich hatte da diese Neuerung im Verdacht. Außerdem verstehe ich nicht ganz die Zeile:

[ "`env | grep -i "^${CONF_ENABLED-${DAEMON}_ENABLED}=" | sed 's/.*=//'`" == "inetd" ] && return 5

Muss man da denn wirklich env komplett laden, um eine einzige Variable per grep rauszufischen? Ich hatte in meinem Fall etwas besseres dafür vorgeschlagen gehabt, was allerdings mit gewissen Einschränkungen funktioniert hat:

[ -z "$daemon_UC" ] && daemon_UC="$(echo ${DAEMON} | tr [a-z] [A-Z] | sed -e 's/\-/_/g')"
local daemon_en="$(eval echo \${${daemon_UC}_ENABLED})"

Das Ersetzen von '-' nach '_' in den Namen war für meine Methode notwendig, weil sonst eval '-' als Substraktion empfand. Es gibt sicherlich auch andere Wege dies zu lösen.

[hermann]

@cuma: Entschuldigung für reassign! Bitte wieder zurückholen. Ich weiß nicht, warum mein Firefox automatisch auf "reassign" springt. Normalerweise steht es doch immer auf "leave as signed"… Wieder nicht aufgepasst.

[cuma]

Böser Fuchs :-]
Die Variablen ist für Sonderfälle, braucht man normalerweise nicht. Hast du die "Beschreibung" dazu am Anfang von /etc/init.d/modlibrc gesehen?

# CONF_ENABLED  other variablename than ${DAEMON}_ENABLED with manual/automatic/inetd in .cfg-file

Die beiden Befehl sind fast gleich, welcher besser ist kann ich nicht sagen. Wirklich optimal finde ich aber keinen von beiden.
Mein normales Linux kann so Variablennamen in Variablen nutzen, die Fritzbox leider nicht

A=ausgeben
B=A
echo ${!B}

[er13]

Replying to cuma: Hast du die "Beschreibung" dazu am Anfang von /etc/init.d/modlibrc gesehen? "Beschreibung": könntest Du diese bitte etwas verständlicher machen, so wie sie jetzt ist, ist sie nämlich keine Hilfe, man muss den Quellcode lesen, um zu verstehen, was gemeint ist.

Bin mir nicht sicher, aber wäre es nicht besser, statt mehrere Male

${PID_FILE-/var/run/$DAEMON.pid}

auszuschreiben, einmal zu Beginn die Variable PID_FILE zu definieren (falls der Aufrufer dies selbst nicht gemacht hat) und diese dann in allen Funktionen zu verwenden. Es sind nämlich alles (jetzt kommt mein Lieblingsschimpfwort) Code-Clones. Dann müsste man übrigens auch weniger dokumentieren. Denn der Code würde für sich sprechen. Das gleiche für die restlichen Variablen.

p.s. ich habe meine Meinung diesbezüglich schon mal geäußert gehabt, mache es aber nochmal. Ich finde diese "Parameter-Übergabe" über Umgebungsvariablen einfach grauenhaft. Wenn jemanden was besseres einfällt, soll er es sofort verbessern

[cuma]

Da ich die "Beschreibung" geschrieben hab finde ich sie selbst einleuchtend. Aber von außen kann man das besser beurteilen. Wie würdest du den hinschreiben? :-]

Wie wäre denn so ein Block am Anfang der modlibrc? Nachteil ist halt dass manche zugewiesen werden obwohl sie nie gebraucht werden

[ -z "$DAEMON_LONG_NAME" ] && DAEMON_LONG_NAME="$DAEMON"
[ -z "$PID_FILE" ] && PID_FILE="/var/run/${DAEMON}.pid"
[ -z "$CONF_NAME" ] && CONF_NAME="${DAEMON}"
[ -z "$CONF_ENABLED" ] && CONF_ENABLED="${DAEMON}_ENABLED"
[ -z "$DAEMON_BIN" ] && DAEMON_BIN="${DAEMON}"

[cuma]

(In [5087]) some rc-scripts reviewed:

• usage of modlibrc
• no multiple starts
• code-styling
• simplifications

(refs #834)

[hermann]

@cuma: Was war der Grund dafür den Aufruf von modlibrc in rc.inetd vor den drei Variabledeklarationen zu stellen? Ich hatte bewußt die Variablen vor dem Aufruf da reingebracht, da ich vor hatte sie auch in modlibrc zu nutzen. Ob es letztendlich geschehen ist und ob die Reihenfolge letztendlich ein Rolle spielt weiß ich nicht. Werde gleich testen.
Sonst war das ganz schon mutig von dir in so vielen rc-Skripten auf einmal modlibrc konsequent einzuführen. Ich hoffe nur, dass du alle "Tausende" Pakete ja auch getestet hast und dass es nicht zu einem großen Geschreie bald kommt, wenn dies oder das nicht wie gewollt startet.
Mit deinem Vorschlag auf leere Variablen zu testen bin ich einverstanden.
Zur "Beschreibung" vor dem modlibrc (und allgemein zu den Kommentaren dortdrin) hätte ich eine Bitte zu irgendeinem "native speaker" oder dem, der sich dafür hält unter uns: Bitte dringends Korrekturlesen[[BR]] Zu einem war ich da mit meinem misarablen Englisch öfter unterwegs, zum anderen sind da in den ersten 5 Zeilen schon so viele gravierenden Fehler und Missverständnisse, dass selbst mir schon meine Haare zu Berge stehen, obwohl ich mangels Kenne in Englisch eigentlich dagegen ziemlich resistent bin.

[cuma]

Da die Variablen in modlibrc nicht genutzt werden ist es egal wo sie stehen. Zwecks besserer Lesbarkeit sind die Variablen des rc-Skriptes nach dem Aufruf von modlibrc.
Dass ich irgendwas übersehen hab schließe ich nicht aus, diese Gefahr besteht jedoch bei jeder noch so kleinen Änderung. Änderungen an den Basic-Diensten und der modlibrc waren im letzten Commit ja nicht mehr drin sondern meist einfach das einsetzen von modlib_*. Und im Katastrophenfall gibt es ja immer noch das Revert
OT: Die Kommentare wurden halt auf englisch festgelegt, ob es bei den meist deutschsprachigen Schreiben so gut war ist eine andere Sache. So macht es halt jeder so gut er kann. Wenn etwas unklar oder unverständlich ist kann man sich ja beschweren, und am besten gleich mit Verbesserungsvorschlag.
Speziell zu "other variablename than ${DAEMON}_ENABLED with manual/automatic/inetd in .cfg-file": Ich finde das halt einleuchtend, was aber auch daran liegen kann, dass ich die Mechanismen die dahinter liegen kenne. Was fehlt euch denn?

[cuma]

(In [5107]) modlibrc (refs #834):

• coding-style: code clones removed
• comments revised (feel free to correct errors!)
• modlib_loadconfig optimized

[cuma]

(In [5108]) removed output-redirections (refs #834)

[cuma]

(In [5109]) modlibrc utilisation & optimizations of gw6, openntpd, ppp-cgi, ser2net, syslogd and vnstat-cgi (refs #834)

[cuma]

(In [5117]) modlibrc: changed detection of "inetd"-starttype (refs #834)

[cuma]

(In [5119]) removed not needed usage of CONF_ENABLED (refs #834)

[er13]

@cuma: statt

tr [:lower:] [:upper:] | sed 's/-/_/g'

könnte man auch einfach

tr [:lower:]- [:upper:]_

schreiben

[cuma]

Danke, hab übrigens kein Problem damit wenn jemand gleich den Code optimiert: r5120

[er13]

Replying to cuma:

Danke, hab übrigens kein Problem damit wenn jemand gleich den Code optimiert

bitte, hab' übrigens auch kein Problem damit den fremden Code gleich zu optimieren, bin einfach noch auf der Arbeit

[hermann]

Mit dem '-' und '_' habt ihr aber kapiert, dass man dann die Variablen unter Umständen "per hand" umbenennen muss, oder? Es ist nur so, wie ich es oben schrieb, dass eval halt Minus als Minuszeichen evauliert, daher werden alle Minuszeichen im Namen einfach mit dem Unterstrich ersetzt. Folge ist allerdings, dass aus dem Paket paket-zusatzname dann Variable $PAKET_ZUSATZNAME_ENABLED wird. Und wenn sie unter FREETZ oder im Paket bereits als $PAKET-ZUSATZNAME_ENABLED oder $ANDERERNAME_ENABLE bekannt ist, sollte man in dem dazugehörigen Skript eine Zuweisung machen:

PAKET_ZUSATZNAME_ENABLED="$PAKET-ZUSATZNAME_ENABLED"

Mit dem Wegoptimieren von sed bin ich voll bei dir, er13. War nur mein erster Schuss mit dem sed. Man sollte es natürlich bei tr mit reinpacken, wie du es vorschlägst.

[cuma]

Das mit den Unterstrichen in den Namen ist schon okay so, schau mal in die Pakete avm-firewall, bluez-utils, hp-utils und inadyn-mt.

[er13]

Replying to hermann:

Und wenn sie unter FREETZ oder im Paket bereits als $PAKET-ZUSATZNAME_ENABLED oder $ANDERERNAME_ENABLE bekannt ist, sollte man in dem dazugehörigen Skript eine Zuweisung machen: {{{ PAKET_ZUSATZNAME_ENABLED="$PAKET-ZUSATZNAME_ENABLED" }}}

Hmm, interessant, seit wann kann man denn im Namen einer Shell-Variable das Minus-Zeichen verwenden?

[er13]

@cuma: Idee, statt in jedem rc-Script die Variable DAEMON vor dem Include von modlibrc zu definieren, könnte man den Wert von dieser am Anfang von modlibrc aus dem Namen des rc-Scripts ableiten, etwa so

[ -z "$DAEMON" ] && DAEMON="${0/rc.}"

Außerdem würde ich auf die Definition von PID_FILE verzichten, sofern sich der Wert vom default nicht unterscheidet.

[cuma]

Die PID_FILE hab ich nur definiert, wenn sie anders ist als default oder irgendwo im rc-Skript selbst genutzt wird. Falls trotzdem, hab ich es übersehen.
Das mit der DAEMON Variable hab ich auch schon überlegt, aber wieder verworfen da ich die Auswirkungen nicht so ganz überblickt hab. Wenn man zB einen Link auf das Skript macht funktioniert es schonmal nicht. Oder manche wollen kein "modlib_loadconfig" und definieren deshalb keinen DAEMON (mir fällt da rc.dsld ein). Es wäre aber schon schöner. Evtl mach genau das bei #874 Ärger.
Der "config"-Teil ist übrigens auch oft gleich

( if ...
  cat ...
) > /mod/etc/$DAEMON.conf

[er13]

Replying to cuma:

Das mit der DAEMON Variable hab ich auch schon überlegt, aber wieder verworfen da ich die Auswirkungen nicht so ganz überblickt hab. Oder manche wollen kein "modlib_loadconfig" und definieren deshalb keinen DAEMON (mir fällt da rc.dsld ein). Es wäre aber schon schöner.

So, ich habe mir folgendes überlegt, zwar noch nichts getestet, meine aber es wird funktionieren und es wird schöner sein Man könnte dann auch DAEMON, wie oben beschrieben, aus dem Namen ableiten (openvpn macht es übrigens schon und zwar besser als ich es vorgeschlagen habe).

Statt Parameter an modlibrc über irgendwelche Umgebungsvariablen zu übergeben, was ich wie gesagt Wahnsinn finde, werden Parameter, die das Verhalten von modlibrc steuern, einfach (oh Wunder ) als Parameter an modlibrc übergeben. D.h. jedes rc-Script, welches die Variablen DAEMON, PID_FILE usw. definiert haben möchte und modlib_loadconfig aufgerufen haben möchte, includiert bzw. ruft modlibrc parameterlos auf:

. /etc/init.d/modlibrc

Jedes Script, das keinen Aufruf von modlib_loadconfig wünscht, includiert es mit:

. /etc/init.d/modlibrc -noloadconfig "$@"

modlibrc wertet die zusätzlichen Parameter aus und verhält sich halt entsprechend. Man muss nur beachten, dass die zusätzlichen modlibrc-internen Parameter mit den Parametern der rc-Scripte nicht kollidieren.

Wenn man zB einen Link auf das Skript macht funktioniert es schonmal nicht.

funktioniert schon und zwar genau wie man es erwarten würde. Rufst Du das Script unter dem Namen rc.xy auf, so ist der Name xy, unter dem Namen rc.yz so ist der Name yz. Dabei ist es völlig unerheblich, ob rc.xy oder rc.yz ein Symlink ist oder nicht, es spielt allein der Aufrufname eine Rolle. Dieses Verhalten kann man sich sogar bei ähnlichen/gleichen rc-Scripten sehr zunutze machen.

[cuma]

Ich finde es nicht so schlimm, dass über die Env-Variablen Daten mitgegeben werden, deine Ideen sehen aber ganz gut aus. Man muss halt wieder alle rc-Skripte durchgehen. Mit -noloadconfig räumst du ja eine meiner Bedenke aus.
Ich meinte es aber als Nachteil, dass wenn man ein Link mit anderem Namen auf ein rc-Skritp macht, dadurch DAEMON, die .cfg Datei usw mitgeändert wird. Aber wenn du das als Vorteil siehst… vermutlich macht das aber niemand.

Dann hab ich momentan noch das Problem diesen Befehl auszuführen: env - eval echo blubb Jemand eine Idee?

Und zuletzt noch der Status des Durchsehens der rc-Skripte. Noch nicht angeschaut hab ich mir diese rc-Skripte (speziell mehrfach startbar)

tor                      USBtimer
xmail                    USBtimer
lighttpd                 USBtimer
nfsd
quagga
cifsmount
bluez-utils
downloader
openvpn                  loadconfig?
mcabber                  "stop" zum löschen der Datei? / daemon --hide?
phpxmail                 daemon --hide?, restart&status möglich?
inotify-tools            kein modlibrc / kein _ENABLED? / ps|grep!
davfs2                   Ticket #863
inadyn-mt                Programmmeldung unterdrücken / Startmeldung anzeigen (eval? updaten? W:LANG: Cannot open..)

[MaxMuster]

Replying to cuma:

Ich meinte es aber als Nachteil, dass wenn man ein Link mit anderem Namen auf ein rc-Skritp macht, dadurch DAEMON, die .cfg Datei usw mitgeändert wird. Aber wenn du das als Vorteil siehst… vermutlich macht das aber niemand.

Zumindest das "ziemlich krude" openvpn macht das Ich wollte "dynamisch" neue, aber unterscheidbare, Instanzen für die verschiedenen Configs haben. So mache ich dann für jede Config ein eigenes rc-file (und sogar ein "eigenes" Programm) als Link auf die originale Datei.
Um innerhalb des einen rc-files für "viele" Namen dann unterscheiden zu können, wofür es gerade "zuständig" ist, habe ich dann im Skript den DAEMON-Namen über den Aufruf herausgesucht.

[cuma]

Ach du warst das Funktioniert das nach #874 noch so wie geplant? (evtl in dem Ticket weiter)

[MaxMuster]

Jepp, mit [5122] geht alles wieder (soweit ich das auf die Schnelle testen konnte).

[cuma]

(In [5131]) rrdstats: modlib usage (refs #834) rrdstats, vnstat-cgi: wrong httpd-status fixed (not loaded .cfg) wol, hp-utils, rrdstats, vnstat-cgi: usage of httpd & DAEMON-variable syncronized

[cuma]

(In [5143]) samba:

• modlibrc usage (refs #834)
• inetd support for smbd

[cuma]

(In [5168]) dnsmasq: (refs #834)

• modlibrc usage
• takes care of removed upnpd/igdd
• multid start still crashes my boxes with custom cpmac config

[oliver]

Kann hier zu? Oder fehlt noch was?

[cuma]

Die in Kommentar 58 aufgeführetn rc-Scripte müsste man noch genauer anschauen.

[markuschen]

Hab noch was.

Problem 1:
Wenn ich den telnetd von 'automatisch' auf 'inetd' umkonfiguriere, wird telnetd gestoppt, aber das 'rc.inetd reload' zeigt keine Wirkung. Die neue inetd.conf wird wohl vom inetd nicht eingelesen.

inetd.conf

23	stream	tcp	nowait	root	/usr/sbin/telnetd	telnetd -i -l /sbin/ar7login
81	stream	tcp	nowait	root	/usr/bin/webcfg	webcfg -i
139 stream tcp nowait root /usr/bin/webdav_wrapper /sbin/smbd /sbin/smbd
445 stream tcp nowait root /usr/bin/webdav_wrapper /sbin/smbd /sbin/smbd

/etc/init.d/rc.inetd reload

Reloading inetd...

Erst ein rc.inetd stop/start zeigt Wirkung.

2. Problem:
Wenn ich die erste telnet Session im inetd-Modus aufbaue, kommt die normale user/password-Abfrage. Baue ich parallel eine zweite Session auf, erfolgt die Abfrage des AVM WebUI-Kennworts, außerdem kommen einige Logon-Fehler (root ?)

Fritz!Box web password:


BusyBox v1.17.1 (2010-08-01 22:00:40 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

sh: root: unknown operand
ermittle die aktuelle TTY
tty is "/dev/pts/2"
weitere telnet Verbindung aufgebaut
sh: root: unknown operand
/usr/mww/cgi-bin/shell #

[cuma]

Inetd ist momentan noch eine Baustelle, siehe Tickets #805 oder #893. Am sichersten ist es die Box neu zu starten.
So kann man ihn überreden die config neu zu erstellen:

/etc/init.d/rc.inetd stop
/etc/init.d/rc.inetd load

Testest du telnet gleich nach dem nöchsten checkin?

[cuma]

(In [5375]) multiple telnetd-logins via inetd fixed (refs #834)

[cuma]

(In [5381]) (refs #834)

• xmail: usb-timer removed, not needed anymore because of externel-services
• tor: variable ordered & some whitespaces removed

[markuschen]

@cuma

Hab das Problem gefunden, wenn ich 'inetd -f -e' starte, kommt 

inetd: /etc/inetd.conf: No such file or directory

Da fehlt wohl noch ein Symlink nach /var/mod/etc/inetd.conf

Problem kommt evtl. auch von der neuen Busybox?

[markuschen]

Vergesst es, der Symlink fehlt nur im 7390-er Branch, o.g. Problem 1 liegt also nicht nur daran.

[cuma]

(In [5465]) mcabber & phpxmail are no daemons, so they shouldn't be start-, stop- or restartable (refs #834)

[cuma]

(In [5466]) inadyn-mt (refs #834):

• removed usage of modlib_startdaemon
• hide annoying output of inadyn-mt at startup
• "Starting $DAEMON…" is now visible again

[cuma]

(In [5468]) prevent multiple starts of:

• bluez-utilz
• cifsmount
• downloader (additionally some html-umlauts fixed)
• nfsd
• quagga (additionally moved config to /tmp/flash/PACKAGE)

All these packages have now a own "running()" function to determine status. I don't have any clue how to better handle packages with multiple daemons. Perhaps someone else?

(refs #834)

[cuma]

(In [5495]) openvpn: prevent multiple starts/stopps (refs #834)

[cuma]

(In [5496]) inotify-tools (refs #834)

• moved to "debug helpers"
• uses modlibrc now
• Webinterface added (starttype & logfile)
• Status page for logfile added
• STARTLEVEL added

[cuma]

(In [5499]) lighttpd (refs #834)

• uses now modlibrc
• removed usb-timer (external-services handles this)
• doesn't delete logfiles on "stop" anymore

[oliver]

Was machen wir mit Inotify? Das wird über ein Patch in der rc.S gaaanz früh gestartet, wenn die passende Variable gesetzt wird. Sollten wir es evtl. in der load Sektion schon wieder stoppen. Den Startlevel könnte man dann wieder auf 99 setzen. Ansonsten läuft das RAM mit dem Logfile voll, wenn es nicht von Hand gestoppt wird…

Der Starttyp automatisch ist daher nicht sinnvoll. Man könnte höchstens versuchen bei "aktiv" diese Variable zu setzen.

[cuma]

Den Eintrag in der rc.S habe ich nicht gesehen. Davon abgesehen kann er nie funktioniert haben, da der Dateiname der rc.inotify-tools falsch ist:

# Initiate inotify-tools file access logging
if ka_isActiveVariable InotifyBootAnalysis; then
        ka_decreaseValue InotifyBootAnalysis
        /etc/init.d/rc.inotify_tools start
fi

Wenn es so wie aktuell im trunk auf "automatisch" ist und damit per rc.mod geladen wird, hab ich keine Probleme mit dme Ram (32 MB ohne Swap auf der 7170) bemerkt. Falls es mit "InotifyBootAnalysis" noch früher geladen wird, ergibt der spätere Aufruf von rc.mod "already running". Ohne das "InotifyBootAnalysis" kann man dann alle Freetz Pakete loggen.
Wie wäre es im "load" zu prüfen ob "InotifyBootAnalysis" gesetzt ist und falls ja es zu beenden?

[oliver]

Whoopie hats auf den Tag vor 2 Jahren kaputt gemacht. r2421

Wenn die Variable gesetzt ist und Autostart nicht an oder immer wenn die Variable gesetzt ist anhalten?

Irgendjemand hatte das (wie auch immmer) aktiviert und nicht daran gedacht und sich dann gewundert, dass die Box andauernd einen Reboot gemacht hat.

[cuma]

Wenn es so lange nicht auffiel, wird es wohl nicht so häufig genutzt. Da es jetzt ein Webinterface gibt, könnte man es auch auswählbar machen, zB "nur Bootvorgang loggen"
Wie setzt man überhaupt das "ka_isActiveVariable"? Vielleicht auch per Webinterface möglich?

[oliver]

Über /usr/bin/kernel_args. Eignetlich sollten das die xxxRoot Systeme nutzen. Ob sie es machen weiß ich nicht.

[cuma]

(In [5588]) fix filename of rc.inotify-tools (refs #834)

[cuma]

Sollen wir inotify-tools nicht so lassen wie es ist, und unterstellen, dass ein Benutzer der die Kernelargumente ändert, inotify auch nach dem Booten stoppen kann?

Replying to oliver:

Irgendjemand hatte das (wie auch immmer) aktiviert und nicht daran gedacht und sich dann gewundert, dass die Box andauernd einen Reboot gemacht hat.

Ich vermute dass dieser es ins Image gepackt hat und dadurch dass es immer "enabled" war lief der RAM durch die Logdatei voll…

[cuma]

(In [5590]) modlibrc (refs #834):

added DAEMON_CHECK: daemon(s) to check with "pidof"

• modlib_check_running: uses DAEMON_CHECK
• modlib_stop: return correct retval

packages accordingly updated (refs r5468)

• bluez-utilz
• cifsmount
• downloader
• nfsd
• quagga
• streamripper

[oliver]

Bis auf inotify-tools (Fortsetzung in #1001) ist hier alles erledigt. Danke cuma!