Иван Корюков

Скорее всего в базовом образе, который вы используете, настроен ENTRYPOINT, который превращает вашe src/start.sh в node src/start.sh или типа того.

Посмотрите что именно прописано в ENTRYPOIN и подстройтесь или замените его.

Хотелось бы побольше подробностей, потому что не совсем ясно как будет использоваться скрипт и, соответственно, что именно он должен делать.
Предположу, что при вызове скрипта должен создаваться один новый пользоваетль с шаблонным именем.
Т.е. нужно как-то из системы получить список таких пользователей, найти последнего, взять из него цифру и увеличить на один.
Если обязательно нужен именно монотонно возрастающий номер, то примерно вот так:

lastUserSuffix=$(cat /etc/passwd | awk 'BEGIN {FS=":"}; {print $1}' | grep systemd | sort -n | sed 's/systemd-//' | tail -1)

Я тут ищу пользователей с именем systemd-***, думаю вам не составит труда изменить пример для своих целей.

Выглядит так, будто вы уже неправильно запускаете ваш проект.
reboot now это вы хотите прям на уровне операционной системы перезагрузиться? Зачем так радикально?
Зачем заходить в скрин? Выскажу догадку - yarn start завершается когда вы выходите с сервера, и вы решили запускать его в скрине?

Ну такое.
Смотрите. Можно сделать надёжнее
1) устанавливаете pm2 - менеджер процессов для долгоживущих nodejs приложений
2) пишете простой как две копейки ecosystem файл
3) запускаете своё творение не в скрине, и выходите с сервера не опасайсь что оно упадёт

Далее можно организовать перезапуск приложения. Не сервера.
Самый простой способ - повесить на этом же сервере на крон скрипт, который будет делать curl -s -o /dev/null -w "%{http_code}". Если ответ этой команды не "200" то выполнять команду pm2 restart myApp

Кстати, если перебои в работе приложения происходят из-за того что прям процесс падает, то даже никакой крон не понадобится - pm2 сам следит за тем что приложение остановилось, и запускает его снова.

Потому что паттерн надо в кавычки брать. А ещё в греп надо явно указывать что паттерн это регулярка опцией -E
Сделайте
grep - E 'ваш паттерн'

Чтобы программа работала "в фоне", она должна либо сама позаботиться о том чтобы не блокировать консоль и не умирать при закрытии баша, либо доверить это специальной программе.

Как уйти в фон самостоятельно:
Процессы (работающие программы) имеют идентификаторы и знают кто их запустил, посредством хранения id родительского процесса. Т.о. у нас есть дерево процессов. Родительский процесс может управлять дочерними, и он должен при своём завершении завершать и свои дочерние процессы. Если он этого не сделает, то дочерний процесс сменит родителя на процесс с id = 1, т.е. на init процесс. Поэтому чтобы уйти в фон, ваша программа должна всего лишь остановить её родительский процесс.
Проблема в том, что родительский процесс для программы, которую вы запускаете в консоли - это сама консоль и нам не надо чтобы она закрылась.
Поэтому уходящие в фон программы перед остановкой родителя увеличивают уровень вложенности - т.е. запускают свою копию, и эта копия, будучи дочерней для первого процесса программы, убивает уже не баш, а вспомогательный родительский процесс.
Другой момент - это отвязаться от консоли. Тут всё просто - надо перенаправить stdin, stderr и stdout в файлы.
Ну и наконец надо позаботиться об управлении демоном, ведь пока что нам не остаётся ничего другого, кроме как посылать ему сигналы командой kill. Чтобы реализовать более понятные команды, надо сделать две вещи:
1) во время ухода в фон сохранить в файл pid результирующего процесса
2) написать немного кода в самой программе или во вспомогательном скрипте, который, при вызове его в консоли, будет читать pid из файла и манипулировать процессом.

Такая функциональность часто выделяется в отдельную библиотеку, можно поискать в документации или на гитхабе.

Другой вариант - использовать вспомогательные программы.
С одной стороны у нас есть возможности самого баша - jobs т.е. фоновые процессы, которые однако умирают при закрытии консоли. Чтобы это обойти есть команда disown и программы nohup и setsid.
Они позволяют так или иначе получить процесс отвязанный от баша. Однако управлять процессом можно будет только сигналами.
С другой стороны есть менеджеры процессов. Например supervisord или pm2. Это такие программы, которые умеют уходить в фон и умеют, уже будучи демоном, запускать другие программы и управлять ими.

Ну и наконец всегда есть главный менеджер процессов вашего компьютера/сервера - это система инициализации, которая сейчас почти везде - systemd. Делает то же самое что и обычный менеджер процессов, но ещё и позволяет управлять последовательностью запуска процессов.

Итог: выбирать способ демонизации процесса необходимо исходя из стабильности его работы. Если это сервер, который должен работать месяцами и запускаться при старте системы - то надо использовать систему инициализации. Так делают Nвеб-сервера, базы данных и всякие капитальные сервисы.
Если процессы более динамичные и их надо периодически запускать и останавливать, то лучше взять менеджер процессов.
Если это совсем уж мимолётное желание запустить программу в фоне, пусть поработает а там остановлю, то можно не заморачиваться и отвязать её от баша тем или иным способом.

Возможность самостоятельно уйти в фон и реализация собственных команд управления процессом нужна только если у вас наполеоновские планы и вы хотите дать пользователям возможность запускать вашу программу на разных ОС.