Re: Schedule for Monday's FESCo Meeting (2012-06-18)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 22.06.12 08:56, Simo Sorce (simo@xxxxxxxxxx) wrote:

> On Fri, 2012-06-22 at 13:38 +0100, Richard Hughes wrote:
> > On 22 June 2012 12:40, Michal Hlavinka <mhlavink@xxxxxxxxxx> 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

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux