Schedule for Monday's FESCo Meeting (2012-06-18)
mzerqung at 0pointer.de
Fri Jun 22 14:27:45 UTC 2012
On Fri, 22.06.12 08:56, Simo Sorce (simo at redhat.com) wrote:
> On Fri, 2012-06-22 at 13:38 +0100, Richard Hughes wrote:
> > On 22 June 2012 12:40, Michal Hlavinka <mhlavink at redhat.com> wrote:
> > > Well, there is difference between inhibited reboot and "are you really sure
> > > you want to reboot and break your system" questions.
> > Is that a joke? [Click here to break your system] is never a good idea.
> > > Anyway, what would happen when user press power button or ctrl-alt-delete in
> > > yum-update-in-extra-target case? Would it shutdown/reboot (breaking the
> > > system) or would it ignore the request?
> > If the required systemd features land in time, it would ignore the
> > ctrl-alt-del when the package manager is locked.
> Oh well, in one of may VMs half of the time systemd ignores my requests
> for reboot anyway ...
Hmm, did you file a bug?
> How do we make sure that if package manager goes crazy the user still
> have a way to reboot his system that is not 'press power button for 5
> seconds' ?
If you have a shell then systemd actually offers you tree ways to reboot
the system, depending on how tough you think you are:
# systemctl reboot
This does the normal clean reboot, stops all services cleanly, ...
# systemctl reboot -f
This does not stop all services cleanly, simply kills all processes with
SIGTERM and after a short timeout with SIGKILL, but it does try to
unmount/detach all file systems/storage devices/swaps/... and the
reboots. This is something like a "yes, i want it know, but i don't like
fsck delaying my next boot".
# systemctl reboot -ff
This is the super hardcore reboot. It just invokes the reboot() system
call immediately. Your file systems are likely to be dirty on the boot.
During the update process you will find that the usualy gettys are
available on tty[2-6].
Now, the way how the btrfs snapshotting should be implemented should
probably be something like this:
a) make a snapshot of the fs, and make it where all changes from now on
are written to, but do not make it the default snapshot to be mounted
for the next boot.
b) make the updates
c) if the update succeeded make the previously created snapshot the new
default, otherwise just drop it.
The result of this will be that the OS will either be in the old state,
or in the new state, but not in half-way state. This should also allow
the user to hard reboot any time without any ill-effect.
Lennart Poettering - Red Hat, Inc.
More information about the devel