Ubuntu journalctl не запускается

Обновлено: 05.07.2024

Журналы - это один из самых важных источников информации при возникновении любых ошибок в операционной системе Linux. Я это уже много раз говорил ранее и вот сказал ещё раз. Раньше в Linux для сохранения журналов сервисов использовался отдельный демон под названием syslogd. Но с приходом системы инициализации systemd большинство функций касающихся управления сервисами перешли под её управление. В том числе и управление логами.

Теперь для просмотра логов определенного сервиса или загрузки системы необходимо использовать утилиту journalctl. В этой статье мы разберем примеры использования journalctl, а также основные возможности этой команды и её опции. По сравнению с обычными файлами журналов, у journalctl есть несколько преимуществ. Все логи находятся в одном месте, они индексируются и структурируются, поэтому к ним можно получить доступ в нескольких удобных форматах.

Синтаксис и опции journalctl

Синтаксис команды очень простой. Достаточно выполнить команду без опций или передав ей нужные опции. Если утилита не выводит ничего, выполните её от имени суперпользователя:

journalctl опции

А теперь давайте разберем основные опции journalctl:

Горячие клавиши journalctl

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

Теперь вы знаете основные опции команды и клавиши, с помощью которых можно ею управлять. Дальше небольшая шпаргалка journalctl.

Шпаргалка по journalctl


Чтобы найти именно то, что вам нужно, необходимо научится перемещаться по этому списку. Формат вывода лога довольно простой:

янв 13 20:55:55 sergiy-pc kernel: Linux version 4.15.0-43-generic

Давайте перейдем к примерам фильтрации и перемещения.

1. Просмотр логов сервисов

sudo journalctl -xe


sudo journalctl -eu apache2.service


2. Просмотр логов в режиме tail

sudo journalctl -f

В этом режиме less не поддерживается, поэтому для выхода нажмите сочетание клавиш Ctrl+C.

3. Просмотр логов загрузки

В логе journalctl содержатся все логи, в том числе и логи загрузки. Для того чтобы открыть лог последней загрузки используйте опцию -b:

sudo journalctl -b

Посмотреть список всех сохраненных загрузок можно командой:

sudo journalctl -list-boots

sudo journalctl -b 37d5c906c9c6404682f029b2c34ec9dc


4. Фильтрация по дате

С помощью опции --since вы можете указать дату и время, начиная с которой нужно отображать логи:

sudo journalctl --since "2019-01-20 15:10:10"


Опция --until помогает указать по какую дату вы хотите получить информацию:

sudo journalctl -e --until "2019-01-20 15:05:50"

Или сразу скомбинируем две эти опции чтобы получить логи за нужный период:

sudo journalctl --since "2019-01-20 15:10:10" --until "2019-01-20 15:05:50"


Кроме даты в формате YYYY-MM-DD в этих опциях можно использовать такие слова, как yesterday, today, и tomorrow. Также допустимы конструкции 1 day ago (один день назад) или 3 hours ago (три часа назад). Ещё можно использовать знаки + и -. Например -1h30min будет означать полтора часа назад.

5. Журнал ядра

sudo journalctl -ek


6. Настройка формата вывода

По умолчанию journalctl выводит информацию с помощью утилиты less, в которой вы можете её удобно листать и просматривать. Но формат вывода можно изменить:

Чтобы указать нужный формат используйте опцию -o. Например:

sudo journalctl -o json-pretty

sudo journalctl -eo json-pretty

7. Очистка логов

Сначала нужно посмотреть сколько ваши логи занимают на диске. Для этого используйте такую команду:

sudo journalctl --disk-usage


Чтобы уменьшить размер лога можно использовать опцию --vacuum-size. Например, если вы хотите, чтобы ваши файлы журналов занимали на диске не более 2 Гб, выполните команду:

sudo journalctl --vacuum-size=2G


Теперь старые логи будут удалены, пока общий объем хранилища не будет составлять 2 гигабайта. Также можно удалять логи по времени. Для этого используется опция --vacuum-time. Например, оставим только логи за последний год:

Выводы

Нет похожих записей


Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Многие новички, которые пытаются настроить свой домашний веб-сервер на основе Apache часто сталкиваются с ошибкой, что Apache не запускается. Благо сейчас в Ubuntu веб-сервер будет правильно работать по умолчанию и запустится, если вы не будете менять настройки, но раньше и в других дистрибутивах приходилось настраивать различные параметры и возникали ошибки.

В этой небольшой статье мы рассмотрим почему Apache не работает, что может стать причиной этой проблемы и как ее решить. Инструкция подойдет не только для Ubuntu, но и для других Linux дистрибутивов.

Почему не запускается Apache?

Вы можете столкнуться с такой проблемой по разным причинам, давайте сначала рассмотрим основные из них, чтобы вы знали что дальше делать:

  • Ошибка в конфигурационном файле - вы меняли конфигурацию и настроили что-то неправильно из-за этого программа не может запустится;
  • Права доступа - у программы нет прав доступа к каким-то важным для нее файлам, например, файлам логов, модулей или конфигурационным файлам;
  • Не запускается служба apache при загрузке, но при запуске из консоли все работает - проблема в том, что на момент запуска загружены еще не все необходимые службы;
  • Неверно указанно доменное имя - такая ошибка довольно часто встречается на локальных компьютерах;

А теперь рассмотрим более подробно почему так происходит и как решить проблему.

Как решить проблему с Apache?

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

See "systemctl status apache2.service" and "journalctl -xe" for details

То есть нам нужно выполнить systemctl status apache2.service или journalctl -xe чтобы получить больше сведений. Выполните сначала первую команду:

systemctl status apache2.service

Мы сразу же видим причину проблемы - ошибка в конфигурационном файле, в директиве Listen, а теперь пробуем другую команду:


Дальше вы можете проверить конфигурационный файл на корректность с помощью такой команды:


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

namei -l /var/www/public_html/


Таким же образом проверяем папку с логами:

namei -l /var/log/apache2/

Как видите, у меня папка /var/www/public_html принадлежит пользователю root, но на папку public_html установлены права чтения и записи для всех пользователей. Поэтому проблем нет, а на папку с логами в качестве группы установлена adm, в эту группу входит пользователь www-data, так что тут тоже проблем нет. Если у вас что-то отличается и вы видите что прав недостаточно, то либо измените владельца папки с файлами веб-сайтов на www-data, либо дайте больше разрешений:

chown -R www-data /var/www/public_html/

Также, если в вашей системе включен SELinux, то вы можете его отключить на время, чтобы понять не в нем ли проблема:

Или вы можете попытаться изменить порт на другой, для этого откройте конфигурационный файл веб-сервера и найдите там строку Listen:

Если такой строки еще нет, то вы можете ее создать. Далее просто измените номер порта с 80 на любой удобный, например, 8080

Дальше про ошибку старта при загрузке. Такая ошибка случалась в версиях ниже 2.2.4, если вы используете эту или более новую версию, то эта проблема вам не страшна. Она была вызвана тем, что Apache с SSL не хотел запускаться без папки /var/run/apache2, которой не было на момент загрузки. Самый простой способ решить проблему - отключить модуль ssl:

Второй способ более сложный - добавьте в конфигурационный файл /etc/init.d/apache2 такую строку:

[ -d /var/run/apache2 ] || mkdir /var/run/apache2

Failed to resolve server name for localhost

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

А также ассоциировать это имя с localhost в файле hosts:

sudo vi /etc/hosts

Дальше было достаточно перезапустить Apache и все начинало работать.

Выводы

В этой статье мы рассмотрели несколько причин почему не запускается Apache и примеров их решения. Причин может быть множество, но мы разобрали только самые главные, которые встречаются наиболее часто. Надеюсь, эта информация была для вас полезной, если у вас остались вопросы, спрашивайте в комментариях! А для тех кого интересует еще один способ решения проблемы xampp apache не запускается для Windows есть видео:

Системы Linux загружаются очень быстро, поэтому большая часть данных, выводимых во время загрузки, быстро прокручивается и мы не успеваем прочитать текст. Тем не менее, во время загрузки, могут возникнуть различные ошибки, вплоть до того, что вы столкнетесь с проблемой не загружается Linux.

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

Почему Linux не загружается?


Причин проблем с загрузкой Linux может быть большое количество, в этой статье мы рассмотрим самые частые из них, которые можно достаточно просто решить. Сначала кратко пройдемся по самим причинам:

  • Linux после обновления не загружается, вы обновляли дистрибутив и что-то пошло не так, и теперь вы не можете попасть в вашу рабочую оболочку;
  • Linux перестал загружаться в результате повреждения файловой системы;
  • Linux не может примонтировать один из важных разделов диска из-за неверных настроек fstab;
  • Система не загружается из-за несовместимости графического драйвера и ядра;
  • Диск переполнен и системе попросту негде создать временные файлы.

Все это может возникать не так редко, если вы очень любите экспериментировать с системой и при этом не очень аккуратны. Мы не будем рассматривать проблемы с загрузкой из за Grub. Я буду надеяться, что там у вас все в порядке. Самое главное, что нужно сделать при проблемах с загрузкой - это посмотреть внимательно логи последней загрузки. Только так вы сможете понять в чем причина проблем и не гадать. Как это сделать? Есть несколько способов, вы можете использовать LiveCD или загрузиться в режим восстановления.

Проверка журналов загрузки

Итак, вы загрузились с LiveUSB системы и подключили разделы с основной системой или же вошли в режим восстановления с помощью загрузчика Grub. Для этого есть специальная опция в большинстве дистрибутивов. Она загружает однопользовательский режим Systemd с поддержкой сети и минимальными возможностями. С помощью него вы можете вернуть систему к нормальной работе.



Для работы в этом режиме нужно ввести пароль суперпользователя.


Если такого пункта нет можно загрузить режим восстановления Bash. Для этого нужно нажать клавишу "E" на пункте меню Grub и дописать в строку параметров ядра "init=/bin/bash":


С этим параметром ядро запустит интерпретатор Bash вместо того, чтобы загружать систему инициализации. Самый первый способ посмотреть логи в systemd - это использовать утилиту journalctl. Система нам сама подсказывает какую команду нужно запустить, чтобы посмотреть логи:


В режиме восстановления можно посмотреть содержимое лога ядра с помощью dmesg, в LiveUSB это бесполезно:

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

Что делать если Linux не грузится?

1. Проблема с местом на диске

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


Если доступно 0% места, то вы знаете в чем проблема. Чтобы ее решить просто удалите ненужные файлы из папок /var/log, /var/cache/ и так далее. Для того чтобы вы смогли редактировать и удалять файлы, корневую систему, возможно, придется перемонтировать для чтения и записи:

mount -o remount,rw /

2. Целостность пакетов и системы

dpkg --configure -a


Также можно выполнить:

Но это сработает только в chroot окружении LiveUSB системы, поскольку в режиме восстановления интернета нет. Вы можете попытаться настроить проводной интернет с помощью команды:

3. Проблема с /etc/fstab

Следующая причина проблем с загрузкой может быть неверная запись в /etc/fstab для одного из разделов, если лог сообщает что-то в роде "Dependency failed for /dev/disk/by-uuid/f4d5ddc4-584c-11e7-8a55-970a85f49bc5" то это означает, что система не может примонтировать один из разделов в /etc/fstab.

Если это будет корневой раздел, система не загрузится. Systemd может выдавать много ошибок, но важно найти первую. Все остальные могут оказаться только ее следствием.


Поэтому если есть такая ошибка в логе проверьте файл /etc/fstab. Правильно ли там указан адрес корневого раздела? Если не уверены, лучше заменить на привычную запись Linux без UUID.

4. Повреждение файловой системы

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


Здесь нужно указать адрес файла нужного раздела в файловой системе.

5. Проблема видеодрайвера

Если вы обновляли систему или устанавливали проприетарный драйвер, а потом в логах загрузки увидели ошибку запуска драйвера, то проблема в нем. Такое происходит потому что проприетарные драйвера не всегда совместимы с самыми новыми версиями ядер. Для решения проблемы достаточно удалить драйвер из системы в режиме восстановления. Например, для Nvidia:

apt purge nvidia*

Для видеокарт AMD команда будет выглядеть так:

apt purge fglrx*

С новым драйвером AMDGPU проблем быть не должно, так как он имеет открытый исходный код и встроен в ядро.

Во всяком случае, после удаления драйвера черный экран Linux должен перестать появляться.

6. Другое

Если у вас все же проблемы с загрузчиком Grub, вы можете использовать инструмент BootRepair для восстановления или просмотрите статью как восстановить Grub2 вручную. Также, возможно, вас заинтересует статья: ускорение загрузки Linux.

Выводы

В этой статье мы рассмотрели что делать когда не загружается Linux. Как видите, может возникнуть достаточно различных проблем. Но преимущество Linux в том, что вы можете решить все это благодаря прямому доступу к файловой системе. Также, если домашняя папка вынесена в отдельный раздел, то если ничего не сработает - можно переустановить систему с минимальными потерями. Надеюсь, эта информация была полезной.

Нет похожих записей

Оцените статью:

(17 оценок, среднее: 4,94 из 5)

Об авторе

10 комментариев

Спасибо Сережа! С уважением А И

Линупс уже давно потерял свою привлекательность. Ещё 6-8 лет назад он был ничего. Отлично пахал на стареньких машинах, можно было и файлопомойку организовать и торрентокачалку, почта там, микросервер, etc. И все работало как winxp на 64-128 Мб оперативки за глаза (есессно не везде), да и вцелом какая-то лёгкость была. Но были и "детские проблемы" ввиде плохой организованности в работе с медиа, кривости драйверов, отсутствию нормальной поддержки образов нового поколения, софт опять же скудный и жалкий был. А сейчас жрет искаропки до 1 Гб, гигабайта, Карл! При этом детские проблемы не излечились, Южноафриканский Линукс стал каким то диким, в остальном какое то все глупое, рассчитанное на поиграться по типу арча, дженты и иже с ними, что там? Рюшечки, шрифтики, тайловые de, а как насчет автомонтирования без костылей? То то же. Те же детские проблемы. И не удивительно, что система падает, но как принято говорить, это не баг, это фича и rolling release, а во всех проблемах винить криворуких и хромых пользователей и ветку testing. Очень жаль, что все стало таким плачевным.

А, ты с чем сравниваешь? Если с семейством windows, то linux на порядок лучше. Уродство Гейтса слетает чаще и проблем больше, и еще к тому же за каждую мелочь денег просит, про вирусы вообще отдельный разговор. Не нравится южно-африканский используй какой нравится, сборок полно. Ну, а если хочешь под себя, берёшь ядро и делай правильный Linux с твоей точки зрения.

Дружок-пирожок, как там в 2017-м со взглядами из 2007-го?

У меня десятка три года стоит на одном компе, четыре на втором, рядом с убунтой. Где у меня было больше проблем? Невероятно, наверное для тебя, но в убунту

спосибо. Был бы еще хорош обзор, если линукс "завис".

Линупс не виснет! (с) Штульман

это конечно чудесные советы, но чтобы ими воспользоваться, нужно всё-таки, чтобы Линукс загрузился

Уважаемый Админ, прошу помощи.
Каюсь в своей криворукости заранее, дайте совет в каком направлении копать.
В общем суть проблемы, Linux Lite 3.8 ubuntu 16.04, заведена в домен средствами PBIS open (likewise-open), но пользователи доменные в терминале не работали с автозаполнением команд и при перемещении стрелками по клавиатуре терминал вместо запомненных команд выдавал символы нажатых клавиш.
Поставил пакеты apt-get install krb5-user, samba, winbind, libnss-winbind, libpam-winbind, терминал ругнулся что likewise несовместим с winbind, продолжить? Жамкнул - Да, заменил файлы, после перезагрузки убунта в режиме восстановления грузится (emergency mode) только по root.
Удалял эти пакеты, которые поставил, удалял их зависимости apt-get autoremove, не помогает, не знаю куда копать, рядом винда стоит по соседству, комп рабочий.
При загрузке стала пробегать строка
Spectre V2: Spectre mitigation:LFENCE not serializing, switching to generic retpoline

Можно как-то восстановить убунту или сносить и по новой ставить?
И еще - какой раздел лучше выбирать при установке, основной или логический или в принципе разницы никакой нет?

В меню загрузчика, в пункте дополнительные опции можно войти в режим восстановления. Здесь можно попытаться выполнить обновление системы, чтобы пакетный менеджер установил всё чего ему не хватает. Не знаю на что влияет домен, но могу предположить, что там монтировались какие-либо диски. Если система не может их смонтировать - это будет мешать загрузке. А вообще, чтобы что-то сказать надо видеть лог загрузки. Для этого надо в загрузчике (там можно редактировать пункт меню, если нажать F10) заменить опцию загрузки ядра quiet на verbose.

2021 год на дворе. Как выражаются опытные линукзятники, я решил уйти со своей гавно-лицензионной Windows 10 на которой проблем не знал вообще никогда и ни с чем, на мною уважаемый Debian Cinnamon. Скачал образ, залил на флешку, начал устанавливать. Устанавливал на SSD Kingston 250гб. Разбил диски, установил. Дебиан не загрузился. Как в пункте 1 посвился целый список, все было ОК, но потом было одно Failed. Я устанавливал вручную, подумал что накосячил. Снова установка. На этот раз выбрал опцию, чтобы при разбивке диска Дебиан сам все сделал. Он разбил. Я установил. Failed. Спасибо Дебиан.
Сейчас по всем правилам мне должны рассказать, что у меня руки кривые, железо кривое, видеокарта кривая, я кривой, и еще раз я кривой. Но тогда вопрос к вам - почему тот же Mint Mate поставился до этого на это же железо норм, а Великий Debian Cinnamon не смог? Минт я кстати снова поменял на Винду из-за ошибок, которые не лечатся годами:
1) невозможно поменять время на нужное;
2) Мате не поддерживает монитор 4к, а когда нашел как поддержать, то и тут всплыли дохренища багов с отображением.
3) Тот же YouTube выглядит как будто под слоем неведомой пыли со странным отображением цветов и контраста, хотя на Винде с этим проблем не было ни разу.
4) Звук шо то был тише, чем на Винде. Даже на Максимуме.
А мне обидно. Мне нравится Дебиан, и я хотел "Корицу". Но она меня не хочет. Уверен, если поставлю тот же Минт Корица, проблем не будет. Соглашусь с одним из комментариев выше - Линукс скатился. Раньше подавал признаки процветания, то сегодня возможно только окружение "Гном" и дистрибутивы "Манжаро" где-то дотягивают, хотя бы на 50% до возвожностей Виндовс 10.

из увиденного вижу 1 еррор фев 28 14:23:53 localhost.localdomain mysql-systemd-start[10386]: 2015-02-28 14:23:53 [ERROR] The data directory '/var/lib/mysql' alread. mpty.

что он означает не знаю, подскажите пожалуйста. Уже и так и этак поискал, ничего найти не могу. заранее спасибо. (Если вопрос не в теме или что-то не понятно прошу прощения)


Если я не ошибаюсь, то нужно перед service mysqld start сделать еще service mysqld initdb (или как-то так).

The service command supports only basic LSB actions (start, stop, restart, try-restart, reload, force-reload, status). For other actions, please try to use systemctl.

Some lines were ellipsized, use -l to show in full.

Для начала понять бы, что на самом деле в этой строке написано.

и как это сделать ?

Добавить ключ -l к команде, которая выводит данный текст.

The data directory '/var/lib/mysql' alread. mpty.

Скорее всего empty - пустая.

mysqld.service - MySQL Community Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled) Active: active (running) since Сб 2015-02-28 15:04:25 MSK; 5min ago Process: 18133 ExecStartPost=/usr/bin/mysql-systemd-start post (code=exited, status=0/SUCCESS) Process: 18095 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS) Main PID: 18132 (mysqld_safe) CGroup: /system.slice/mysqld.service ├─18132 /bin/sh /usr/bin/mysqld_safe └─18276 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock

фев 28 15:04:10 localhost.localdomain mysqld_safe[18132]: 150228 15:04:10 mysqld_safe Logging to '/var/log/mysqld.log'. фев 28 15:04:10 localhost.localdomain mysqld_safe[18132]: 150228 15:04:10 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql фев 28 15:04:25 localhost.localdomain systemd[1]: Started MySQL Community Server.

еррор пропал когда я переименовал там папку но по прежнему не запускается


Если в базе ничего нет, удали mysql, удали /var/lib/mysql и заново поставь.

после того как удалил ошибка пропала, а не запускается все равно. Оно там создало новую mysql с большим количеством внутренностей.


тег code используй

Во-вторых, у тебя

Started MySQL Community Server. The start-up result is done.

Написал ini-шник для запуска сервиса, добавил его через systemctl enable, проверил старт-стоп-рестарт через systemctl start, stop и restart. Перезагружаю машину — не запускается. Что я упустил?

Но после ребута сервер сам не запускается.

Добавление в конфиг

Дистрибутив — Ubuntu 16.04. Но хотелось бы ответ без привлечения Upstart.

Что сделать, чтобы запускался после ребута?

Ответ: в секции [Service] не хватало


Встречался с подобным. Самописный конфиг, ложил в /lib/systemd/system. Разбираться некогда было, прописал systemctl start в /etc/rc.local. Подписался на тред.

P.S. Давно надо перевести сервак на devuan. Руки никак не дойдут.


Разбираться некогда было, прописал systemctl start в /etc/rc.local.

Это сработает в Ubuntu 16.04?

Попробуй, у меня да. Причём, возникло после переключения в disable и снова enable. У меня тоже Ubuntu 16.04. Возможно, стоит завести/плюсануть багрепорт, если ты есть сообществе убунты на ланчпаде. У меня последний сервак доживает на убунте свою жизнь, и я забил.


Сначала приведи логи проблемного запуска.

Возможно docker не умеет сигналить systemd о том, что он готов принимать подключения и запускать контейнеры. В результате твой сервис запускается _сразу_ после того, как запускается сервис docker. Но взлетает он не мгновенно и может получиться так, что твой сервис пытается делать docker run после того, как демон докера запустился, но до того, как он взлетел и всё проинициализировал.

Сначала добавь в конфиг

А то без этой секции оно не знает куда тебе его енейблить.

Эта штука правильно колдует cgroups.

alex_the_v ★★★ ( 20.03.18 07:54:42 )
Последнее исправление: alex_the_v 20.03.18 07:57:29 (всего исправлений: 1)

почему не multi-user.target? Мне кажется, в этом вся проблема


Сначала приведи логи проблемного запуска.



с этим всё сложно :)


Сначала добавь в конфиг
[Install]
WantedBy=default.target

Результат не меняется, об этом сказано в стартовом посте.

А без посторонних утилит, средствами одного systemd нельзя? Не проще ли тогда совсем отказаться от systemd и запускать сервер через rc*.* ?


почему не multi-user.target? Мне кажется, в этом вся проблема

Мне нужно, чтобы сервер запускался при включении машины. Вне зависимости от того, логинится ли туда кто-то или нет. Вне зависимости от запуска иксов. Какую прописать target?


systemctl status и journalctl -e

но вам, возможно, лучше сразу на devuan переходить. может, хоть через руки дойдёт.

default.target — симлинк на таргет по умолчанию и может меняться. multi-user.target — настоящий target.


При чём тут devuan? Я про него впервые слышу. Вопрос про Ubuntu.

На этом дереве отсутствует сервис, запущеный вручную, через systemctl start. Почему?

Спасибо! И даже --no-pager работает.

[/etc/systemd/system/machine.service:11] Failed to parse service restart specifier, ignoring: /bin/sh -c '/usr/bin/docker restart `cat /var/run/machine.key`'

Почему это нормально работает для systemctl restart, но вызывает проблемы при загрузке?


Может прописать в localrc (ну или как там у тебя в rclocal)?

Почему это нормально работает для systemctl restart, но вызывает проблемы при загрузке?

Блин, просмотрел. Эта опция делает другое: Deleted ( 20.03.18 12:50:20 )


Блин, просмотрел. Эта опция делает другое:

systemctl restart делает сначала stop, а затем снова start.

Спасибо. Скопировал из чьего-то примера на Хабре.

Но не работает даже вариант без Restart и Stop.


default.target — симлинк на таргет по умолчанию и может меняться. multi-user.target — настоящий target.

Который из них правильно отражает роль машины — удалённого веб-сервера без монитора, с которым работают почти исключительно через браузер, и иногда по SSH? Задействуется ли multi-user.target, если на машину вообще никто не логинится?


Кстати, как передать less параметры -I -S ? Для данного запуска, а не глобально для каждого вызова less. Надоедает при каждом просмотре журнала вбивать руками.



1. Существует ли мануал, где всё сведено на одну страницу?

2. В логе написано, что сервис успешно стартовал. Сервис не работает. Куда копать?

olegd ★★ ( 20.03.18 13:47:48 )
Последнее исправление: olegd 20.03.18 13:54:19 (всего исправлений: 2)

В логе написано, что сервис успешно стартовал.

Покажи его status.


То есть запускается ExecStart и сразу же ExecStop? Почему?

Это после чистого запуска или после systemctl restart?


В том что у это переменной по умолчанию задано значение. А ты его переписал, вместо того что бы дописать.

То есть запускается ExecStart и сразу же ExecStop

А чего ты ожидал? Если не указывать тип сервиса, используется дефолтный simple, который подразумевает, что запускаемый процесс не будет завершаться. У вас же команда запуска тут же завершается, отчего systemd считает, что сервис завершился, и вызывает ExecStop. man systemd.service , читать о Type=.

Вам нужен тип oneshot, а также RemainAfterExit=yes.


запускается ExecStart и сразу же ExecStop?

Неверно указан Type=. Тебе нужен Type=oneshot, RemainAfterExit=yes.


Это после чистого запуска или после systemctl restart?

После чистого запуска.

Кстати, тебе ещё скорее всего надо указать RemainAfterExit=yes и Type=oneshot.

Именно! После этого всё заработало.


Если не указывать тип сервиса, используется дефолтный simple, который подразумевает, что запускаемый процесс не будет завершаться.

Он и не должен завершаться. Докер с заданием продолжает висеть в памяти. Но stdout/stdin/stderr освобождает. Это считается завершением?


Неверно указан Type=. Тебе нужен Type=oneshot, RemainAfterExit=yes.

Читайте также: