On 2023-08-21 18:32, Dragan Simic wrote:
On 2023-08-21 18:19, Andrew Gregory wrote:
On 08/21/23 at 04:42am, Dragan Simic wrote:
Running "pacman -Syyu" to perform a full system update resulted
in a rather conspicuous error message in the output of pacman:
( 3/18) Creating temporary files...
Assertion 'fd' failed at src/tmpfiles/tmpfiles.c:843, function
fd_set_perms(). Aborting.
/usr/share/libalpm/scripts/systemd-hook: line 28: 1735 Aborted
(core dumped) /usr/bin/systemd-tmpfiles --create
error: command failed to execute correctly
Expectedly, running "systemd-tmpfiles --create" manually afterwards
went just fine and resulted in no errors, leading to a conclusion
that executing /usr/share/libalpm/hooks/30-systemd-tmpfiles.hook
failed, but only when it was run from within pacman.
After a detailed and rather lengthy investigation, it turned out
the code in lib/libalpm/util.c that executes the hooks by forking
a child has some bugs that allow the error to occur under certain
circumstances. In particular, function _alpm_run_chroot() that
executes hooks in a fork()ed child does not employ dup2() properly,
but instead executes close() followed by dup2().
The man page for dup2() clearly states in the quotation below that
attempts to re-implement the equivalent functionality, which is the
case in function _alpm_run_chroot(), must be avoided:
The dup2() system call performs the same task as dup(), but
instead of using the lowest-numbered unused file descriptor,
it uses the file descriptor number specified in newfd. In other
words, the file descriptor newfd is adjusted so that it now
refers to the same open file description as oldfd.
If the file descriptor newfd was previously open, it is closed
before being reused; the close is performed silently (i.e., any
errors during the close are not reported by dup2()).
The steps of closing and reusing the file descriptor newfd are
performed atomically. This is important, because trying to
implement equivalent functionality using close(2) and dup()
would be subject to race conditions, whereby newfd might be
reused between the two steps. Such reuse could happen because
the main program is interrupted by a signal handler that
allocates a file descriptor, or because a parallel thread
allocates a file descriptor.
As a result, a condition can occur in which the file descriptor 0 is
closed by calling close(0), and left closed after the while loop that
fails to execute dup2() because of receiving EBUSY, resulting in the
described issues. Also, failed attempts to execute dup2() should be
treated as fatal errors instead of being silently ignored.
I am trying to reproduce this to wrap my head around what's actually
happening
and verify that this actually fixes it, but I am unable to get pacman
to
execute a hook with fd 0 closed with or without the ARM patches. Can
you
provide a reproducible case?
Ah, I know very well how it feels, I spent at least a couple of days
hunting the issue down and fixing it.
One of the issues with reproducing the error is that you must have an
old systemd version installed, which still contains assert(fd) checks
in src/tmpfiles/tmpfiles.c that actually trigger the error. IIRC,
systemd removed those checks about a couple of years ago, presumably
to fix similar complaints.
You may also want to see my original report of the issue, which also
contains the fix:
https://gitlab.manjaro.org/manjaro-arm/packages/core/pacman/-/issues/1
Just checking, have you managed to reproduce the issue? If not, please
let me know, and I'll put together some kind of instructions for
creating an appropriate environment and a test case that reproduces the
error.
