1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

VidMGR

Discussion in 'Developers Corner' started by Soapm, Jan 8, 2012.

  1. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Well, I wouldn't quite put it like that. Watching videos while they are transferring with a pull is no problem. There may be a brief delay before one can start viewing, is all, when transferring high bit rate or 720p .mpg files. Personally I find this less annoying than pauses while in the middle of viewing the material. I eliminate both, however, by recoding everything to h.264 before storing it on the hard drive.

    Well, that depends. Even with an S3, 720p content just does not transfer fast enough if it is coded as .mpg, and anything whose average bit rate exceeds 17 Mbps also generally does not transfer quite fast enough if it is coded as .mpg. With the THD, the issue is even worse.

    Again, that's not always true. Indeed, with most .mpg pushes, I get at least a minute or two of buffering before the program will start, even if I have both tuners disabled. Mp4 pushes are another matter, and along with the space savings, that is why I recode all my videos to h.264 in a .mp4 container.
     
  2. johnh123

    johnh123 New Member

    429
    0
    Dec 7, 2000
    Over there
    Anyone using vidmgr on a box in the tivo beta program? PMs welcome.
     
  3. jcthorne

    jcthorne Active Member

    2,720
    2
    Jan 28, 2002
    Houston
    From prior experience, check the mind server settings in pytivo....
     
  4. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Can't quite get this to work; vidmgr doesn't appear in 'Music, Photos & Showcases'.
    I can successfully run vidmgr with these console commands:
    1. /usr/share/pyTivo/pyTivo.py &
    2. cd /usr/share/pyhme
    3. ./start.py &
    Note that if I leave out cd then start.py doesn't pick up the config.ini in /usr/share/pyhme; instead it appears as though he is running thru a default configuration.

    Code:
    root@tivo-fs:/usr# find . -name "config.ini"
    ./share/pyhme/config.ini
    ./bin/kmttg/config.ini
    root@tivo-fs:/usr#
    
    All this about config.ini may be a red herring, just thought I'd mention it in case it's a clue.

    There's a few things I'm not clear on in your scripts (well, more than a few but these seem to be setup related):
    1. both refer to mountnfs.sh script re path; I've left the path unaltered
    2. both scripts 'Read configuration variable file if it is present'; there is no such dir on my system

    /var/log/pyTivo.log & /var/log/pyhme.log & /var/log/pyhme.err do not exist. Neither do /var/run/pyHME.pid or /var/run/pyTivo.pid.

    I edited /etc/insserv.conf to add:
    Code:
    $pyTivo         pyTivo
    I've rechecked the installation of all 4 scripts and see nothing left out, but clearly something's not right. A clue would be much appreciated!
     
  5. windracer

    windracer joined the 10k club

    11,580
    3
    Jan 3, 2003
    St. Pete, FL
    I don't know about lrhorer's init scripts, but here are mine (for Ubuntu, you'll need to change your paths accordingly where necessary):

    pytivo
    Code:
    #!/bin/bash
    ### INIT INFO
    # Provides: pytivo
    # Short-description: pyTivo server
    # Description: Start and stop the pyTivo server.
    ### END INIT INFO
    
    RETVAL=0
    
    . /lib/lsb/init-functions
    
    start() {
            log_daemon_msg "Starting pyTivo server" "pytivo"
            pgrep -f pyTivo.py > /dev/null
            RETVAL=$?
            [ $RETVAL -eq 0 ] && echo "pyTivo already running: Exiting" &&
    exit 1
    
            # this call actually starts pyTivo.
            /usr/bin/python /usr/local/tivo/pyTivo/pyTivo.py > /var/log/pytivo.log 2>&1 &
            # sleep for 1 second, giving the script time to start up
            sleep 1
            pgrep -f pyTivo.py > /dev/null
            RETVAL=$?
            log_end_msg $RETVAL
            return $RETVAL
    }
    
    stop() {
            log_daemon_msg "Stopping pyTivo server" "pytivo"
            pkill -f pyTivo.py > /dev/null
            RETVAL=$?
            log_end_msg $RETVAL
            return $RETVAL
    }
    
    # See how we were called.
    case "$1" in
    start)
            start
            ;;
    stop)
            stop
            ;;
    restart|reload)
            stop
            sleep 3
            start
            RETVAL=$?
            ;;
    *)
            echo "Usage: $0 {start|stop|restart}"
            exit 1
            esac
            exit $RETVAL
    pyhme
    Code:
    #! /bin/sh
    ### BEGIN INIT INFO
    # Provides:          pyhme
    # Short-Description: HME for Python Framework
    # Description:       Starts/Stops/Restarts the pyhme daemon
    ### END INIT INFO
    
    set -e
    
    DESC=pyhme
    
    # Gracefully exit if the package has been removed.
    test -x $DAEMON || exit 0
    
    d_start() {
        cd /etc/tivo/pyhme
        /etc/tivo/pyhme/start.py > /var/log/pyhme.log 2>&1 &
    }
    
    d_stop() {
        pkill -f start.py
    }
    
    case "$1" in
      start)
            echo -n "Starting $DESC"
            d_start
            echo "."
            ;;
      stop)
            echo -n "Stopping $DESC"
            d_stop
            echo "."
            ;;
      restart|force-reload)
            echo -n "Restarting $DESC"
            d_stop
            sleep 2
            d_start
            echo "."
            ;;
      *)
            echo "Usage: pyhme {start|stop|restart|force-reload}" >&2
            exit 3
            ;;
    esac
    
    exit 0
     
  6. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Thanks very much! BTW I'm running Debian, not Ubuntu. Are you running Debian?
     
  7. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Perfect! I'm able to run these scripts while root in /etc/init.d, the daemons are running and vidmgr looks great.

    But on reboot the daemons are not running. Afraid I'm pretty ignorant about linux .. is there something obvious that needs to be stated for a newbie? I don't fully understand how to get daemons running on boot re /etc/init.d and so on.

    BTW as part of lrhorer's setup, I did edit /etc/insserv.conf to add:
    Code:
    $pyTivo         pyTivo
    Should that remain in /etc/insserv.conf and is there something analogous for your scripts?
     
  8. windracer

    windracer joined the 10k club

    11,580
    3
    Jan 3, 2003
    St. Pete, FL
    I'm running Ubuntu (Precise) but since it's Debian based ... ;)

    Great!

    To add the init scripts to boot, I do this:

    $ sudo update-rc.d pytivo defaults
    $ sudo update-rc.d pyhme defaults

    Those two commands will add the start/stop links to your init.d scripts under the default runlevels. If you have it installed on your system, you can also use sysv-rc-conf to customize which services start at which runlevels.

    I've never touched insserv.conf.
     
  9. jbernardis

    jbernardis New Member

    1,072
    0
    Oct 21, 2003
    Princeton NJ
    I run my programs on my NAS which is debian based and I use the same scripts and procedures as windracer. Without close inspection they appear to be identical - apparently these scripts have made the rounds :)
     
  10. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Both of these commands give complaints, but pytivo does come up on reboot; pyhme does not. Took a look with sysv-rc-conf and saw only pytivo was activated for runlevels 2-5. I activated pyhme with sysv-rc-conf, but it didn't fix it.

    After boot, with pytivo daemon running & pyhme not, I started pyhme manually and vidmgr is happy.

    Here's the errors reported by update-rc.d pytivo defaults; in my naive interpretation it's due to not specifying every possible invoke argument in the switch statement which I assumed was okay else you'd have problems.
    Code:
    root@tivo-fs:/etc/init.d#  update-rc.d pytivo defaults
    update-rc.d: using dependency based boot sequencing
    insserv: warning: script 'K01pytivo' missing LSB tags and overrides
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: warning: script 'pytivo' missing LSB tags and overrides
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Default-Start undefined, assuming empty start runlevel(s) for script `pyhme'
    insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for script `pyhme'
    root@tivo-fs:/etc/init.d#
    
    Here's the errors reported by update-rc.d pyhme defaults; same naive interpretation
    Code:
    root@tivo-fs:/etc/init.d#  update-rc.d pyhme defaults
    update-rc.d: using dependency based boot sequencing
    insserv: warning: script 'K01pytivo' missing LSB tags and overrides
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Default-Start undefined, assuming empty start runlevel(s) for script `pyhme'
    insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for script `pyhme'
    insserv: warning: script 'pytivo' missing LSB tags and overrides
    root@tivo-fs:/etc/init.d#
    
    I'm guessing maybe pyhme isn't activated because of the detected 'errors' in pytivo; this is the last error msg from update-rc.d pyhme defaults:
    Code:
    insserv: warning: script 'pytivo' missing LSB tags and overrides
    

    I've removed the line I had added earlier.

    I'll go ahead and start screwing with the scripts but I'll probably get myself in trouble since I don't know the language. Hoping that there's something obvious to you; figure there must be or you'd have similar problems.
     
  11. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    As if I needed more evidence, this nails it that I must be doing something wrong! :eek:
     
  12. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    I thought I'd verify that pytivo daemon was running & pyhme daemon not after reboot, so I rebooted again.

    This time both daemons are running, vidmgr is happy.

    Okay, then.

    Thanks!
     
  13. windracer

    windracer joined the 10k club

    11,580
    3
    Jan 3, 2003
    St. Pete, FL
    It might have been that line in insserv.conf. Anyway, glad it's all working for you! :up:
     
  14. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    That may well be true. Jeff can chime in with more details, I expect. Note the script I use does do an explicit

    Code:
    RUNDIR=/usr/share/pyhme
    ...
    cd $RUNDIR
    What happens if you run the run scripts directly by typing /usr/share/pyTivo/pyTivo and /usr/share/pyhme/pyHME?

    Just FYI, the double quotes in the find statement are not necessary unless there are special characters (like the wildcard character * or a space) in the name being sought. In this case `find . -name config.ini` is just fine. The config.ini file in /usr/bin/kmttg is not relevant to any issues you may have here.

    Well, that is a comment that is in the System V skeleton file, but it is a good idea to leave it there. What it is saying is that (in a default Debian system) /var is not properly available for reading and writing until after the mountfs.sh script is run during boot. Any application writing to /var should not be initialized until after mountfs.sh is run and should be shut down before /var is umounted. If the System V headers are intact and the system is correctly using dependency based booting, this will automatically be addressed properly, but it is a good idea to keep the note handy so one correctly assigns the dependencies. This is salient to the majority of daemons, because daemons usually write either to /var/log/syslog or to their own file in /var/log.

    Um, I'm just about absolutely certain there is a /etc/default directory on your system. Debian would have an exceedingly hard time running without it. If you mean no /etc/default/phyHME or /etc/default/pyTivo file, then that's right, there won't be. Again, this is a comment from the skeleton file. (You can take a look at the skeleton at /etc/init.d/skeleton. It is intended as a template for all init files in /etc/init.d.) If no such file as $NAME exists in /etc/default, nothing happens, either good or bad. If it does exist, then it is sourced as part of the init script. Any commands, variables, whatever from the named file are inserted into the script at that point. Since the file does not exist, nothing gets inserted. It's an easy and straightforward way to keep the init files uniform across many installations and invariant from release to release while at the same time allowing for great variability of the init configurations both from installation to installation and in general as time passes.

    For more info, look up "dependency based booting in Linux".

    They won't until the scripts run successfully. The .pid files are created near the bottom of each $NAME run file. You can see the next to last line is

    Code:
    echo $! > $PIDFILE
    That writes the PID of the application to the /var/run/pyTivo.pid or /var/run/pyHME.pid file, as the case may be. The system variable "$!" contains the PID of the most recently run command in the script. The variable $PIDFILE is assigned at the top of each script, and is the name of the file where the PID of the daemon is kept.

    The .log and .err files are created when the applications write to what would normally be stdout and stderr. These streams are re-directed by the run scripts when nohup is invoked. (Actually, the .err file redirection is disabled in the scripts I posted.)

    That registers pyTivo as a service. Note the two lines near the top of the pyHME init script:

    Code:
    # Required-Start:    $remote_fs $syslog $network $pyTivo
    # Required-Stop:     $remote_fs $syslog $network $pyTivo
    This insures that the specified services remote_fs, syslog, network, and pyTivo have had their init scripts run at boot time before pyHME is started and that in this case pyHME is stopped before those same four services are stopped whenever a runlevel is entered that shuts down any or all of those services. Typically this would be during shutdown or perhaps when dropping to single user mode. Usually, any dependent daemons are shut down before the services upon which they depend are shut down, but there can be exceptions. An obvious one is where an init script does not start a daemon, but rather initializes some utility that then terminates. In that case, the Required-Stop line would have noting in it beyond the colon. The two lines labeled Default-Start and Default-Stop contain the runlevels where the scripts are started and stopped. Usually, unless the service is a system default, the union of the two lines will contain every number from 0 - 6. There should never be a duplicate between the two. If the service is a system default, then the Default-Start line will have an S in it and the Default-Stop line will be empty. This means the service is started only at boot time, before any runlevel is entered.

    In any case, to simplify, registering pyTivo as a service and then specifying it as a Required-Start and Required-Stop makes sure the update-rc.d utility creates the init links so that pyTivo is started before those scripts are run and that they are stopped cleanly before pyTivo is shut down. I'm not sure, strictly speaking, that it would cause a huge problem if vidmgr or jukebox tried to do something with pyTivo not loaded, but the action would most certainly fail. Other HME for Python apps could not care less.

    As I mentioned above, with both utilities unloaded, what happens if you run the run files directly? If they both work, then unload them again and run the init files, first with `/etc/init.d/<utility> start` and then with `/etc/init.d/<utility> stop`.

    Check the files permissions.
     
  15. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Those are not valid System V dependency-based init scripts, I'm afraid. At a bare minimum, every System V init script is required to have the following, with each line modified to fit the script parameters:

    Code:
    #! /bin/sh
    ### BEGIN INIT INFO
    # Provides:          skeleton
    # Required-Start:    $remote_fs $syslog
    # Required-Stop:     $remote_fs $syslog
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: Example initscript
    # Description:       This file should be used to construct scripts to be
    #                    placed in /etc/init.d.
    ### END INIT INFO
    
    # Author: Foo Bar <foobar@baz.org>
    #
    # Please remove the "Author" lines above and replace them
    # with your own name if you copy and modify this script.
    Without this header, insserv cannot proplerly assign the link names in the /etc/rcX.d directories. Non-dependency based booting can live without the headers, but non-dep booting can get very manual and can easily wind up with dependency conflicts if one is not very careful.
     
  16. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    He is running Debian. After he logs in (assuming he does not log in as root) he can simply issue the `su` command to assume the mantle of root. Sudo is then not necessary. In a secure environment, disabling root logins, especially via ssh, is not really necessary. Preventing a su to root is blankly stupid, if you ask me. It's one of the things I really dislike about Ubuntu. Let the sysadmin decide what security is appropriate. The distro maintainers should keep their paternalistic noses out of it. [/rant]

    It may not be absolutely necessary in this case, but since vidmgr and jukebox both depend on pyTivo being loaded, I prefer to make sure pyTivo is running before loading HME for Python and that HME for Python is stopped cleanly before pyTivo is shut down. With dependency-based booting, by far the best way to insure that is to register the service (in this case pyTivo) upon which the dependent apps depend.
     
  17. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    I definitely do not recommend the use of sysv-rc-conf for managing any dependency based System V distro. It's probably OK to view it, but I would let insserv manage it.

    Well, look at the errors, if any, from the scripts as I mentioned. I definitely do not recommend using non-compliant init scripts, but of course it is your system, not mine.

    I suggest you read through the man page for update-rc.d and insserv.

    No. The errors you encountered are due to the missing LSB tags at the top of the init headers in the init scripts. The Required-Start, Required-Stop, Default-Start and Default-Stop tags are required to be there, even if they are blank beyond the colons. Failure to have the proper tags will likely result in the links being named inappropriately, which in turn may cause the daemons to fail.

    Code:
    root@tivo-fs:/etc/init.d#  update-rc.d pytivo defaults
    update-rc.d: using dependency based boot sequencing
    insserv: warning: script 'K01pytivo' missing LSB tags and overrides
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: warning: script 'pytivo' missing LSB tags and overrides
    insserv: Script pyhme is broken: incomplete LSB comment.
    insserv: missing `Required-Start:' entry: please add even if empty.
    insserv: missing `Required-Stop:'  entry: please add even if empty.
    insserv: missing `Default-Start:'  entry: please add even if empty.
    insserv: missing `Default-Stop:'   entry: please add even if empty.
    insserv: Default-Start undefined, assuming empty start runlevel(s) for script `pyhme'
    insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for script `pyhme'
    root@tivo-fs:/etc/init.d#
    
    Those are all errors due to insserv not knowing what to do with the scripts. This will in turn cause the links to either be wrong or not be created at all. Take a look in /etc/rc2.d (runlevel 2, which is the default boot runlevel for Debian), for example:

    Code:
    RAID-Server:/etc/rc2.d# ll
    total 24
    drwxr-xr-x   2 root root  4096 Dec 25 09:22 .
    drwxr-xr-x 165 root root 16384 Jun 17 16:29 ..
    -rw-r--r--   1 root root   677 Dec 31  2010 README
    lrwxrwxrwx   1 root root    17 May 30  2011 S01dirmngr -> ../init.d/dirmngr
    lrwxrwxrwx   1 root root    15 Nov 24  2011 S01ncidd -> ../init.d/ncidd
    lrwxrwxrwx   1 root root    17 May 30  2011 S01netperf -> ../init.d/netperf
    lrwxrwxrwx   1 root root    18 Nov 24  2011 S01sip2ncid -> ../init.d/sip2ncid
    lrwxrwxrwx   1 root root    14 May 30  2011 S01sudo -> ../init.d/sudo
    lrwxrwxrwx   1 root root    17 May 30  2011 S02rsyslog -> ../init.d/rsyslog
    lrwxrwxrwx   1 root root    17 May 30  2011 S03apache2 -> ../init.d/apache2
    lrwxrwxrwx   1 root root    15 May 30  2011 S04acpid -> ../init.d/acpid
    lrwxrwxrwx   1 root root    17 May 30  2011 S04anacron -> ../init.d/anacron
    lrwxrwxrwx   1 root root    13 May 30  2011 S04atd -> ../init.d/atd
    lrwxrwxrwx   1 root root    14 May 30  2011 S04atop -> ../init.d/atop
    lrwxrwxrwx   1 root root    14 May 30  2011 S04cron -> ../init.d/cron
    lrwxrwxrwx   1 root root    14 May 30  2011 S04dbus -> ../init.d/dbus
    lrwxrwxrwx   1 root root    15 May 30  2011 S04exim4 -> ../init.d/exim4
    lrwxrwxrwx   1 root root    17 May 30  2011 S04galleon -> ../init.d/galleon
    lrwxrwxrwx   1 root root    17 May 30  2011 S04hddtemp -> ../init.d/hddtemp
    lrwxrwxrwx   1 root root    22 May 30  2011 S04hotkey-setup -> ../init.d/hotkey-setup
    lrwxrwxrwx   1 root root    25 Dec 25 09:22 S04isc-dhcp-server -> ../init.d/isc-dhcp-server
    lrwxrwxrwx   1 root root    20 May 30  2011 S04kerneloops -> ../init.d/kerneloops
    lrwxrwxrwx   1 root root    14 May 30  2011 S04lirc -> ../init.d/lirc
    lrwxrwxrwx   1 root root    14 May 30  2011 S04lisa -> ../init.d/lisa
    lrwxrwxrwx   1 root root    21 May 30  2011 S04loadcpufreq -> ../init.d/loadcpufreq
    lrwxrwxrwx   1 root root    15 May 30  2011 S04mdadm -> ../init.d/mdadm
    lrwxrwxrwx   1 root root    18 May 30  2011 S04netatalk -> ../init.d/netatalk
    lrwxrwxrwx   1 root root    13 May 30  2011 S04ntp -> ../init.d/ntp
    lrwxrwxrwx   1 root root    13 May 30  2011 S04nut -> ../init.d/nut
    lrwxrwxrwx   1 root root    23 May 30  2011 S04openbsd-inetd -> ../init.d/openbsd-inetd
    lrwxrwxrwx   1 root root    25 May 30  2011 S04policycoreutils -> ../init.d/policycoreutils
    lrwxrwxrwx   1 root root    19 May 30  2011 S04pppstatus -> ../init.d/pppstatus
    lrwxrwxrwx   1 root root    16 May 30  2011 S04pyTivo -> ../init.d/pyTivo
    lrwxrwxrwx   1 root root    15 May 30  2011 S04rsync -> ../init.d/rsync
    lrwxrwxrwx   1 root root    18 May 30  2011 S04sendmail -> ../init.d/sendmail
    lrwxrwxrwx   1 root root    17 May 30  2011 S04sensord -> ../init.d/sensord
    lrwxrwxrwx   1 root root    23 May 30  2011 S04smartmontools -> ../init.d/smartmontools
    lrwxrwxrwx   1 root root    27 May 30  2011 S04speech-dispatcher -> ../init.d/speech-dispatcher
    lrwxrwxrwx   1 root root    13 May 30  2011 S04ssh -> ../init.d/ssh
    lrwxrwxrwx   1 root root    17 May 30  2011 S04sysstat -> ../init.d/sysstat
    lrwxrwxrwx   1 root root    19 Dec 25 09:22 S04tftpd-hpa -> ../init.d/tftpd-hpa
    lrwxrwxrwx   1 root root    17 May 30  2011 S04winbind -> ../init.d/winbind
    lrwxrwxrwx   1 root root    22 May 30  2011 S05avahi-daemon -> ../init.d/avahi-daemon
    lrwxrwxrwx   1 root root    19 May 30  2011 S05bluetooth -> ../init.d/bluetooth
    lrwxrwxrwx   1 root root    22 May 30  2011 S05cpufrequtils -> ../init.d/cpufrequtils
    lrwxrwxrwx   1 root root    16 May 30  2011 S05dhcdbd -> ../init.d/dhcdbd
    lrwxrwxrwx   1 root root    19 May 30  2011 S05fetchmail -> ../init.d/fetchmail
    lrwxrwxrwx   1 root root    13 May 30  2011 S05hal -> ../init.d/hal
    lrwxrwxrwx   1 root root    25 May 30  2011 S05network-manager -> ../init.d/network-manager
    lrwxrwxrwx   1 root root    20 May 30  2011 S05pulseaudio -> ../init.d/pulseaudio
    lrwxrwxrwx   1 root root    15 May 30  2011 S05pyHME -> ../init.d/pyHME
    lrwxrwxrwx   1 root root    17 May 30  2011 S06openvpn -> ../init.d/openvpn
    lrwxrwxrwx   1 root root    14 May 30  2011 S07cups -> ../init.d/cups
    lrwxrwxrwx   1 root root    13 May 30  2011 S07gdm -> ../init.d/gdm
    lrwxrwxrwx   1 root root    13 May 30  2011 S07kdm -> ../init.d/kdm
    lrwxrwxrwx   1 root root    18 May 30  2011 S08bootlogs -> ../init.d/bootlogs
    lrwxrwxrwx   1 root root    15 May 30  2011 S08samba -> ../init.d/samba
    lrwxrwxrwx   1 root root    17 May 30  2011 S15portmap -> ../init.d/portmap
    lrwxrwxrwx   1 root root    20 May 30  2011 S16nfs-common -> ../init.d/nfs-common
    lrwxrwxrwx   1 root root    27 May 30  2011 S17nfs-kernel-server -> ../init.d/nfs-kernel-server
    lrwxrwxrwx   1 root root    18 May 30  2011 S18rc.local -> ../init.d/rc.local
    lrwxrwxrwx   1 root root    19 May 30  2011 S18rmnologin -> ../init.d/rmnologin
    lrwxrwxrwx   1 root root    23 May 30  2011 S18stop-bootlogd -> ../init.d/stop-bootlogd
    
    The links in each runlevel are asserted in alphabetic order. Insserv has assigned pyTivo the name S04pyTivo, which means it will run prior to pyHME which has been assigned the name S05pyHME. Init will run the scripts with a "start" parameter whenever entering any runlevel from a runlevel where the script is run with a "stop", indicated by the name being KxxpyTivo. In those directories, pyTivo will have a higher number with the K prefix, so it is killed after pyHME.

    No. Other than assigning the link names in proper order, insserv doesn't really care what pyTivo does. It's possible running HME for Python before pyTivo is loaded will jam it up, but I'm not sure. If not, then simply having an error when running insserv won't stop it from coming up. If the links don't exist at all, though, then of course it won't ever come up. Ditto if there are errors in the scripts themselves.

    The first task is going to be making sure the scripts work at all. Then we can worry about insserv.

    It probably won't hurt if it isn't there at this point. It definitely will never hurt if it is there, as long as the pyTivo header is correct. The body of the init script itself could be a fracking mess, and insserv would never know it.

    I strongly suspect his system is not doing dependency based booting. It may have an older init version, or else he has legacy boot ordering enabled. Insserv will have dependency based booting disabled if there is a file named .legacy-bootordering in the /etc/init.d diretory. Absent that file, insserv will implement a boot order based upon the fields in the init script headers.

    Once again, see the man pages for update-rd.d and insserv.
     
  18. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Well, not exactly. Their systems are not the same as yours.
     
  19. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    No, insserv.conf is only referenced when insserv is run, and that is only when update-rc.d is run. This will, however, happen whenever he upgrades or adds any boot-time system utilities, so I really suggest he gets his boot scripts straightened out. It could save him a lot of grief in the future. Non-dependency based booting is a lot less strict than dependency based booting, but it is also a great deal frailer and a lot harder to maintain.
     
  20. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Thanks for the detailed lessons; I'll go back to your dependency based booting code when I get a chance. I see the advantages and it'd be good to understand. Meantime it's all working, fragile though it may be. Thanks again to you & all!
     

Share This Page