Hot answers tagged

85

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 -...


49

For Red Hat systems, there is no functional difference between reboot and shutdown -r now. Do whatever is easier for you.


34

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/...


33

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 ...


26

So set it up to start at boot: chkconfig php-fpm on


17

No - they go to STDOUT (if you use echo) or STDERR (if you use echo >&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 can ...


17

The correct answer for this was that for proper "daemonization", standard input, standard output and standard error need to be redirected to /dev/null (or some real file): su someuser -c "nohup some_script.sh >/dev/null 2>&1 &" su - substitute user identity to someuser -c - su argument to run specified command nohup - Run a command immune to ...


16

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.


15

Files in /etc/profile.d/ are run when a user logs in (unless you've modified /etc/profile to not do this) and are generally used to set environment variables.


15

For me it was easier to just add the init info block in the header as suggested here: #!/bin/sh ### BEGIN INIT INFO # Provides: solr # Required-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: solr # Description: solr ### END INIT INFO Then, execute sudo systemctl enable solr.


13

As we have compiled PHP we should, I hope, still have source code. In the source code for PHP they very graciously included an init script for PHP-FPM. You can find it in <phpsrcdir>/sapi/fpm/init.d.php-fpm. You can copy this file directly with cp <phpsrcdir>/sapi/fpm/init.d.php-fpm /etc/init.d/php-fpm and then chmod it to make it executable ...


13

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.


12

Debian will eventually have systemd, so this is the way to do it on a Linux system which uses systemd (and many do already; you might consider switching distributions). Systemd can handle keeping the service alive for you automatically; no other tools are required. Simply make sure that Restart=always is set in the service file's [Service] section. # vi /...


12

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.


11

I put the following into /etc/init.d/pwrstatd: #!/bin/sh ### BEGIN INIT INFO # Provides: pwrstatd # Required-Start: udev # Required-Stop: # Should-Start: # Default-Start: 2 3 4 5 # Default-Stop: # Short-Description: PowerPanel to monitor CyberPower UPS ### END INIT INFO It seemed to make sense to make it rely on udev. To verify that this ...


11

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 if ...


11

I ended up creating a wrapper script for the openconnect, which loads the password and pipes it to the stdin of the openconnect daemon, IOW: #!/bin/bash PASSWD=`/bin/cat /etc/openconnect/passwd` /bin/echo $PASSWD | /usr/sbin/openconnect $@ And start-stop-daemon invokes this wrapper instead of the openconnect.


10

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.


10

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


10

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 or ...


9

Write a wrapper script that calls your script and redirects the output to a files #!/bin/bash /path/to/your/script &>/path/to/logfile


9

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 ...


9

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


9

Using reboot is safer. Using reboot your intent is clear and there is no way to mistype it for something else like shutdown -t now which could leads to a few headache if you are using on a remote server with limited control.


8

$ sudo update-rc.d -f servicename remove


8

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 ...


7

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 (...


7

Another solution to use the solr legacy init script with systemd: systemctl daemon-reload systemctl enable solr systemctl start solr


6

You could make a function to echo the message to both the screen and to syslog, something like this: LOGGER="/usr/bin/logger -t $myScript" # check the location of logger for your system myEcho () { echo "$1" $LOGGER "$1" } You could also put that into a separate file and include it into your scripts with #!/bin/bash myScript=$(basename $0) [ -...


6

I use those for Sick Beard and SabNZBd, two python/cherrypy apps. The difference is knowing when to use 'forking'. That basically tells systemd that the main binary will fork stuff so it has to guess the PID from a file. WantedBy is just to define the target that will require this to start, think it as runlevel. You will notice also that the second ...


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