Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have installed a shutdown script on an Ubuntu system which doesn't get executed. It is an Amazon EC2 instance. I'm not sure it has to do with this fact just wanted to point it out.

The script should push some log files to an Amazon S3 bucket so it has to be executed while networking is up.

Here is how I installed the script:

1) Created the file in /etc/init.d/push-apache-logs-to-s3.sh with the required commands.

2) Made it executable with sudo chmod +x push-apache-logs-to-s3.sh

3) Executed sudo update-rc.d push-apache-logs-to-s3.sh start 0 0 .

Output from the above was:

update-rc.d: warning: /etc/init.d/push-apache-logs-to-s3.sh missing LSB information
update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
 Adding system startup for /etc/init.d/push-apache-logs-to-s3.sh ...
   /etc/rc0.d/S00push-apache-logs-to-s3.sh -> ../init.d/push-apache-logs-to-s3.sh

The contents of /etc/rc0.d/ is now:

lrwxrwxrwx  1 root root   17 Jul 31  2012 K09apache2 -> ../init.d/apache2
lrwxrwxrwx  1 root root   29 Jun 16  2012 K10unattended-upgrades -> ../init.d/unattended-upgrades
lrwxrwxrwx  1 root root   26 Jun 16  2012 K15landscape-client -> ../init.d/landscape-client
lrwxrwxrwx  1 root root   19 Apr 10 11:11 K20memcached -> ../init.d/memcached
-rw-r--r--  1 root root  353 Jul 26  2012 README
lrwxrwxrwx  1 root root   35 Jul 10 12:01 S00push-apache-logs-to-s3.sh -> ../init.d/push-apache-logs-to-s3.sh
lrwxrwxrwx  1 root root   18 Jun 16  2012 S20sendsigs -> ../init.d/sendsigs
lrwxrwxrwx  1 root root   17 Jun 16  2012 S30urandom -> ../init.d/urandom
lrwxrwxrwx  1 root root   22 Jun 16  2012 S31umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx  1 root root   20 Jun 16  2012 S35networking -> ../init.d/networking
lrwxrwxrwx  1 root root   18 Jun 16  2012 S40umountfs -> ../init.d/umountfs
lrwxrwxrwx  1 root root   20 Jun 16  2012 S60umountroot -> ../init.d/umountroot
lrwxrwxrwx  1 root root   14 Jun 16  2012 S90halt -> ../init.d/halt

When I manually execute the script with sudo ./push-apache-logs-to-s3.sh, it does the intended job.

Are these scripts executed by root? What am I missing?

share|improve this question
1  
This sort of problems are usually caused by something missing from the environment variables when run non-interactively. I assume you took the precaution to not use relative paths on your scripts so maybe a dependence on an environment variable that isn't available. Could you add the script to your question? –  gnp Jul 10 '13 at 13:42
    
@gnp I posted another question about this with more details and the script contents. Please check it here: superuser.com/questions/617957/lsb-init-script-not-executed –  Marcell Fülöp Jul 10 '13 at 13:51
    
I think I now what's wrong. s3cmd was configured under another user not root thus the init script which is run by root fails to execute the s3cmd command. I'll try configuring it under the root user and see if that helps. –  Marcell Fülöp Jul 10 '13 at 13:58
    
Nope, that didn't help. When I execute the script with either user, it is doing what it should so s3cmd CAN access its configuration. Still, apparently the init script is not executed at shutdown... –  Marcell Fülöp Jul 10 '13 at 14:04

3 Answers 3

You want the script to run on shutdown. Replace start with stop as follows:

sudo update-rc.d push-apache-logs-to-s3.sh stop 0 0 .

Note that it will get a K prepended, instead of an S

share|improve this answer
    
I've tried that earlier but still no sign of it being executed. –  Marcell Fülöp Jul 10 '13 at 13:25
    
That is not what the stop and start do, they have nothing to do with shutdown, that is defined by the run levels given. See man update-rc.d. –  terdon Jul 10 '13 at 13:28
    
You're right, it will run when switching to runlevel 0, the stop and start only change the parameter passed to it, which in the OPs case doesn't make any difference. –  gnp Jul 10 '13 at 13:43
    
The stop and start are there to specify which runlevels it will start and stop at. stop 0 1 6 means stop at runlevels 0,1 and 6 for example. –  terdon Jul 10 '13 at 14:17

What's the expected behavior when you set the script to be run at S00? I have no scripts with S00 on my system, could it be that a minimum of 1 is required? You also did not explicitly set start/stop, perhaps that's causing problems. Just in case, try

sudo update-rc.d push-apache-logs-to-s3.sh start 01 2 3 4 5 . stop 01 0 1 6 .  

If that still doesn't work, please update your question to who your script (or at least its headers), there might be something wrong there.


EDIT

Having seen the script you posted in your other question, I see two possible problems. First, you have a space in your shebang line !# /bin/sh instead of #!/bin/sh.

More importantly, why are you using sh instead of bash? sh does not support source, let alone . as an alias for source. Change your script to run with bash instead, that should fix it. In fact I don't understand why it works when you run it manually, the . should throw an error:

$ sh
$ source foo
sh: 1: source: not found
$ bash
$ source foo
bash: foo: No such file or directory

Scratch that, I was wrong, as @gnp pointed out, dash does actually support ..

share|improve this answer
    
I have tried your suggestion but still no luck. Also, now I modified the script in /etc/init.d/ to be a proper LSB script like all others. Still doesn't get called... –  Marcell Fülöp Jul 10 '13 at 13:25
    
@MarcellFülöp and /etc/init.d/push-apache-logs-to-s3.sh is owned by root right? –  terdon Jul 10 '13 at 13:29
    
Yes it's -rwxr-xr-x 1 root root –  Marcell Fülöp Jul 10 '13 at 13:34
    
On most ubuntu systems sh is a symlink to bash or dash lrwxrwxrwx 1 root root 4 mar 29 2012 /bin/sh -> dash. Also most of the scripts I have on /etc/init.d have the space after the shebang and use sh as the shell. –  gnp Jul 10 '13 at 14:23
    
Re: EDIT. Good points. In the first version I had #!/bin/bash. Then I copied one of the existing init scripts and modified it so the #! /bin/sh came from there so I assume that's OK. Will try to change it back to #!/bin/bash though. –  Marcell Fülöp Jul 10 '13 at 14:24

The root of the problem is that s3cmd is not able to read its config file. For some reason unknown to me, during runlevel change (0), when init executes init-scripts, apparently the root user who runs those scripts doesn't count as a "real" user so it doesn't have a "home" directory from where s3cmd tries to read the config.

Explicitly specifying the config file's location using the --config=... solves this problem.

Thanks for the help and input from everyone!

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.