On 2022-08-24 09:57:51, Geoffroy Youri Berret wrote:
> Hi Antoine :)
>
> On 8/22/22 16:55, Antoine Beaupre wrote:
>> […] > Here the mpd daemon tries to start whenever *anyone* SSHes into my
>> home server. I have a system-wide mpd running on that server, yet it
>> still tries to start the socket service, which means that any systemd
>> --user session is "degraded". Here's one example:
>>
>> anarcat@marcos:~$ systemctl list-units --failed
>> UNIT LOAD ACTIVE SUB DESCRIPTION
>> ● mpd.socket loaded failed failed mpd.socket
>> […]
>>
>> anarcat@marcos:~$ systemctl --user status mpd.socket
>> ● mpd.socket
>> Loaded: loaded (/home/anarcat/.config/systemd/user/mpd.socket;
>> enabled; vendor preset: enabled)
>> Active: failed (Result: resources)
>> Triggers: ● mpd.service
>> Listen: [::]:6600 (Stream)
>>
>> […]
>
> It looks like socket service was explicitly installed for
> anarcat@marcos, the unit lies in ${HOME}/.config/systemd/user/mpd.socket
> (then it fails because MPD is already running system wide on :6600).
Ah, yes. That's my bad, actually.
>> The .service file also tries to start for some users:
>>
>> […]
>> register@marcos:~$ systemctl --user status mpd.service
>> ● mpd.service - Music Player Daemon
>> Loaded: loaded (/usr/lib/systemd/user/mpd.service; enabled; vendor
>> preset: enabled)
>> Active: failed (Result: exit-code) since Mon 2022-08-22 10:51:21 EDT;
>> 18s ago
>> Docs: man:mpd(1)
>> man:mpd.conf(5)
>> file:///usr/share/doc/mpd/html/user.html
>> Process: 613776 ExecStart=/usr/bin/mpd --no-daemon (code=exited,
>> status=1/FAILURE)
>> Main PID: 613776 (code=exited, status=1/FAILURE)
>> CPU: 85ms
>
> That I don't understand, systemd service is already disabled for user,
> cf. https://salsa.debian.org/mpd-team/mpd/-/commit/891b8318 (shipped in
> 0.21.26-1).
Uh. Really odd.
> I've installed MPD on a fresh bullseye headless install, I don't get MPD
> user service|socket enabled and trying to start.
>
> Maybe you have some settings kept from a previous dist upgrade?
> Did I miss something?
Okay well, obviously it seems I haven't properly done my homework and I
have leftover cruft from a previous upgrade... or is it? could it be
that the patch doesn't enable it on new installs, but doesn't disable it
on upgrades?
I guess there's no way for the package to tell the difference between
"service was mistakenly enabled in the past" and "user actually wants
service enabled"...
In any case, I think you're right this might not be an actual bug,
although I can't help but think that the [Install] block could target
graphical-session.target instead of default.target, which would possibly
remove a lot of those problems in the future.
Thanks for the quick feedback!
a.
--
Like slavery and apartheid, poverty is not natural. It is man-made and
it can be overcome and eradicated by the actions of human
beings. Overcoming poverty is not a gesture of charity. It is an act
of justice. - Nelson Mandela
