LINUX.ORG.RU

Failed to send stream file descriptor to service manager: Connection refused

 ,


0

1

Привет! Кто-то знает что ошибка файла дескриптора https://pp.userapi.com/c847017/v847017241/d976b/OA8wwm8cjHQ.jpg) и почему соединение сброшено? Мож лечить как, я нашёл только одну тему по этому поводу на лоре, и там сомнительное лечение по типу «Вроде-как исправляет». Ошибка не всегда, и на работу не влияет, но иногда останавливает нормальное выключение машины и делает задержку в минуту и больше


По «картине маслом»:
Ну загрузка системы же. В это время не «всё может пойти не так». Диск проверяется (/dev/sda1 - он системный?), а systemd-journald «уже спешит с докладом» к service manager. А тому «некогда болтать, дел по-горло».

В двух словах

ошибка файла дескриптора

обычно означает, что этот файл не существует (или занят другим процессом).

почему соединение сброшено?

вероятно потому, что файл (сокет?) не существует(занят).

* я думаю, что systemd-journald пытается писать в файлы на проверяемом диске

там сомнительное лечение

ссылку на «рецепт» в студию

на работу не влияет

А лечить зачем?

останавливает нормальное выключение машины и делает задержку в минуту и больше

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

* как-то наблюдал загрузку системы со старого диска установленного через переходник. Вот там ошибки чтения диска и обмена с контроллером «рекой лились». На вопрос «А может надо диск поменять?» мне сказали «Забей, работает».

anymouze ★★
()
Ответ на: комментарий от anymouze

Хм, спасибо за расклад «по полочке». Да, про сокет уже уточнял, но точные логи никак не могу найти в journalctl (у меня арч), диск одним только разделом. Диск рабочий, битых блоков нет, работает замечательно уже 6-ой год. И то, ошибка раз через раз получается, видимо всё таки можно сдвинуть на занятость, потому что если бы сокет не существовал, то ошибка была бы постоянно, и с более серьёзными последствиями. Думаю, проблему можно закрыть. Ещё раз спасибо за ответ

jistake
() автор топика
Ответ на: комментарий от jistake

раз на раз не приходится (c)

сокет почему-то не доступен (его ещё нет [не создан] в момент обращения — один из очевидных вариантов) — получаете ошибку. В логах будет эта ошибка (что в этот ещё происходило можно только догадки строить). Поинтересуйтесь вопросом подробного логирования этапа загрузки и/или старта systemd. Возможно, есть более подробный уровень журналирования в systemd-journald (временно для нескольких тестов старта системы). Мне это ещё не требовалось...

anymouze ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.