[devel] [cyber] I: Sisyphus-20221222 x86_64 beehive_status: +37 -3 (101)

[Alexey Gladkov]

On Fri, Dec 23, 2022 at 06:51:22PM +0300, Dmitry V. Levin wrote:
> On Fri, Dec 23, 2022 at 06:47:21PM +0300, Dmitry V. Levin wrote:
> > On Fri, Dec 23, 2022 at 04:42:04PM +0100, Alexey Gladkov wrote:
> > > On Fri, Dec 23, 2022 at 06:26:31PM +0300, Dmitry V. Levin wrote:
> > > > On Thu, Dec 22, 2022 at 02:01:18PM +0300, Dmitry V. Levin wrote:
> > > > > On Thu, Dec 22, 2022 at 01:33:30PM +0300, Валерий Иноземцев wrote:
> > > > > > 22.12.2022 13:26, Dmitry V. Levin пишет:
> > > > > > > On Thu, Dec 22, 2022 at 12:05:56PM +0300, Валерий Иноземцев wrote:
> > > > > > >> 22.12.2022 11:25, Dmitry V. Levin пишет:
> > > > > > >>> On Thu, Dec 22, 2022 at 08:10:27AM +0000, ALT beekeeper wrote:
> > > > > > >>>> 	37 NEW error logs
> > > > > > >>> [...]
> > > > > > >>>> xdg-dbus-proxy-0.1.4-alt1
> > > > > > >>>> 	dbus-daemon[4180584]: Failed to start message bus: Failed to bind socket
> > > > > > >>>> 	"/run/dbus/users/dbus-DkOyMz7clK": No such file or directory
> > > > > > >>>
> > > > > > >>> Что-то массово сломалось после обновления пакета dbus?
> > > > > > >>
> > > > > > >> да. см. аттач
> > > > > > >> какие предложения? откатывать a70b042f?
> > > > > > > 
> > > > > > > Альтернативно, может быть, что-то в системе должно создавать /run/dbus/users/ ?
> > > > > > > Хотя наличие по умолчанию в системе каталога /run/dbus/users/, доступного
> > > > > > > всем на запись, что позволяет легко устроить DoS на /run/, тоже не
> > > > > > > выглядит хорошей идеей.
> > > > > > 
> > > > > > для этого есть /lib/tmpfiles.d/dbus.conf
> > > > > > d /run/dbus 0755 root root -
> > > > > > d /run/dbus/users 1777 root root -
> > > > > > 
> > > > > > в hasher это не работает
> > > > > 
> > > > > Если в системе присутствует пакет systemd или systemd-utils-standalone,
> > > > > то /usr/lib/rpm/systemd-tmpfiles.filetrigger из пакета
> > > > > systemd-utils-filetriggers обрабатывает эти файлы.
> > > > 
> > > > Обрабатывать-то оно обрабатывает, однако
> > > > $ hsh-run --root -- systemd-tmpfiles --create; echo $?
> > > > /proc/ is not mounted, but required for successful operation of systemd-tmpfiles. Please mount /proc/. Alternatively, consider using the --root= or --image= switches.
> > > > 1
> > > 
> > > Эм. А зачем ему /proc ???
> > 
> > Оно утверждает, будто "for successful operation", что бы это ни значило. :)
> 
> https://github.com/systemd/systemd/commit/01131684ac6
> 
> /* We require /proc/ for a lot of our operations, i.e. for adjusting access modes, for anything
>  * SELinux related, for recursive operation, for xattr, acl and chattr handling, for btrfs stuff and
>  * a lot more. It's probably the majority of invocations where /proc/ is required. Since people
>  * apparently invoke it without anyway and are surprised about the failures, let's catch this early
>  * and output a nice and friendly warning. */

Как мило. Правда это искажает причину. Проблема не в том, что access modes
или xattr требуют procfs, а в том, что _systemd-tmpfiles_ использует
procfs для своей работы.

Тут понятнее бага[1], которая упоминается в коммите.

The error message is misleading. /var/log/journal does exist and what is failing instead is that chown_one() requires a mounted /proc

getxattr("/proc/self/fd/4", "system.posix_acl_access", 0x7ffc2fdcc8c0, 132) = -1 ENOENT (No such file or directory)
writev(2, [{iov_base="ACL operation on \"/var/log/journ"..., iov_len=69}, {iov_base="\n", iov_len=1}], 2ACL operation on "/var/log/journal" failed: No such file or directory

poettering: btw, we use /proc for a lot more than the ACL stuff, i.e.
after following symlink chains via O_PATH fds we need to convert the fds
back to something real, for which we use /proc/self/fd/.

[1] https://github.com/systemd/systemd/issues/14745

-- 
Rgrds, legion