see URL for description. Unknown whether or not this is generated by the ebuild or from upstream, but this problem has been present since mythtv release 0.18 in my personal experience. Is possible that something else is causing it, I don't fully understand what is hoped will be accomplished by "--chuid mythtv" from the mythtv backend. The frontend can be run in usermode (sometimes anyway, I haven't gotten my 0.20 based system running it yet) but the backend seems to work only from root. Reproducible: Always Steps to Reproduce: 1.install mythtv (unknown if backend only build will exhibit the same behavior) 2."/etc/init.d/mythbackend start" 3."ps -A | grep mythbackend" Actual Results: if one waits 5 seconds between steps 2 and 3 above, the output of step 3 will be null. Expected Results: at least one mythbackend instance should be running and accepting connections not sure what security problems can or will arise from lack of chuid entry, but this workaround from the gentoo forums works for me and at least one forum poster.
So you're compiling from source and not using the ebuilds and you want us to fix your machine?
No sir, I am not building directly from the sources. I am building from the ebuilds, media-tv/mythtv-0.20_p12172 in particular is the build on the second system which exhibited this problem to me. the previous system is no longer among the living, so I cannot check to see which ebuild I used from the 0.18 releases of mythtv. I don't remember if I had the same problem or not with the 0.17 ebuild since that was nearly 18 months ago when I built that system. I'm sorry for the confusion, I just found the forum post with the workaround and was trying to get it brought to someone's attention since it continues to happen with later releases. If no-one feels the need to change the script or to explain to me what I and at least one person from the forums could have done wrong to cause the problem in the first place, that's fine, I'm getting used to that.
You didn't provide emerge --info as is required on all bugs. You didn't provide anything from your logs to show what is happening to the daemon. There are multiple places. dmesg, /var/log/mythtv/, and /var/log/messages or /var/log/everything/current. The point of --chuid mythtv is so that the backend does not run as root and allow arbitrary data reads/writes to files on your system since you run it as root and it is technically possible to tell allow this through the MythTV protocol. Currently it works for me and many other people. This is most likely a configuration issue. So post some data we can parse through to see what the issue is and then we can help.
/var/log/messages is 7MB, what things do you need/want from it? It looks like a file/directory write permissions issue since /var/log/mythtv/mythbackend.log doesn't contain very much. I'm more than happy to provide information, but am also too well aware that dumping the contents of my drive in this bug is less than useless. I didn't find any other bugs mentioning this problem, only one forum post with a workaround dated august of 2006. Since this system is going to be in a place which doesn't have any net access other than very spotty dialup, the security risk is not very high for me personally to not have the chuid entry in the startup. It was just mildly annoying to me to be confronted with this issue again and was trying to find some clarification. If that means the configuration issue is on my end, so be it, close the bug and forget that I ever filed it. I'm about done with trying to make mythtv work again anyway. that being said, mythbackend.log, dmesg output and emerge --info are below. FWIW, any and all references to 192.168.1.96 are because I was using that system as a local sync server for the mythDVB system and my attempt at a smaller frontend system. dmesg.txt will be attached cat /var/log/mythtv/mythbackend.log Starting up as the master server. /mnt/store//nfslockfile.lock: Permission denied Unable to open lockfile! Be sure that '/mnt/store/' exists and that both the directory and that file are writeable by this user. Starting up as the master server. /mnt/store//nfslockfile.lock: Permission denied Unable to open lockfile! Be sure that '/mnt/store/' exists and that both the directory and that file are writeable by this user. Starting up as the master server. emerge --info Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 i686) ================================================================= System uname: 2.6.19-gentoo-r5 i686 Intel(R) Pentium(R) D CPU 3.00GHz Gentoo Base System release 1.12.9 Timestamp of tree: Fri, 13 Apr 2007 00:30:04 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /home/mythtv/ /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/terminfo" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distcc distlocks metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://www.gtlib.gatech.edu/pub/gentoo http://gentoo.mirrors.tds.net/gentoo " MAKEOPTS="-j13" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://192.168.1.96/gentoo-portage" USE="X alsa berkdb bitmap-fonts cdr cli cracklib crypt cups dri dvd dvdrw fortran gdbm gpm iconv ipv6 isdnlog libg++ midi ncurses nls nptl nptlonly pam pcre perl ppds pppd python qt3 qt4 readline reflection session spl ssl tcpd truetype-fonts type1-fonts unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 116861 [details] output from dmesg raw dmesg output. you can safely ignore any references to 192.168.1.96, it was being mounted via NFS for /usr/portage/distfiles and has had a nasty tendency towards overheating and hard locking, which is why I have been trying to build the new system, mythDVB.
You need to help us help you. You need to do some debugging yourself. Figure out why it's not starting. Run it by hand from command line as the mythtv user. Do something other then say "it doesn't work!!!! fix it!!!". Re-open the bug once you can provide some useful debugging.
Created attachment 118592 [details] Corrected Initscript
Comment on attachment 118592 [details] Corrected Initscript --daemon needed to be added to the startscript.
Unfortunately your changes aren't correct either since it will cause mythbackend to start up and the recorded pid file to be incorrect so /etc/init.d/mythbackend stop will not work. You can try this.. start-stop-daemon --start --quiet --chuid mythtv \ --exec /usr/bin/mythbackend -- \ --pidfile /var/run/mythbackend.pid \ --daemon --verbose ${MYTH_VERBOSE} \ --logfile /var/log/mythtv/mythbackend.log Previously mythbackend had serious issues forking itself so that behavior was not preferred and we allowed start-stop-daemon to fork it. I however strongly doubt this will fix your issue. I'm willing to bet since you tweaked the init script to have start-stop-daemon to fork and then have mythbackend to fork. You're still having the same problem except the init script appears to start up fine because you have the forked process returning successfully since it is actually forking yet again to really run. Run the mythbackend from the commandline as the mythtv user like I previously said and provide the output from that. attach the mythbackend.log, like I previously said and we'll work from there. Also when you attach this information, make sure you reopen the bug, like I previously said, so that it gets noticed.
well you were right. i think the problem is, that mythbackend refuses to start with logging turned on (here).
What's the ownership of /var/log/mythtv ? and any files contained inside?
sry, about the logfile was an wrong guess. here is what happens if i start mythbackend normaly as user. As you can see it starts as expected: 2007-05-17 15:49:06.665 Using runtime prefix = /usr 2007-05-17 15:49:06.688 New DB connection, total: 1 2007-05-17 15:49:06.701 Current Schema Version: 1160 Starting up as the master server. 2007-05-17 15:49:06.710 New DB connection, total: 2 2007-05-17 15:49:06.731 EITHelper: localtime offset 2:00:00 2007-05-17 15:49:06.747 New DB connection, total: 3 2007-05-17 15:49:06.785 New DB scheduler connection Radio is defined, but isn't attached to a cardinput. 2007-05-17 15:49:06.792 Main::Starting HttpServer 2007-05-17 15:49:06.799 Main::Registering HttpStatus Extension 2007-05-17 15:49:06.805 mythbackend version: 0.20.20060828-4 www.mythtv.org 2007-05-17 15:49:06.809 Enabled verbose msgs: important 2007-05-17 15:49:06.810 AutoExpire: Found 1 recorders w/max rate of 138 MiB/min 2007-05-17 15:49:06.812 AutoExpire: Required Free Space: 3.0 GB w/freq: 10 min When i use the Init Script: 2007-05-17 15:49:42.787 Using runtime prefix = /usr 2007-05-17 15:49:42.829 New DB connection, total: 1 2007-05-17 15:49:42.839 Unable to connect to database! 2007-05-17 15:49:42.851 Driver error was [1/1045]: QMYSQL3: Unable to connect Database error was: Access denied for user 'mythtv'@'localhost' (using password: YES) QSqlQuery::exec: database not open QSqlQuery::exec: database not open 2007-05-17 15:49:42.908 DB Error (KickDatabase): Query was: SELECT NULL; No error type from QSqlError? Strange... 2007-05-17 15:49:42.961 Failed to init MythContext, exiting. --- as you can see, it refuses to connect to the mysql using the initscript.
That's because you didn't configure mythtv properly via mythtv-setup and configure your database properly. You can hand change the settings in /etc/mythtv/.mythtv/mysql.txt And you should be fine.
(In reply to comment #13) > That's because you didn't configure mythtv properly via mythtv-setup and > configure your database properly. > > You can hand change the settings in /etc/mythtv/.mythtv/mysql.txt > > And you should be fine. > yes, you were right. i just imported the database from an old backup. thanks ... :)
