Hot answers tagged init.d
Shutdown is preferable because it allows you to specify the reason for the drastic action -- something you should always do. The message will be recorded in the log(s) for posterity. For example: shutdown -r now 'Kernel upgrade requires reboot' You can also perform a scheduled reboot -- by specifying something other than now as the reboot time: shutdown -...
For Red Hat systems, there is no functional difference between reboot and shutdown -r now. Do whatever is easier for you.
You want to remove the passphrase from a key file. Run this: openssl rsa -in key.pem -out newkey.pem Be aware that this means that anyone with physical access to the server can copy (and thereby abuse) the key.
There are a couple ways. If you just want to do this temporarily, you can remove the execute bit from the file: $ chmod -x /etc/init.d/varnish Then re-add it when appropriate: $ chmod +x /etc/init.d/varnish The "official" way in Ubuntu (as well as in Debian and other Debian derivatives), though, is to use the update-rc.d command: $ update-rc.d varnish ...
I've been guilty of removing the passphrase from my own key files in the past, because it's the simplest solution, but security-wise, it's not the best idea. An alternative is to feed the passphrase to Apache. You can do this with the SSLPassPhraseDialog option in your httpd.conf (or another file that it includes). If you only have one SSL site on your ...
Use chkconfig: chkconfig --level 345 mysqld on
So set it up to start at boot: chkconfig php-fpm on
If you take a look, in RHEL 7 both /sbin/shutdown and /sbin/reboot are actually just symlinks to systemd's systemctl command. So, use whatever you want. No functional difference as ewwhite told, not even in earlier RHEL releases which did not yet use systemd.
Seriously, a systemd unit file is trivial to write for a service like this...or for most services. This ought to get you about 95% of the way there. Put this in, for example, /etc/systemd/system/solr.service [Unit] Description=Apache Solr After=syslog.target network.target remote-fs.target nss-lookup.target [Service] Type=simple EnvironmentFile=/etc/...
1.: No - they go to STDOUT (if you use echo) or STDERR (if you use echo >&2). 2.: Your scripts have to write to logs and/or syslog on their own (your distribution might contain some init.d-functions that might help there - add your Distribution to your question). If you go for logs look for the tee command. If you go for syslog look at logger. You ...
First of all, init scripts are supposed to be run sudo /etc/init.d/name when you are not logged in as root( when logged-in user is sudo enabled) Secondly, when you run sudo /etc/init.d/nginx start ==> it fires the master nginx process as root and worker processes as the user you specified in your nginx.conf user directive(eg. www-data) Can you confirm ...
I don't see a problem with it, if you know, for sure, that the Python interpreter will be available when the init.d script is being run. This, to me, indicates that you're looking at something being done relatively late in a multi-user (or "graphic console") run-level. However... This means that a specific version of the Python interpreter MAY be vital for ...
The best way to go for it are the daemontools. They allow you to monitor and respawn processes. See the documentation on their website: http://cr.yp.to/daemontools.html
supervise is a lightweight, efficient alternative. Under debian it is packaged in daemontools. You can also read this related question, which lists some supervise criticisms, and mentions restartd as another possibility. Finally, if you want something incredibly easy to setup, I've had great success with monit. It is also packaged in Debian.
Yes. There are issues of availability, speed, reliability, maintainability, etc, but init scripts can be written in whatever you want. As is implied in your question, the /usr filesystem must be mounted before you can use the interpreters residing on it. There are Perl modules for just this task. One example is Daemon::Control, there are many more for ...
I'd say #2, but very close to #1 -- "Bad. Bad. Bad. Never do this." The standard, such as it is, for Linux init scripts is in the LSB, and while it never comes out and says "these are bourne shell scripts", several assumptions are made. One, that lines beginning with # are comments, happens to work out fine. More problematic is the requirement that the init ...
You can just su. You won't need the password because the script will initally be running as root. There's also the runuser command. If you use /etc/init.d/functions you can use the daemon function which has an option for specifying the user to run as. I'd personally sway towards the latter all other things being equal.
xbindkeys needs a running X server to work which isn't available at that stage of starting your system. You should add xbindkeys to your .xinitrc (see man page xinit(1)) or .Xsession (see man page Xsession(5)) instead.
Write a wrapper script that calls your script and redirects the output to a files #!/bin/bash /path/to/your/script &>/path/to/logfile
Putting a file readable only by root somewhere into /etc is a technique I've come across a few times at least in Debian (dbconfig-common does that, for example). Sourcing a file with plain passwords belonging to root sounds like quite a good idea to me, given the fact that init runs as root and there's already a lot of sensitive files in /etc anyway (...
See the man page for update-rc.d. To stop a service from running at boot: update-rc.d -f servicename remove Or: update-rc.d servicename stop 20 2 3 4 5 . If you have Debian squeeze or later, or Ubuntu 12.10 or later: update-rc.d servicename disable To allow a service to run at boot: update-rc.d servicename defaults If you have Debian squeeze ...
Initscripts are responsible for setting an appropriate path themselves. Set the $PATH variable at the top of the script: PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin
I agree that your solution seems a bit complex, so I'll go with "give me some idea how this could be implemented in an entirely different way" :-) The standard solution for this is to use a configuration management system, such as puppet, and allow users to add their stuff to the puppet config for the server. Puppet will then push out the start script and ...
I found that the function was sourced from /lib/lsb/init-functions in the nginx init script. So adding: . /lib/lsb/init-functions To my init script solved the problem.
A "sudo: parse error in ..." originating from /etc/sudoers or any of the files included with either the #include <filename> or #includedir <path> directives may be caused by a missing new-line on the last entry in that file.
If you run the script at boot time, when no one is logged in, how could it modify anything in the user's session? :-) You should run it from your .bash_profile startup script (or from /etc/profile, to run it for every user in the system).
Correct stop: start-stop-daemon --stop --oknodo --pidfile $PIDFILE
Passing 1 on the kernel line in the bootloader should start it in single user mode, which should not start the initscript unless it is severely broken. If booting into single mode does not work then you will need to get the install disc and boot into rescue mode using it.
As Ignacio suggested, the simplest solution is to boot into single user mode. To do this press any key on the countdown splash screen before it boots into the kernel. From here highlight the proper kernel and press e. Press e again to edit the cmdline and at the end at either S, s, single, or 1. Press return and then b to boot. This won't run your init ...
Depending on your Linux distro and release, ultimately sysvinit scripts (those scripts in /etc/init.d/) are generally run from the symlinks which exist in /etc/rc[0-6S].d, by /etc/init.d/rc. Under Ubuntu, you're either using old-style sysvinit, or more recently, upstart. Under the upstart management directory (/etc/events.d/) you'll find a legacy mode that ...
Only top voted, non community-wiki answers of a minimum length are eligible