1

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.

Improve this question

3 Answers 3

Reset to default
3

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
Improve this answer
4
  • 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?
    – user69082
    Commented Jun 1, 2014 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
    – phemmer
    Commented Jun 1, 2014 at 3:09
  • there is no /var/log/upstart directory on my machine. There is also no /etc/fstab directory
    – user69082
    Commented Jun 1, 2014 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
    – user69082
    Commented Jun 1, 2014 at 3:56
0

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.

Improve this answer
2
  • 1
    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
    Commented Jun 1, 2014 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?
    – user69082
    Commented Jun 1, 2014 at 2:42
0

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.

Improve this answer

You must log in to answer this question.