Unix/Java процесс останавливается при перемещении в фоновый режим

Question

У нас есть процесс Java, который был создан с использованием Appassembler. Он работает нормально, если он запущен и работает на переднем плане:

[ec2-user@ip-xxx ourapp-0.0.1-SNAPSHOT]$ bin/ourapp
Starting in APP_HOME=/home/ec2-user/app_home
Press Q to quit

Затем мы можем получить доступ и протестировать приложение успешно. Однако, если мы запустим его в фоновом режиме, он не только перестанет работать, но мы не сможем его оживить, не выдвинув его на передний план:

[ec2-user@ip-xxx ourapp-0.0.1-SNAPSHOT]$ bin/ourapp &
[1] 11661
Starting in APP_HOME=/home/ec2-user/app_home
Press Q to quit
                                                     ## Not accessible!
[ec2-user@ip-xxx ourapp-0.0.1-SNAPSHOT]$  jobs
[1]+  Stopped                 bin/ourapp
[ec2-user@ip-xxx ourapp-0.0.1-SNAPSHOT]$  bg %1
[1]+ bin/ourapp &                                    ## Still not accessible!
[ec2-user@ip-xxx ourapp-0.0.1-SNAPSHOT]$  jobs
[1]+  Stopped                 bin/ourapp
[ec2-user@ip-xxx ourapp-0.0.1-SNAPSHOT]$  fg %1
bin/ourapp                                           ## Now, it's accessible.

Я начинаю это неправильно? Есть ли способ сохранить работу, даже если она работает в фоновом режиме? Мне нужно запустить его как процесс-демон с nohup а затем выйти из системы, но я не могу поддерживать его в рабочем состоянии, пока он не останется процессом переднего плана, что невозможно.

Answer 1

Кажется, что фоновые задания, ожидающие ввода , в большинстве сред останавливаются .

Со страницы Википедии в Unix Job Control:

Фоновому процессу, который пытается прочитать или записать на свой управляющий терминал, отправляется сигнал SIGTTIN (для ввода) или SIGTTOU (для вывода). Эти сигналы останавливают процесс по умолчанию, но они также могут обрабатываться другими способами.

А со страницы Рутгерса о промежуточном использовании Unix:

Работа, выполняемая в фоновом режиме, остановится, если потребуется ввод данных. Вход не может быть передан в фоновое задание, поэтому убедитесь, что все необходимые данные доступны для него.

В качестве решения мы просто обновили наш Java-процесс, приняв необязательный аргумент, который заставит основной поток бездействовать бесконечно, а не ждать ввода. У нас есть хук отключения, который будет обрабатывать сигналы SIGTERM/SIGINT соответственно:

        if (args.length >= 0 && StringUtils.equals(args[0], "daemon")) {
            while (true) {
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }