And now, the systemd answer.
You're using, per the tag on your question, Red Hat Enterprise Linux. Since version 7, that has used systemd. None of the other answers are correct for the world of systemd; nor even are some of the assumptions in your question.
Forget about runlevels; they exist, but only as compatibility shims. The systemd documentation ...
There is no difference in them. Internally they do exactly the same thing:
reboot uses the shutdown command (with the -r switch). The shutdown command used to kill all the running processes, unmount all the file systems and finally tells the kernel to issue the ACPI power command. The source can be found here.
In older distros the reboot command was forcing ...
You can do this directly from the shutdown command, see man shutdown:
/sbin/shutdown [-akrhPHfFnc] [-t sec] time [warning message]
time When to shutdown.
So, for example:
shutdown -h 21:45
That will run shutdown -h at 21:45.
For commands that don't offer this functionality, you can try one of:
A. Using at
The at daemon is ...
The suggested solution is to run the service unit as a normal service - have a look at the [Install] section. So everything has to be thought reverse, dependencies too. Because the shutdown order is the reverse startup order. That's why the script has to be placed in ExecStop=.
The following solution is working for me:
Anyone can execute shutdown, but triggering a system shutdown requires root privileges. But shutdown is not setuid, and so only root can successfully execute it. The shutdown program is nice enough to check your privileges and let you know if there is a problem, but even if it naively tried a system shutdown, nothing would happen.
GLENDOWER: I can call ...
There are a several options.
Provide time directly to shutdown -P:
shutdown -P +60
Note that shutdown man page also points out:
If the time argument is used, 5 minutes before the system goes down the /run/nologin file is created to ensure that further logins shall not be allowed.
Use at command.
Create a systemd unit file or init script which runs ...
Warning: by the end of this answer you'll probably know more about linux than you wanted to
Why reboot and poweroff require root privileges
GNU/Linux operating systems are multi-user, as were its UNIX predecessors. The system is a shared resource, and multiple users can use it simultaneously.
In the past this usually happened on computer terminals ...
In the 1980s, the BSDs had halt, reboot, and shutdown. System 5 UNIX had a BSD compatibility toolset. But natively it had its own, different, shutdown command; and didn't have halt or reboot at all. (Some System 5 variants had things like SCO XENIX's haltsys.)
The BSD halt and reboot commands were low-level, drastic, and immediate. The ...
A workaround to this problem is to reduce this timeout in /etc/systemd/system.conf down from 90s to for example 10s:
and run the following command in terminal after making changes
$ systemctl daemon-reload
at 18:00 shutdown now creates an "at" job, which is performed at the specified time by the at daemon or perhaps the cron daemon, depending on your system.
shutdown 18:00 starts a process in your shell that waits until the specified time and then performs the shutdown. This command can be terminated if e.g. your shell session is terminated.
The net result ...
Linux has its origins in Unix and Unix was initially developed as a multi-user operating system. You could have one user disrupt other users by wanting to reboot the system. Only the administrator with root privileges could do that.
Linux Mint is based on Ubuntu, so I'm guesing the runlevel system is probably the same. On Ubuntu, scripts for the different runlevels are executed according to their presence in the /etc/rc[0-6].d directories. Runlevel 0 corresponds to shutdown, and 6 to reboot.
Typically the script itself is stored in /etc/init.d, and then symlinks are placed in the ...
You should use the at command:
$ sudo at 6:45
[sudo] password for root:
warning: commands will be executed using /bin/sh
Don't type the <EOT>, but press Ctrl+D at the second at> prompt.
The significant advantage of using at over using shutdown with a TIME argument, is that it involves real, persistent, ...
Its quite natural and a policy matter and convenience, it had been allowed from GUI because you are physically logged in to the machine. ( Some Linux distributions will still ask you for password if the GUI is not running as root , I am using Centos 6 and there is even no GUI shutdown/reboot option for my user , there is only log out and lock option)
From a ...
systemd operates internally in terms of a queue of "jobs". Each job (simplifying a little bit) is an action to take: stop, check, start, or restart a particular unit.
When (for example) you instruct systemd to start a service unit, it works out a list of stop and start jobs for whatever units (service units, mount units, device units, and so forth) are ...
This looks like an XY problem.
My tasks take usually no more than 15 minutes. I would like to implement a mechanism to shutdown it automatically after 60 minutes.
If you shut down after 60 minutes, you run the risk that you may be running a particularly complicated problem and just need to have more time. Many of the previous solutions would not make it ...
You have to examine 2 things:
The output of last -x command
The log files in /var/log/
Use these 2 commands and keep reading for more information.
last -x | head | tac
grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \
/var/log/messages /var/log/syslog /var/log/apcupsd* \
It doesn't get much faster than using the System Request (SysRq) functionality and then triggering an immediate reboot.
This is a key combination understood by the kernel.
echo 1 > /proc/sys/kernel/sysrq
Now, send it into reboot.
echo b > /proc/sysrq-trigger
b - Immediately reboot the system, without unmounting or syncing ...
The main resources to understand how the Linux kernel works are:
Linux Weekly News articles.
The source. This is a complex beast which is a little easier to apprehend through LXR, the Linux cross-reference. The LXR variant running on lxr.linux.no is nicer than others, but it's often down.
In this case, I can't find anything centrally ...
It's a bit historical.
halt was used before ACPI (which today will turn off the power for you)*. It would halt the system and then print a message to the effect of "it's ok to power off now". Back then there were physical on/off switches, rather than the combo ACPI controlled power button of modern computers.
poweroff, naturally will halt the system and ...
No you can't specify a date at the shutdown command but two alternatives exist:
1) The easiest is to use the at command. The following example will execute shutdown +5 at a specific time and day:
echo "shutdown +5" | at 10:05am 2019-01-19
2) if you don't mind using you calculator and want to shutdown in say 24hours (24*60=1440 minutes) and you're ...
halt instructs the hardware to stop all CPU functions, but leaves it in a powered-on state. This usually means someone has to reboot or shut the machine down manually by pressing the power button afterwards. The specific way to achieve this is architecture specific, but for instance the x86 instruction set provides the HLT instructions which halts the ...
You can run it with the timeout command,
timeout - run a command with a time limit
timeout [OPTION] NUMBER[SUFFIX] COMMAND [ARG]...
Start COMMAND, and kill it if still running after NUMBER seconds. SUFFIX may be 's' for seconds (the default), 'm' for minutes, 'h' for hours or 'd' for days.
PS. If your sync process ...
I changed /etc/sudoers so that every user that is in the admin group can execute the following commands without being ask for a password.
You just need to add the following lines to /etc/sudoers
## Admin user group is allowed to execute halt and reboot
%admin ALL=NOPASSWD: /sbin/halt, /sbin/reboot, /sbin/poweroff
And now, the systemd answer.
If you have CentOS 7, you have a systemd operating system and the answer is different.
at 18:00 shutdown now still schedules via the at subsystem, but that shutdown command, as well as the one that you invoke directly with shutdown 18:00, is different. It's actually systemd's systemctl program. systemctl does things ...
If you execute your tasks as the same user every time, you can simply add the shutdown command, optionally with the option -P, to your profile. The number stands for the amount of minutes the shutdown command is delayed.
Make sure your user has the ability to execute the shutdown command via sudo without a password.
echo "sudo shutdown -P +60" >> ~/....
Every process has a directory named according to its process id (pid) in the proc filesystem. Therefore you can wait for a specific process' termination by checking whether its directory exists repeatedly.
You can use this to perform a system shutdown after process termination like this (replace 2296 by the pid to wait for):
su -c 'while [[ -d /proc/2296 ]]...
This problem can have many causes, so specific answers don't work too well. Try this for troubleshooting:
wait for the "A stop job is running for Session c2 ..." message to appear on shutdown and reboot after shutdown has completed
run journalctl -p5 in a terminal and press END to get to the end of the systemd journal (-p5 filters out a lot of garbage)
For newer systems with systemd this has been solved by systemd-inhibit. Example of usage:
systemd-inhibit --why="Doing weekly backup" bash my-backups.sh
Then, if a user attempts to shutdown it will not be allowed unless forced.
❯ systemctl poweroff
Operation inhibited by "bash my-backups.sh" (PID 2414 "systemd-inhibit", user ntrrgc),
reason is "Doing ...