[mythtv-users] mythbackend fails silenty

[Greg Woods]

On Wed, 2005-09-14 at 18:39 +0100, Nick wrote:

> On a related theme, what is the difference between starting a daemon
> in /etc/rc.d/init.d with the service command and just running it from
> the command line directly? 

Most likely, environment variables such as $HOME.

> I've always run init.d scripts using the
> service command, but now this thread shows it may be problematic when
> running scripts directly without it.

When you are already logged in and using the "service" command, the
login environment is already set up for you. When daemons are started,
there is no login environment. It is therefore a bug (or a mis-design if
you will) to depend on the login environment for a program that is
started at boot time. Programs designed to run at system startup time
should not be looking in user home directories (even root). Such
programs normally use config files kept in /etc somewhere (e.g. on FC
systems, /etc/sysconfig/mythbackend or some such thing). Or the startup
script should have a variable to set where the config file is. But
relying on environment variables like $HOME to find it results in
exactly this sort of problem. I note that on my FC3 system, you can set
$MYTHTV_HOME in the /etc/sysconfig/mythbackend file, but doing so did
not work. That's a bug I think, albeit one that is easily worked around.

I ran into this same problem on my frontend system; it worked fine if I
started mythbackend as root or as mythtv, but would not work if started
at boot time. I solved it by having mythbackend start when mythtv logs
in (right before mythfrontend starts), which also happens automatically.
On my back end, it does look as though I put a copy of mysql.txt
into /.mythtv, which I only discovered I needed when I modified the
startup script to start mythbackend under strace, so I could then see
that it was trying to open /.mythtv/mysql.txt . I don't know why I
didn't think of the environment thing before that. And I *really* don't
know why I didn't remember going through this when the same problem
occurred on my slave backend system. I think I'm getting too old for
this stuff :-)

--Greg