rc scripts

[subhashni]

Hello,
How do i define environment (env) with in the script ,which is a startup script.
For some reason ftp logins are all not working which is defined within the script.
.netrc files have been updated appropriately.
I did get good responses when i posted the related topic though.Appreciate any suggestions.
Thanks

[Frank de Vries]

I assume you mean rc unix startup script in
/sbin/init.d/
Then
You can use su - accountname -c script
and ensure this account has the appropriate env via its .profile and .kshrc

[Tim Nelson · Accepted solution]

The FTP server is typically defined in the inetd.conf file and not normally part of the boot scripts unless things have been modified.

Otherwise all environment paths and variables need to be definded in the startup script, via su to another user ( not for FTPD as it runs as root typically ).

More info on how things are setup on your side will help.

[James R. Ferguson]

Hi:

Standard startup scripts run by '/sbin/rc' are going to be devoid of any environmental variables that your application needs.

It's up to you to either declare variables you need in your customized startup script, or to source (read) a file containing them as your startup script begins executing.

One cruder method to employ is to do an 'su - -c <script>' within your startup script. This causes the profile to be sourced and <script> to be run.

Regards!

...JRF...
Regards!

...JRF...

[Dave La Mar]

subhashni -
To add to James' valid points -
If the startup you wish to add is using ftp, insure it starts behind any ftp rc startup scripts, else the service may not be available whe you want to start yours. [My apologies if this was overly obvious.]
I'm attaching a doc we have found useful in the past when writing new rc level startup scripts.
Note that it provides information on testing your script real time without having to perform a reboot, etc.

Best of luck on this.

Regards,

dl

[Dave La Mar]

Sorry, forgot the attachment.
Note that is says for version 10.X, but we used it for 11.0, etc.

dl

[James R. Ferguson]

Hi (again):

The document attached by Dave is a favorite of mine, since it quite clearly describes the entire paradigm.

Despite the fact that the document was written for the 9x-10.0 transition of HP-UX, it continue to apply through all current releases (11.23). About the only update is that a script exiting with a return value of '4' denotes one that started a background process. The manpages for 'rc(1M') document this and provide an alternative, but parallel, document.

Regards!

...JRF...

[subhashni]

Thanks so much for the responses.
What could be the right way or format to specify the .profile within the script.
Thanks again.

[James R. Ferguson]

Hi:

> What could be the right way or format to specify the .profile within the script?

As I noted before, you would do something like:

# su - subhashni -c /home/subhasni/his_thing

Assuming that the calling script was running as root, as a normal 'startup' script would be, this changes the user to 'subhasni', *runs* 'subhasni's '.profile' as a consequence of the 'su -' and then executes "/home/subhasni/his_thing".

The principal problem with this approach is that the login '.profile' is generally constructed to be interactive. Commands therein like 'stty' and 'tset' are meant to be executed when associated with a *terminal*. Unless you conditionally exclude these commands with:

# if [ -t 0 ]; then
> stty ...
> fi

...then when your profile runs, you will see messages like "Not a typewritter".

The alternative is *not* to allow the user's profile to be sourced *and* to include any or all environmental variables by sourcing (reading) a file containing them as part of your executed script. Thus, you could do:

# su subhashni -c /home/subhasni/his_thing

...Notice the absence of the "-" after the 'su' in this form. This means that "subhasni"'s profile is *not* read (sourced). The assumption is probably that within the script '/home/subhasni/his_thing' is something like:

# . /home/subhasni/env_vars

Note that this is a dot character, followed by as space, followed by a script name. This is "sourcing" or reading. The 'env_vars' file might look like:

PATH=${PATH}:/home/subhasni
HOME=/home/subhasni
DOING=mything

Regards!

...JRF...

[subhashni]

Thank You All.