I'm trying to set up an init script for a process on redhat linux:

# Startup script for Conquest
# chkconfig: 345 85 15     - start or stop process definition within the boot process
# description: Conquest DICOM Server
# processname: conquest
# pidfile: /var/run/conquest.pid

# Source function library.      This creates the operating environment for the process to be started
. /etc/rc.d/init.d/functions


case "$1" in
        echo -n "Starting Conquest DICOM server: "
        cd $CONQ_DIR && daemon --user mruser ./dgate -v                 - Starts only one process of a given name.
        touch /var/lock/subsys/conquest
        echo -n "Shutting down Conquest DICOM server: "
        killproc conquest
        rm -f /var/lock/subsys/conquest
        rm -f /var/run/conquest.pid      - Only if process generates this file
        status conquest
        $0 stop
        $0 start
        echo -n "Reloading process-name: "
        killproc conquest -HUP
        echo "Usage: $0 {start|stop|restart|reload|status}"
        exit 1

exit 0

However, the cd $CONQ_DIR is getting ignored, because the script errors out:

# ./conquest start
Starting Conquest DICOM server: -bash: ./dgate: No such file or directory

For some reason, I have to run dgate as ./dgate. I cannot specify the full path /usr/local/conquest/dgate

The software came with an init script for a Debian system, so the script uses start-stop-daemon, with the option --chdir to where dgate is, but I haven't found a way to do this with the Redhat daemon function.

  • Perhaps dgate is a script, and you can fix that so it can be run from the full path? – Kyle Brandt Apr 7 '10 at 12:06
  • No, it's a binary. – churnd Apr 7 '10 at 13:33
  • Have you been able to run the process without an init script, and then in another terminal verify the process is running with ps? I don't see confirmation of it working outside of the init in this discussion. – labradort Apr 7 '10 at 17:57
  • Yes, it does work if I run it manually. ps -aux | grep dgate shows a ./dgate process running. – churnd Apr 7 '10 at 18:06
  • Is it possible that it's running as "conquest", not "dgate"? I ask because the stop is doing killproc conquest. – Bill Weiss Apr 7 '10 at 20:45

Why not just:

daemon --user mruser ${CONQ_DIR}/dgate -v



cd ${CONQ_DIR} && daemon --user mruser ./dgate -v &
  • This doesn't work. For some reason, I have to run dgate as ./dgate. I cannot specify the full path /usr/local/conquest/dgate – churnd Apr 7 '10 at 20:18
  • Can you add a "echo $CONQ_DIR" before the "cd $CONQ_DIR && daemon --user mruser ./dgate -v" line and let me know what it says? – Bill Weiss Apr 7 '10 at 20:43
  • It says Starting Conquest DICOM server: /usr/local/conquest. – churnd Apr 7 '10 at 21:52
  • Ok, so it's getting the path... Is there a "conquest" running? How about any processes running as "mruser" ? – Bill Weiss Apr 7 '10 at 22:16
  • 1
    adding the "&" to the end of your line makes it error with "No such file or directory" ? cd $CONQ_DIR && daemon --user mruser ./dgate -v & ? I hope the ${} didn't give it problems. – Bill Weiss Apr 8 '10 at 17:17

Old question is old, still: you can troubleshoot this kind of problem with a set -x (xtrace) at the top of your script. Also, consider set -e, so the script errors out early.


Does dgate file has execution permission?

Try to echo the current directory (echo `pwd`) before launch dgate.

Regards, Lorenzo.

  • Yes, dgate is executable. I can run it manually. echo pwd shows the CD command is working, but ./dgate just doesn't work. If I add $CONQ_DIR/dgate, then do /etc/init.d/conquest start, it says it starts OK, but ps ax shows no dgate process running. – churnd Apr 7 '10 at 13:43
  • Try to replace: cd $CONQ_DIR && daemon --user mruser ./dgate -v with: cd $CONQ_DIR && sudo -u mruser ./dgate -v – lg. Apr 7 '10 at 15:06
  • I did this... now for some reason the script stops responding at "Starting Conquest DICOM server:". I even tried to change it back to the previous "daemon" line, but it still halts. What would make an init script halt? – churnd Apr 7 '10 at 17:58

export CONQ_DIR The subshell doesn't know about the directory.


$ FOO=skhfkjsdh
$ cat foo.sh

    echo $FOO

$ sh foo.sh

$ export FOO=skhfkjsdh
$ sh foo.sh
  • I think it does... see my comment on lg's Answer. – churnd Apr 7 '10 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.