Hi,


I refereed to an old post prior to posting, among researching the web.

I have read there are many ways to have a startup script, my requirements are simple, to start a service for an application, so i do not have to do it manually.

I referred to this post: http://www.linuxquestions.org/questi...sartup-423154/

Which did not work, the command i entered in /etc/init.d/boot.local.was: elogd -p80 -c /usr/local/elog/elogd.cfg -D

Which works fine manually, but not in the startup script, any advice would greatly be appreciated.

Kind rgds,

Simple script to start the service
----------------------------------
#!/home/scripts

#Purpose: To start the elog deamon and the service via port 80
elogd -p 80 -c /usr/local/elog/elogd.cfg -D

Error returned: -bash: ./elogd.sh: /home/scripts: bad interpreter: Permission denied

Permission set on file are chmod 755.

Maybe this is the reason why the start does not work, for some reason this does not work in a script.

Any advice is appreciated.

Thanks.

Your problem is in bold. When you start a script, the first line should read #!/path/to/interpreter

Usually this would be #!/bin/bash or #!/bin/tcsh, or any other interpretter. You set this path to an interpretter that does not exist (I'm assuming, since that would be a weird name for it), hence the "bad interpreter" response.

Hi,

Yes, this made the shell script work. But the same command in the init.d/boot.local file does not work. How can make this script run so when the server boots up, the service is started?

Thanks thus so far.

What does your boot.local file look like?

Hi,

Please see below. I have commented out the command i want to use, as it was not working.

#! /bin/sh
#
# Copyright (c) 2002 SuSE Linux AG Nuernberg, Germany. All rights reserved.
#
# Author: Werner Fink <werner@suse.de>, 1996
# Burchard Steinbild, 1996
#
# /etc/init.d/boot.local
#
# script with local commands to be executed from init on system startup
#
# Here you should add things, that should happen directly after booting
# before we're going to the first run level.
#

# start elog deamon on port 80
# elogd -p 80 -c /usr/local/elog/elogd.cfg -D

Where is the elogd binary? Maybe it's not in the PATH, you should try using the absolute path to it in the startup script.

what version of suse is this ?
you do not say

start up changed with opensuse 12
it no longer is using the old int system v
they moved to system D

so the whole start up process changed

If you're using systemd, have a look at this
http://freedesktop.org/wiki/Software/systemd/
and in particular
http://0pointer.de/blog/projects/sys...-admins-3.html

Hi,

I amended the code to give the path to the binary file:

cd /usr/local/sbin/

elogd -p 8080 -c /usr/local/elog/elogd.cfg -D


But it still doesn't work upon boot, however when run separately it works fine.

Binary location:

SUSE:/usr/local/sbin # whereis elogd
elogd: /usr/local/sbin/elogd /usr/share/man/man8/elogd.8.gz

PS - I might reply a bit later than expected as I am moving homes.

Thank you.

---------- Post added 10-30-13 at 08:35 AM ----------

Hi,

I am on suse linux enterprise server 11.

Thanks.

Hi,

I am not a Linux admin, so not really too sure about what the link is showing me.

Thank you.

That doesn't change anything. You did not give the script the path to anything, you simply changed directories.

When you run a program, the shell does not care where you are, not one bit. It only cares about one of two things:

Did you provide the path to the executable - absolute or relative doesn't matter, as long as you provided a path.
1) If you did provide a path, does the executable exist where you said it did?
2) If you did not provide a path, does the executable exist in any of the directories specified by the PATH environment variable?

Notice how your pwd doesn't come into play here at all unless you provided a relative path to the executable, which you did not. Change you call from "elogd" to "/usr/local/sbin/elogd" to eliminate this from the list of possible problems.

"/usr/local/sbin" is a bit of an odd location
/usr/sbin is the standard location for root user ONLY programs

the "local" folder might NOT be in the system $PATH unless YOU put it in the system path

did you ? add that odd location to the system $PATH ?

to check compare the root and NORMAL user $PATH - they SHOULD be different
--- then as root----