Ctrl + c in un processo secondario sta uccidendo un processo nohup in precedenza nello script

Non sapevo se questo appartenesse a SO (in quanto è un bug di codifica) ma pensavo che voi ragazzi sareste più informati riguardo alle sottigliezze del software utilizzato (quindi forse anche U&L potrebbero essere considerati).

Ecco lo script di codice minimo (vedi le modifiche per lo script completo, c'è una ragione per cui lo sto facendo in questo modo);

#/bin/bash
nohup {SERVERCOMMAND} > currentOutput.log 2>&1 &

less +F currentOutput.log

Ciò che tenta di fare è eseguire un server in background, che genera un file di registro.
Quindi ho followquel file di registro usando less +F. Mentre lo fai, per uscire da questo devi premere ctrl+ cprima di poter premere Q.

Quello che succede è che quando I ctrl+ call'interno del lesscomando (per fermarsi tailing) in qualche modo uccide il server iniziato con nohupin alto! Nient'altro è interessato. Posso shift+ fper ricominciare a seguire il registro (che non riceve nuove informazioni da quando il server viene ucciso) e se premo Qil resto dello script viene eseguito normalmente.

Sai perché questo accade? Come evitarlo / qualcos'altro che dovrei usare?

PS
Il programma server potrebbe essere in attesa di a ^C, che potrebbe essere il problema; c'è qualcosa che posso fare per fermarlo? Ad esempio, quando corro {SERVERCOMMAND}da solo (in modo bloccante), posso premere ctrl+ c, che non lo uccide immediatamente; stampa Received ^C signal, shutting down(e poi si uccide). Questo è ciò che sta accadendo quando ^Centro less(un finale Received ^C signal, shutting downè scritto nel registro).

PPS
Ho provato diverse cose (nessuna ha funzionato);

• cercando di disconnettere lo stdin dallo script cambiando

  nohup {SERVERCOMMAND} > currentOutput.log 2>&1 &
  to
  nohup echo '' | {SERVERCOMMAND} > currentOutput.log 2>&1 &
  or
  nohup cat /dev/null/ | {SERVERCOMMAND} > currentOutput.log 2>&1 &

• usando stty intr ^Gper sostituire il comando di interruzione, ma poi ctrl+ ha gfatto esattamente quello che ^Cstava facendo comunque (quindi potrebbe essere un problema con il mio emulatore di terminale; konsole)

• posizionando la nohup& / o la lesslinea tra parentesi (per renderla una subshell)

• eseguendo lo script xterminvece dikonsole

Avevo ragione nel pensare che SIGINTfosse inviato a tutti i processi quando ctrl+ c, ma ero sciocco nel pensare che fare un altro processo l'avrebbe portato fuori dal process group(vedi i miei tentativi nel P.P.S.).

Questo non è solo il caso d'uso esatto, ma la soluzione corretta.

A causa di come la mia sceneggiatura era strutturata, la risposta lì non si adattava alla lettera, questa è la sceneggiatura ora;

#/bin/bash

setsid {SERVERCOMMAND} > currentOutput.log 2>&1 &
less +F currentOutput.log

Il server continua a essere emesso nel file di registro dopo I ctrl+ cin less.

Grazie per il tempo di tutti.

Hai provato a rinnegare ?

  disown -h %1

o qualunque sia il tuo lavoro; disown è una shell integrata, la sua pagina man afferma:

rinnegare

disown [-ar] [-h] [jobspec ...]

Senza opzioni, ogni jobspec viene rimosso dalla tabella dei lavori attivi. Se l' opzione -h' option is given, the job is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. If jobspec is not present, and neither the-a 'né -r' option is supplied, the current job is used. If no jobspec is supplied, the-a' significa rimuovere o contrassegnare tutti i lavori; l'opzione `-r 'senza un argomento jobspec limita l'operazione ai lavori in esecuzione.

MODIFICARE

Cosa divertente, i tuoi lavori di costruzione sul mio Arch Linux:

 $ cat testm
  #!/bin/sh

  nohup /home/mario/temp/waste & 

  less +F out.log

 $ cat waste
  #!/bin/sh

  while [ 1 ]; do
    find / -print 2>1 1> out.log
  done
  $ ./testm
   nohup: appending output to ‘nohup.out’
  $ ps ax | grep waste
    19090 pts/2    S      0:00 /bin/sh /home/mario/temp/waste
    19124 pts/2    S+     0:00 grep waste]
  $

Prima del comando ps , dovevo scorrere il file out.log, quindi Ctrl+C, quindi q.