Файл init в вызовах init.d с использованием sudo в script.sh выдает ошибку sudo: tty отсутствует и не задана программа askpass

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

То, что происходит, является вложенным вызовом sudo в рамках того сценария, перестал работать, потому что sudo обычно запрашивал бы пароль, но нет никакой оболочки управления, таким образом, он не может. Это генерирует немного неоднозначное sudo: no tty present and no askpass program specified ошибка, которую Вы видите.

Простой способ проиллюстрировать это состоит в том, если, как Ваш пример, init сценарий содержит внутренние вызовы с помощью sudo. Выполнение:

sudo /etc/init.d/startvpn

может перестать работать, если Ваш собственный пользователь не имеет sudo прав на все вызовы sudo в и мог бы дать Вам sudo tty ошибка. Однако выполняя его как это:

sudo sh /etc/init.d/startvpn

вероятно, работал бы. В последнем случае, sudo sh создает командный процессор как корень, таким образом, что-либо, что выполняется в той оболочке на самом деле, выполняется как корень. Корень обычно имеет неограниченные sudo полномочия, таким образом, больше не имеет значения, если команда выполняется с sudo или нет.

Некоторые вещи, которые стоит упомянуть:

• Как другие указали, большей части этой путаницы можно избежать, не используя sudo в рамках сценариев. Часто подкоманды, которые перестали работать, когда выполнено с sudo, могут хорошо работать без него (когда родительский скрипт запущен с sudo).
• При запущении скрипта с sudo sh может решить проблему, снова существуют последствия безопасности к выполнению так. Полагайте, что sudo ведет себя этот путь как проверка работоспособности, чтобы гарантировать, что содержание сценария не делает чего-то, что они не были должны, даже если сам сценарий позволяется.
• Если пользователь, Вы выполняете sudo, равно как и имеет достаточные общие полномочия, Вы не можете видеть ни одну из этих проблем. Но они могут появиться позже, сказать, разрабатываете ли Вы сценарий со своей собственной привилегированной учетной записью, и в производстве это, работал как непривилегированная сервисная учетная запись.
• В целом необходимо постараться не давать широкие sudo разрешения к учетным записям пользователей как способ решить этот вид проблемы. Если действительно необходимый, ограничьте правила доступа к счету тем пользователем и что определенная команда.