Danke für die Anpassung auch an "alte Systeme" 
Ausprobiert und funktioniert sofort!!
Danke Andreas!!
Gruß Micha
.. und allen nen schönen 4. Advent...
Hallo Andreas,
ich habe grade mal die 3.6.4 ausprobiert, aber sie startet bei mir nicht vernünftig, weil der Prozessname sich ändert (geändert in 3.6.3, hatte vorher 3.6.2 benutzt). Ich benutze zum Starten ein Runlevel-Skript mit startproc und das prüft den Prozessnamen (inkl. Pfad) nach dem Aufruf. Da dieser aber geändert wird findet startproc den Prozess offenbar nicht und meint deshalb, der Start hätte nicht funktioniert.
Was war denn der Grund für die Änderung?
Gruß
FireFly
ZitatOriginal von amair
Ich halte das für sinnvoll.
Hallo Andreas, ich ja auch. Aber muss denn der Pfad und Interpreter abgeschnitten werden?
So wie ich Tobias Hinweis und den Debian Link verstehe, sollte einfach vdradmin.pl in vdradmin umbenannt werden.
Dass der Skriptname im Skript mit $0 = $PROCNAME umbenannt wird finde ich nicht so gut - das haben meiner Meinung nach eigentlich nur Programme nötig, die etwas zu verbergen habe, wo vdradmin definitiv nicht dazugehört.
Mit $0 = PROCNAME erscheint ja in der Prozessliste nur noch "vdradmind", ohne Pfad und Interpreter. Wenn ich vdradmind anstatt vdradmind.pl aufrufe, erscheint in der Prozessliste "/usr/bin/perl /usr/sbin/vdradmind".
Was hälst Du davon? Das sollte doch auch den Debian Rulez genügen.
Frohe Feiertage
FireFly
ZitatOriginal von amair
Der Vorschlag kam von Ville Skyttä. Dadurch funktioniert dann ein "pidof vdradmind".
Aber startproc funktioniert damit nicht mehr 
Wie sollte vdradmind denn überhaupt gestartet werden? Ich habe mir dazu ein Runlevel Skript geschrieben, das LSB-konform ist und deshalb startproc (bzw. start_daemon) benutzt, was ja jetzt nicht mehr funktioniert.
Gruß
FireFly
Hallo FireFly!
ZitatOriginal von FireFly
Aber startproc funktioniert damit nicht mehr
Wie sollte vdradmind denn überhaupt gestartet werden? Ich habe mir dazu ein Runlevel Skript geschrieben, das LSB-konform ist und deshalb startproc (bzw. start_daemon) benutzt, was ja jetzt nicht mehr funktioniert.
Gruß
FireFly
Also ich starte ganz einfach das Perl-Skript, ohne startproc oder ähnliches.
Ich habe mir mal die man-Page von startproc durchgelesen, kann es aber nicht testen, da es nicht installiert ist. Dort steht u.a.
Zitatif the executable changes its zeroth argument, startproc uses the base name (/proc/<pid>/stat) to identify the running program.
Ich würde sagen, dass startproc also mit der $0 Zuweisung klar kommen sollte. Kann es sein, dass Du "vdradmind.pl" startest und nicht "vdradmind"? Könnte eine Verbesserung bringen. Startproc dürfte dann aber noch den "-L" Parameter brauchen, da vdradmind nur ein Link auf vdradmind.pl ist.
Gruß,
Andreas
Danke Andreas. Die manpage hatte ich auch studiert, aber ich dachte man kann es anders lösen. Ich werde mal in diese Richtung weiterforschen, muss aber jetzt erst mal mein ACPI wakeup-Problem lösen
Schöne Feiertage
FireFly
PS: Hättest Du Interesse an nem Runlevel-Skript für das vdradmin-am-Paket?
Hallo Andreas,
ich habe das jetzt so gelöst, dass in vdradmind ein "$0=$EXECNAME" steht anstatt $PROCNAME. Damit wird der Pfad wieder angezeigt ("/usr/sbin/vdradmind" und sonst nichts) und dann klappt es sowohl mit startproc als auch mit pidof.
Wäre das ne Option für die nächste Version?
Viele Daemons (cupsd, ntpd, acpid und und und) stehen MIT Pfad in der Prozessliste (oder sogar alle?). Ohne Pfad, dafür mit eckigen Klammern stehen IMHO nur Kernel-Prozesse in der Prozessliste (lockd, kswapd, kacpid und und und).
Außerdem ist mir aufgefallen, dass (auch in der ungepatchten Version) die Abfrage zum doppelten Starten ein Problem hat, da in der Prozessliste nach "[vdradmind]" gesucht wird, aber nur "vdradmind" auftaucht.
Grüße
FireFly
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
