Machine Initialization problem.

[Cesar Soublette_1]

We have a problem while the machine is starting the Operatibg System, we need to execute a daemon in the machine's initialization process but the system is generating an error as follows:
"No such file or directory" ..
We are invoking the daemon from the following path:
/sbin/init.d
moreover, we have a symbolic link between this path and the real daemon program file path:
So, what could you recommend in order to solve this problem?
Thank's
Best Regards

[Patrick Wallek]

The first step is to figure out exactly what command is giving you the "No such file or directory" error. It sounds as if you a command specified and did not fully qualify the path. Check through your startup script and see if that is the case.

It would also help if you would post the startup script you are using.

[Eugeny Brychkov]

Cesar,
which daemon do you try to run? Please post whole command.
You can check if this daemon is seen on the path issuing
ll /sbin/init.d/daemonname
and look at output if it will list this daemon (try it in single user mode too)
Eugeny

[Sandip Ghosh]

Try to put the absolute path name inside your script, avoid relative pathname or link.

Sandip

[harry d brown jr]

At what run level are you attempting to start this daemon?

If this is a process that "listens" to network connections, then it HAS to be started AFTER the networking daemons.

live free or die
harry

[Bob_Vance]

When the startup scripts are being launched at system initialization, the "PATH" variable (which specifies a list of directories where commands are to be found in case they are referenced with relative names rather than absolute pathnames) is set to a small default value (something like,
"/sbin:/usr/sbin:/usr/bin" ).

This is fine for most system commands, but if you are running commands (including scripts) from your own local directories somewhere else, then the commands will not be found (unless the absolute pathname is specified).

If you look at the scripts in /sbin/init.d, you'll see that almost every one of them includes a PATH= statement near the top. When you create your own startup script, you should also be sure that you have a PATH= statement that includes directories where your home-grown commands are located. This is actually safer than simply specifying an absolute pathname if you are including calls to home-grown scripts, as these scripts might assume that PATH is set correctly (e.g., because they might be tested or used interactively after a login which has set PATH correctly). In fact you should make the statement:

export PATH=....

so that it will be set for any scripts that you might call. Be sure to add your directories *after* the standard, so you don't mask the search for normal system commands:
export PATH=/sbin:/usr/sbin:/usr/bin:/my-own-stuff

bv

[Bob_Vance]

Actually, it's slightly better to use

PATH=....
followed by

export PATH

(which is what the HP startup scripts use).

This is for legacy situations in case the shell being used at startup is not the POSIX shell, but is the old Bourne shell (which didn't support "export VAR=").

Practically speaking, HP-UX now uses the POSIX shell for root, anyway, so it's not a problem, there (the old Bourne shell is in /usr/old/bin/sh). It's a habit thing when you're supporting multiple Unices to use Bourne-shell style at the system level so you don't get hurt on a system that is not using a POSIX-compliant shell.

bv

[Bob_Vance]

OK, a couple of "final" comments :)

1) To be technically precise, the "real" truth is that "/sbin/rc" sets (and exports) PATH to simply "/sbin" before cycling thru the startup scripts. Thus the "small default value" that I mentioned is *not* "something like,
/sbin:/usr/sbin:/usr/bin", but rather *exactly* "/sbin".
So, you need some sort of PATH=....
Note that the skeleton template file has:

PATH=/usr/sbin:/usr/bin:/sbin
export PATH



2) One important thing to note about startup configuration is that, prior to the launch of *each* startup script, **all** the configuration files in /etc/rc.config.d are sourced. Thus, all the variables defined therein will be set at the time of the execution of your script. If you create your own configuration script use by your startup script, then be sure to "uniqify" your variables so that you don't clobber one needed by another script, or vice versa. E.g., for my config variables, I always use the form:

SBM__var

as in

SBM_SOCKS=0
SBM_SOCKS_VER=4
SBM_SOCKS_ARGS=""
SBM_SSHD=1
SBM_SSHD_ARGS=""
SBM_SSHD_VER=2
SBM_SSHD_VER=""

yadayada

bv

[Bob_Vance]

Damn. I'll state it correctly someday :|

The sourcing of the config vars is done from *within* each startup script at the start/stop case, as in

'start')
if [ -f /etc/rc.config ] ; then
. /etc/rc.config

If you start from the template as a base, then this code will be there. If you create your own script from scratch or comment out that code, then var-name conflict is not an issue.

bv