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
Related
So we have a 3rd party process running intermittently which needs to shutdown gracefully. This process has a file present (lets call it /tmp/process1) when running. Is there anyway I can modify the standard linux shutdown process so that if this file is present the shutdown will be aborted (or delayed)?
Thanks
You need to look into the Linux shutdown process.
You will need to add the shutdown script for this 3rd party process to the appropriate run-levels.
This can also be used to start the process automatically on start.
Just create a wrapper script named shutdown, and make sure it invokes the original which shutdown by its full path and that it's in a directory that overrides the directory of the original shutdown in $PATH (e.g., in /usr/local/sbin; see echo $PATH).
A common Linux/UNIX idiom when it comes to running daemons is to spawn the daemon, and create a PID file which just contains the process ID of the daemon. This way, to stop/restart the daemon you can simply have scripts which kill $(cat mydaemon.pid)
Now, there's a lot of opportunity here for inconsistent state. Suppose the machine running the daemon is forcefully shut off, then restarted. Now you have a PID file which refers to a non-existent process.
Okay, so no problem... your daemon will just try to kill the non-existent process, find that it's not a real process, and continue as usual.
But... what if it is a real process - just not your daemon? What if it's someone else's process, or some other important process? You have no way of knowing - so killing it is potentially dangerous. One possibility would be to check the name of the process. Of course, this isn't foolproof either because there's no reason another process might not have the same name. Especially, if for example, your daemon runs under an interpreter, like Python, in which case the process name will never be something unique - it will simply be "python", in which case you might inadvertently kill someone else's process.
So how can we handle a situation like this where we need to restart a daemon? How can we know the PID in the pid file necessarily is the daemon?
You just keep adding on layers of paranoia:
pid file
process name matching
some communication channel/canary
The most important thing that you could to in order to ensure that the pid isn't stale following a reboot is to store it in /var/run, which is a location that is guaranteed to be cleared every reboot.
For process name matching, you can actually redefine the name of the process at the fork/exec point, which will allow you to use some unique name.
The communication channel/canary is a little more complex and is prone to some gotchas. If a daemon creates a named socket, then the presence of the socket + the ability to connect and communicate with the daemon would be considered evidence that the process is running.
If you really want to provide a script for your users, you could the let the daemon process manage its pidfile on its own and add an atexit and a SIGABRT handler to unlink the pidfile even on unclean shutdown.
More ways include also storing the process startup time in the pidfile. Together with volatile storage (e.g. /var/run) this is a pretty reliable way to identify a process. This makes the kill command a bit more complicated though.
However, I personally think that a daemon developer should not care (too much) about this and let this being handled by the target platforms way to manage daemons (systemd, upstart, good ol’ SysV init scripts). These have usually more knowledge: systemd for example will happily accept a daemon which does not fork at all, allowing it to monitor its status directly and without the requirement for a PID file. You could then provide configuration files for the most common solutions (currently probably systemd, given that Debian migrates to it too and it will thus also hit ubuntu soon), which are usually easier to write than a full fledged daemon process management.
I want to make a process alive during reboot. I am thinking that, I can backup all process related information and i will store it on some file. After reboot i will take that data back and by using that i will create a process again. Is my thinking is correct? Please clarify.
Your question is too vague. Can you provide with more information? I can give a basic outline of what is required to run a process on system startup.
Deamonize
A process must be a deamon (it shouldn't run in the context of a terminal) Read deamon process for more information.
chkconfig
Use this to add your deamon to your system startup run levels. sudo chkconfig deamon_name on
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.
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