После обновления до Jessie управление службами не работает вернуть результат
Процесс в состоянии 'D' обычно (но не всегда) "заблокирован на ожидание ввода/вывода". Это может произойти, например, если диск занят и имеет высокое время обслуживания. Процессы в состоянии D учитываются при подсчете средней нагрузки, даже если они не используют реальные ресурсы ЦП.
В случае с NFS процесс может проводить много времени в состоянии 'D', ожидая ответа сервера NFS.
Поведение клиента NFS по умолчанию заключается в том, что перед повторным запросом он будет повторять попытку в течение 60 секунд (см. опцию timeo в man nfs). Это означает, что при возникновении проблемы процесс может находиться в ожидании ввода-вывода не менее 60 секунд.
Что произойдет потом, зависит от настройки retrans и настроек hard/soft.
Если файловая система смонтирована жестко, то повторные попытки будут происходить бесконечно; если смонтирована мягко, то запрос ввода/вывода будет окончательно провален. Но мы видим, что это происходит не сразу из-за опций timeo и retrans.
Клиенты могут испытывать проблемы с NFS по ряду причин; общая из них - пропускная способность сети (особенно если вы работаете в сети WiFi). Другой причиной является объем запросов (если вы работаете параллельно, то это может стать причиной узкого места). Сам сервер может страдать от низкой производительности диска и поэтому медленно реагировать на запросы NFS, или на сервере может быть недостаточно потоков демонов для обработки большого количества запросов.
A lot of services on error, some services always return sucess, even if the service not started, because systemd is starting a kind of service manager instead of the service itself..... And no dont trust service status about what hapenned I get a lot of times a "STARTED OK" and service is really not running without any feedback! So it still does not solve the problem! But is better if you run journal -xe lot better than doing this, but not good enough because you need to run it everytime and remember of it. – @Luciano Andress Martini
«Нет результата» означает, что операция прошла успешно. Это значение по умолчанию для UNIX. Например, так ведут себя команды cpили rm.
Если ваша служба написана неправильно, она может вернуть успех, а затем сразу после этого произойдет сбой, например. когда он читает плохую конфигурацию. Это баг в сервисе! Если скрипт sysvinit ведет себя так, у вас будет точно такая же проблема! systemdничего не может сделать, чтобы это исправить.
Когда ваш модуль выходит из строя, есть хитрость, позволяющая просмотреть последние 10 строк только из вашего демона. Запустите systemctl statusот имени пользователя root (, т.е. sudo). Кроме того, вы можете добавить своего пользователя в качестве члена одной из групп systemd-journalили adm.
Когда мне нужно больше, чем последние 10 строк, я использую journalctl -u tor -b, имея в виду все, начиная с текущей загрузки. Или, если вы перезапускали его много раз во время текущей загрузки, вы можете использовать journalctl -u tor --since=-1hour. Или для краткости --since=-1h.
Я думаю, что systemctlуже предлагает запускать systemctl status, когда устройство не запускается. (К сожалению, systemctl никогда не упоминает о правах доступа ).
systemctlтакже предполагает journalctl -xe. Лично я считаю, что это бесполезно. -xв основном просто добавляет много шума. -eпропускает, например. сообщения stdout/stderr и все остальное, что явно не помечено как сообщение об ошибке. (Извините, он пропускает даже сообщения stderr. Менять это неудобно :, это позволит переупорядочивать строки stderr -по сравнению с обычными строками. stdout, что может быть нежелательно для сценариев оболочки ).
Существует аналогичная жалоба пользователя на систему отслеживания проблем systemd , которая касается некоторых других служб, которые содержат ошибки. (Или один из них выглядит так, как будто он преднамеренно дает сбой «в фоновом режиме» после длительного тайм-аута сети. Опять же, сервис именно так и написан, это не systemd пытается вас насолить ).