Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

CentOS 6.5

The server is an AWS AMI, specifically this one

I'm trying to use upstart to start a process on boot

On this particular box, the root login is disabled, and every time I need to run something with sudo it asks for my password

So simply putting my command in the script won't work.

I tried to follow this answer, with no success

I've got this rio.conf file in the /ect/init directory:

start on runlevel [2345]
stop on runlevel [!2345]

exec echo Password! | sudo -s /usr/bin/riofs --fuse-options="allow_other" --fmode=0777 --dmode=0777 xx.xxxxxx /mnt/applications/recorder/streams/_definst_/s3

And whenever I run this, nothing seems to happen.

Password! is just an example password.

EDIT:

If I type exec /usr/bin/riofs my SSH window will close, and then when I go back in, I can see that it's working. I don't know what that means, or how to automate that.

share|improve this question

3 Answers 3

up vote 3 down vote accepted

You don't need sudo within an init/upstart script. All init/upstart services run as root by default.

Think of it this way, what user do you expect the upstart script to run as? If you expect it to run as your personal user, why would it? The system just sees a script, it doesn't know who your personal user is.

In short, change your exec line to this:

exec /usr/bin/riofs --fuse-options="allow_other" --fmode=0777 --dmode=0777 xx.xxxxxx /mnt/applications/recorder/streams/_definst_/s3

Though ultimately, I wouldn't do this either. You're mounting a filesystem, this is a job for /etc/fstab:

riofs#xx.xxxxxx    /mnt/applications/recorder/streams/_definst_/s3    _netdev,allow_other,fmode=0777,dmode=0777   0 0
share|improve this answer
    
1) this still doesn't seem to work. I'm not seeing the changes to my directory that I would see if I were to run the command normally. 2) Are you suggesting I use fstab instead of riofs or simply to use fstab WITH riofs? And if I were to use fstab wold I replace my exec line with the one you provided? –  Houseman Jun 1 at 3:06
    
That line would go in /etc/fstab. Note the bit at the beginning, it's still using riofs. If you're getting errors, we need to see the output. If you're using upstart, upstart keeps a log at /var/log/upstart/SERVICENAMEHERE.log –  Patrick Jun 1 at 3:09
    
there is no /var/log/upstart directory on my machine. There is also no /etc/fstab directory –  Houseman Jun 1 at 3:11
    
If I type exec /usr/bin/riofs my SSH window will close, and when I go back in and check my directory to see if it's working, it is. I don't know what that means –  Houseman Jun 1 at 3:56

You can configure sudo to work without the user password. Execute visudo as root, and add NOPASSWD to the user line:

user    ALL=(root)    NOPASSWD: ALL

Edit

Given that this is an upstart script, Patrick's answer is correct.

Also, for arbitrary scripts, 0xC0000022L makes a good point. Say that you want to run this root-only script as user with no password required:

user@host:~$ ls -lah /usr/local/bin/script.sh
-rwx------  1 root root ... script.sh

Using visudo, the user line should be:

user    ALL=(root)    NOPASSWD: /usr/local/bin/script.sh

That way, the password requirement is waived only for that command.

share|improve this answer
    
Perhaps also include the exact command. I prefer for such cases to put a script into a folder and lock its permissions down, and then say user ALL=(root) NOPASSWD: /path/to.my/lockedown/script.sh. This way user can only execute this particular script as root. It's an important difference. I suggest man sudoers and reading up on Cmnd_Alias, User_Alias and friends. –  0xC0000022L Jun 1 at 2:31
    
That didn't seem to work. I still get prompts to enter my password. Is there any log file that my upstart script would write to if it failed or succeeded? –  Houseman Jun 1 at 2:42

There are two things to consider.

Firstly, if you find that entering your password at every sudo is tedious do as @mirimir suggests and edit the `/etc/sudoers' file to something like:

yourusername ALL=(root) NOPASSWD: ALL

or

yourusername ALL=(ALL) NOPASSWD: ALL

to fix it for ever and ever :-).

Secondly, check the owner of the script. I'm pretty sure owner and permissions matter. Change the owner thusly sudo chown root:root /path/to/script.sh. Also consider setting permissions to 744 with sudo chmod 744 /path/to/script.sh.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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