Сообщения Systemd при каждом действии в консоли.

Это точно journald, а не printk() какой-нибудь?

А что это?

Это, наверное, systemd спамит в dmesg по какой-то важной причине. А что именно сообщает?

Что я подключил флешку,например,или,во время запуска logind,что сетевой интерфецс не готов,а потом,что он готов.

А можешь пример сообщения написать?

Иногда пишет,но редко. mce: [Hardware error]: Machine check events logged

Странно. Вроде, не похоже на сообщения ядра.

Можешь показать /etc/systemd/journald.conf ?

Вот еще пример

This is armoken-laptop. Now 22:04:57 Mon Aug 4  2014

armoken-laptop login: r8169 0000:08:00.0 enp8s0: link down
r8169 0000:08:00.0 enp8s0: link down
IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
iwlwifi 0000:09:00.0: L1 Disabled; Enabling L0S
iwlwifi 0000:09:00.0: L1 Disabled; Enabling L0S
IPv6: ADDRCONF(NETDEV_UP): wlp9s0: link is not ready
r8169 0000:08:00.0 enp8s0: link up
IPv6: ADDRCONF(NETDEV_CHANGE): enp8s0: link becomes ready
usb 1-2: new high-speed USB device number 5 using xhci_hcd
usb 1-2: New USB device found, idVendor=0951, idProduct=1624
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: DataTraveler G2
usb 1-2: Manufacturer: Kingston
usb 1-2: SerialNumber: 001CC0EC34D1F9C126A00CB4
usb 1-2: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
usb 1-2: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi5 : usb-storage 1-2:1.0
scsi 5:0:0:0: Direct-Access     Kingston DataTraveler G2  1.00 PQ: 0 ANSI: 2
sd 5:0:0:0: Attached scsi generic sg2 type 0
sd 5:0:0:0: [sdb] 31252024 512-byte logical blocks: (16.0 GB/14.9 GiB)
sd 5:0:0:0: [sdb] Write Protect is off
sd 5:0:0:0: [sdb] Incomplete mode parameter data
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] Incomplete mode parameter data
sd 5:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 5:0:0:0: [sdb] Incomplete mode parameter data
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] Attached SCSI removable disk
armoken
Password:
Last login: Mon Aug  4 21:41:25 FET 2014 on tty1

Определённо, это лог сообщений ядра. dmesg, наверное, то же самое выведет.

У меня второй системой Gentoo с systemd, но ещё не до конца установлена. Там такое... иногда происходит, а иногда нет.

В Arch-Wiki пишут, что это происходит потому, что systemd не выставляет для ядра loglevel. Там рекомендуют сделать это параметром ядра при загрузке (loglevel=4, например). Или выставить нужный CONFIG_DEFAULT_MESSAGE_LOGLEVEL при сборке ядра ( http://elinux.org/Debugging_by_printing ).

Ну с OpenRC или чистой SysvInit такое не происходит. Определённо дело в systemd, а именно в её параллелизме и видимо кривизне, которая присутствует уже 2 года.

Да ещё потому, что разработчики systemd в консоль носа не кажут, вот и не видят всего этого безобразия.

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

Спасибо, добавил параметр loglevel=3 в в строку GRUB_CMDLINE_LINUX_DEFAULT конфига grub и все сработало.

Тоесть надо отправить баг репорт.Не подскажите как.

https://bugs.freedesktop.org/enter_bug.cgi?product=systemd

Это точно journald, а не dmesg?

Если dmesg, то в openrc есть init.d/dmesg устанавливающий loglevel.

В systemd в getty@.service можно добавить ExecStartPost=/bin/dmesg -n 1. Ну или сделать dmesg.start в /etc/local.d делающий то же самое, но сразу и навсегда.

Ну с OpenRC или чистой SysvInit такое не происходит.

Потому что там есть скрипт, который это настраивает, а в systemd — нет. Вон liaonau выше указал, как это сделать. Если бы мейнтейнеры дистрибутивов озаботились этим, то всё бы работало.

Хм, systemd позиционирует себя даже как замена базовых частей ОС, генератор /etc/fstab, даже замена coreutils и прочее, прочее, так почему же разработчики systemd не озаботились переключением уровня логирования ядра?

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

у меня вот такой проблемы нет, как, наверное, и у разработчиков systemd

У меня тоже нет такой проблемы, как systemd, использую OpenRC. Ну а так, если уж Леннарт взялся писать новую систему инициализации, то как минимум уж должен позаботиться о том, что бы она вела себя как минимум не хуже старой, в данном случае не сыпала в консоль сообщениями ядра. Что бы всё это работало из коробки.

У меня тоже нет такой проблемы, как systemd, использую OpenRC

что ж ты тогда вообще тут раскукарекался?

Ну а так, если уж Леннарт взялся писать новую систему инициализации, то как минимум уж должен...

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

ещё раз, для тупого: у меня такой проблемы нет, у знакомых, использующих systemd, такой проблемы нет, наверняка и у разрабов такой проблемы нет, так как они должны исправить недочёт, с которым столкнулись полтора анонимуса и не сообщили об этом разработчикам?

что ж ты тогда вообще

Пока я только от тебя вижу петушиное поведение.

ты systemd не используешь,

Вот поэтому и не использую, что слишком непредсказуемое поведение.

мало что о нём знаешь,

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

с чего бы кому-то из разрабов прислушиваться к тебе?

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

у меня такой проблемы нет, у знакомых, использующих systemd, такой проблемы нет,

Это не показатель, хотя это ТЫ же и ТВОИ знакомые, как же ещё.

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

Это показатель всех, кто использует systemd, не отправляют bug репорты.

ещё раз, для тупого:

Правильно, повторю ещё раз для тебя, система, написанная для замены чего-либо, должна как минимум предоставлять функционал оригинала и не вносить проблем, пока у Systemd не будет стабильного поведения, я на него не перейду. Не говоря даже о случаях завершения unit`ов по тайм ауту, что не редкость, даже в Fedora.

Еще у одного подгорел пердак. Не пользуйся, нахрен ты кому нужен. У меня на федоре нет такой проблемы, так что гентупроблемы и вперёд в багзиллу.

Кхм, на Gentoo я systemd не ставил, а присматривался как раз на Fedora 20.

Если ты присматривался так же как в этом треде, то лучше бы вовсе не смотрел.

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

У меня F20 на 2х хостах.

Так ладно, продолжайте защищать свой любимый Systemd. Ну а по сути когда купил ноут, решил по взять поставить на него бинарный дистрибутив, что бы получить рабочую систему, заодно со свежим софтом и systemd, раз уж пошла такая малина, и уже в нём начать собирать Gentoo, возможно даже с systemd.

Так вот простояла у мена там Fedora 20, около месяца, глюки были и в Systemd и в самой системе, так что принял решение всё же собирать Gentoo без systemd.

В общем, я высказал свою точку зрения по поводу systemd, никому её не навязываю, нравится использовать - используйте, кто же запрещает, но мне её поведение не нравится, поэтому пока на OpenRC.

Отчасти соглашусь, но пока на systemd переходить не собираюсь.

Поздравляю, если всё работает - то рад за вас.

Это очень интересно, всем нам, и твоя точка зрения тоже безумно оригинальна и увлекательна. И конечно вбросы типа «если systemd позиционируется как система инициализации, почему Леннарт не носит мне кофе» - это нисколько не навязывание и не троллинг, а объективная критика systemd.

Она ведет себя не хуже старой. Пилите свой сервис (я в треде раньше зачем-то упомянул local.d, которая, конечено, относится к openrc) что-то типа

[Unit]
Description=dmesg level setter
Before=getty.target

[Service]
Type=oneshot
RemainAfterExit=yes
#EnvironmentFile=/etc/conf.d/dmesg
#ExecStart=/bin/dmesg -n${dmesg_level}
#ExecStop=/bin/dmesg -n7
ExecStart=/bin/dmesg -D
ExecStop=/bin/dmesg -E

[Install]
WantedBy=getty.target

И хватит по этому поводу ныть о багзилле, это RESOLVED WONTFIX. https://bugs.freedesktop.org/show_bug.cgi?id=67114

Kay Sievers 2013-07-20 16:39:50 UTC

So far we are very careful with messing with the defaults of the kernel.

People have different expectations and configure their kernel to that, and unless we have a really good reason, we should leave these setting alone.

There is CONFIG_DEFAULT_MESSAGE_LOGLEVEL= in the kernel compile-time config, that should be changed if we are sure we want a different default.

The kernel's log behavior is controlled by: /proc/sys/kernel/printk see: man 5 proc

Пока я только от тебя вижу петушиное поведение

потому что у тебя способности к самоанализу, как у улитки

Вот поэтому и не использую, что слишком непредсказуемое поведение

а ты его хоть пробовал использовать, клоун, или ориентируешься по напевкам Рабиновича?

Вот ты то уж знаешь о systemd гораздо больше

конечно

Это да, они вообще ни к кому не прислушиваются, пилят и пилят дальше

к нормальным предложениям и жалобам они прислушиваются, не прислушиваются они к фимозным клоунам, которые «вы всё делаете неправильно и не по юниксвею кококо!!!111»

Это не показатель

в сравнении с тобой - это показатель

Это показатель всех, кто использует systemd, не отправляют bug репорты

отправлять репорты на непроявляющиеся баги? ты просто гений, лол

пока у Systemd не будет стабильного поведения, я на него не перейду

systemd уже давно стабилен более чем, просто в специфических ситуациях маны читать надо

впрочем, твои топанья ножкой доставляют, продолжай

Ясно, спасибо за уточнение, дойдут руки попробую.

Это такая тонкая ирония?

Вводи команды со второго терминала и не парься.

Не поможет, естесственно. printk() будет на активный терминал.

Подумал и решил, что самое, пожалуй, простое решение — строка kernel.printk = 1 в /etc/sysctl.conf

Лучше 4, это сравнительно вменяемый дефолт (в арче так). Ну и да, собственно, это и есть решение.

ForwardToConsole=yes

А зачем оно? Сам же сказал «сри в консоль», и потом удивляешься, почему это оно срёт в консоль.