Failed to write entry linux

Arch Linux

You are not logged in.

#1 2016-06-04 15:03:26

Systemd fails to write : systemd-journald[179]: Failed to write entry

I cloned my sdd (40Gb) to a larger one (240Gb) by using

After that, I keep seeing a bunch of errors like

After some research, I found a forum post describing my issue and providing a fix for it : https://www.linuxquestions.org/question … 175527467/
I am unable to follow it through, so I’ll do the most I can and describing what I get in this post.

The whole output is uploaded to http://pastebin.com/myb7EuHR

It contains a lot of error messages like :

writes on the console

and gives me back the prompt

I don’t understand what is happening. The other forum post describes large logs whereas mine are not that big, and I still have plenty of space available.

I have no idea what steps I should do to solve this issue.

—
edit : I use a thinkpad x201 if it helps.

Last edited by mehz (2016-06-04 15:25:18)

#2 2016-06-05 09:28:09

Re: Systemd fails to write : systemd-journald[179]: Failed to write entry

You might try to clean your journal using one of the options:

—vacuum-size=, —vacuum-time=, —vacuum-files=

See ‘man journalctl’.

It should be better than manually removing corrupted journal files.

#3 2016-06-05 11:12:33

Re: Systemd fails to write : systemd-journald[179]: Failed to write entry

it printed on the console

I then reboot the computer, but the issue was not solved.

Источник

Замораживания Ubuntu и выставочные ошибки

Мои замораживания человечности и затем показывают черный экран с текстами ошибки цикличного выполнения:

systemd-journald: failed to write entry, ignoring: read-only file system

ext4-fs error device nvme0n1p2 ext4_find_entry:1454: inode #22152700: comm gdm-seesion-wor: reading directory lblock 0

Что это об и как я могу решить это?

Править: У меня также была ошибка Buffer I/0 error on device nvme0n1p2

РЕДАКТИРОВАНИЕ 2: Я смог загрузиться однажды и протестировать исправность диска с smartmontools . Результат передается (но проблема все еще состоит):

РЕДАКТИРОВАНИЕ 3: кажется, что мой SSD имеет некоторый дефект. Я вошел в контакт с Lenovo. Они отправят мне новый SSD в обмен на мой поврежденный.

Трудно для веры этому может произойти точно так же, как это, как smartctl показал мне, диск имеет a Percentage Used: 3% и ноутбуку даже не 2 года. Что-нибудь я могу сделать для улучшения исправности диска в будущем?

РЕДАКТИРОВАНИЕ 4: Я был успешен в начальной загрузке однажды (от 50 попыток), я смог к сдвигу времени назад к более старому устойчивому состоянию, с тех пор больше никаких ошибок (начиная с теперь, по крайней мере), машина, работающая как новорожденный! Я успешно обновил все, никакие ошибки здесь также. Я сбросил свой nvme контроллер и работал sudo fsck -f /dev/nvme0np2 , в котором все тесты передали (благодарит @xenoid и @heynnema). Я нашел эту ссылку, которая описала те же признаки, которые я имел; решение состояло в том, чтобы заменить SSD и материнскую плату. Не уверенный все же, если это относится ко мне также.

РЕДАКТИРОВАНИЕ 5: Новые обновления: таким образом, сначала я, проверилось, временно устанавливал Windows, но я хочу сохранить это как свое последнее средство, так как я должен был бы восстановить свою целую систему Linux. Таким образом, я думал, что мог запустить Windows по Живому USB, но нет, это не возможный, Windows, только когда-либо позволяет полную установку (игнорирующий трудные обходные решения). Таким образом, я думал, что, возможно, мог запустить программное обеспечение Utility, предлагаемое Lenovo с помощью Вина, но это также не работало как ожидалось. Используя FreeDOS (как предложенный в видео YouTube) мог бы работать, но еще не попробовали его, также я не уверен, где найти просто простой файл ISO встроенного микропрограммного обеспечения Toshiba, в котором я нуждался бы. Странно, мне не удалось найти мою модель NVMe на веб-сайте встроенного микропрограммного обеспечения Toshiba. Затем я столкнулся с fwupd. Какой большой инструмент, именно так мне нравится он! И Lenovo даже добавила поддержку моей модели Thinkpad, T480s, к LVFS!Отлично! Но не много встроенного микропрограммного обеспечения загружается все же для моей модели. Мой SSD Toshiba однако перечислен в LVFS, но новое встроенное микропрограммное обеспечение (как предложенный с веб-сайта Dell) еще не загружается. Я вошел в контакт с Lenovo об этом, для ускорения вещей. Я также вошел в контакт с Richard Hughes (создатель LVFS) для просьбы его справку. Так как мой Ноутбук не страдает от ошибки только в данный момент, я буду ожидать некоторое время, возможно, новые разработки подходят. Так, как Вы видите, его odysee для меня и все еще движения 🙂 Я очень благодарен за всю справку сообщества и сообщите мне, есть ли у Вас больше идей и мыслей!

Редактирование 6: Я пытался использовать FreeDOS Живой USB для установки встроенного микропрограммного обеспечения .exe файлы, которые я нашел на Lenovo и домашней странице Dell. Но они оба дали мне высказывание сообщения об ошибке cannot be executed in DOS или что-то как этот. Это происходит, вероятно, из-за этих .exe файлов быть служебным программным обеспечением, что Lenovo и предложение Dell, с GUI и так далее. Таким образом для петляния я должен был бы на самом деле установить Windows временно на моем Ноутбуке.

РЕДАКТИРОВАНИЕ 7: Lenovo отправила мне новый SSD, на этот раз Samsung. Я заменил его своим дефектным SSD, установленным Windows, выполнил микропрограммное использование обновлений Lenovo Vantage (на всякий случай). Я хотел все актуальные встроенные микропрограммные обеспечения, прежде, чем установить Ubuntu 19.10, которая работает действительно великолепно! Особенно kernel-built-in драйверы Nvidia являются просто благословением, ошибками старого сообщения из Ubuntu 18.04. все исчезаются.

Источник

Стали появляться проблемы с диском.

Уже второй раз (первый был несколько дней назад) возникают ошибки ФС и диск перемонтируется в ро:

Сам я в этом смарте ничерта не понимаю:

После перезагрузки система не грузится и просит fsck. После проверки начинает работать нормально.

UPD: Проблема проявляется на всех ядрах от 4.15 до 4.19 включительно.

Пока всегда только с диском /dev/sda2 (но он и используется интенсивнее). На данный момент диски смонтированы так:

Сервис Lenovo с помощью встроенного тестировния выявил неисправность планки RAM, которую надо сказать к чести Lenovo заменили в течении недели у меня на дому и мне даже не пришлось никуда ехать.

Тест железа встроенный прогнал 4 раза — никаких ошибок ниразу не вылезло. Следующим этапом по совету сервисника обновил BIOS (была и правда очень старая версия). Потом скачал SanDisk Dashboard и проверил диск им (пришлось венду на флэшку ради этого вкорячить), в том числе расширенное тестирование SMART. Прошивка диска последняя.

UPD:
С момента переустановки прошел месяц. Полет нормальный. Нужно констатировать следующее — источником проблем стала оперативная память, что привело к повреждению данных записываемых на диск, а это в свою очередь повлекло все остальные последствия. Считаю что сервис Lenovo отработал оперативно — от момента обращение в чат, на сайте производителя, до замены планки памяти прошло 6 дней. Учитывая погодные условия и то что я не в ДС считаю это хорошей реакцией + мне не пришлось никуда ехать — специалист СЦ, приехал для выполнения работ ко мне, в тот же день когда в СЦ поступила деталь, не смотря на то, что к этому времени рабочий день уже завершился.

Источник

Ubuntu 18.04 вылетает с ошибкой EXT4-fs и systemd-journald

Обновление от 22 октября:

Две недели назад я сменил свой SSD с LITEON CV3-8D256 на Samsung 970 Evo Plus, и с тех пор описанной ниже проблемы не возникало. Я подозреваю, что проблема связана с неисправным SSD.

Я использую Ubuntu 18.04.04 на Samsung Notebook 9 pro. У меня и Windows 10, и Ubuntu. (Моя Windows работает отлично.)

Моя Ubuntu вылетает двумя разными способами:

• Когда я блокирую свой экран и пытаюсь повторно войти через некоторое время, на экране входа в систему отображается сообщение «Ошибка аутентификации», и я не могу ввести свой пароль.
• Иногда Gnome перестает работать (все значки на левой панели становятся пустыми; значки свертывания, увеличения и закрытия в правой верхней части окна также становятся пустыми), и я не могу использовать терминал. Это происходило дважды, когда я использовал Zoom, но происходило и в других случаях.

Когда эти два события происходят, я не могу вносить какие-либо данные в свою Ubuntu. Если я выключу компьютер с помощью кнопки питания, появится следующее сообщение об ошибке.

Множество похожих ошибок EXT4-fs (с разными названиями приложений, например gdm3 ) и ошибка systemd-journald[327] также появляется на экране. Они продолжают появляться постоянно, и мне приходится использовать кнопку питания, чтобы выключить их.

Когда я перезагружаю свой компьютер и проверяю dmesg | grep ‘systemd’ , Я вижу

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

Fsck и smartctl ошибок не показывали.

Я попытался WaylandEnable=false в /etc/gdm3/custom.conf и изменение fs.inotify.max_user_watches после этого.

Поскольку два указанных выше не сработали, я отформатировал раздел, в котором была установлена ​​Ubuntu, и снова установил Ubuntu. После чистой установки я восстановил данные, и Ubuntu нормально работала около месяца, и начала появляться та же ошибка.

1. Буду признателен за любую помощь!

Изменить 1. Снимок экрана SMART test

Изменить 2. Результат free -h

Источник

systemd-journald stopped logging on CentOS 7 (Failed to write entry)

Published on March 17th 2016 — Listed in Linux SystemD

On a production server running CentOS 7 I stumbled on a (new?) systemd problem that systemd’s journald, which is responsible for system logging (and kind of replacing syslog. ). I tried to analyze what happened on the system yesterday and couldn’t find any logs. Neither in /var/log, nor anything in journalctl.

The last logged entries according to journalctl were from February 18th, almost a month ago:

After February 18th 15:15:24 no new entries were logged anymore. I mean in general no more logs; no logins, no kernel messages, no mail logs, nothing.
I checked if the system time was correct (it is) and also looked at the current uptime:

[root@centos log]# date
Thu Mar 17 08:42:55 CET 2016

[root@centos log]# uptime
08:43:48 up 37 days, 17:09, 2 users, load average: 0.00, 0.01, 0.05

The uptime is older than when the problem arose, so a reboot is definitely not the cause.

I suspected that maybe the systemd-journald process crashed. This would explain the immediate stop of logging. However systemctl showed that the «systemd-journald.service» is loaded and actively running:

[root@centos log]# systemctl list-units | egrep «(log|journal)»
rhel-dmesg.service loaded active exited Dump dmesg to /var/log/dmesg
rsyslog.service loaded active running System Logging Service
systemd-journal-flush.service loaded active exited Flush Journal to Persistent Storage
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-journald.socket loaded active running Journal Socket

A status check on systemd-journald.service shows that the service is up for 1 month and 7 days (and running):

[root@centos log]# systemctl status systemd-journald.service
● systemd-journald.service — Journal Service
Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
Active: active (running) since Mon 2016-02-08 15:33:17 CET; 1 months 7 days ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 361 (systemd-journal)
Status: «Processing requests. »
CGroup: /system.slice/systemd-journald.service
└─361 /usr/lib/systemd/systemd-journald

Feb 08 15:33:17 centos.local systemd-journal[361]: Runtime journal is using 8.0M (max allowed 189.5M, trying to leave 284.3M free of 1.8G available → current limit 189.5M).
Feb 08 15:33:17 centos.local systemd-journal[361]: Runtime journal is using 8.0M (max allowed 189.5M, trying to leave 284.3M free of 1.8G available → current limit 189.5M).
Feb 08 15:33:17 centos.local systemd-journal[361]: Journal started
Feb 08 15:33:19 centos.local systemd-journal[361]: Runtime journal is using 8.0M (max allowed 189.5M, trying to leave 284.3M free of 1.8G available → current limit 189.5M).

I checked dmesg to maybe catch a segfault or something similar but I caught this:

[root@centos log]# dmesg | tail
[3258033.227855] systemd-journald[361]: Failed to write entry (13 items, 318 bytes), ignoring: Cannot assign requested address
[3258089.234540] systemd-journald[361]: Failed to write entry (23 items, 605 bytes), ignoring: Cannot assign requested address
[3258089.236248] systemd-journald[361]: Failed to write entry (24 items, 636 bytes), ignoring: Cannot assign requested address
[3258089.238195] systemd-journald[361]: Failed to write entry (22 items, 618 bytes), ignoring: Cannot assign requested address
[3258093.202606] systemd-journald[361]: Failed to write entry (20 items, 481 bytes), ignoring: Cannot assign requested address
[3258093.209852] systemd-journald[361]: Failed to write entry (20 items, 517 bytes), ignoring: Cannot assign requested address
[3258093.212118] systemd-journald[361]: Failed to write entry (16 items, 370 bytes), ignoring: Cannot assign requested address
[3258095.090851] systemd-journald[361]: Failed to write entry (11 items, 295 bytes), ignoring: Cannot assign requested address
[3258105.616016] systemd-journald[361]: Failed to write entry (12 items, 314 bytes), ignoring: Cannot assign requested address
[3258105.618950] systemd-journald[361]: Failed to write entry (16 items, 395 bytes), ignoring: Cannot assign requested address

What the hell?! There is definitely something bad happening with systemd-journald! By reading the text I thought maybe the disk is full. But then my monitoring would have alerted me and a verification revealed all OK on /var:

root@centos log]# df -h | grep var
/dev/mapper/vgsystem-lvvar ext4 3.9G 210M 3.4G 6% /var

So the problem is somewhere else.
Of course I tried to restart the service with «systemctl restart systemd-journald.service» — but nothing happened.
I then came across a forum post at linuxquestions.org which mentioned to run verify. And that’s what I did:

[root@centos log]# journalctl —verify
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system.journal
454530: unused data (entry_offset==0)
454598: invalid object
File corruption detected at /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000001442e-00052bff5257e30c.journal:454598 (of 8388608 bytes, 54%).
FAIL: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000001442e-00052bff5257e30c.journal (Cannot assign requested address)
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000001242d-00052bdfb8cb8d83.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000010460-00052bbf48b22ed6.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000000d417-00052ba467e8f90a.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000009faf-00052b8afeaa9672.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000006b98-00052b7171ab2d26.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000003705-00052b5868f72dc3.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000000001-00052b4314b1902b.journal

The lines appearing in red show quite obviously a file corruption.
After I ran the verify command, logging started working again:

[root@centos log]# journalctl -f
— Logs begin at Mon 2016-02-08 15:33:13 CET. —
Mar 17 09:01:05 centos.local sshd[1643]: Set /proc/self/oom_score_adj to 0
Mar 17 09:01:05 centos.local sshd[1643]: Connection from 10.162.215.204 port 51034 on 10.162.215.53 port 22
Mar 17 09:01:05 centos.local sshd[1643]: Connection closed by 10.162.215.204 [preauth]
Mar 17 09:02:01 centos.local systemd[1]: Started Session 61871 of user root.
Mar 17 09:02:01 centos.local systemd[1]: Starting Session 61871 of user root.
Mar 17 09:02:01 centos.local CROND[1724]: (root) CMD (/app/scripts/idssrvjobs/idsjobindex)
Mar 17 09:02:05 centos.local sshd[1743]: Set /proc/self/oom_score_adj to 0
Mar 17 09:02:05 centos.local sshd[1743]: Connection from 10.162.215.204 port 51202 on 10.162.215.53 port 22
Mar 17 09:02:05 centos.local sshd[1743]: Connection closed by 10.162.215.204 [preauth]

Another run of —verify still showed the same corrupted journal file, so I deleted it and then ran verify again:

[root@centos log]# rm «/run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000001442e-00052bff5257e30c.journal»
rm: remove regular file ‘/run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000001442e-00052bff5257e30c.journal’? y

[root@centos log]# journalctl —verify
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000001242d-00052bdfb8cb8d83.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000010460-00052bbf48b22ed6.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-000000000000d417-00052ba467e8f90a.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000009faf-00052b8afeaa9672.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000006b98-00052b7171ab2d26.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000003705-00052b5868f72dc3.journal
PASS: /run/log/journal/5050c3bd03844f988c3383ff7e5a4b52/system@11d03d9ffaa240bbb2cdbdee87d322bb-0000000000000001-00052b4314b1902b.journal

This time all checks passed.

For over 10 years I never had to worry that Linux stops logging. And even if that happened, the syslog process could be monitored.
Here systemd told me that systemd-journald is running correctly although it clearly had a problem. As this is not my first systemd problem in a production environment, I avoid or ditch systemd wherever possible. On Debian and Ubuntu I replaced systemd by the stable SysV init system. Unfortunately this system is a CentOS and systemd is very much bundled fix into the system. I just hope this was a one time problem, but I doubt that.

Update September 15th 2016:
More and more distributions have switched to systemd. I just experienced the same problem on a openSUSE 13.2 machine:

# journalctl —verify
Invalid tail monotonic timestamp██████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 49%
File corruption detected at /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-1002@e2b1911792f44ec2a5af6eef8cc2fdf1-00000000000cecf4-00053876db13a8e9.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-1002@e2b1911792f44ec2a5af6eef8cc2fdf1-00000000000cecf4-00053876db13a8e9.journal (Bad message)
Invalid tail monotonic timestamp██████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 49%
File corruption detected at /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-900@46649045ac2d45bc8543ab113c770566-0000000000064f0c-00052e4c2c98616c.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-900@46649045ac2d45bc8543ab113c770566-0000000000064f0c-00052e4c2c98616c.journal (Bad message)
Invalid tail monotonic timestamp██████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 49%
File corruption detected at /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-1000@b78fe5fd971048d6a4abf38182ad32ec-00000000000052c7-000522238f831f95.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-1000@b78fe5fd971048d6a4abf38182ad32ec-00000000000052c7-000522238f831f95.journal (Bad message)
Invalid tail monotonic timestamp██████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 49%
File corruption detected at /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-902@d37e827bc73b42bba5e732f37a4c6bdd-00000000000c5b03-000537962000a79a.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/74fc18841ff54a7f8e09f6b58d4bad53/user-902@d37e827bc73b42bba5e732f37a4c6bdd-00000000000c5b03-000537962000a79a.journal (Bad message)

So this is a general systemd-journald problem, not just one on CentOS 7.

Источник