Проклятый systemd заломал мой тестинг

Линк на багрепорт или балабол.

Нету линка. Проверил, сейчас все работает как в мане, можно и без ноликов. Забавно, но багрепортов про это не нашел, видать само починилось. Просто неудачное стечение обстоятельств: в 208 они поломали fsck для non-devices и потом до того как это починилось в 209, случилось что fsck начал плевать на умолчания (а вот про это вообще ничего не нашел). Вот тут я и попался. Правда я дописал нолики, успокоился и просто подумал что создатели systemd просто поменяли стандарты. Таки выходит на святое разработчики systemd не замахивались, просто кривой код.

Принцип системд в том, чтобы домохозяйка орала на сисадмина каждый раз при сбоях? Тупняк какой-то

Редхату домохозяйки не нужны, ибо не заплатят за тех. поддержку.

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

Уже выяснили, что обязана не валить (это у меня память плохая), а просто «каким-либо образом сообщать об ошибке».

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

Ой дядька - совсем мимо. Ибо дистр - арч. Ты вот, если спец по systemd, ответь на вопрос ниже. Сам баг с дохлыми иксами возможно даже и монтайнеры арча спровоцировали, они там этот патч для non-devices туда-сюда дергали. Но суть, что systemd три месяца, от одного к следующему релизу был поломатый. Если интересно, то 64e70e4b86d ломает, а e2f123b97b9a - чинит.

Почему systemd рвался запустить fsck не на файловой системе - понятно. Не понятно, почему там где явно не указано что файловая система подлежит проверке, пытаются запустить fsck. Вот кстати, выходит багрепорт писать всетаки нужно:

$ cat /etc/fstab|grep c3810902
UUID=c3810902-92d4-4ea2-8320-899e62c51c94	/home/bigboss/.bigBindDirs	ext4		rw,relatime,data=ordered

$lsblk
/dev/sdb6: UUID="c3810902-92d4-4ea2-8320-899e62c51c94" TYPE="ext4" PARTLABEL="BigBoss home" PARTUUID="cc0d029a-7d14-439d-ba97-e8a00b4223c8"

systemctl|grep c3810902
systemd-fsck@dev-disk-by\x2duuid-c3810902\x2d92d4\x2d4ea2\x2d8320\x2d899e62c51c94.service loaded active exited    File System Check on /dev/disk/by-uuid/c3810902-92d4-4ea2-8320-899e62c51c94

systemd-fsck[815]: /dev/sdb6: clean, 515129/10485760 files, 35374611/41943040 blocks

И ты, timuaz, подскажи [как специалист по systemd], где почитать правила по которым динамически создаются юниты монтирования из fstab? Логическое мышление есть, нет желания ковырять исходники systemd в поисках ответа на вопрос: каково значение по умолчанию для fs_passno? Единственное, что нашел, это фак красношляпых, где они говорять что если не хочешь проверки - пиши явно нуль. Но фак это как бы не документация.

$ grep linux-data /etc/fstab
/dev/disk/by-label/linux-data    /mnt/data              ext4     noatime,data=writeback,discard,noauto,x-systemd.automount

$ systemctl | grep 'linux\x2ddata'

$ journalctl -b | grep linux-data

$

Если что-то было сломано раньше — ну, значит, было сломано. Бывает. Значит, я не заметил.

нет желания ковырять исходники systemd в поисках ответа на вопрос

А зря... :) Это единственный 100% метод найти точный ответ по systemd...

во-первых, школолоарч. ну ты понял, да?

что systemd три месяца, от одного к следующему релизу был поломатый. Если интересно, то 64e70e4b86d ломает, а e2f123b97b9a - чинит.

Багрепорты в студию. что поломано, чем исправили.

Вот кстати, выходит багрепорт писать всетаки нужно:

Все-таки? Ты совсем идиот чтоли? Разработчики должны коннектится к тебе через libastral?

где почитать правила по которым динамически создаются юниты монтирования из fstab?

man systemd.mount

man systemd.service

man systemd.automount

Багрепорты в студию.

Дядька ну нельзя же себя таким неумным выставлять. Ты ладно бы сделал вид, что не заметил. Но ты ПРОЦИТИРОВАЛ хэши ломающего и чинящего коммитов. (и да это про проверку не-устройства, интерпретация отсутствия значения fs_passno не как 0 - это кажется для systemd нормальное поведение)

man...

Читал, не нашел. Сейчас попробую перечитать. А еще где-нибудь может быть? Мне кажется это важно, если systemd при преобразовании fstab интерпретирует его несколько иначе. Наыерное, что им стоило об этом написать.

У меня нет криптоключа, ибо честный гражданин Республики и не шифруюсь =)

интерпретация отсутствия значения fs_passno не как 0 - это кажется для systemd нормальное поведение

Это не так: Проклятый systemd заломал мой тестинг (комментарий)

Это не так

Объясни, где ты нашел документацию как systemd интерпретирует твою строчку из fstab? (man 5 fstab - не подходит). У тебя там systemsd-cпецифичные опции монтирования, собственно эта партиция монтируется не при загрузке, а при первом обращении

man systemd.automount: Example: if an automount unit home-lennart.automount is active and the user accesses /home/lennart the mount unit home-lennart.mount will be activated.

Где описано поведение fsck в данном случае?

man 8 systemd-fstab-generator, который отсылает за подробностями в man 5 fstab. Поэтому можно считать, что поведение systemd должно соответствовать описанному в fstab(5).

То, что у меня automount, никак не влияет на поведение fsck. Оно описано в man 8 systemd-fsck.

Однако надоело спорить, и да Леннарт - опять не виноватый. Зачем либЦэ так делает, но:

#include <stdlib.h>
#include <stdio.h>
#include <mntent.h>

main()
{
	FILE *f;
	struct mntent *me;
	f = setmntent("/etc/fstab", "re");
	if(!f){
		printf("ERRRORRR!!!!");
		exit(2);
	}
	while ((me = getmntent(f))){
		printf("mnt_dir = %s\t",me->mnt_dir);
		printf("mnt_passno = %d\n",me->mnt_passno);
	}
}

Кусок fstab'a:

UUID=1527c960-50eb-4720-a587-ee8a26a5d456	/home				ext4		rw,relatime,data=ordered,discard 
UUID=c3810902-92d4-4ea2-8320-899e62c51c94	/home/bigboss/.bigBindDirs	ext4		rw,relatime,data=ordered,discard,noauto,x-systemd.automount

mnt_dir = /home	mnt_passno = 2
mnt_dir = /home/bigboss/.bigBindDirs	mnt_passno = 2

 if (passno != 0) {
                r = generator_write_fsck_deps(f, arg_dest, what, where, fstype);
                if (r < 0)
                        return r;
        }

Я у себя наблюдаю корректное поведение... Может, всё-таки дистропроблемы? // системы под рукой нет, скомпилять не могу

Уже выяснили, что обязана не валить (это у меня память плохая), а просто «каким-либо образом сообщать об ошибке».

ОК.

Начнём с другой стороны. Привожу примеры на основе openrc, так как системдой не пользуюсь.

Вот у меня есть /etc/init.d/cupsd

depend() {
	use net
	need dbus
	before nfs
	after logger
}

Очевидно, что сервис для своей работы требует dbus.

Теперь предположим, что в процессе загрузки dbus вместо запуска «сообщает об ошибке». Должен ли запускаться купс? Очевидно, что не должен, ибо работа без dbus в данной сборке купса не предусмотрена.

Теперь берём /etc/init.d/xdm

depend() {
	need localmount xdm-setup

	# Много букав, не относящихся к делу
}

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

Дальше ты зачем-то прописываешь в fstab необходимость наличия смонтированного сидюка. Очевидно, что после этого localmount должен будет «сообщить об ошибке» в случае невозможности этот самый сидюк смонтировать.

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

И виноват во всем ненужный пробел после четвертой записи (опций монтирования). getmntent() странно парсит /etc/fstab: если после четвертой записи идет конец строки, то fs_freq и fs_passno равны нулю. А иначе туда попадает мусор ибо думают, что sscanf() может вернуть только 0,1 или 2.

Читай выше - виноват лишний пробел в конце строки и кривой либЦэ.

Линк на багрепорт или балабол.

Теперь можно и написать багрепорт. Проблема в glibc, misc/mntent_r.c, [у меня 167 строка]; функция __getmntent_r(), там в самом конце не проверяют, что sscanf() может вернуть EOF. В результате, если строка в fstab не кончается концом строки, то в fs_passno и fs_freq - мусор. Ну и вообще, там все плохо.

Вот теперь я тебе с уверенностью скажу - нету багрепорта(кажись этот прикол с 1996 года там живет). Половину системдэшники накосячили, половину либЦэшники.

Вот и пиши, ибо чем больше будет багрепортов, тем меньше серьёзных косяков останется в поделии Поттеринга к тому моменту, как оно будет везде.

кажись этот прикол с 1996 года

Это багофича - в fstab и скриптах всегда рекомендовали пустую строку оставлять. Просто раньше прокатывало, а с поделкой получается нет...

И виноват во всем ненужный пробел после четвертой записи

Ну, то есть виноват кривой конфиг. ЧИТД.

Ты точно с тем человеком споришь? ;)

Эм, дебиан можно месяцами спокойно не обновлять. Даже на тестинге.

поставить gentoo

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

Да, уже увидел.

Это ТС ( minakov) хочет, чтобы иксы запускались и ошибки в fstab магически игнорировались, когда сказано «не игнорировать». Я-то с тобой полностью согласен.

Поделка вообще не при делах. Запись в fstab вида

/dev/sda1    /home    ext4    rw,relatime

/dev/sda1    /home    ext4    rw,relatime  

От системы инициализации это не зависит. redgremlin, объясни, в чем кривизна конфига? Это явный баг в функции парсящей строчку fstab.

Нет. То же самое было у меня на одной самопальной системе, где вообще ничего, кроме ядра и busybox-static, не было. Нули приходилось явно прописывать.