🚀 go-pugleaf

Alexander Lucke wrote:
> 
> Hi!
> 
> Ich hab da nen Unix-System, auf dem ich gern staendig nen Script
> laufen lassen will. Wie kann ich das tun. Wenn ich mich einlogge, das
> Script starte und mich dann wieder auslogge, wird automatisch das
> Script beendet.
> 
> Kann man das irgendwie umgehen ?
> 
> Reply bitte per email! Thnx!
> 
> bye...
> Alexander
Hi Alex,

einfach:

"nohup DeinSript" eingeben. Das laueft dann solang bis Dein Script ordentlich terminiert oder das System 
runtergefahren wird >>>> also sei vorsichtig damit !!!
-- 
Knut Hofmann, Berlin, GERMANY			

email :   hofmann@is.in-berlin.de
www   :   http://w3.rz.fhtw-berlin.de/~s004060x/

Alexander Lucke wrote:
> 
> Hi!
> 
> Ich hab da nen Unix-System, auf dem ich gern staendig nen Script
> laufen lassen will. Wie kann ich das tun. Wenn ich mich einlogge, das
> Script starte und mich dann wieder auslogge, wird automatisch das
> Script beendet.
> 
> Kann man das irgendwie umgehen ?
> 

Mach doch mal  <  man at  > das koennte Dir vielleicht weiterhelfen.

Gruss Andreas

-- 

| mailto:seltmann@student.uni-kl.de |  ** Be the Blue Ribbon with you **
| Phone  : +49 0631 98117           |
| e-plus : +49 177 249 02 03        |

Alexander Lucke (al@next2.psychologie.hu-berlin.de) wrote:
:> 
:> Ich hab da nen Unix-System, auf dem ich gern staendig nen Script
:> laufen lassen will. Wie kann ich das tun. Wenn ich mich einlogge, das
:> Script starte und mich dann wieder auslogge, wird automatisch das
:> Script beendet. 
:> 
Wie waere es mit 'script &' oder mit 'nohup script' ?

Wenn Du das Skript mit & am Ende startest und Dich dann ausloggst,
dann laeuft es ohne controlling tty weiter, d.h Du siehst keinen
tty-Eintrag, wenn Du ein ps -ax absetzt.

Und wenn Du es mit nohup startest, dann werden alle Ausgaben des Skripts
in die Datei nohup.out umgeleitet.

Das & am Ende tut es nur dann, wenn Deine Shell Posix-Job-Control beherrscht.
Das kann z.B. die bash oder auch eine csh sein. Kannst Du mal checken,
indem Du dein Skript einfach mit 'script' startest und danach Control-Z
drueckst. Wenn Dein Shell Job-Control kann, dann wird das Script angehalten
und in den Hintergrund geschickt. Mit 'bg' kannst Du es im Hintergrund 
weiterlaufen lassen und mit 'fg' wieder in den Vordergrund holen.

Du solltest nur darauf achten, dass Dein Script keine Terminal-Eingaben 
erwartet. Dann wird es schwierig.

Bis dann
Andreas
-- 
------------------------------------------------------------------------------
     PGP public key: http://www.westfalen.de/private/alderan/index.html
     PGP fingerprint: D5 B6 82 CB 66 8A 07 A8  08 95 C2 B0 ED 69 30 1E
------------------------------------------------------------------------------
I'm not speaking for anyone or anything else. Sometimes not even for myself...

aj@alderan.westfalen.de (Andreas Joppich) writes:

>Alexander Lucke (al@next2.psychologie.hu-berlin.de) wrote:
>:> 
>:> Ich hab da nen Unix-System, auf dem ich gern staendig nen Script
>:> laufen lassen will. Wie kann ich das tun. Wenn ich mich einlogge, das
>:> Script starte und mich dann wieder auslogge, wird automatisch das
>:> Script beendet. 
>:> 
>Wie waere es mit 'script &' oder mit 'nohup script' ?

>Wenn Du das Skript mit & am Ende startest und Dich dann ausloggst,
>dann laeuft es ohne controlling tty weiter, d.h Du siehst keinen
>tty-Eintrag, wenn Du ein ps -ax absetzt.

>Und wenn Du es mit nohup startest, dann werden alle Ausgaben des Skripts
>in die Datei nohup.out umgeleitet.

>Das & am Ende tut es nur dann, wenn Deine Shell Posix-Job-Control beherrscht.

Hm, nein, eher nicht.

1. "script &" klappt nur bei shells, die sozusagen ein eingebautes
"nohup" haben, z. B. tcsh/csh, sonst wird der Prozess beim Ausloggen
mit HUP gekillt. (* siehe unten)

2. "nohup script &" klappt eigentlich immer, das nohup sorgt daf�r,
da� das HUP Signal beim Ausloggen ignoriert wird. (** siehe unten)

3. job control ist nur n�tig, wenn man das script im Vordergrund
(ohne &) starten will und es dann sp�ter in den Hintergrund schicken
will. Das normale & f�r Hintergrund d�rfte schon seit Generationen in
/bin/sh drin sein, da hat man von job control noch getr�umt.

(*) Ich kenne mich mit tcsh/csh nicht aus und wei� nicht genau, wie
das "eingebaute" nohup funktioniert, entweder setzt die shell 
vorm exec() die signal mask, oder Hintergrundprozesse kommen gar nicht
in die gleiche Process-Group. 

(**) zum Thema HUP Signal: Das ist ziemlich verwirrend. Eigentlich
sollte der Terminal-Treiber das HUP beim logout schicken. Und zwar an
die ganze Process-Group der login shell. Damit bekommen z. B. bei ksh
auch die Kinder der Shell (Hintergrundprozesse) ein HUP, daher das
nohup. Wenn man aber die login shell mit "kill -9" killt, kann
anscheinend der Kernel (tty Treiber) nicht mehr rauskriegen, was denn
die Process-Group war, damit gibt's auch kein HUP an die Kinder (das
w�re dann also die unsaubere L�sung wenn man das nohup vergessens
hat).

Au�erdem gibt's nat�rlich noch viel mehr M�glichkeiten, seinem Job das
�berleben zu garantieren (hatte ich schonmal gepostet :-)

$ job &; kill -9 $$ # hatten wer schon

oder

$ (job &)&

oder vielleicht

$ echo `job &`|mail -s Bloedsinn `whoami`

Wie waers mit

su `whoami` -c "job &"

(hier musst Du noch Dein password eingeben.)

Dann waere da noch

$ export EDITOR="job&"; crontab -e&

Hm, oder einfach

$ echo "job"|at now

Falls Du root bist und ein SYS V artiges System hast, versuch doch

# echo 'jo:2:once:/complete/path/job'>>/etc/inittab;telinit 2

Oder wie waer's mit

$ rsh <hostname> 'job>/dev/null 2>&1 0>&1'<&-&

Falls Du perl hast, nimm doch

$ perl -e 'fork||exec "job"'

Unter AIX (in der Standardinstallation) koenntest Du auch 

$ lp -d bsh job

Tsch�� denn,
	Michael
--
Michael Staats, Theoretical Physics, Uni-GH Duisburg 
email: michael@thp.Uni-Duisburg.DE
<a href="http://WWW.thp.Uni-Duisburg.DE/">Click</a> me!
<a href="http://WWW.thp.Uni-Duisburg.DE/cuaix/cuaix.html">A c.u.aix archive</a>

michael@hal6000.thp.Uni-Duisburg.DE (Michael Staats) writes:

>(**) zum Thema HUP Signal: Das ist ziemlich verwirrend. Eigentlich
>sollte der Terminal-Treiber das HUP beim logout schicken. Und zwar an
>die ganze Process-Group der login shell. Damit bekommen z. B. bei ksh
>auch die Kinder der Shell (Hintergrundprozesse) ein HUP, daher das
>nohup. Wenn man aber die login shell mit "kill -9" killt, kann
>anscheinend der Kernel (tty Treiber) nicht mehr rauskriegen, was denn
>die Process-Group war, damit gibt's auch kein HUP an die Kinder (das
>w�re dann also die unsaubere L�sung wenn man das nohup vergessens
>hat).

Ich dachte, es sei so, dass bei kill -9 der entsprechend gekillte
Prozess keine Chance mehr hat irgendwas aufzuraeumen. Somit hat es
auch keine Moeglichkeit seine Kinder zu killen. Oder liege ich da 
falsch?

h.f.s.
[f'up,cc]
--
Hans Friedrich Steffani
Institut fuer Elektrische Maschinen und Antriebe
TU Chemnitz-Zwickau
e-mail: hans.steffani@e-technik.tu-chemnitz.de

Hans Steffani (hfst@hrz.tu-chemnitz.de) wrote:
: michael@hal6000.thp.Uni-Duisburg.DE (Michael Staats) writes:
: 
: >(**) zum Thema HUP Signal: Das ist ziemlich verwirrend. Eigentlich
: >sollte der Terminal-Treiber das HUP beim logout schicken. Und zwar an
: >die ganze Process-Group der login shell. Damit bekommen z. B. bei ksh
: >auch die Kinder der Shell (Hintergrundprozesse) ein HUP, daher das
: >nohup. Wenn man aber die login shell mit "kill -9" killt, kann
: >anscheinend der Kernel (tty Treiber) nicht mehr rauskriegen, was denn
: >die Process-Group war, damit gibt's auch kein HUP an die Kinder (das
: >w�re dann also die unsaubere L�sung wenn man das nohup vergessens
: >hat).
: 
: Ich dachte, es sei so, dass bei kill -9 der entsprechend gekillte
: Prozess keine Chance mehr hat irgendwas aufzuraeumen. Somit hat es
: auch keine Moeglichkeit seine Kinder zu killen. Oder liege ich da 
: falsch?

Das ist die alternative Erk�rung :-)
Die hielt ich fr�her auch f�r richtig, das w�rde aber bedeuten, da�
die shell beim exit noch ein HUP an ihre eigene Prozessgroup
schickt. Auch m�glich. Nur denke ich jetzt, da� es eigentlich Aufgabe
des Terminal-Treibers ist, ein HUP zu verschicken, und nicht Aufgeb
der shell. 
Hm, vielleicht h�ngt das auch mit dem Teminal zusammen, wenn man �ber
ein tty eingeloggt ist, schickt der Terminal-Treiber ein HUP, sonst
nicht, daf�r aber die shell.

Hm, genaugenommen wei� ich es nicht, und es hat keinen Sinn, in
de.comp.os.unix halbwahre Sachen zu vermuten, es gibt immer jemanden,
der es genau wei� :-)

Also: Wer schickt wann ein HUP beim ausloggen?

Tsch��,
	Michael

-- 
Michael Staats, Theoretical Physics, Uni-GH Duisburg 
email: michael@thp.Uni-Duisburg.DE
<a href="http://WWW.thp.Uni-Duisburg.DE/">Click</a> me!
<a href="http://WWW.thp.Uni-Duisburg.DE/cuaix/cuaix.html">A c.u.aix archive</a>

Ich schrieb:

> $ ps -j
>    PID  PGID   SID TTY      TIME COMD
>   6832  6832  4353 pts000   0:01 ksh
>   6942  6942  4353 pts000   0:00 ps
>   6940  6940  4353 pts000   0:00 ksh
>   6941  6940  4353 pts000   0:00 sleep
> 
> Es ist deutlich zu sehen, da� die Vordergrundproze�gruppe die 6832
> ist, w�hrend die while-Schleife die 6940 belegt.

Nat�rlich ist die 6832 die Proze�gruppe der Shell und die 6942 die
Vordergrundproze�gruppe (n�mlich die des ps selbst).  Allerdings tut
das nicht viel zur Sache -- es bleibt dabei, da� die ksh wie alle
anderen job-control-f�higen Shells mehrere Proze�gruppen aufbaut.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

michael@hal6000.thp.Uni-Duisburg.DE (Michael Staats) schrieb:

> >Das & am Ende tut es nur dann, wenn Deine Shell Posix-Job-Control
beherrscht.

> Hm, nein, eher nicht.

Eher doch. :)

> 1. "script &" klappt nur bei shells, die sozusagen ein eingebautes
> "nohup" haben, z. B. tcsh/csh, sonst wird der Prozess beim Ausloggen
> mit HUP gekillt. (* siehe unten)

Eben bei Job-Control shells.  Kann sein, da� die Korn-Shell
�bereifrigerweise ein SIGHUP, das sie bekommt, auch gleich noch an
alle ihre Kind-Proze�gruppen weiterreicht -- so genau kenne ich mich
mit der ksh nicht lang.  Auf jeden Fall _verwaltet_ sie aber auch
getrennte Proze�gruppen:

$ uname -a                             
UNIX_SV snaily 4.2 1.1 i386 386/AT
$ what /bin/ksh
/bin/ksh:
        Version 11/16/88g
$ (while true; do sleep 10; done) &
[1]     6940
$ ps -j
   PID  PGID   SID TTY      TIME COMD
  6832  6832  4353 pts000   0:01 ksh
  6942  6942  4353 pts000   0:00 ps
  6940  6940  4353 pts000   0:00 ksh
  6941  6940  4353 pts000   0:00 sleep

Es ist deutlich zu sehen, da� die Vordergrundproze�gruppe die 6832
ist, w�hrend die while-Schleife die 6940 belegt.

> (*) Ich kenne mich mit tcsh/csh nicht aus und wei� nicht genau, wie
> das "eingebaute" nohup funktioniert, entweder setzt die shell 
> vorm exec() die signal mask, oder Hintergrundprozesse kommen gar nicht
> in die gleiche Process-Group.

Sie kommen genau wie bei obiger Korn-Shell nicht in die gleiche
Proze�gruppe und ... 

> (**) zum Thema HUP Signal: Das ist ziemlich verwirrend. Eigentlich
> sollte der Terminal-Treiber das HUP beim logout schicken.

...macht er auch, aber nur an die Vordergrundproze�gruppe.  Sollte
nat�rlich die dort laufende Shell so doof sein und dann noch alle ihre
Kinder mit in den Tod rei�en (,,Wenn ich schon sterben mu�, dann
braucht ihr ja nicht weiterleben!''), dann ist das ihr (oder Dein :)
Problem.  C-alike Shells machen das nicht (und sind daher effektiv
,,nohuped'' f�r ihre Hintergrundjobs, egal, wie sie in den Hinter-
grund gelangt sind), und meines Wissens machen das zumindest die bash,
die pdksh, und 4.4BSD's job-control-f�hige /bin/sh nicht.

Wenn Du eine Shell mit -KILL abschie�t, bist Du nat�rlich f�r die
Folgen verantwortlich.  Wenn schon, dann schie� die ganze Proze�gruppe
ab (negative PID verwenden).  Normalerweise schickt man ein -HUP an
die Proze�gruppe (was auch bei background jobs der csh geht, weil sie
eben nur ``effectively nohuped'' sind).

-- 
J"org Wunsch					       Unix support engineer
joerg_wunsch@interface-business.de       http://www.interface-business.de/~j

j@ida.interface-business.de (J Wunsch) writes:

>michael@hal6000.thp.Uni-Duisburg.DE (Michael Staats) schrieb:

>> >Das & am Ende tut es nur dann, wenn Deine Shell Posix-Job-Control
>beherrscht.

>> Hm, nein, eher nicht.

>Eher doch. :)

Hm, also entweder reden wir aneinander vorbei oder nicht :-)
Also: Nat�rlich tut ein & das was es schon immer getan hat: Den
Prozess in den Hintergrund schicken. Das meinte ich.

>> 1. "script &" klappt nur bei shells, die sozusagen ein eingebautes
>> "nohup" haben, z. B. tcsh/csh, sonst wird der Prozess beim Ausloggen
>> mit HUP gekillt. (* siehe unten)

>Eben bei Job-Control shells.  Kann sein, da� die Korn-Shell
>�bereifrigerweise ein SIGHUP, das sie bekommt, auch gleich noch an
>alle ihre Kind-Proze�gruppen weiterreicht -- so genau kenne ich mich
>mit der ksh nicht lang.  Auf jeden Fall _verwaltet_ sie aber auch
>getrennte Proze�gruppen:

[ ... ]
Ok, das stimmt.

>Sie kommen genau wie bei obiger Korn-Shell nicht in die gleiche
>Proze�gruppe und ... 

>> (**) zum Thema HUP Signal: Das ist ziemlich verwirrend. Eigentlich
>> sollte der Terminal-Treiber das HUP beim logout schicken.

>...macht er auch, aber nur an die Vordergrundproze�gruppe.  Sollte
>nat�rlich die dort laufende Shell so doof sein und dann noch alle ihre
>Kinder mit in den Tod rei�en (,,Wenn ich schon sterben mu�, dann
>braucht ihr ja nicht weiterleben!''), dann ist das ihr (oder Dein :)
>Problem.

Tja, was sagt denn z. B. Posix zu dem Thema? Mu� das so oder nicht?

>C-alike Shells machen das nicht (und sind daher effektiv
>,,nohuped'' f�r ihre Hintergrundjobs, egal, wie sie in den Hinter-
>grund gelangt sind), und meines Wissens machen das zumindest die bash,
>die pdksh, und 4.4BSD's job-control-f�hige /bin/sh nicht.

Ha, mit der pdksh hast Du mich jetzt aber �berrascht. Tats�chlich sind
auch dort Hintergrundprozesse effektiv ge-nohuped, hab's grad
ausprobiert. 

>Wenn Du eine Shell mit -KILL abschie�t, bist Du nat�rlich f�r die
>Folgen verantwortlich. Wenn schon, dann schie� die ganze Proze�gruppe
>ab (negative PID verwenden).

Nein. Genau das will ich ja nicht. Der kill -KILL Trick ist die quick
and dirty Methode, bei der ksh z. B. ein laufendes ftp im Vordergrund
zu starten, in den Hintergrund zu schicken und ein logout ohne
Beendigung des ftp Prozesses zu machen. Wie ich �berfl�ssige Prozesse
loswerde, ist das genaue Gegenteil.

Tsch��,
	Michael
--
Michael Staats, Theoretical Physics, Uni-GH Duisburg 
email: michael@thp.Uni-Duisburg.DE
<a href="http://WWW.thp.Uni-Duisburg.DE/">Click</a> me!
<a href="http://WWW.thp.Uni-Duisburg.DE/cuaix/cuaix.html">A c.u.aix archive</a>

michael@hal6000.thp.Uni-Duisburg.DE (Michael Staats) schrieb:

> >...macht er auch, aber nur an die Vordergrundproze�gruppe.  Sollte
> >nat�rlich die dort laufende Shell so doof sein und dann noch alle ihre
> >Kinder mit in den Tod rei�en (,,Wenn ich schon sterben mu�, dann
> >braucht ihr ja nicht weiterleben!''), dann ist das ihr (oder Dein :)
> >Problem.
> 
> Tja, was sagt denn z. B. Posix zu dem Thema? Mu� das so oder nicht?

Sollte in Posix.1 stehen, das habe ich aber leider nicht.

Ich vermute, da� das dort eher schwammig formuliert ist, da� es also
so sein darf (schlie�lich hat man in Posix alles unterlassen, um die
ksh irgendwie zu kompromittieren, und deren teilweise dubioses
Verhalten dann oft als ``implementation-defined'' deklariert), aber
nicht sein mu�.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)