Ich habe an meiner erweiterten modlibrc weiter gebastelt. Jetzt habe ich eine bei mir halbwegs funktionierende Version mit erweiterten Rückgaben, wie ich es vorher schon mal hatte. Ich würde es aber gerne noch intern testen, bevor ich es poste. cuma hat da leider in modlibrc sehr viel geändert und mein Konzept passt da jetzt nicht mehr so glatt, wie es Ende Mai noch mit dem damaligen trunk-Status war. cuma hat wohl die gleichen Probleme entdeckt, die ich damals in meiner erweiterten Version bereits zum Teil realisiert hatte, und auf seine Art gelöst. Leider sind unsere Denkweisen und Vorlieben zur Benennung der Variablen etwas unterschiedlich, sodass ich noch Einiges gerne anpassen würde. Gebt mir bitte noch etwas Zeit dafür.
Ich hatte dennoch in meinem Anpassungstrieb einige Fehler von cuma entdeckt, die ich gerne schon jetzt posten würde, damit jemand von den devs sie vielleicht schon jetzt einpflegt. Es geht -wie Oliver bereits richtig gemerkt hat- um modlib_reload:
Code:
# modlib_reload
# reloads the daemon with SIGHUP
# if available runs "config" of rc.$DAEMON
# reloads daemon with "reload" of rc.$DAEMON if available
modlib_reload()
{
local fn=$PID_FILE
echo -n "Reloading ${DAEMON_LONG_NAME} ... "
modlib_check_running
case $? in
[COLOR="Red"][B]1[/B][/COLOR])[COLOR="DarkGreen"][B] # hier sollte 0 stehen[/B][/COLOR]
config
reload 1
local status=$?
if [ $status -ne 127 ]; then
sleep 1
else
kill -HUP $(cat "$fn") 2> /dev/null
local status=$?
fi
if [ $status -eq 0 ]; then
echo 'done.'
return 0
else
rm -f "$fn"
echo 'failed.'
return 1
fi
;;
3)
echo 'not running.'
return 0
;;
5)
config
reload 5
[ $? -eq 127 ] && killall -HUP $DAEMON_BIN 2>/dev/null 1>&2
echo 'inetd.'
return 0
;;
esac
}
Wenn man in case-Wahl die nicht existierende 1 gegen 0 tauscht, dann dürfte es erstmal mit dem reloaden von inetd wieder laufen. Ich habe allerdings hier cuma nicht ganz verstanden, was er mit "reload 1" oder "reload 5" will und warum im Falle inetd (Status 5) Daemon-Binary geHUPt wird. Wenn man hier schon etwas HUPt dann inetd, sinnvolerweise. In meiner Variante hatte ich gerade an dieser Stelle die vorher diskutierte modlib_reload_inetd eingebaut.
Allerdings würde die reload-Funktion von inetd in meinem Fall nicht vernünftig funktionieren, denn ich rufe aus der internen "reload"-Funktion von inetd modlib_reload. Und dies ist nach der Umstellung von cuma fatal, weil es zur endlosen Schleife führt (modlib_reload->reload->modlib_reload...). Um auch dies sauber zu lösen, muss man die Funktion "reload" in rc.inetd löschen und deren Inhalt vorher nach reload)-Sektion im Haupt-case bringen.
Was cuma da mit diesen Rückgabewerten von 127 gedacht hat, wenn die Funktionen "start", "stop", "reload" nicht existieren, muss ich mir auch noch genau anschauen.
Aber wie gesagt, auf die Schnelle sollte erstmal reichen 1 gegen 0 zu tauschen.
MfG
