Tag Info

Hot answers tagged

6

No matter what distro I nowadays use, I have learnt my lesson: if I want to make sure something comes up at boot, I will reboot the server and see what happens. Just schedule a maintenance window for your server (if needed) and perform couple of test restarts at that time. See if it works. In the past I've been sure that "this will start during next ...


6

Running sudo su user01 in a script does not mean the following commands are sent to the resultant shell. In fact, it likely means a new shell is spawned as user01, which never exits! Two things: You can execute a command as another user either by passing the -c 'command...' argument to su, like su user01 -c '/etc/init.d/script start'. Starting a service ...


5

You could put something in /etc/crontab and run it @reboot @reboot username /etc/init.d/script start


3

You could try to edit your kernel options in grub to append: init=/bin/bash Failing that, you could try a rescue disk to fix your rc.local.


2

I suppose the shell TERMs it when it exits, which would be immediately, due to the '&'. Maybe you want to use start-stop-daemon? E.g: start-stop-daemon --start -b -x /usr/bin/Xvfb :1 I suppose if you want the help of the startx wrapper, you may want to run your shellscript instead.


2

You can use my init script. It's based on /etc/init.d/skeleton and seems to work well: #! /bin/sh ### BEGIN INIT INFO # Provides: Xvfb # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start Xvfb. # Description: Start the X virtual ...


2

One of the commands on your /etc/rc.local must be exiting with a non-zero status. Because of the -e parameter to sh on the first line this is causing the script to exit immediatly. You can either remove the -e or find the responsible command and fix its error.


2

In order to log all the output to a file, i.e., add the following to all your commands in rc.local: >> /var/log/rc.local.log 2>&1 This will collect both stdout and stderr to /var/log/rc.local.log then you should be able to know what happened.


2

Redirect the output of your script to a file in rc.local e.g. /path/to/yourscript >/tmp/script.out 2>&1 which should capture the stdout and stderr from yourscript.


2

I am retarded, /etc/rc.local is a symlink to /etc/rc.d/rc.local.


2

We can't debug a mystery script. Does running the python script work with an empty environment? Try: env -i /usr/bin/python /root/automation/initSystem.py Modify your script to capture the output of your command in the script: /usr/bin/python /root/automation/initSystem.py > /root/init.stdout 2> /root/init.stderr and it'll probably contain hints ...


2

My investigation further into this led me to a solution. So now I know how to do it correctly, but I still do not understand why startpar behaved like it did. So if anyone is willing to step in and explain that, I'm more than willing to accept that answer than this one. Basically the problem was that I called the scripts without redirecting(or closing) ...


1

You can use crontab to execute a command on boot: http://www.cyberciti.biz/faq/linux-execute-cron-job-after-system-reboot/ you have to "chmod +x" your script and then use the full path. chmod +x /home/mylin/exmpl.sh And then in your crontab: @reboot /home/mylin/exmpl.sh Or in your rc.local file: /home/mylin/exmpl.sh


1

ntpdate is depreciated. You should install the NTP client and configure the ntpd daemon configuration file /etc/ntp.conf: # cat /etc/ntp.conf | grep -v ^# | grep -v ^$ driftfile /var/lib/ntp/drift restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server ...


1

I have no idea why you (and I get the same problem) can't capture the output of the command when run from rc.local. If you want to capture it you can do something like out=$(ntpdate ntp.fudan.edu.cn 2>&1) echo $out >>/data/logs/1.log which just worked on a system I have to hand.


1

Try putting /bin/bash in front of your command. You can't use relative paths because there is no environment to keep track of them. If you run everything in a bash-shell, bash will keep track of these things for you. Same goes for crontab


1

Looks like either: ttserver isn't in the path when /etc/rc.local runs. Make sure that the environment is set up correctly in /etc/rc.local. As you say, it works from the command line. the ruby script is calling the entire command string as a single command without any parameters. I suspect the first.


1

What does chkconfig postgresql report? You should be able to do chkconfig postgresql on as root in ubuntu to turn it on. see http://manpages.ubuntu.com/manpages/lucid/man8/chkconfig.8.html


1

At one point in the text boot process (press Esc if you get the graphical bootup instead) it will ask you to press I for interactive boot. Do so, then answer yes to every service other than local scripts.


1

The IP rules you displayed are not directly related to iptables. The ip command controls the advanced routing. Your system has setup something to do split routing. The iptables command controls firewall (netfilter) rules. iptables-save/iptables-restore doesn't really do anything directly with the routes and rules. See the Linux Advanced Routing & ...


1

@Redmumba is on the right path here. If you try to add iptables rules for interfaces that aren't configured/up yet, then iptables will throw an error and the rules doesn't get added. This sounds to me like you are configuring at least one of your interfaces through NetworkManager or something similar (depends on your distro) and that part only happens when ...



Only top voted, non community-wiki answers of a minimum length are eligible