Since systemd v236, several Arch users complained that
systemd-cryptsetup-generator exits with an OOM error and that it
prevents the boot from continuing.
Investigating the diff of cryptsetup-generator between v235 and v236 I
noticed that create_disk allowed for the `password` and `filtered`
variables to be NULL (they're handled with `strempty()`) but not their
`*_escaped` versions, and returned OOM errors in those cases.
Fix this by checking that the input string is non-NULL before deciding
that `specifier_escape` had an OOM error.
I could not test this fix myself, but some users have reported success.
Downstream bug: https://bugs.archlinux.org/task/56733
This is a piece of refactoring I've done while looking for a solution to bug #2378.
It separates the password sending from `parse_password`, which only needs to know
about the socket path and the list of passwords to send.
As a caveat, the `ask_password_tty` path needs to construct a one-password strv, too.
The user manager is still limited by its parent slice user-UID.slice,
which defaults to 4096 tasks. However, it no longer has an additional
limit of 512 tasks.
Fixes#1955.
While 235c6e6 gets LTO builds running again, it goes back to using fat
LTO objects instead of using gcc-{ar,nm,ranlib}. Building these fat
objects takes significantly more time.
Use the suggested solution and look for gcc-{ar,nm,ranlib}, which launch
the binutils tools with the appropriate --plugin parameter. GCC versions
that do not ship these should either default to -ffat-lto-objects or do
not support LTO at all.
On another note, nm from binutils 2.25 seems to be smart enough to load
the LTO plugin when needed without having to specify --plugin.
Since 11ec7ce, journald isn't setting the ACLs properly anymore if
the files had no ACLs to begin with: acl_set_fd fails with EINVAL.
An ACL with ACL_USER or ACL_GROUP entries but no ACL_MASK entry is
invalid, so make sure a mask exists before trying to set the ACL.
The vacuum code used to stop vacuuming after one deletion, even
when max_use was still exceeded.
Also make usage a uint64_t, as the code already pretends it is one.
Signed-off-by: Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>
Jan Alexander Steffens (heftig)