Изпечатай

[growchie]

Отдавна не се бях занимавал с openSUSE и преди няколко месеца подтикнат покрай глупостите с unity в Убитуту се върнах обратно там. Днес обаче след като се разрових под десктоп нивото се сблъсках с нещо което доста ме озадачи. Забелязвам, че са минали на някаква нова (поредната) инит система systemd. В резултат на което покрай всичките неудобства свързани с новия начин на управление "systemctl" са изпряскали и нещо от което буквално ми настръхнаха косите, а именно journald.
От това което прочетох и от самите настройки на системата ми установих, че journald е някаква измислена система за управление да системните дневници, която в момента просто пренасочва съобщенията към стандартния rsyslog. Понеже установих, че journald пише някакви бинарни (по настоящем напълно безполезни и нечетими логове поради липсата на journaldctl пакет в опънсузе) логове в /var/log/journald/  които на практика дублират стандартните записани, искам да попитам някой има ли идея как тоя паразитен процес да се разкара от системата и да остана само с човешка система за логове като rsyslogd.
Бих бил много благодарен, ако някой ми подскаже как може този безсмислен паразитен процес (systemd-journald) да бъде прескочен. Логовете в текстов формат ми заемат около мегабайт, докато журналд логовете са 50 пъти по-големи. За една система с ограничени ресурси като моята това е напълно безсмислено раздуване. Освен това от нета разбирам, че апи-то на журнард не е напълно готово и за да мога да изчета  бинарните  логовете  (коя маймуна малоумна реши че логовете в юникс трябва да са бинарни?!) трябва да си компилирам journaldctl от сорсове.
Благодаря предварително.

[growchie]

****

[n00b]

 

верно си е проблем...

[appmaster]

Man page systemd-journald.conf

       ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=
           Control whether log messages received by the journal daemon shall
           be forwarded to a traditional syslog daemon, to the kernel log
           buffer (kmsg), or to the system console. These options take boolean
           arguments. If forwarding to syslog is enabled but no syslog daemon
           is running the respective option has no effect. By default only
           forwarding to syslog is enabled. These settings may be overridden
           at boot time with the kernel command line options
           systemd_journald.forward_to_syslog=,
           systemd_journald.forward_to_kmsg= and
           systemd_journald.forward_to_console=. If forwarding to the kernel
           log buffer and ImportKernel= is enabled at the same time care is
           taken to avoid logging loops. It is safe to use these options in
           combination.

Изисkва се последна налична версия, за да е сигурно че опциите ще сработят
ПС: Това е като някакво advanced proxy за грешки, което за сега няма как да не работи.
Ако го премахнеш, повече основни процеси реват на умряло (общо взето стигаш само до конзола)

[growchie]

И аз така забелязвам че няма как да се махне. Единственото решение което намирам за момента е просто да подменя init системата със старата.
http://lists.opensuse.org/opensuse-factory/2012-09/msg00729.html 
Това като гледам е само временно решение. Докато човърках из нета попаднах на една доста притеснителна дискусия сред Gentoo разработчиците (имам и сървъри на Gentoo).
http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=262780;page=1;sb=post_latest_reply;so=ASC;mh=25;list=gentoo
Очевидно проблемите със systemd ще стават все по-големи. Май времето което отделям ще е по-ползотворно използвано ако мигрирам всичките си сървъри на FreeBSD  Нещата в Линукс започват да стават много грозни.

[shoshon]

От автора на rsyslog по темата:

http://blog.gerhards.net/2011/11/journald-and-rsyslog.html

Иначе мисля че е лоша идея да го махаш. По-скоро виж как да спреш логването в /var/log/journal, защото аз ползвам също съответното демонче (на десктоп) и нямам такива файлове.

"мигрирам всичките си сървъри на FreeBSD" много ми е интересно каква версия OpenSuSE използваш за сървърите си... но няма значение. Също така не разбирам как си инсталирал система, която не познаваш, на сървърите си, както и защо един администратор трябва да сменя init система... но и това май няма значение...

[growchie]

Не се изразявам точно и не описвам какво мисля да правя и за това явно настъпва объркване, за което моля да бъда извинен.
Opensuse в момента е на лаптопа ми като имах идея да го пробвам и за сървър (имам една стара p3 с малко рам). В момента сървърите ми са на Gentoo които явно ще форкват udev поради ред причини. Там си ползвам syslog-ng и си имам нещо като лог сървър и беше естествено да проверя как стоят нещата с opensuse.
По принцип съм много доволен от генту но взе да ми писва постоянната прекомпилация и "rolling update" политиката си има и недостатъци.
Та така обмислях мигриране към опънсузе (сега съм с 12.2), но след като четох какво пишат за системд (policykit и dbus като зависимост?!) почвам да разглеждам и други алтернативи (freebsd).

[Naka]

Абе онзи ден, като излезе новината в линукс.бг за 'котката на Шрьодингер' реших да видя какво има ново и това доста ме озадачи:

70%    SysV to Systemd    Porting from sysVinit init scripts to systemd unit files.

само че за F18 http://fedoraproject.org/wiki/Releases/18/FeatureList
http://fedoraproject.org/wiki/Systemd

че какво му е на system V инит стила? Какво сега няма да има шел скриптове които да се изпълняват като се стартира системата...... Да ама шел скриптовете винаги може да видиш какво правят и какво стартират, а и можеш да ги промениш.

Абе нещата не вървят към опростяване а към забатачване.

Както е тръгнало някой ден ще махнат и терминала....... щото разбирате ли ама то е много грозно и трудно за обикновенният user........ 

[laskov]

Абе онзи ден, като излезе новината в линукс.бг за 'котката на Шрьодингер' реших да видя какво има ново и това доста ме озадачи:

70%    SysV to Systemd    Porting from sysVinit init scripts to systemd unit files.

само че за F18 http://fedoraproject.org/wiki/Releases/18/FeatureList
http://fedoraproject.org/wiki/Systemd

че какво му е на system V инит стила? Какво сега няма да има шел скриптове които да се изпълняват като се стартира системата...... Да ама шел скриптовете винаги може да видиш какво правят и какво стартират, а и можеш да ги промениш.

Абе нещата не вървят към опростяване а към забатачване.

Офф, уви - така е. Когато излезе първата Fedora с GNOME 3 си пуснах OpenVPN за да съм във връзка с офиса. Имаше проблем и се скъсах да търся конфиг файла за да добавя два реда! Е не! Няма такова нещо!

Иначе, systemd бе въведен във Fedora 15. Бях мислил тогава за преимуществата му и се бях съгласил с въвеждането му, макар че толкова съм свикнал със System V в Slackware.

Моля автора на темата да ме извини, че цапам, но не се сдържах !

[growchie]

Моля автора на темата да ме извини, че цапам, но не се сдържах !

Напротив, коментарът е уместен, както и връзките принципно.

[go_fire]

Аз от кога рева за целият скрап, който РХ и другите корпорации вкарват  в ГНУ/Линукс и какъв ужас настава цели стотици фермани изписах. Никой не му пука, проблем нямало. Ами това е само началото.

Корпорациите бяха добри за нас в началото. Помогнаха за популяризацията. Платиха разработката на много важни програми. Но какво стана накрая? Показаха си рогата и правят всякакви своеволия.

Нямаме друг избор освен да ги изхвърлим. Но не го правим и няма да го направим. Скоро просто ще загубим своята ОС.

[backinblack]

Гога, нали знаеш, че безплатен обяд няма, а още по-малко безплатен програмистки труд, при положение, че има недостиг на ИТ кадри и този недостиг расте в световен мащаб!

Доброто в нашата ос е, че бизнес логиката е съвсем различна от тази на Уиндоус и лицензирането и, гарантира, че ще се запази.

[shoshon]

Добре бе дае*** какво толкова не може да се види какво прави, било затворено....


[hpeivged@ivan-laptop system]$ cat ./multi-user.target.wants/smartd.service
[Unit]
Description=Self Monitoring and Reporting Technology (SMART) Daemon
After=syslog.target

[Service]
EnvironmentFile=-/etc/sysconfig/smartmontools
ExecStart=/usr/sbin/smartd -n $smartd_opts
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=syslog

[Install]
WantedBy=multi-user.target


кое не е ясно???

[appmaster]

Проблема е, че се сменя цялостна подсистема на която разчитат едно 90% от основните приложения.
Логовете са една доста важна част. И тя наистина беше остаряла, но мисля, че работеше сравнително добре.

Относно systemd - няма две мнения. Това трябваше да се пипне. Най-малкото, което е - не може смотания Windows, да ми зарежда за 6-8 секунди, а последен линукс релийз, да не може...
Тука доста са се постарали и мисля, че нещата са доста ясни, когато ги разучиш.
Според мен са решили да пипнат и системата за логовете, за да стане цялата патардия на веднъж.
Иначе през година да правят генерални промени, ще е доста по-досадно от колкото на един път и после само да се правят подобрения без да пипат основата.

Тука изобщо не говоря за конкретната реализация и качества, а за общият подход към проблема.
Колкото до това за корпорациите - ако ги нямаше, линукса щеше да е много по-назад.
Така че без едното и другото нямаше да е на това ниво - не се самозалъгвайте, че ентусиасти щяха да докарат линукса до това ниво

[growchie]

Проблемът не е технически.

кое не е ясно???

Не е ясно какви проблеми ми решава това. Напротив получава се така, че чупи напълно работещи системи. Кавгите сред дебиан и генту средите го доказват. Играя си в момента с systemctrl и просто се чудя защо всичко е станало толкова излишно сложно. Какво правят .device и .service units в един и същи екран. Какви са тия .timer, .target истории - крон-а ли искат да заменят?! Някак си лично мен не ме грабва.

Нещото което определено ме дразни е, че правят майкрософтските номера с "интегрирането" на интернет експлорър. Каквото прочетох направили са systemd изискване за GNOME като по този начин са обрекли проекта да е Linux only shop. Простотията с интегрирането на udev в системд определено цели и другите DE да зависят от тях като по този начин май се цели нито соларис нито бсд да могат да се възползват от тях (или поне нещата да станат доста труди за портване). Сега гледам и consolekit са прилапали.
Да отбележим и journald - нещото заради което започнах да се ровя по темата - следвайки "светлия" пример от udev каква е гаранцията, че Ленард Пьотеринг някоя сутрин няма да се събуди и да реши, че само той може да логва в линукс и да отреже препращането на съобщенията към rsyslog например. Освен това само пълен малоумник може да реши, че лог файловете трябва да са бинарни.
Преследват се някакви цели с този системд и се упражнява нелоялен натиск дистрибуциите и ДЕ средите да се съобразяват с него. Действията около udev мога да ги определя само като чист рекет. В резултат на това почват форковете. Вече въобще не се чудя защо се пръкна това нещо Юнити. Скоро ще има и udev форк. Просто се пилее сили и енергия в политика за прослава на определени хорица. Линуз нещо също четох че жестоко ги подигравал заради качеството на кода им. Някакви иронични подмятания, че понеже те са толкова кадърни с поддръжката на udev се е наложило линукс ядрото директно да си зарежда фърмуерите от диска.