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

[Patrick Häcker]

Hi James,

thanks for taking care of Gerbera and mediatomb's bug reports.

Unfortunately, I do not have a UPnP setup anymore, so I can't test it. 
However, with /etc/default being removed, I can't see how this bug could still 
occur, so even without testing, I am very positive, that the bug is fixed.

Thanks
Patrick

On Sat, 25 Nov 2017 06:35:00 + James Cowgill  wrote:
> Source: gerbera
> Source-Version: 1.0.0-1
> 
> Hi,
> 
> I think this bug is fixed in gerbera. The gerbera package has a much
> simpler systemd service file (all it does is invoke the main program)
> and the /etc/default file has been removed so all configuration is read
> from config.xml now.
> 
> It would be good if you could test it and reply if there is still a problem.
> 
> Thanks,
> James
> 


signature.asc
Description: This is a digitally signed message part.

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

[Patrick Häcker]

Dear Héctor,

sorry for the delay until I found the time to answer.

  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.
 
 For reference, Fedora which did the systemd units ships with:
   http://pkgs.fedoraproject.org/cgit/mediatomb.git/tree/mediatomb.service
 
 So, IIUC, you suggest to release mediatomb without a preconfigured
 port because it causes conflicts when user has those settings
 configured in config.xml file. I might need to do some testing on that
 before pushing it forward.
I probably didn't think about that, but it sounds like a good idea, to either 
add the port to the sysvinit script, or to remove it from the systemd call. 
This would lead to a consistent Mediatomb behavior when switching the init 
system. Currently, Mediatomb can break when switching from sysvinit to 
systemd. The latter solution has the advantage, that there can be no 
conflicting port definition between the configurations in 
/etc/default/mediatomb and /etc/mediatomb/config.xml.

  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)
 
 Same conflict between config.xml and daemon configuration.

 I agree with your analysis, adding a NEWS note might be consistent.
 
 Let's focus on Jessie release, we need to do minimal, less intrusive
 changes to be able to pass release team acceptance.
 My plan is to drop MT_PORT and MT_INTERFACE from systemd unit file, if
 that works for all of us.
Unfortunately, I think that does not work in all cases. With your proposed 
change if a user configured the interface in /etc/default/mediatomb, his 
configuration changes by switching from sysvinit to systemd, as his 
configuration option is loaded from /etc/init.d/mediatomb, but not from 
/lib/systemd/system/mediatomb.service.

I think it will not even work with the port in all cases, as if a testing or 
unstable user configured the port in /etc/default/mediatomb and used systemd, 
his port has been respected before this change, but will not anymore after 
this change. But I think this is acceptable if accompanied with a NEWS note, 
as testing and unstable user should be able to cope with that and the behavior 
has not been in the archive for long.

  I recommend to patch Mediatomb to exit with an error if the interface (and
  ip) is configured in both /etc/mediatomb/config.xml and
  /etc/default/mediatomb with differing values.

 For next release, are you willing to work/propose a patch that exits
 gratefully when there is a config mismatch between config.xml and
 default config? I would be willing to support that idea.
 
 Do you think that is good compromise?
Yes, I really appreciate your patient and impressive handling of this bug 
report. However, I think my proposal is flawed. If Mediatomb checks, if 
/etc/init.d/mediatomb and /etc/mediatomb/config.xml contain conflicting 
variables, Mediatomb will also warn, if it has not been started by the init 
script or the unit file at all, which is wrong, because then there is no 
conflict. Depending on the implementation it will even warn, if 
/etc/mediatomb/config.xml is not used at all.

Fortunately, the proposal can be fixed, for example if Mediatomb detects how 
it has been started (by init script or by unit file or independently). 
However, this sounds like a hard problem.

Alternatively, the init script or the unit file have to do the checks, because 
they have all the information they need. I do not know if systemd can handle 
such a setup, but I guess, that it can execute some shell code, too.

Surprisingly, if we only want to support the default situation (where no 
variables have been removed from /etc/default/mediatomb), it's very simple to 
check if there are options in /etc/mediatomb/config.xml which will be ignored, 
as the options are already set in /etc/default/mediatomb:

 egrep --quiet 'ip|interface' $MT_HOME/$MT_CFGDIR/config.xml \
  echo Warning: ip or interface definition in \
 $MT_HOME/$MT_CFGDIR/config.xml will be ignored \
 and the values defined in /etc/default/mediatomb will be used instead

This check could easily be extended to test for port, too. Do you think this 
would work?

Kind regards
Patrick

signature.asc
Description: This is a digitally signed message part.

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

[Hector Oron]

Hola,

Find inlined comments below.

2014-12-09 14:35 GMT+01:00 Patrick Häcker pa...@web.de:

  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.

Right.

 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.

Not sure I clearly understand you here. In older released mediatomb
has always shipped /etc/default/mediatomb file.
When adding systemd support, we updated variables to be more mediatomb
specific, similar to what Fedora uses.
  
http://anonscm.debian.org/cgit/pkg-multimedia/mediatomb.git/commit/?id=5acd74434fbe71aa638529720fc5f11d14a857db
Some assumptions done by sysvinit script were moved into that same
default file for systemd compatibility.

  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.

If you delete (or filter) systemd unit files it should fallback to use
sysvinit script as you were doing previously.

 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.

Right, the config.xml file is still taken into account, if we look at unit file:
  
http://anonscm.debian.org/cgit/pkg-multimedia/mediatomb.git/commit/?id=90f46857736afb6f49afe6c83dfc4d77fdb29613

  ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P
  /run/mediatomb.pid

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

where

## Location of the config file/database
MT_HOME=/etc
MT_CFGDIR=mediatomb

that way it still finds and parses config.xml.

Due to some other bug reports complaining that mediatomb exposed the
whole rootfs structure via web interface, I decided to hardcode
ethernet interface to loopback address and that needs to be changed by
admins if they want it to work on their network.

 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.

Right, that's -u $MT_USER -g $MT_GROUP part

 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.

My most sincere apologies, I am still concerned about your issue and
trying to understand, was it disruptive because the $MT_ variable
update? I cant think on anything else.

 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 

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

[Patrick Häcker]

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 

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

[Tom P]

I'm a first time poster here and a complete Linux noob.  I, too, am having a 
hard time with this version of Mediatomb. Earlier this year Jessie's mediatomb 
worked fine until mid October.  Things broke so bad so I reloaded with Debian 
7.7 and things worked again.  My setup is a dummy headless server where I just 
turn it on and it just worked (without the need to login).  I can't get 
anything to work with the default installation.  I can't get things to work 
properly by setting a few other files mentioned in this thread.  The only 
progress that I get is a remote PC that can see a library full of pointers to 
127.0.0.1, which means nothing to a remote PC.  
Hector - Sounds like you have things working.  Can you provide some guidance or 
documentation somewhere on how to set things up?    

I don't mind reloading the OS and getting some log files to report on this 
thread, but I'll need some guidance on how to do so.  
Tom


 

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

[Hector Oron]

severity 769325 important
thanks


Hello,

On Wed, Nov 12, 2014 at 09:43:21PM +0100, Patrick Häcker wrote:

 version 0.12.1-7 does not start when using systemd without a useable error
 message:
  Process: 2788 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 (code=exited, status=0/SUCCESS)
  Process: 2785 ExecStartPre=/sbin/ifconfig $MT_INTERFACE allmulti 
  (code=exited, status=0/SUCCESS)
  Process: 2782 ExecStartPre=/sbin/route add -net 239.0.0.0 netmask 255.0.0.0 
  $MT_INTERFACE (code=exited, status=0/SUCCESS)
  Process: 2779 ExecStartPre=/bin/grep -q MT_USER /etc/default/mediatomb 
  (code=exited, status=0/SUCCESS)
  Main PID: 2789 (code=exited, status=1/FAILURE)
 
 Even if it started, it wouldn't work, as it does not read the configuration
 file /etc/mediatomb/config.xml, which can be seen 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 -e 
  $MT_INTERFACE
 
 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). 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. We picked to configure 
it via CLI with environment file, it has been that way for several releases now.

 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.

 These changes should thus probably be reverted. Alternatively,
 /etc/default/mediatomb should be deleted and
 /lib/systemd/system/mediatomb.service should be changed into
  [Unit]
  Description=UPnP MediaServer
  After=NetworkManager-wait-online.service network.target
  
  [Service]
  Type=forking
  PIDFile=/run/mediatomb.pid
  ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P 
  /run/mediatomb.pid
  
  [Install]
  WantedBy=multi-user.target

Sorry, I disagree to do those changes at this stage in the release, we are 
frozen.
I do not think it's good idea to run the daemon as root, but instead use the 
mediatomb user/group.
Also you seem to drop network settings for UPnP to work properly on some 
systems, why is that?

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.

Regards,
-- 
  Hector Oron


signature.asc
Description: Digital signature

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

[Patrick Häcker]

Package: mediatomb
Version: 0.12.1-7
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

version 0.12.1-7 does not start when using systemd without a useable error
message:
 Process: 2788 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 (code=exited, status=0/SUCCESS)
 Process: 2785 ExecStartPre=/sbin/ifconfig $MT_INTERFACE allmulti 
 (code=exited, status=0/SUCCESS)
 Process: 2782 ExecStartPre=/sbin/route add -net 239.0.0.0 netmask 255.0.0.0 
 $MT_INTERFACE (code=exited, status=0/SUCCESS)
 Process: 2779 ExecStartPre=/bin/grep -q MT_USER /etc/default/mediatomb 
 (code=exited, status=0/SUCCESS)
 Main PID: 2789 (code=exited, status=1/FAILURE)

Even if it started, it wouldn't work, as it does not read the configuration
file /etc/mediatomb/config.xml, which can be seen 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 -e 
 $MT_INTERFACE

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.

Mediatomb had working systemd support before these changes had been applied.
These changes should thus probably be reverted. Alternatively,
/etc/default/mediatomb should be deleted and
/lib/systemd/system/mediatomb.service should be changed into
 [Unit]
 Description=UPnP MediaServer
 After=NetworkManager-wait-online.service network.target
 
 [Service]
 Type=forking
 PIDFile=/run/mediatomb.pid
 ExecStart=/usr/bin/mediatomb -d -c /etc/mediatomb/config.xml -P 
 /run/mediatomb.pid
 
 [Install]
 WantedBy=multi-user.target

Kind regards
Patrick


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 
'testing-proposed-updates'), (400, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mediatomb depends on:
ii  chromium [www-browser]   38.0.2125.101-3
ii  iceweasel [www-browser]  31.2.0esr-3
ii  konqueror [www-browser]  4:4.14.2-1
ii  mediatomb-daemon 0.12.1-7
ii  rekonq [www-browser] 2.4.2-0ubuntu2
ii  w3m [www-browser]0.5.3-19

mediatomb recommends no packages.

mediatomb suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org