Linux 15.071 Themen, 107.545 Beiträge

problem mit seti als dienst unter linux

Silent Bob / 19 Antworten / Baumansicht Nickles

hallo zusammen,
ich möchte auf meinem mandrake 9.2 server den seti client als dienst laufen lassen.

aber ich kann machen was ich will, immer wenn ich den starten will, kommt "permission denied".

ich habe folgendes gemacht:

1.: ich habe in /etc/init.d die datei \'seti\' erstellt.
die datei erhält den folgenden code:

#!/bin/bash
#seti starten
su setiuser -c /opt/setiathome/setiathome >&/dev/null&


2.: ich habe einen user für seti angelegt, der sinnvollerweise \'setiuser\' heisst.

3.: der seti client ist natürlich in /opt/setiathome installiert.

4.: ich habe dann noch den dienst mit ln -sf /etc/init.d/seti /etc/rc3.d ins runlevel 3 hinzugefügt, damit er direkt beim booten mitgestartet werden soll.

ja. soweit so gut. wenn ich jetzt als \'root\' oder als \'setiuser\' das ganze starten will (mit /etc/init.d/seti start) kommt \'permission denied\'.

warum? das verstehe ich nicht so ganz. dann ist mir auch aufgefallen, dass in dem ordner /etc/init.d/ alle einträge in meiner bash mit grüner schrift geschrieben sind und ein sternchen hinter dem namen haben. bis auf seti.
was bedeutet das? und wer kann mir sagen was ich falsch gemacht oder vergehssen habe?

danke im voraus

bei Antwort benachrichtigen
the_mic Silent Bob „problem mit seti als dienst unter linux“
Optionen

das bedeuted, dass du dein skript noch keine ausführberechtigung hat und entsprechend auch nicht ausgeführt werden darf. um die ausführberechtigung zu geben musst du folgenden befehl verwenden:
chmod 0755 /etc/init.d/seti

bedeuted:
erste oktalzahl: spezialbits
zweite oz: owner
dritte: gruppe
vierte: andere benutzer

die zahlen errechnen sich:
4: lesen
2: schreiben
1: ausführen
d.h. 0755 -> keine spezialbits, alle rechte für den owner, lesen+ausführen für group und others
noch ein bsp: 0640 -> keine spezialbits, lesen und schreiben für owner, lesen für gruppe, kein zugriff für others
prinzip begriffen?

cat /dev/brain > /dev/null
bei Antwort benachrichtigen
Silent Bob the_mic „das bedeuted, dass du dein skript noch keine ausführberechtigung hat und...“
Optionen

hi,

ja ich denke das hab ich immerhin ansatzweise kapiert ;-)

ich habe die anleitung übrigens auch von dir! aus einem alten posting. leider bin ich seit dem nicht mehr dazu gekommen. ich werde das dann gleich direkt ausprobieren.

vielen dank

bei Antwort benachrichtigen
Silent Bob Nachtrag zu: „hi, ja ich denke das hab ich immerhin ansatzweise kapiert - ich habe die...“
Optionen

okay. ich habe das soweit mal probiert.

wenn ich das ganze jetzt start/etc/init.d/seti

passiert irgendwie gar nix. ich bekomme weder eine fehlermeldung, noch eine erfolgsmeldung. ich kann das 10 mal hintereinandermachen. ohne erfolg.
auch in der prozessanzeige sieht alles normal aus. cpu hat fast langeweile und kein prozess der unter 'setiuser' läuft.

?

bei Antwort benachrichtigen
Klaus_T Silent Bob „okay. ich habe das soweit mal probiert. wenn ich das ganze jetzt...“
Optionen

Klar, was soll da auch passieren. Schau mal mit ls -ld /opt/setiathome die Rechte an. Sehr wahrscheinlich wird es so aussehen:

drwxr-xr-x 2 root root /opt/setiathome

Das heisst, nur root darf dort reinschreiben, dein Setiuser nicht. Wenn du einen extra user angelegt hast, gebe ihm unter /home ein Verzeichnis und schiebe den Seti-Client dorthin. Dann klappt das auch. Den Seticlient solltest du natuerlich auch als Setiuser installieren.

Bye, Klaus

bei Antwort benachrichtigen
Silent Bob Klaus_T „Klar, was soll da auch passieren. Schau mal mit ls -ld /opt/setiathome die...“
Optionen

aalso:

ich habe Klaus_T´s ratr befolgt. seti gelöscht und unter 'setiuser' im ordner /home/setiuser/setiathome den client neu installiert.
ich kann als 'setiuser' den client auch ausführen. no problem. dann habe ich das startscript von the_mic verwendet. datei seti in /etc/init.d
-----------------------------------------------------------
#!/bin/bash
. /etc/rc.d/init.d/functions
case "$1" in
start)
#seti starten
su setiuser -c /home/setiuser/setiathome/setiathome >&/dev/null 2>&1
;;
stop)
#allen seti-instanzen sigterm schicken
VAR=$(ps ax | grep seti | awk '{ print $1 }')
for i in $VAR; do
kill $i
done
;;
*)
gprintf "Usage: seti {start|stop}\n"
exit 1
esac
exit 0
--------------------------------------------------------------------

ich habe dann

den alten (falschen) symbolischen link gelöscht und einen neuen mit
' ln -sf /etc/init.d/seti /etc/rc3.d/S99seti '
angelegt.

im startscript habe ich natürlich den pfad auf den neuen ordner geändert.

nun versuche ich ' /etc/init.d/seti start ' ausführe, ist das gleiche problem wie vorhin. ich drücke enter, und nach einer sekunde ca. hab ich die eingabeaufforderung wieder.

aber in 'top' oder 'pstree' gibt es keinen setiprozess.
der client läuft definitiv nicht.

ich versteh das alles nicht...

gibts nicht irgendwo ein .log wo man nachschauen kann, wo es hier knallt?

bei Antwort benachrichtigen
the_mic Silent Bob „@ihr beiden“
Optionen

dann gib mal als root den befehl ein:
su setiuser -c /home/setiuser/setiathome
was passiert dann?

cat /dev/brain > /dev/null
bei Antwort benachrichtigen
Silent Bob the_mic „@ihr beiden“
Optionen

dann erscheint die meldung:
--------------------------------------------------------------
Couldn't get lock file. This is probably because
another instance of SETI@home is running in this directory.
Each instance of SETI@home must run in a separate directory.
--------------------------------------------------------------

aber das kann doch nicht stimmen. es läuft definitiv kein anderer seti prozess!

bei Antwort benachrichtigen
Klaus_T Silent Bob „@ihr beiden“
Optionen

Ja, dann gibt es schon ein Lock-File. Mach folgendes: Du gibst ein:

find . -name lock.sah

Dann bekommst du die Ausgabe, wo das Lock-File ist, normalerweise in dem Verzeichnis, wo der Seti-Client ist. Das musst du abschalten. Vielleicht liegt auch noch ein 'lock.sah' unter /opt/setiathome. Gebe als root einfach ein:

kill `ps aux | grep setia | grep -v grep | awk '{print $2}'`

Das killt alle Lock-Files. Dann startest du den noch einmal aber mit dem Schalter -verbose, also:

su setiuser -c /home/setiuser/setiathome -verbose

Und denke daran, dass du auch in Runlevel 1 und Runlevel 6 einen Link auf seti legst, der den Seti stopt, sonst hast du nachher wieder das Problem:

ln -sf /etc/init.d/seti /etc/rc0.d/K1seti
ln -sf /etc/init.d/seti /etc/rc6.d/K1seti

Das war schon alles. Und schau nach, ob das mit dem Script wirklich so stopt. Bei mir ist wie gesagt der obige Befehl nur wirksam, also:

kill `ps aux | grep setia | grep -v grep | awk '{print $2}'`

Bye, Klaus

bei Antwort benachrichtigen
Silent Bob Klaus_T „@ihr beiden“
Optionen

schönen guten morgen.

also klaus seine tipps haben geklappt.
ich versteh zwar die ganzen kryptischen formeln nicht, und die
kill `ps aux | grep setia | grep -v grep | awk '{print $2}'`
hat auch nicht funktioniert, aber das problem lag tatsächlich bei bei der lock.sah. nachdem die weg ist startet der client.

also /etc/init.d/seti start funktioniert, aaaaaber:
der client startet im vordergrund. d.h. mit dem befehl ist die bash blockiert, bis ich das programm mit STRG + C abbreche.
das darf ja nicht sein. der muss ja im hintergrund starten und weiterlaufen, damit ich den ssh client zum server wieder schliessen kann, ohne das der client stoppt.

bei Antwort benachrichtigen
Klaus_T Silent Bob „fast geschafft!!!“
Optionen

Das ist klar, wenn du das aus der bash startest, dass die blockiert ist. Entweder haengst du ein '&' dahinter, also:

/etc/init.d/seti start &

oder du laesst es eben beim booten starten, eben durch den Symlink, den du in Runlevel 3,4 und 5 anlegst.
Was anderes: Was meinst du mit ssh? Startest du den Client ueber ssh auf einem anderen Rechner? Das geht natuerlich nur, wenn du die Verbindung offen haelst oder wenn das Programm 'screen' auf dem anderen Rechner laeuft. Wenn du eine ssh Verbindung schliesst, werden alle Dienste, die du ueber diese Verbindung gestartet hast, beendet.

Bye, Klaus

bei Antwort benachrichtigen
Silent Bob Klaus_T „fast geschafft!!!“
Optionen

achso.

ja gut, ich wusste nicht, dass die dienst die ich per ssh client gestartet habe, nach dem ausloggen beendet werden.

dann werde ich den rechner einfach mal neu starten und dann schauen obs läuft.

bei Antwort benachrichtigen
Silent Bob Nachtrag zu: „fast geschafft!!!“
Optionen

nach nem neustart des rechners:

in der boot.log steht ganz zum schluss drin: rc: starten der seti-dienstes succeeded !

aber da läuft kein seti dienst. kein prozess von setiuser, keiner von root der irgendwas mit seti zu tun hat.

das kann doch nicht sein!

starte ich den seti mit der hand

su setiuser -c /home/setiuser/setiathome &

läuft der ohne probleme, wird ja aber beendet, wenn ich mich auslogge :-(

bei Antwort benachrichtigen
Klaus_T Silent Bob „vielleicht sollte ich es aufgeben...“
Optionen

Dann schreibe mal in dem Script den kompletten Pfad zu 'su'. Kann sein, dass zu dem Zeitpunkt noch kein $PATH gesetzt ist. Anders kann ich mir das nicht mehr vorstellen. Das muss funktionieren.
Egal, aufgeben gibt es nicht. Wir werden das schon finden. In welchem Runlevel startest du denn und wo hast du das Script verlinkt? Du musst es in 3,4 und 5 verlinken.

Bye, Klaus

bei Antwort benachrichtigen
Silent Bob Klaus_T „vielleicht sollte ich es aufgeben...“
Optionen

hi,

also der komplette pfad zu 'su' steht schon in dem script drin.
su setiuser -c /home/setiuser/setiathome/setiathome
also das script hab ich nur in runlevel 3 stehen. warum den plötzlich in 3,4 und 5? da war doch nie die rede von. wird das dann nicht 3 mal gestartet?

ich kann das alles aber erst am montag wieder ausprobieren, weil der server auf der arbeit steht.

dafür hab ich das wochenende etwas im netz was zum thema "runlevel" zu suchen. da steig nämlich noch nicht wirklich durch.

schönes WE

bei Antwort benachrichtigen
Klaus_T Silent Bob „vielleicht sollte ich es aufgeben...“
Optionen

Nein, mit 'dem Pfad zu su meine ich auch den Pfad, also bei mir z.B.:

[nathan:klaus]~$ which su
/bin/su
[nathan:klaus]~$

Also:

/bin/su setiuser -c /home/setiuser/setiathome/setiathome

Und die Sache mit den Runlevel ist einfach. Es kommt darauf an, wie du bootest. Bootest du bis zur Text-Console, bist du in Runlevel 2 oder 3, je nach Distri. Bootest du aber bis zum grafischen Login, ist das normalerweise Runlevel 5, also musst du eben das Boot-Script mit allen Runleveln verlinken, in denen gestartet werden kann, also 3,4 und 5, bei manchen Distris auch noch 2. Runlevel 0 ist fuers anhalten des Systems und Runlevel 6 fuers rebooten. Mehr dazu in den Manpages:

man inittab
man init

Bye, Klaus

bei Antwort benachrichtigen
Silent Bob Klaus_T „vielleicht sollte ich es aufgeben...“
Optionen

also langsam beginne ich ersthaft an meinem verstand zu zweifeln:

in der /var/log/boot.log steht 'rc: starten des seti dienstes succeeded'

aber der dienst läuft trotzdem nicht.
im programmordner von seti existiert die datei lock.sah auch nicht. also kann es schonmal nicht daran liegen.

das einzige was jetzt noch sein kann, ist ein fehler in der syntax.
so sieht das seti startscript zur zeit aus:

----------------------------------------------------------
#!/bin/bash
. /etc/rc.d/init.d/functions
case "$1" in
start)
#seti starten
/bin/su setiuser -c /home/setiuser/setiathome/setiathome >&/dev/null 2>&1
;;
stop)
#allen seti-instanzen sigterm schicken
VAR=$(ps ax | grep seti | awk '{ print $1 }')
for i in $VAR; do
kill $i
done
;;
*)
gprintf "Usage: seti {start|stop}\n"
exit 1
esac
exit 0
------------------------------------------------------------------

sollte da jetzt kein fehler drin sein....
hoffungsloser fall.

danke für die bemühungen

bei Antwort benachrichtigen
Klaus_T Silent Bob „hat keine zweck“
Optionen

Tut mir leid, dir das sagen zu muessen: Ich sehe dort auch keinen Fehler. Ich weiss nicht mehr weiter, sorry. Gebe trotzdem nicht auf, beschaeftige dich etwas damit, du kannst nur lernen. Vielleicht bekommst du es noch hin.

Bye, Klaus

bei Antwort benachrichtigen
the_mic Silent Bob „problem mit seti als dienst unter linux“
Optionen

hm, ich hab grad mal kurz nachgeschaut. mandrake ist da etwas eklig und verlangt zwingend, dass seine startskripte eine minimalsyntax erfüllen. ich weiss nicht, ob die case-verzweigung dazugehört, aber zumindest musst du das functions-skript importieren (mit dem .). ich hab mal ein altes startskript, das ich mal für mandrake gebastelt habe, an deine zwecke angepasst:

#!/bin/bash
. /etc/rc.d/init.d/functions
case "$1" in
start)
#seti starten
su setiuser -c /opt/setiathome/setiathome >&/dev/null 2>&1
;;
stop)
#allen seti-instanzen sigterm schicken
VAR=$(ps ax | grep seti | awk '{ print $1 }')
for i in $VAR; do
kill $i
done
;;
*)
gprintf "Usage: seti {start|stop}\n"
exit 1
esac
exit 0


wenn du das skript einem runlevel hinzufügst, darfst du nicht einfach einen symlink erstellen (ausser bei gentoo ;-) ). du musst ihm auch noch sagen, was das system dann damit anfangen soll. das machst du, indem du dem link als ersten buchstaben ein S oder K mitgibst (S für start, K für stop (kill)).
ausserdem musst du angeben, in welcher reihenfolge es gestartet werden soll. dazu kommt nach dem K/S eine zweistellige zahl zwischen 01 und 99 (je höher desto später).
also:
ln -sf /etc/init.d/seti /etc/rc3.d/S99seti
und allenfalls noch ein K01 in runlevel 0 und 6

cat /dev/brain > /dev/null
bei Antwort benachrichtigen
Silent Bob Nachtrag zu: „problem mit seti als dienst unter linux“
Optionen

immerhin sagst du was sache ist.

danke für die hilfe trotzdem. auch wenn jetzt nicht alles geklappt hat, hab ich immerhin einiges über runlevel gelernt. das kann ja auch nicht schaden. ich denke ich wander nachher in den keller und schliess nen alter 14 zoller an den rechner an und lass dann den seti client auf konsole 6 lokal laufen. dann muss ich wenigstens nicht immer den dicken x server laufen lassen. auf der maschine macht sich das nämlich in sachen performance ganz schön bemerkbar.

nagut, dann bis bald mal

bei Antwort benachrichtigen