j'ai fait un script qui lance rsync, et je le lance avec le terminal
avec "&" pour pouvoir fermer le terminal avant la fin
bizarre ... des que je ferme le terminal, rsync fait
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at
/SourceCache/rsync/rsync-35.2/rsync/rsync.c(244) [sender=2.6.9]
ou
Killed by signal 1.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
OdarR
On 29 sep, 19:56, Thomas wrote:
bonjour :-)
j'ai fait un script qui lance rsync, et je le lance avec le terminal avec "&" pour pouvoir fermer le terminal avant la fin
bizarre ... des que je ferme le terminal, rsync fait rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at /SourceCache/rsync/rsync-35.2/rsync/rsync.c(244) [sender=2.6.9] ou Killed by signal 1.
qqn sait pourquoi ?
le process reste attaché à ton terminal, donc si tu le fermes, il ne sait pas où envoyer stdout (la sortie standard), etc. Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
Olivier
On 29 sep, 19:56, Thomas <fantome.forums.tDeCon...@free.fr.invalid>
wrote:
bonjour :-)
j'ai fait un script qui lance rsync, et je le lance avec le terminal
avec "&" pour pouvoir fermer le terminal avant la fin
bizarre ... des que je ferme le terminal, rsync fait
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at
/SourceCache/rsync/rsync-35.2/rsync/rsync.c(244) [sender=2.6.9]
ou
Killed by signal 1.
qqn sait pourquoi ?
le process reste attaché à ton terminal, donc si tu le fermes, il ne
sait pas où envoyer stdout (la sortie standard), etc.
Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
j'ai fait un script qui lance rsync, et je le lance avec le terminal avec "&" pour pouvoir fermer le terminal avant la fin
bizarre ... des que je ferme le terminal, rsync fait rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at /SourceCache/rsync/rsync-35.2/rsync/rsync.c(244) [sender=2.6.9] ou Killed by signal 1.
qqn sait pourquoi ?
le process reste attaché à ton terminal, donc si tu le fermes, il ne sait pas où envoyer stdout (la sortie standard), etc. Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
Olivier
xavier
OdarR wrote:
Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
nohup(1), c'est vilain. Utiliser screen(1) demande un poil plus d'investissement, mais est énormément plus puissant.
Mais bon, dans le cas qui nous intéresse ici (une sauvegarde), la bonne solution est de créer une tâche launchd
-- XAv Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
OdarR <olivier.darge@gmail.com> wrote:
Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
nohup(1), c'est vilain. Utiliser screen(1) demande un poil plus
d'investissement, mais est énormément plus puissant.
Mais bon, dans le cas qui nous intéresse ici (une sauvegarde), la bonne
solution est de créer une tâche launchd
--
XAv
Disponible au 01/04/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
nohup(1), c'est vilain. Utiliser screen(1) demande un poil plus d'investissement, mais est énormément plus puissant.
Mais bon, dans le cas qui nous intéresse ici (une sauvegarde), la bonne solution est de créer une tâche launchd
-- XAv Disponible au 01/04/2010 <http://www.xavierhumbert.net/perso/CV2.html>
OdarR
On 29 sep, 20:38, (Xavier) wrote:
OdarR wrote: > Écris nohup en début de ligne et réessaie, ça devrait aller mie ux.
nohup(1), c'est vilain. Utiliser screen(1) demande un poil plus d'investissement, mais est énormément plus puissant.
utiliser nohup en connaissance de cause http://fr.wikipedia.org/wiki/Nohup c'est aussi faire preuve de pragmatisme, tout dépend du temps dont dispose notre ami.
Mais bon, dans le cas qui nous intéresse ici (une sauvegarde), la bonne solution est de créer une tâche launchd
la vraie (c) solution quoi ;-)
Olivier
On 29 sep, 20:38, xav...@groumpf.org (Xavier) wrote:
OdarR <olivier.da...@gmail.com> wrote:
> Écris nohup en début de ligne et réessaie, ça devrait aller mie ux.
nohup(1), c'est vilain. Utiliser screen(1) demande un poil plus
d'investissement, mais est énormément plus puissant.
utiliser nohup en connaissance de cause
http://fr.wikipedia.org/wiki/Nohup
c'est aussi faire preuve de pragmatisme, tout dépend du temps dont
dispose notre ami.
Mais bon, dans le cas qui nous intéresse ici (une sauvegarde), la bonne
solution est de créer une tâche launchd
OdarR wrote: > Écris nohup en début de ligne et réessaie, ça devrait aller mie ux.
nohup(1), c'est vilain. Utiliser screen(1) demande un poil plus d'investissement, mais est énormément plus puissant.
utiliser nohup en connaissance de cause http://fr.wikipedia.org/wiki/Nohup c'est aussi faire preuve de pragmatisme, tout dépend du temps dont dispose notre ami.
Mais bon, dans le cas qui nous intéresse ici (une sauvegarde), la bonne solution est de créer une tâche launchd
la vraie (c) solution quoi ;-)
Olivier
Thomas
In article , OdarR wrote:
On 29 sep, 19:56, Thomas wrote: > bonjour :-) > > j'ai fait un script qui lance rsync, et je le lance avec le terminal > avec "&" pour pouvoir fermer le terminal avant la fin > > bizarre ... des que je ferme le terminal, rsync fait > rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at > /SourceCache/rsync/rsync-35.2/rsync/rsync.c(244) [sender=2.6.9] > ou > Killed by signal 1. > > qqn sait pourquoi ?
le process reste attaché à ton terminal, donc si tu le fermes,
c'est relativement nouveau, que le terminal envoie SIGHUP à tous ses fils, non ? j'ai un souvenir assez net de pouvoir faire script & pour pouvoir fermer le terminal et qu'il reste en tache de fond, et que ça marchait très bien ... (ou alors c'est vrai quand on le fait à travers ssh ?)
surtout qu'il demande si on veut vraiment fermer, dans certains cas, on peut s'attendre à ce qu'il envoie SIGHUP dans ce cas là mais pas s'il ne pose pas cette question ...
il ne sait pas où envoyer stdout (la sortie standard), etc.
ah bon ? il me semblait que ça ne posait pas de pb, que si ça ne sait pas où aller ça ne va simplement nulle part, mais qu'en tout cas c'est pas une cause de fin prématurée
Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
merci bcp, d'après wikipedia ça a l'air d'être ça :-)
reste un pb :
quand je fais nohup script &> /dev/null & je n'ai plus le Killed by signal 1. dans le rsync lancé par script normalement, mais j'ai encore le rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) dans le rsync lancé par script avec "&"
comment ça se fait ? le nohup n'est pas transmis ??
In article
<a0e7dbf7-1218-4278-8f53-f3b2448d2ad6@z24g2000yqb.googlegroups.com>,
OdarR <olivier.darge@gmail.com> wrote:
On 29 sep, 19:56, Thomas <fantome.forums.tDeCon...@free.fr.invalid>
wrote:
> bonjour :-)
>
> j'ai fait un script qui lance rsync, et je le lance avec le terminal
> avec "&" pour pouvoir fermer le terminal avant la fin
>
> bizarre ... des que je ferme le terminal, rsync fait
> rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at
> /SourceCache/rsync/rsync-35.2/rsync/rsync.c(244) [sender=2.6.9]
> ou
> Killed by signal 1.
>
> qqn sait pourquoi ?
le process reste attaché à ton terminal, donc si tu le fermes,
c'est relativement nouveau, que le terminal envoie SIGHUP à tous ses
fils, non ?
j'ai un souvenir assez net de pouvoir faire
script &
pour pouvoir fermer le terminal et qu'il reste en tache de fond, et que
ça marchait très bien ...
(ou alors c'est vrai quand on le fait à travers ssh ?)
surtout qu'il demande si on veut vraiment fermer, dans certains cas,
on peut s'attendre à ce qu'il envoie SIGHUP dans ce cas là mais pas s'il
ne pose pas cette question ...
il ne
sait pas où envoyer stdout (la sortie standard), etc.
ah bon ?
il me semblait que ça ne posait pas de pb,
que si ça ne sait pas où aller ça ne va simplement nulle part, mais
qu'en tout cas c'est pas une cause de fin prématurée
Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
merci bcp, d'après wikipedia ça a l'air d'être ça :-)
reste un pb :
quand je fais
nohup script &> /dev/null &
je n'ai plus le
Killed by signal 1.
dans le rsync lancé par script normalement,
mais j'ai encore le
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20)
dans le rsync lancé par script avec "&"
comment ça se fait ?
le nohup n'est pas transmis ??
On 29 sep, 19:56, Thomas wrote: > bonjour :-) > > j'ai fait un script qui lance rsync, et je le lance avec le terminal > avec "&" pour pouvoir fermer le terminal avant la fin > > bizarre ... des que je ferme le terminal, rsync fait > rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at > /SourceCache/rsync/rsync-35.2/rsync/rsync.c(244) [sender=2.6.9] > ou > Killed by signal 1. > > qqn sait pourquoi ?
le process reste attaché à ton terminal, donc si tu le fermes,
c'est relativement nouveau, que le terminal envoie SIGHUP à tous ses fils, non ? j'ai un souvenir assez net de pouvoir faire script & pour pouvoir fermer le terminal et qu'il reste en tache de fond, et que ça marchait très bien ... (ou alors c'est vrai quand on le fait à travers ssh ?)
surtout qu'il demande si on veut vraiment fermer, dans certains cas, on peut s'attendre à ce qu'il envoie SIGHUP dans ce cas là mais pas s'il ne pose pas cette question ...
il ne sait pas où envoyer stdout (la sortie standard), etc.
ah bon ? il me semblait que ça ne posait pas de pb, que si ça ne sait pas où aller ça ne va simplement nulle part, mais qu'en tout cas c'est pas une cause de fin prématurée
Écris nohup en début de ligne et réessaie, ça devrait aller mieux.
merci bcp, d'après wikipedia ça a l'air d'être ça :-)
reste un pb :
quand je fais nohup script &> /dev/null & je n'ai plus le Killed by signal 1. dans le rsync lancé par script normalement, mais j'ai encore le rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) dans le rsync lancé par script avec "&"
comment ça se fait ? le nohup n'est pas transmis ??
À (at) Wed, 07 Oct 2009 17:54:04 +0200, Thomas écrivait (wrote):
c'est relativement nouveau, que le terminal envoie SIGHUP à tous ses fils, non ? j'ai un souvenir assez net de pouvoir faire script & pour pouvoir fermer le terminal et qu'il reste en tache de fond, et que ça marchait très bien ... (ou alors c'est vrai quand on le fait à travers ssh ?)
surtout qu'il demande si on veut vraiment fermer, dans certains cas, on peut s'attendre à ce qu'il envoie SIGHUP dans ce cas là mais pas s'il ne pose pas cette question ...
Ce n'est pas le terminal qui envoie le SIGHUP, c'est le shell. Selon le shell, le comportement n'est pas le même vis-à vis des commandes lancées via 'commande &' et certains shells permettent de le configurer...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 07 Oct 2009 17:54:04 +0200,
Thomas <fantome.forums.tDeContes@free.fr.invalid> écrivait (wrote):
c'est relativement nouveau, que le terminal envoie SIGHUP à tous ses
fils, non ?
j'ai un souvenir assez net de pouvoir faire
script &
pour pouvoir fermer le terminal et qu'il reste en tache de fond, et que
ça marchait très bien ...
(ou alors c'est vrai quand on le fait à travers ssh ?)
surtout qu'il demande si on veut vraiment fermer, dans certains cas,
on peut s'attendre à ce qu'il envoie SIGHUP dans ce cas là mais pas s'il
ne pose pas cette question ...
Ce n'est pas le terminal qui envoie le SIGHUP, c'est le shell. Selon
le shell, le comportement n'est pas le même vis-à vis des commandes
lancées via 'commande &' et certains shells permettent de le
configurer...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 07 Oct 2009 17:54:04 +0200, Thomas écrivait (wrote):
c'est relativement nouveau, que le terminal envoie SIGHUP à tous ses fils, non ? j'ai un souvenir assez net de pouvoir faire script & pour pouvoir fermer le terminal et qu'il reste en tache de fond, et que ça marchait très bien ... (ou alors c'est vrai quand on le fait à travers ssh ?)
surtout qu'il demande si on veut vraiment fermer, dans certains cas, on peut s'attendre à ce qu'il envoie SIGHUP dans ce cas là mais pas s'il ne pose pas cette question ...
Ce n'est pas le terminal qui envoie le SIGHUP, c'est le shell. Selon le shell, le comportement n'est pas le même vis-à vis des commandes lancées via 'commande &' et certains shells permettent de le configurer...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
