Bug#1023557: rygel: consider After=network.target in rygel.service for lingering

[Barak A. Pearlmutter]

Package: rygel
Version: 0.42.0-2

Dear Maintainer,

Thanks for maintaining Rygel. It's made our big TV useful! And tablets!
Everyone on the local network is happy!

To keep everyone happy, I turned on lingering for the involved user (me)

$ loginctl enable-linger $(whoami)

and enabled rygel. This causes rygel to start when the machine boots,
instead of waiting for me to log in.

One tiny problem: rygel starts before the network is up, gets an error
having to do with the network not being set up, and apparently fails
to announce itself on the local network, so nobody can watch videos or
listen to music. Which makes everyone in the house sad until I log in
and

$ systemctl --user restart rygel.service

which is a hassle.

I *think* the right way to solve this is by adding a line

After=network.target

to the rygel unit file, /usr/lib/systemd/user/rygel.service

Cheers,

--Barak.

-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (550, 'testing'), (500, 'stable-updates'), (500,
'proposed-updates'), (500, 'stable'), (450, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rygel depends on:
ii init-system-helpers 1.65.2
ii libc6 2.36-4
ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1
ii libgee-0.8-2 0.20.6-1
ii libges-1.0-0 1.20.3-1
ii libglib2.0-0 2.74.1-1
ii libgssdp-1.6-0 1.6.0-3
ii libgstreamer-plugins-base1.0-0 1.20.3-2
ii libgstreamer1.0-0 1.20.3-1
ii libgupnp-1.6-0 1.6.0-3
ii libgupnp-av-1.0-3 0.14.1-1
ii libgupnp-dlna-2.0-4 0.12.0-3
ii libmediaart-2.0-0 1.9.6-1
ii librygel-core-2.8-0 0.42.0-2
ii librygel-db-2.8-0 0.42.0-2
ii librygel-renderer-2.8-0 0.42.0-2
ii librygel-server-2.8-0 0.42.0-2
ii libsoup-3.0-0 3.2.1-2
ii libsqlite3-0 3.39.4-1
ii libx11-6 2:1.8.1-2
ii libxml2 2.9.14+dfsg-1+b1

Versions of packages rygel recommends:
ii dbus-user-session 1.14.4-1
ii gstreamer1.0-libav 1.20.3-1+b1
ii gstreamer1.0-plugins-base 1.20.3-2
ii gstreamer1.0-plugins-good 1.20.3-1+b1
ii gstreamer1.0-plugins-ugly 1.20.3-1

Versions of packages rygel suggests:
ii rygel-playbin 0.42.0-2
pn rygel-preferences <none>
pn rygel-ruih <none>
ii rygel-tracker 0.42.0-2
ii tumbler 4.16.1-1

-- no debconf information

[Jens Georg]

Hi Barak,

Rygel should be able to cope with this situation. If it does not not,
then this is a bug that needs looking into.

Please provide the output of journalctl -u rygel.service and also feel
free to take this upstream at
https://gitlab.gnome.org/GNOME/rygel/issues

[Barak A. Pearlmutter]

Okay, here's a manifestation of some network-change rygel-stops issue.
This is rygel 0.42.0-2.
Logs below.
After "systemctl --user restart rygel.service" it works fine.

$ last -1 reboot
reboot system boot 6.0.0-6-amd64 Wed Dec 21 09:00 still running

$ systemctl --user status rygel.service
○ rygel.service - Rygel DLNA/UPnP server
Loaded: loaded (/usr/lib/systemd/user/rygel.service; enabled;
preset: enabled)
Active: inactive (dead) since Wed 2022-12-21 09:00:46 GMT; 13min ago
Duration: 30.065s
Process: 853 ExecStart=/usr/bin/rygel (code=exited, status=0/SUCCESS)
Main PID: 853 (code=exited, status=0/SUCCESS)
CPU: 6.485s

Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to
FF0E::C: Error sending message: Network is unreachable
Dec 21 09:00:20 sweat rygel[853]: Error creating GUPnP context: Failed
to bind socketError binding to address
[fe80::4f84:2ae9:bb96:f67f%3]:1900: Cannot assign requested address
Dec 21 09:00:46 sweat systemd[811]: Stopping Rygel DLNA/UPnP server...
Dec 21 09:00:46 sweat rygel[853]: Process check_async failed: Child
process killed by signal 15
Dec 21 09:00:46 sweat rygel[853]: g_file_new_for_uri: assertion 'uri
!= NULL' failed
Dec 21 09:00:46 sweat rygel[853]:
rygel_media_export_harvesting_task_on_extractor_error_cb: assertion
'file != NULL' failed
Dec 21 09:00:46 sweat mx-extract[2354]:
rygel-media-export-extract.vala:180: Started with descriptors 3 (in) 4
(out), extracting meta-data: true
Dec 21 09:00:46 sweat systemd[811]: Stopped Rygel DLNA/UPnP server.
Dec 21 09:00:46 sweat systemd[811]: rygel.service: Consumed 6.485s CPU time.

[Jens Georg]

On Mi, Dez 21 2022 at 13:34:15 +0000, Barak A. Pearlmutter <ba...@pearlmutter.net> wrote:

Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to FF0E::C: Error sending message: Network is unreachable Dec 21 09:00:20 sweat rygel[853]: Error sending SSDP packet to FF0E::C: Error sending message: Network is unreachable Dec 21 09:00:20 sweat rygel[853]: Error creating GUPnP context: Failed to bind socketError binding to address [fe80::4f84:2ae9:bb96:f67f%3]:1900: Cannot assign requested address

This is upstream ticket https://gitlab.gnome.org/GNOME/gupnp/-/issues/83 - I believe I have fixed that with the release of GUPnP 1.6.3.

Sorry for resending, debian bugtracker does not love my primary mail address

[Barak A. Pearlmutter]

Cool!

I had assumed, from the log messages etc, that this was likely a race
condition between the network configuration changing and rygel being
notified of, and adjusting to, said configuration.

[Barak A. Pearlmutter]

Just wanted to confirm that upgrading to libgupnp-1.6-0 from sid,
version 1.6.3-1, seems to have completely solved this problem. Rygel
used to crash constantly, and now seems rock solid on a server with a
WiFi link to the home network and exposing a NAT Ethernet connection
to a TV, with both bouncing sporadically.

Thanks!