IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's explicitly deactivate all home dirs on shutdown, in order to
properly synchronizing unmounting and avoiding blocking devices.
Previously, we'd rely on automatic deactivation when home directories
become unused. However, that scheme is asynchronous, and ongoing
deactviations might conflicts with attempts to unmount /home. Let's fix
that by providing an explicit service systemd-homed-activate.service
whose only job is to have a ExecStop= line that explicitly deactivates
all home directories on shutdown. This service can the be ordered after
home.mount and similar, ensuring that we'll first deactivate all homes
before deactivating /home itself during shutdown.
This is kept separate from systemd-homed.service so that it is possible
to restart systemd-homed.service without deactivating all home
directories.
Fixes: #16842
Strictly speaking you can run homed without userdb. But it doesn't
really make much sense: they go hand in hand and implement the same
concepts, just for different sets of users. Let's hence disable both
automatically by default if homed is requested.
(We don't do the reverse: opting into userdbd shouldn't mean that you
are OK with homed.)
And of course, users can always deviate from our defaults easily, and
turn off userbd again right-away if they don't like it, and things will
generally work.
We want to watch USB sticks being plugged in, and that requires
AF_NETLINK to work correctly and get the host's events. But if we live
in a network namespace AF_NETLINK is disconnected too and we'll not get
the host udev events.
Fixes: #15287
/home is posibly a remote file system. it makes sense to order homed
after it, so that we can properly enumerate users in it, but we probably
shouldn't pull it in ourselves, and leave that to users to configure
otherwise.
Fixes: #15102
