Shell Script to Shutdown/Restart Linux System

shell script to shutdown/restart Linux system

Yes, use the -S switch which reads the password from STDIN:

$echo <password> | sudo -S <command>

So to shut down the machine, your command would be like this (just replace <password> with your password):

$echo <password> | sudo -S poweroff

Exposing your password is generally bad idea search for something that can protect / hide it. In the past I've used Jenkins plugins to do this while executing the scripts regularly.

how to use linux reboot function in C for shutdown Linux(Ubuntu) system?

For a large number of reasons, it is better to power off the machine using e.g.

execl("/bin/shutdown", "shutdown", "-P", "now", (char *)0);

or reboot using

execl("/bin/shutdown", "shutdown", "-r", "now", (char *)0);

There is no shell involved at all. The current process is replaced by the shutdown system management command, which already has the necessary privileges if the user the process is running has is allowed to shutdown or reboot the machine.

(That is, code following the above statement is not executed at all, except if the system utility is missing. It will be there on any functioning system, even embedded ones.)

You can even replace the "now" with a fixed string like "+1m", to shutdown or reboot after one minute has elapsed. (During that time, everything else will continue running normally. Running shutdown with just a -c parameter during that period will cancel the pending shutdown/reboot.)

If you do this from a GUI application, only do it where a normal program would either return from main(), or exit().

---

What are those reasons?

Simplicity, robustness, the principle of least surprise, proper management of privileges for shutdown/reboot, not requiring special privileges and thus reduced threat surface (bugs in your program less likely to grant special privileges, because there are none). For starters.

How can I trigger a delayed system shutdown from in a shell script?

No need to create a second BASH script to run the shutdown command. Just replace the following line in your backup script:

bash -c "nohup /sbin/shutdown -h 10" &

with this:

echo "/sbin/poweroff" | /usr/bin/at now + 10 min >/dev/null 2>&1

Feel free to adjust the time interval to suit your preference.

How do I run a Bash script before shutdown or reboot of a Raspberry Pi (running Raspbian)?

As it turns out, part of the shutdown command has already executed (and unmounted the filesystem) before these scripts are executed.

Therefore, mounting the filesystem at the start of the script and unmounting it at the end is necessary.

Simply add:

mount -oremount,rw /

...at the start of the script (beneath the #!/bin/bash)

...then have the script's code...

and then finish the script with:

mount -oremount,ro /

So, the OP script should become:

#!/bin/bash
mount -oremount,rw /
touch /home/pi/ShutdownFileTest.txt
mount -oremount,ro /

...that then creates the file /home/pi/ShutdownFileTest.txt just before shutdown/reboot.

---

That said, it may not be best practice to use this method. Instead, it is better to create a service that runs whenever the computer is on and running normally, but runs the desired script when the service is terminated (which happens at shutdown/reboot).

This is explained in detail here, but essentially:

1: Create a file (let's call it example.service).

2: Add the following into example.service:

[Unit]
Description=This service calls shutdownScript.sh upon shutdown or reboot.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStop=/home/pi/shutdownScript.sh

[Install]
WantedBy=multi-user.target

3: Move it into the correct directory for systemd by running sudo mv /home/pi/example.service /etc/systemd/system/example.service

4: Ensure the script to launch upon shutdown has appropriate permissions: chmod u+x /home/pi/shutdownScript.sh

5: Start the service: sudo systemctl start example --now

6: Make the service automatically start upon boot: sudo systemctl enable example

7: Stop the service: sudo systemctl stop example

This last command will mimic what would happen normally when the system shuts down, i.e. it will run /home/pi/shutdownScript.sh (without actually shutting down the system).

You can then reboot twice and it should work from the second reboot onwards.

EDIT: nope, no it doesn't. It worked the first time I tested it, but stopped working after that. Not sure why. If I figure out how to get it working, I'll edit this answer and remove this message (or if someone else knows, please feel free to edit the answer for me).

How do I write a bash script to restart a process if it dies?

Avoid PID-files, crons, or anything else that tries to evaluate processes that aren't their children.

There is a very good reason why in UNIX, you can ONLY wait on your children. Any method (ps parsing, pgrep, storing a PID, ...) that tries to work around that is flawed and has gaping holes in it. Just say no.

Instead you need the process that monitors your process to be the process' parent. What does this mean? It means only the process that starts your process can reliably wait for it to end. In bash, this is absolutely trivial.

until myserver; do
    echo "Server 'myserver' crashed with exit code $?.  Respawning.." >&2
    sleep 1
done

The above piece of bash code runs myserver in an until loop. The first line starts myserver and waits for it to end. When it ends, until checks its exit status. If the exit status is 0, it means it ended gracefully (which means you asked it to shut down somehow, and it did so successfully). In that case we don't want to restart it (we just asked it to shut down!). If the exit status is not 0, until will run the loop body, which emits an error message on STDERR and restarts the loop (back to line 1) after 1 second.

Why do we wait a second? Because if something's wrong with the startup sequence of myserver and it crashes immediately, you'll have a very intensive loop of constant restarting and crashing on your hands. The sleep 1 takes away the strain from that.

Now all you need to do is start this bash script (asynchronously, probably), and it will monitor myserver and restart it as necessary. If you want to start the monitor on boot (making the server "survive" reboots), you can schedule it in your user's cron(1) with an @reboot rule. Open your cron rules with crontab:

crontab -e

Then add a rule to start your monitor script:

@reboot /usr/local/bin/myservermonitor

---

Alternatively; look at inittab(5) and /etc/inittab. You can add a line in there to have myserver start at a certain init level and be respawned automatically.

---

Edit.

Let me add some information on why not to use PID files. While they are very popular; they are also very flawed and there's no reason why you wouldn't just do it the correct way.

Consider this:

1. PID recycling (killing the wrong process):

   • /etc/init.d/foo start: start foo, write foo's PID to /var/run/foo.pid
   • A while later: foo dies somehow.
   • A while later: any random process that starts (call it bar) takes a random PID, imagine it taking foo's old PID.
   • You notice foo's gone: /etc/init.d/foo/restart reads /var/run/foo.pid, checks to see if it's still alive, finds bar, thinks it's foo, kills it, starts a new foo.

2. PID files go stale. You need over-complicated (or should I say, non-trivial) logic to check whether the PID file is stale, and any such logic is again vulnerable to 1..

3. What if you don't even have write access or are in a read-only environment?

4. It's pointless overcomplication; see how simple my example above is. No need to complicate that, at all.

See also: Are PID-files still flawed when doing it 'right'?

By the way; even worse than PID files is parsing ps! Don't ever do this.

1. ps is very unportable. While you find it on almost every UNIX system; its arguments vary greatly if you want non-standard output. And standard output is ONLY for human consumption, not for scripted parsing!
2. Parsing ps leads to a LOT of false positives. Take the ps aux | grep PID example, and now imagine someone starting a process with a number somewhere as argument that happens to be the same as the PID you stared your daemon with! Imagine two people starting an X session and you grepping for X to kill yours. It's just all kinds of bad.

If you don't want to manage the process yourself; there are some perfectly good systems out there that will act as monitor for your processes. Look into runit, for example.

---

Related Topics