Hello all,
I came across a similar issue today during 'apt-get upgrade' on my
Debian unstable amd64 machine. The system was installed back in 2014 as
Debian Wheezy and through the years (dist-)upgraded until the current
unstable. The minissdpd package was probably installed as part of the
system installation at the beginning as it was completely unknown to me
(and I have never dealt with its configuration). DPKG failed with the
following message:
----------
Nastavuje se balík minissdpd (1.5.20190824-1) …
Job for minissdpd.service failed because the control process exited with
error code.
See "systemctl status minissdpd.service" and "journalctl -xe" for
details.
invoke-rc.d: initscript minissdpd, action "restart" failed.
● minissdpd.service - keep memory of all UPnP devices that announced
themselves
Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled;
vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2020-08-29 16:08:28
CEST; 23ms ago
Docs: man:minissdpd(1)
Process: 16207
ExecCondition=/usr/lib/minissdpd/minissdpd-systemd-wrapper -t
${MiniSSDPd_INTERFACE_ADDRESS} (code=exited, status=0/SUCCESS)
Process: 16208
ExecStart=/usr/lib/minissdpd/minissdpd-systemd-wrapper
${MiniSSDPd_INTERFACE_ADDRESS} $MiniSSDPd_OTHER_OPTIONS (code=exited,
status=1/FAILURE)
srp 29 16:08:28 P01-MARTIN minissdpd-systemd-wrapper[16208]: Error
parsing address/mask (or interface name) : eth0
srp 29 16:08:28 P01-MARTIN minissdpd-systemd-wrapper[16208]: can't parse
"eth0" as a valid address or interface name
srp 29 16:08:28 P01-MARTIN minissdpd-systemd-wrapper[16208]: Usage:
/usr/sbin/minissdpd [-d] [-6] [-s socket] [-p pidfile] [-t TTL] [-f
device] -i <interface> [-i <interface2>] ...
srp 29 16:08:28 P01-MARTIN minissdpd-systemd-wrapper[16208]:
<interface> is either an IPv4 address with mask such as
srp 29 16:08:28 P01-MARTIN minissdpd-systemd-wrapper[16208]:
192.168.1.42/255.255.255.0, or an interface name such as eth0.
srp 29 16:08:28 P01-MARTIN minissdpd-systemd-wrapper[16208]: By
default, socket will be open as /var/run/minissdpd.sock
srp 29 16:08:28 P01-MARTIN minissdpd-systemd-wrapper[16208]: and pid
written to file /var/run/minissdpd.pid
srp 29 16:08:28 P01-MARTIN systemd[1]: minissdpd.service: Control
process exited, code=exited, status=1/FAILURE
srp 29 16:08:28 P01-MARTIN systemd[1]: minissdpd.service: Failed with
result 'exit-code'.
srp 29 16:08:28 P01-MARTIN systemd[1]: Failed to start keep memory of
all UPnP devices that announced themselves.
dpkg: chyba při zpracovávání balíku minissdpd (--configure):
installed minissdpd package post-installation script subprocess
returned error exit status 1
----------
After that, I tried changing the '/etc/default/minissdpd' config file to
reflect my current interface name ('enp0s25'), but after running
'apt-get upgrade' again, it was rewritten back to 'eth0' (like Dann
wrote) and the same error was returned.
After finding this bug report, I tried the 'debconf-show minissdpd'
which reported:
---------
minissdpd/ip6: false
* minissdpd/listen: eth0
* minissdpd/start_daemon: true
* minissdpd/why_I_am_here:
---------
I changed it using a short script (as I don't know a better way as of
now):
---------
debconf-set-selections <<- 'END'
minissdpd minissdpd/listen \
string enp0s25
END
---------
And 'debconf-show minissdpd' reported:
---------
* minissdpd/start_daemon: true
* minissdpd/listen: enp0s25
minissdpd/ip6: false
* minissdpd/why_I_am_here:
---------
After that, 'apt-get upgrade' finished successfully and also 'enp0s25'
was written into the '/etc/default/minissdpd' config file (overwriting
the 'eth0' left there from the attempt mentioned above).
Looking into the script '/var/lib/dpkg/info/minissdpd.config' (as Thomas
pointed out) with my minimal bash knowledge, it seems to me, that it
fetches the values from the '/etc/default/minissdpd' config file first
(https://salsa.debian.org/miniupnp-team/minissdpd/-/blob/debian-sid/debian/minissdpd.config#L24)
to overwrite them with values from debconf later
(https://salsa.debian.org/miniupnp-team/minissdpd/-/blob/debian-sid/debian/minissdpd.config#L38).
I don't know, if this is the required behaviour to be able to use
debconf, but it seems to me as the possible source of the reported
problem.
Best regards
Martin Šturc
