Bug#769325: mediatomb: Mediatomb does not work with systemd

Tue Dec 9 13:35:59 UTC 2014

Hello,

thanks for answering this bug report and sorry for reporting back this late.

> > Even if it started, it wouldn't work, as it does not read the
> > configuration file /etc/mediatomb/config.xml
> > 
> > Additionally, it does not seem to make sense to have
> > /etc/default/mediatomb, as nearly all options are duplicates of options in
> > /etc/mediatomb/config.xml. It is completely unclear to a normal user which
> > value is used, if the values of both files differ.
> /etc/default/mediatomb is a file for daemon configuration (network card to
> attach to, user/group to run under, location of config.xml, etc...)), while
> /etc/mediatomb/config.xml is for mediatomb configuration (see upstream
> documentation http://mediatomb.cc/pages/documentation#id2856319).
Just for clarity for other readers, as I misunderstood this paragraph on first 
read: The documentation does not mention any separation of a "daemon 
configuration" from a "mediatomb documentation". But it states, that all 
relevant network related options are optional in config.xml.

> You are right and some optional values can be set at config.xml, but Debian
> mediatomb older releases have been configuring the daemon, even other
> distros, as Fedora, configure the daemon. It is not our fault the upstream
> provides two different ways to configure the daemon, via CLI or via
> config.xml.
It's absolutely standard for a Unix daemon to be configurable via 
configuration file, environment variables and CLI options (with increasing 
priority in case an option is set multiple times). Nevertheless, I can't 
remember a daemon where the configuration file is not the reference for 
default daemon startup. /etc/default is normally only used with parameters, 
which are not part of the daemon's configuration file.

> > Mediatomb had working systemd support before these changes had been
> > applied.
> Sorry, there was no systemd unit file before, you might had been using the
> old init script which also sets up the daemon.
Thanks for clarification. That's what I meant, but my statement has indeed 
been ambiguous.

> We picked to configure it via CLI with environment file, it has been that
> way for several releases now.
Yes, but in the init-script, config.xml is used (line 80), while in the new 
systemd unit file, config.xml is not used. Or that's what I thought. According 
to the documentation, /etc/mediatomb/config.xml should not be used with the 
configuration used in /lib/systemd/system/mediatomb.service, but I just found 
out, that this is incorrect. The above config.xml file is read even if no "-c" 
option is given in the service file. This makes one problem less.

> > ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P
> > /run/mediatomb.pid
> 
> I do not think it's good idea to run the daemon as root, but instead
> use the mediatomb user/group.
Yes, that was a dumb idea from me, thanks for paying attention. This was the 
minimal working configuration for me and should not be used in Jessie.

> Sorry, I disagree to do those changes at this stage in the release, we are
> frozen.
Yes, we should aim for the least disruptive change which works for everyone. 
But please note, that the change in 0.12.1-7, uploaded directly before the 
freeze, was already a disruptive change, at least to me.

> Also you seem to drop network settings for UPnP to work properly on some
> systems, why is that?
I dropped them as I didn't need them (for a minimal working example). What do 
they do? Are there different UPNP standards and do some devices need them?

> I do not agree on the severity reported, as the package works for me with
> that setup, and it might work for you, if you configure it properly.
> Therefore I am downgrading severity to at most important as I do not think
> it should be removed from jessie release, but I am further interested to
> hear about your proposed changes and find a common area that works for all.
It is not my intention to remove Mediatomb from Jessie. Instead I want to have 
a fix applied to Mediatomb before Jessie is released, as at least two users 
have problems with this version, although they had a working setup before and 
I fear that a lot of users might be affected when Jessie is released. Having 
it documented (with a release critical bug), that this package needs a fix 
before Jessie can be released seemed helpful to me.

Anyway, let's find the root cause, then we have better data and don't have to 
guess so much.
I tried several combination in /lib/systemd/system/mediatomb.service:

# Does not work
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -e $MT_INTERFACE

# Does not work
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT

# Works
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR

So setting the interface or the port makes mediatomb fail with systemd (using 
the init script works, but does not use the service file, of course).

The variables MT_INTERFACE and MT_PORT are defined in /etc/default/mediatomb 
as following:
MT_INTERFACE="eth1"
MT_PORT="50500"

The corresponding lines in /etc/mediatomb/config.xml read as following:
<ip>192.168.1.10</ip>
<port>49152</port>

The port is definitely different, but the interface should be correct 
according to "ip route":
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.10

After changing MT_PORT to 49152 in /etc/default/mediatomb, Mediatomb works 
with systemd with the following line in /lib/systemd/system/mediatomb.service:
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT

The reason this hasn't been a problem with the init-script is, that there is 
no port mentioned in the call:
DAEMON_ARGS="-c /etc/mediatomb/config.xml -d -u $MT_USER -g $MT_GROUP -P 
$MT_PIDFILE -l $MT_LOGFILE $INTERFACE_ARG $OPTIONS"

So this is definitely inconsistent (using the port number from 
/etc/default/mediatomb in systemd and using the port number from 
/etc/mediatomb/config.xml in the init script) and completely non-transparent 
to the user.

Btw: The reason that Port 49152 works while 50500 does not is probably that 
49152 has a special rule allowing it in my iptables rules, why there is no 
such rule for 50500. This could be changed, of course.

The remaining problem is the network interface option. Using
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -i 192.168.1.10
in the service file works with systemd, while
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P /run/mediatomb.pid 
-l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e $MT_INTERFACE
does not.

The reason can be seen in
/var/log/mediatomb:
ERROR: You can not specify interface and IP at the same time!
(Remember, that the ip has been set in /etc/mediatomb/config.xml)

To summarize everything:
The last mediatomb version broke working setups. These setups can be fixed by 
changing the configuration correctly and adapting the firewall rules. As 
Mediatomb behaves differently depending on being started by the init script or 
by systemd and as some options are available twice, it's very hard to find a 
working configuration. Nevertheless, it is possible.

Overall, it's quite a mess. I would recommend to patch Mediatomb to exit with 
an error if the interface (and ip) or the port is configured in both 
/etc/mediatomb/config.xml and /etc/default/mediatomb with differing values. 
Additionally, I would recommend to change the init script to also use the port 
from /etc/default/mediatomb. A note on package upgrade would also be very 
helpful. Some additional documentation might also be in order.

Kind regards
Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20141209/93407be1/attachment-0001.sig>