Jak radzić sobie z zadaniami, które przestają działać i nie mogą być kontynuowane, chyba że są na pierwszym planie?

Ostatni przykład: mountlo (przy użyciu UML):

vi @ vi-notebook: ~ / b $ mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other &
[1] 32561
vi @ vi-notebook: ~ / b $ Sprawdzanie, czy ptrace może zmieniać numery wywołań systemowych ... OK
Sprawdzanie łatki emulacji syscall pod kątem ptrace ... OK
Sprawdzanie zaawansowanej łatki emulacji syscall pod kątem ptrace ... OK
Sprawdzanie mmapy PROT_EXEC w /tmp...OK
Sprawdzanie poprawki skas3 na hoście:
  - /proc/mm... nie znaleziono
  - Nie znaleziono PTRACE_FAULTINFO ...
  - Nie znaleziono PTRACE_LDT ...
UML działa w trybie SKAS0


[1] + Zatrzymano mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other
vi @ vi-notebook: ~ / b $ bg
[1] + mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other &

[1] + Zatrzymano mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other
vi @ vi-notebook: ~ / b $ bg
[1] + mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other &

[1] + Zatrzymano mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other
vi @ vi-notebook: ~ / b $ bg
[1] + mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other &

[1] + Zatrzymano mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other
vi @ vi-notebook: ~ / b $ fg
mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8, allow_other
Wersja Linux 2.6.15 (miko @ dorka) (gcc wersja 3.3.5 (Debian 1: 3.3.5-13)) # 1 Pn 27 lutego 13:27:52 CET 2006
(normalna wydajność)
...

vi @ vi-notebook: ~ / b $ socat - exec: 'mountlo -m 16 -d / dev / uba1 / home / vi / mnt / usb -t vfat -o iocharset = utf8 \, allow_other', pty, ctty
fusermount: waitpid: Brak procesów potomnych
vi @ vi-notebook: ~ / b $ 

Dzieje się tak również z Gimpem (kiedy działa, to wtyczki). Części Gimpa uruchomione przez `gimp q.jpg & 'zawieszają się i nie mogą być kontynuowane, chyba że„ killall -CONT ”lub nie pojawią się na pierwszym planie.

Czy to błąd? Jak niezawodnie uruchamiać rzeczy w tle?

To chyba nie jest błąd. Czasami program chce lub musi komunikować się ze standardowym wejściem (STDIN). Na przykład może chcieć zadać pytanie. Ale program nie może tego zrobić, chyba że jest uruchomiony na pierwszym planie, więc pojawi się komunikat „Zatrzymany”. Następnie możesz przenieść go na pierwszy plan za pomocą „fg”. Czasami działa przekierowanie standardowego wejścia z jakiegoś pliku, ale wtedy możesz potrzebować wiedzieć, co umieścić w tym pliku. Możesz spróbować przekierować z / dev / null, który powinien być zawsze dostępny dla programu, nawet jeśli działa w tle. Aby uruchomić z przekierowaniem STDIN z / dev / null, możesz:

$ program arg1 arg2 arg3 ... </dev/null

Są chwile, kiedy program będzie nalegał, aby STDIN był terminalem, więc może to nie działać i może nie działać, jeśli program oczekuje pewnych danych. Podsumowując, niektóre programy oczekują działania w sposób interaktywny i nie będą działać poprawnie, gdy będą działać w tle.