Upon upgrading to version 261~rc2-1 (from 261~rc1-1) I found that audio
was broken in some programs (but still working in others).  Since the
upgrade involved many other packages in addition to systemd, I looked at
the following list of potential culprits:

alsa-utils:amd64 1.2.15.2-2 -> 1.2.15.2-3
dbus:amd64 1.16.2-4 -> 1.16.2-5
systemd:amd64 261~rc1-1 -> 261~rc2-1

Some programs using audio (Firefox, xine, some simple games, even
DosBox) were unaffected, while others would run but were silent.
Checking ~/.xsession-errors quickly revealed that libopenal was now
unable to enumerate audio devices -- 2 failing games were torcs and
alien-arena, and both depend on libopenal1.  I decided to quickly
install openal-tools to check the output of 'openal-info' and this
confirmed what I was seeing... and provided a very nice tool to check
whether the problem was present or not as I tested things further... as
demonstrated by this (truncated) output:

$ systemctl --version
systemd 261 (261~rc2-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS
[...]

$ openal-info
Available playback devices:
     !!! none !!!
Available capture devices:
     !!! none !!!
Default playback device:
Default capture device:
ALC version: 1.1

!!! Failed to open default device !!!

[after downgrading systemd and rebooting

$ systemctl --version
systemd 261 (261~rc1-1)
[...]

$ openal-info
Available playback devices:
     Built-in Audio Analog Surround 5.1
     Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] Digital
Stereo (HDMI 4)
     CA0108/CA10300 [Sound Blaster Audigy Series] (E-MU 0404) Analog
Surround 5.0
Available capture devices:
     Monitor of Built-in Audio Analog Surround 5.1
[...]


After downgrading alsa-utils (and restarting Xfce), things were still
broken.  I additionally downgraded dbus and then rebooted, but things
were still broken.  Finally, I downgraded systemd (back to 261~rc1-1)
and rebooted, and found that audio was working again in all programs,
including those relying on libopenal.

I didn't see any warnings or errors relevant to systemd or libopenal in
my boot logs.

It is relatively easy for me to switch between the working and broken
versions of systemd, so if there are commands I can run or logs that
would useful, I can get those for you.  Something in the latest systemd
must have affected how Xfce sets itself up and makes libopenal available
to programs, but I'm afraid that how such things happen under-the-hood
is opaque to me... and have no idea how to triage the exact problem further.

I have been holding version 261~rc1-1 to keep programs using libopenal
working, but have now found time to bisect the problem.  After cloning
the Debian systemd git repository from

https://salsa.debian.org/systemd-team/systemd.git

and on branch "debian/master" located tags corresponding to the last
version for which libopenal was unaffected,

     debian/261_rc1-1

and the first version which prevents libopenal from working,

     debian/261_rc2-1

Using 'git bisect' with these tags specifying "good" and "bad" versions,
I was able to identify this commit as the first causing the problem with
libopenal:

a05fe6684ae0af8128c20e2054d52d8393c2ac61 is the first bad commit
commit a05fe6684ae0af8128c20e2054d52d8393c2ac61
Author: Luca Boccassi <luca.boccassi@gmail.com>
Date:   Sat May 23 16:18:03 2026 +0100

     libc: dlsym the time64 alias for epoll_pwait2() on 32-bit _TIME_BITS=64


Afterwords, I attempted a couple of simple reverts successfully.  First,
I created a branch off tag "debian/261_rc2-1" and ran 'git revert
a05fe6684a'; this succeeded, and the packages I built no longer broke
programs using libopenal.  Second, I created a branch off tag
"debian/261.1-3" and successfully carried out the same revert; the
package built, and libopenal worked correctly now.


HTH,
Dave W.

I tested the latest version (261.2-1) to make sure the bug (libopenal
broken on my desktop) is still there.  It is.

Lately, I've noticed that sometimes 'top' is showing a runaway 'sed'
process.  It never occurred to me that it could be related to this bug;
I guessed that an upgrade of 'sed' (or some package using sed) might
have introduced a bug, and that a later update (hopefully) would fix it.

At some point, I noticed that the runaway 'sed' was happening
immediately upon booting, so then I decided to look into it more.  I
quickly discovered that 'sed' was being run by logcheck, and this was
being run by systemd.

When things are working correctly, upon boot/reboot I can see this
output from 'systemctl status':

     # systemctl status logcheck.service

     ○ logcheck.service - logcheck
          Loaded: loaded (/usr/lib/systemd/system/logcheck.service; static)
     [...]
     Jul 24 14:02:01 desktop systemd[1]: Starting logcheck.service -
logcheck...
     Jul 24 14:02:23 desktop systemd[1]: logcheck.service: Deactivated
successfully.
     Jul 24 14:02:23 desktop systemd[1]: Finished logcheck.service -
logcheck.
     Jul 24 14:02:23 desktop systemd[1]: logcheck.service: Consumed
6.139s CPU time over 22.090s wall clock time, 781.2M memory peak.


So, in this example the process terminated normally in about 20 seconds.

When the bug is affecting things, I see this:

     # systemctl status logcheck.service

     ○ logcheck.service - logcheck
          Loaded: loaded (/usr/lib/systemd/system/logcheck.service; static)
     [...]
     Jul 24 14:02:01 desktop systemd[1]: Starting logcheck.service -
logcheck...


and the process is hung (never terminates).

I realize now that the pattern is:  each time I test a new systemd from
the Debian repository, libopenal is broken and the logcheck.service
hangs at boot time.  When I install my own locally built packages which
have commit a05fe6684a reverted, both libopenal and logcheck.service
work correctly.

I have now verified that a revert of commit a05fe6684a on top of 261.2-1
still fixes the bug for me (as with previous versions mentioned in
earlier messages in this bug report).