How do I deal with job that stop and cannot continue unless made foreground?

Question

Recent example: mountlo (using 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$ Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking PROT_EXEC mmap in /tmp...OK
Checking for the skas3 patch in the host:
  - /proc/mm...not found
  - PTRACE_FAULTINFO...not found
  - PTRACE_LDT...not found
UML running in SKAS0 mode


[1]+  Stopped                 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]+  Stopped                 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]+  Stopped                 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]+  Stopped                 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
Linux version 2.6.15 (miko@dorka) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 Mon Feb 27 13:27:52 CET 2006
(normal output)
...

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: No child processes
vi@vi-notebook:~/b$ 

Also happens with Gimp (when it does run it's plug-ins). Parts of Gimp started by `gimp q.jpg&' freeze and cannot continue unless "killall -CONT" or made foreground.

Is it a bug? How do I reliably start things in a background?

Answer 1

It's probably not a bug. Sometimes a program wants or needs to communicate with the standard input (STDIN). For example it might want to ask a question. But a program cannot do this unless it's running in the foreground, so then you get the "Stopped" notice. You can then bring it to the foreground with 'fg'. Sometimes it works to redirect standard input from some file, but then you might need to know what to put in that file. You could try redirecting from /dev/null which should always be available to the program, even if it's running in the background. To run with STDIN redirected from /dev/null, you could do:

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

There are times when a program will insist that STDIN be a terminal, so this may not work and it might not work anyway if, the program is expecting some data . Bottom line, some programs expect to work in an interactive manner and will not work properly when backgrounded.