Hot answers tagged runlevel
As per man inittab: The /etc/inittab file was the configuration file used by the original System V init(8) daemon. The Upstart init(8) daemon does not use this file, and instead reads its configuration from files in /etc/init. See init(5) for more details. If you look into /etc/init/rc-sysinit.conf you should find a line similar to this: # ...
This should do the trick : update-rc.d apache2 disable Basically update-rc.d will modify existing runlevel links for the script /etc/init.d/apache2 by renaming start links to stop links. If you wanted to disable only runlevel 2 and 5, you could do : update-rc.d apache2 disable 2 5 nico
This is what they mean: 0 Halt 1 Single-User mode 2 Multi-user mode console logins only (without networking) 3 Multi-User mode, console logins only 4 Not used/User-definable 5 Multi-User mode, with display manager as well as console logins (X11) 6 Reboot So, when specifying a runlevel in chkconfig, you tell the service if it should be on or ...
If you look at the "chkconfig" line of /etc/init.d/network you'll see that the network has a start priority of "10". /etc/init.d/yourscript: #!/bin/bash # # yourscript short description # # chkconfig: 2345 9 20 # description: long description case "$1" in start) Do your thing !!! chkconfig yourscript off ;; ...
sysv-rc-conf is the new way to do this job.
Ubuntu uses the upstart init daemon which by default boots to (an equivalent of?) runlevel 2. If you want to change the default runlevel then create an /etc/inittab with an initdefault entry for the runlevel you want. :id:3:initdefault: would bring the system up to runlevel 3. An article on it here
The issue he is actually caused by Upstarts flexibility in handling both Upstart jobs and SystemV services on Ubuntu. For information on events, a good place to look is the man pages on your system. If you're running Ubuntu Natty or newer, you'll now have upstart-events(7): man 7 upstart-events This gives you a lot of information. Here's an online ...
I'm guessing that the issue here is that checkconfig checks the old style init scripts, and you have a new upstart init script. Go to /etc/init/mysql.conf and change start on (net-device-up and local-filesystems) to start on runlevel [!0123456] If you need to start it manually service mysql start will do the trick. This thread on ubuntu forums goes into ...
First of all, /home/servidor/apache is not an adequate path for an executable in a server. Use the /usr/local hierarchy for locally compiled packages. That is the default option, you should not change it. With regards to the init script, adapt the one distributed with your distro to your needs. Just download the RPM and extract the /etc/init.d/apache2 file. ...
I recommend a different approach, which will address the start-on-boot issue, as well as make Nginx easier to manage on Ubuntu in the future. Set yourself up with the official Nginx Ubuntu PPA. I presume you are customizing some compile-time options, for the pre-built binaries won't work for you. So instead, use some commands to download the package ...
Post the full script. Your shebang line, "#!/bin/sh -e" will exit on error. If the error condition is met before your debug output / lines run, you won't see them. Alternately, remove the '-e' option and retry your script.
Per the chkconfig(8) manpage, it favors LSB Required-Start and Required-Stop over the # chkconfig: line, if it is available: Note that default entries in LSB-delimited 'INIT INFO' sections take precedence over the default runlevels in the initscript; if any Required-Start or Required-Stop entries are present, the start and stop priorities of the script will ...
I look at the runlevels in this way: S - true single user mode usually drops you into a minimal root shell 1 - Administrative mode, you get a standard login request before access 2 - Multi-user without TCP/IP networking -- could use serial ports for other logins 3 - Multi-user with TCP/IP networking and text 4 - To be determined by the system owner 5 ...
If you do not have backups, you could try installing rcconf and see if it will re-create the links. But in reality all Debian init files would have following information at the top of each script: ### BEGIN INIT INFO # Provides: inetd # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Should-Start: $syslog # ...
You can remove symblinks by hands, there is no problem to do that this way if you know what you are doing.
update-rc.d -f apache2 remove
You should perform a ps aux to see if any of the shutdown scripts are hung waiting for a process to finish. It should look something like this: /etc/rc6.d/K##procname You can try manually issuing a kill command for that hung script. Strange though, since there's a timeout set on the scripts where it will force a -KILL signal to any leftover process. ...
Simple answer: Stick it in /etc/init.d (symlinked to /etc/rc#.d) & the first thing it does is check for a file's presence: If the file exists the script has already run (so exit). If not, run the script and touch the file. This also lets you delete the file to force the script to run again later.
sudo update-rc.d -f gdm remove
I'm fairly sure you can't boot an EC2 instance to rescue mode or single user mode. If it's an EBS backed instance then you can attach the EBS root volume to another instance and access it that way. Failing that you may have to use AWS premium support.
Only top voted, non community-wiki answers of a minimum length are eligible