- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- init.d script permission denied
Operating System - HP-UX
1819966
Members
3838
Online
109607
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-05-2001 12:05 PM
тАО04-05-2001 12:05 PM
init.d script permission denied
Hi everyone,
Background: I have to create a second instance of a running "gateway" software to start up at boot. The gateway is RedBack (database stuff) and has to run as a different user, only one specified user can start the gateway. The old instance starts fine, so I copied that init.d script and edited it as needed, and then changed the environment variables in the /etc/rc.config.d file for UDTHOME,UDTBIN & RBHOME (special environment variables).
Situation: The command to start or stop the gateway dies when I try to execute it. The startup says it is already running and stop says permission denied. The command on the properly functioning gateway is su username -c "/path/to/program". The problem is the second or "newer" instance of the gateway will not start unless I put the command su - username -c "/path/to/program" (notice the - after su).
Tried: I have even stated all the environment variables given from the env command in the /etc/rc.config.d/file and still no luck.
Any suggestions as to what may be happening?
Background: I have to create a second instance of a running "gateway" software to start up at boot. The gateway is RedBack (database stuff) and has to run as a different user, only one specified user can start the gateway. The old instance starts fine, so I copied that init.d script and edited it as needed, and then changed the environment variables in the /etc/rc.config.d file for UDTHOME,UDTBIN & RBHOME (special environment variables).
Situation: The command to start or stop the gateway dies when I try to execute it. The startup says it is already running and stop says permission denied. The command on the properly functioning gateway is su username -c "/path/to/program". The problem is the second or "newer" instance of the gateway will not start unless I put the command su - username -c "/path/to/program" (notice the - after su).
Tried: I have even stated all the environment variables given from the env command in the /etc/rc.config.d/file and still no luck.
Any suggestions as to what may be happening?
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-05-2001 01:02 PM
тАО04-05-2001 01:02 PM
Re: init.d script permission denied
I would suggest you create a second user account with the exact same permissions as the working user account. Remember this "RedBack" software may not normally allow a second instance of the program to run.
-Jason
-Jason
Never Underestimate the Power of Human Stupidity -RAH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-05-2001 02:06 PM
тАО04-05-2001 02:06 PM
Re: init.d script permission denied
The second instance will run perfectly if I put the - in the su command, or if I manually login as that user and type the command manually. There isn't a problem with not allowing a second instance in that respect. However there is something that is set with the su - that isn't set with just su.
Just a reminder, I have already copied the output from the env command and declared all of those environment variables and that didn't work either.
Just a reminder, I have already copied the output from the env command and declared all of those environment variables and that didn't work either.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-06-2001 05:17 AM
тАО04-06-2001 05:17 AM
Re: init.d script permission denied
Jeff, when you put the - after the su command it's like you telneted into that user. Here's an excerpt from the su man page:
If you specify the - option of the su command, the new shell starts up as if you just logged in, except as follows:
+ The HOME variable is reset to the new user's home directory.
+ If the new user name is root, the path and prompt variables are
reset:
PATH=/usr/bin:/usr/sbin:/sbin
PS1=#
For other user names:
PATH=/usr/bin
PS1=$
+ The rest of the environment is deleted and reset to the login
state. However, the login files are normally executed anyway,
usually restoring the expected value of PATH and other
variables.
However if you don't user the - after su:
If you omit the - option, the new shell starts up as if you invoked it as a subshell, except as follows:
+ If the new user name is root, the path and prompt variables are
reset:
PATH=/usr/bin:/usr/sbin:/sbin
PS1=#
+ The rest of the environment is retained.
Hope this helps explain it.
If you specify the - option of the su command, the new shell starts up as if you just logged in, except as follows:
+ The HOME variable is reset to the new user's home directory.
+ If the new user name is root, the path and prompt variables are
reset:
PATH=/usr/bin:/usr/sbin:/sbin
PS1=#
For other user names:
PATH=/usr/bin
PS1=$
+ The rest of the environment is deleted and reset to the login
state. However, the login files are normally executed anyway,
usually restoring the expected value of PATH and other
variables.
However if you don't user the - after su:
If you omit the - option, the new shell starts up as if you invoked it as a subshell, except as follows:
+ If the new user name is root, the path and prompt variables are
reset:
PATH=/usr/bin:/usr/sbin:/sbin
PS1=#
+ The rest of the environment is retained.
Hope this helps explain it.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Learn About
News and Events
Support
© Copyright 2025 Hewlett Packard Enterprise Development LP