I have a backup script that runs in the background daily on my linux (Fedora 9) computer. If the computer is shut down while the backup is in progress the backup may be damaged so I would like to write a small script that temporarily disables the ability of the user to reboot or shut the computer down.
It is not necessary that the script is uncirumventable, it's just to let the users of the system know that the backup is in progress and they shouldn't shut down. I've seen the Inhibit method on the DBus Free desktop power management spec:
http://people.freedesktop.org/~hughsient/temp/power-management-spec-0.3.html
but that only prevents shutdowns if the system is idle not explicitly at the users request.
Is there an easy way to do this in C/Python/Perl or bash?
Update: To clarify the question above, it's a machine with multiple users, but who use it sequentially via the plugged in keyboard/mouse. I'm not looking for a system that would stop me "hacking" around it as root. But a script that would remind me (or another user) that the backup is still running when I choose shut down from the Gnome/GDM menus
Another get-you-started solution: During shutdown, the system runs the scripts in /etc/init.d/ (or really, a script in /etc/rc.*/, but you get the idea.) You could create a script in that directory that checks the status of your backup, and delays shuts down until the backup completes. Or better yet, it gracefully interrupts your backup.
The super-user could workaround this script (with /sbin/halt for example,) but you can not prevent the super-user for doing anything if their mind is really set into doing it.
There is molly-guard to prevent accidental shutdows, reboots etc. until all required conditions are met -- conditions can be self-defined.
As already suggested you can as well perform backup operations as part of the shutdown process. See for example this page.
If users are going to be shutting down via GNOME/KDE, just inhibit them from doing so.
http://live.gnome.org/GnomePowerManager/FAQ#head-1cf52551bcec3107d7bae8c332fd292ec2261760
I can't help but feel that you're not grokking the Unix metaphor, and what you're asking for is a kludge.
If a user running as root, there's nothing root can do to stop root from shutting down the system! You can do window dressing things like obscuring shutdown UI, but that's not really accomplishing anything.
I can't tell if you're talking about this in the context of a multi-user machine, or a machine being used as a "desktop PC" with a single user sitting at a console. If it's the former, your users really shouldn't be accessing the machine with credentials that can shutdown the system for day-to-day activities. If it's the latter, I'd recommend educating the users to either (a) check that the script is running, or (b) use a particular shutdown script that you designate that checks for the script's process and refuses to shutdown until it's gone.
More a get-you-started than a complete solution, you could alias the shutdown command away, and then use a script like
#!/bin/sh
ps -ef|grep backupprocess|grep -v grep > /dev/null
if [ "$?" -eq 0 ]; then
echo Backup in progress: aborted shutdown
exit 0
else
echo Backup not in progress: shutting down
shutdown-alias -h now
fi
saved in the user's path as shutdown. I expect there would be some variation dependant on how your users invoke shutdown (Window manager icons/command line) and perhaps for different distros too.
But a script that would remind me (or another user) that the backup is still running when I choose shut down from the Gnome/GDM menus
One may use polkit to completely block shutdown/restart - but I failed to find method that would provide a clear response why it is blocked.
Adding the following lines as /etc/polkit-1/localauthority/50-local.d/restrict-login-powermgmt.pkla works:
[Disable lightdm PowerMgmt]
Identity=unix-user:*
Action=org.freedesktop.login1.reboot;org.freedesktop.login1.reboot-multiple-sessions;org.freedesktop.login1.power-off;org.freedesktop.login1.power-off-multiple-sessions;org.freedesktop.login1.suspend;org.freedesktop.login1.suspend-multiple-sessions;org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions
ResultAny=no
ResultInactive=no
ResultActive=no
You still see a confirmation dialog but there are not buttons to confirm. Looks ugly, but works ;)
Unfortunately this applies to all users, not only the lightdm session, so you have to add a second rule to white-list them if desired.
Note that this method block solely reboot/etc commands issued from GUI. To block reboot/etc commands from command line one may use molly-guard - as explained in https://askubuntu.com/questions/17187/disabling-shutdown-command-for-all-users-even-root-consequences/17255#17255
Related
How can I run a script in linux that can access kwallet, before the system goes to sleep?
Here I give more details:
I'm looking for a mechanism to execute a (user) script that runs before sleep/hibernate.
I initially tried a systemd (system) service, WantedBy suspend.target, hibernate.target, and hybrid-sleep.target.
The problem is that this service does not have access to kwallet since it is a system service (actually kwallet requires the user dbus context).
The next idea was to run a systemd user service. An user service has access to kwallet, but cannot be tied to suspend.target or any of the others mentioned before.
I've been later advised to use a logind inhibitor hook. From what I read, this mechanism can be used by programs for inhibiting or delaying the transition to sleep mode, until some code is executed. Much like a lock. However, I do not find a tutorial or example that does this kind of hook with a simple bash script. I would appreciate if somebody, could point me to some article, or give an example of how could I do this.
I've found a plausible solution for this problem, as suggested in the answer to this post.
The idea is to create systemd --user targets that are rised by listening to system events for sleep or lock, though dbus messages, and then use this targets to create another user service wanted by these targets. This has been implemented in this repository.
Initially, I was somewhat surprised by the absence of a systemd's native way to create user services wanted by system targets. But then, I realized my surprise was due to my ignorance of how systemd works. Systemd system services are executed by a single root process, while systemd user services run in separate user processes, and there is no straightforward way to link them together. With this understanding, the solution I found seams like a reasonable one.
I thank the people that read this post and gave a thought.
Suggesting to read this manual page:
https://www.man7.org/linux/man-pages/man8/systemd-sleep.8.html
Especially this section:
Immediately before entering system suspend and/or hibernation
systemd-suspend.service (and the other mentioned units,
respectively) will run all executables in
/usr/lib/systemd/system-sleep/ and pass two arguments to them. The
first argument will be "pre", the second either "suspend",
"hibernate", "hybrid-sleep", or "suspend-then-hibernate" depending on
the chosen action. An environment variable called
"SYSTEMD_SLEEP_ACTION" will be set and contain the sleep action that
is processing. This is primarily helpful for "suspend-then-hibernate"
where the value of the variable will be "suspend", "hibernate", or
"suspend-after-failed-hibernate" in cases where hibernation has
failed. Immediately after leaving system suspend and/or hibernation
the same executables are run, but the first argument is now "post".
All executables in this directory are executed in parallel, and
execution of the action is not continued until all executables have
finished.
root can runs scripts as other users
/tmp/test.sh
#!/bin/bash
echo "id: $(id)"
echo "home: $HOME"
echo "path: $PATH"
echo "logname: $(logname)"
echo "date: $(date)"
root runs /tmp/test.sh as user u24
sudo -u u24 /tmp/test.sh
output:
id: uid=1000(u24) gid=1000(u24) groups=1000(u24),4(adm),190(systemd-journal) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
home: /home/u24
path: /sbin:/bin:/usr/sbin:/usr/bin
logname: root
date: Mon Jun 6 08:28:08 UTC 2022
What append in Linux when the user type "halt" in? Is there any script that force process to end as soon as possible? If yes, is there any way to schedule process shutdown?
The purpose of this scheduler will be force GPIO management to be the last one to exit.
Thanks in advance
Depending init system it can force killing services. General way to shedule stop order is sorting "K*" links in /etc/rc.d/
To understand deeper first look in /etc/inittab at lines:
::shutdown:/etc/rc.d/rcS K shutdown
::shutdown:/bin/umount -a -r
In this example shutdown sheduled by /etc/rc.d/rcS script.
After typing halt init executes inittab rules, then killing himself with still live childrens. Then kernel stops CPU.
As i understand question, one of solution is:
remove stop link for gpio-management service
add script to ensure that gpio-sensible services stopped/killed to inittab
add script to stop gpio-management service at end
My team at work manages a few thousand compute hosts for several thousand users. We have a system in place that allows users to open a terminal "somewhere" in the farm, and keeping the workload level is an important part of it. We depend on being able to to process accounting for each terminal process that is started.
It's common for users to ask for xterm, dtterm, and gnome-terminal processes. gnome-terminal presents a unique challenge for us. When you start a "new" gnome-terminal process, if you already have an "old" gnome-terminal process running in the same user session on the same machine, the "new" process passes the shell command on to the "old" process, and the shell/window are created as part of the "old" process tree; and the "new" process exits. This causes us to have problems with our process accounting, for obvious reasons.
This default behavior of gnome-terminal can be stopped by giving the --disable-factory option. But there's no way we can train all our users (8000+) to remember to use this option every time they ask for a gnome-terminal process in the farm. We need to find a way to lock this down so that gnome-terminal always behaves as if the --disable-factory option is given.
Is there a way to configure this for all users, site-wide? We'd prefer not to "wrap" gnome-terminal with a script to inject the option at invocation time, if possible-- that would work, but it's difficult to maintain, and it could be brittle. Adding a key in some /etc/gconf file would be ideal, but I'm not sure what (if any) key would be honored by gnome-terminal...?
Any advice would be appreciated!
Thanks
The most painless way to do this would be using a configuration management tool to modify the gnome-terminal.desktop file to pass the --disable-factory option on the Exec= line. If you want to ensure this isn't affected by OS upgrades I think user specific .desktop files get processed before system ones, so copying this modified .desktop into either the local user's applications directory (or /etc/skel/) or moving the old one to a new different name might work.
I'm interested in how rebooting is implemented in Linux. When I press ctrl-alt-del or click "restart" in the menu bar, what happens next?
Thanks!
brings the system down in a secure way. All logged-in users are notified that the system is going down, and login(1) is blocked. It is possible to shut the system down immediately or after a specified delay. All processes are first notified that the system is going down by the signal SIGTERM.
It does its job by signalling the init process, asking it to change the runlevel. Runlevel 0 is used to halt the system, runlevel 6 is used to reboot the system, and runlevel 1 is used to put to system into a state where administrative tasks can be performed;
So basically reboot calls the "shutdown".
Quick answer is that all the scripts that are in /etc/rc6.d are executed.
scripts that start with "K" are executed with the "stop" parameter.
scripts that start with "S" are executed with the "start"parameter.
For more you can start reading about runlevels here: http://en.wikipedia.org/wiki/Runlevel
There are different init systems on Linux, and they also control what happens on restart/shutdown. See https://unix.stackexchange.com/questions/18209/detect-init-system-using-the-shell to tell which you're using.
If you're using SysVinit, then there is a runlevel associated with the overall system status. The init system will first run all the kill scripts associated with your current runlevel and then the start scripts associated with runlevel 6. If your current runlevel was 5, it would run /etc/rc5.d/K* and then /etc/rc6.d/S*. They might be in another directory, such as /etc/init.d/rc5.d/k*, depending on your Linux distribution.
If you're using systemd, then instead of having an overall "runlevel", there would be a list of defined targets and services. A list of targets is essentially a runlevel. These are defined in .service and .target files under /etc/systemd. There will likely be a "reboot.target" defined under there, and other services with a dependency on that will be run on reboot. See the systemd homepage or this stackexchange question for an example.
Some Ubuntu versions also use upstart, but I think it's been replaced by systemd in more recent versions. If you are using upstart, see this guide or this askubuntu question.
One thing to be careful of is that regardless of which init system you're using you may be using init scripts generally associated with another one. So you may be using sysVinit, but some of the rc*.d scripts may be links to things that invoke systemd scripts. Or vice-versa.
Are there "clean" ways of undeploying Etherpad on a (Windows Server 2003) server? Right now, I just use ctrl+c on the cygwin console or end the process on the Task Manager. I don't want to use TASKKILL /fi "imagename eq cmd*" since it can end other cmd processes as well. I plan to make a script to automate deployment and undeployment of Etherpad.
Regards
Etherpad was built to run on unix, and when you do a clean shutdown you'll notice a few lines about saving to disk etc being output.
You can make your .cmd or .bat script stay open after it finishes running, or add a line
pause
at the end of the script, and then you'll see if Ctrl-C causes a clean shutdown.
If you want to automate the shutdown, you'll need to find a windows software that can send the appropriate signals. Windows supposednly has some posix compatibility built in, so there's a fair chance you can find both the needed signal and some free/shareware to send the signal.
If this works out, maybe you could blog about your solution and/or add a wikipage on github.com/ether/pad/wiki
Otherwise, contact the etherpad team via github.com/ether/pad/issues and ask for a windows-compatible clean shutdown feature.