10:10 p.m.
Yesterday, I had no problem writing to a USB device.
Today, with the latest batch of updates (including
selinux-policy-targeted), I could not write to a USB drive. I was under
the gun to get something out, so I rebooted and USB writing worked.
Just a bit of a glitch, but an inconvenience. It takes a bit of work to
get everything set up again.
10:46 p.m.
On 06/01/18 11:10, Robert Moskowitz wrote:
Yesterday, I had no problem writing to a USB device.
Today, with the latest batch of updates (including selinux-policy-targeted), I
could not write to a USB drive. I was under the gun to get something out, so I
rebooted and USB writing worked.
Just a bit of a glitch, but an inconvenience. It takes a bit of work to get
everything set up again.
So, the takeaway from this is "never do updates when under the gun to get something
done"?
Also, it is a good practice to run "tracer" as root to see what it suggests.
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
4:40 a.m.
On 05/31/2018 11:46 PM, Ed Greshko wrote:
On 06/01/18 11:10, Robert Moskowitz wrote:
> Yesterday, I had no problem writing to a USB device.
>
> Today, with the latest batch of updates (including selinux-policy-targeted), I
> could not write to a USB drive. I was under the gun to get something out, so I
> rebooted and USB writing worked.
>
> Just a bit of a glitch, but an inconvenience. It takes a bit of work to get
> everything set up again.
So, the takeaway from this is "never do updates when under the gun to get something
done"?
:)
Also, it is a good practice to run "tracer" as root to see
what it suggests.
I will make a note for the future about tracer. Thanks for this tip.
6:32 a.m.
On Thu, 2018-05-31 at 23:10 -0400, Robert Moskowitz wrote:
Yesterday, I had no problem writing to a USB device.
Today, with the latest batch of updates (including
selinux-policy-targeted), I could not write to a USB drive. I was under
the gun to get something out, so I rebooted and USB writing worked.
Just a bit of a glitch, but an inconvenience. It takes a bit of work to
get everything set up again.
In general terms, "It didn't work" is not a useful comment unless you
give more detail.
poc
8:02 a.m.
On 06/01/2018 07:32 AM, Patrick O'Callaghan wrote:
On Thu, 2018-05-31 at 23:10 -0400, Robert Moskowitz wrote:
> Yesterday, I had no problem writing to a USB device.
>
> Today, with the latest batch of updates (including
> selinux-policy-targeted), I could not write to a USB drive. I was under
> the gun to get something out, so I rebooted and USB writing worked.
>
> Just a bit of a glitch, but an inconvenience. It takes a bit of work to
> get everything set up again.
In general terms, "It didn't work" is not a useful comment unless you
give more detail.
Writes to USB devices failed. I was using Thunar and it ignored all
delete clicks and drag to copy activities to the USB device. I did not
investigate further. Just booted out of the problem to get the USB
drive so people could get on their way.
Not so useful, other than a heads up for others if they encounter
strangeness.
Take care.
1:30 p.m.
On 05/31/2018 08:10 PM, Robert Moskowitz wrote:
Today, with the latest batch of updates (including
selinux-policy-targeted), I could not write to a USB drive. I was under
the gun to get something out, so I rebooted and USB writing worked.
Just a bit of a glitch, but an inconvenience. It takes a bit of work to
get everything set up again.
You did online updates? This is the reason why offline updates is the
default now, because doing updates without a reboot can cause weird
situations like this.
1:33 p.m.
On 06/01/2018 02:30 PM, Samuel Sieb wrote:
On 05/31/2018 08:10 PM, Robert Moskowitz wrote:
> Today, with the latest batch of updates (including
> selinux-policy-targeted), I could not write to a USB drive. I was
> under the gun to get something out, so I rebooted and USB writing
> worked.
>
> Just a bit of a glitch, but an inconvenience. It takes a bit of work
> to get everything set up again.
You did online updates? This is the reason why offline updates is the
default now, because doing updates without a reboot can cause weird
situations like this.
Online? Offline?
dnf update. basically what I have been doing for years (once was yum
update)....
Those windows users just could not understand taking time to figure out
how to get things working again instead of 'just reboot already'... :)
2:59 p.m.
On 06/01/2018 11:33 AM, Robert Moskowitz wrote:
On 06/01/2018 02:30 PM, Samuel Sieb wrote:
> You did online updates? This is the reason why offline updates is the
> default now, because doing updates without a reboot can cause weird
> situations like this.
Online? Offline?
online update is what you did
offline update is when it reboots to install the updates
dnf update. basically what I have been doing for years (once was yum
update)....
Those windows users just could not understand taking time to figure out
how to get things working again instead of 'just reboot already'... :)
Like you had to do?
Usually the online update works fine, but occasionally it doesn't.
5:51 p.m.
On 06/01/2018 03:59 PM, Samuel Sieb wrote:
On 06/01/2018 11:33 AM, Robert Moskowitz wrote:
> On 06/01/2018 02:30 PM, Samuel Sieb wrote:
>> You did online updates? This is the reason why offline updates is
>> the default now, because doing updates without a reboot can cause
>> weird situations like this.
>
> Online? Offline?
online update is what you did
offline update is when it reboots to install the updates
Considering my operating mode is to reboot once a month at best. I have
always installed updates as they came, not when I was planning on rebooting.
With all I have open, getting everything set up takes real time.
> dnf update. basically what I have been doing for years (once was yum
> update)....
>
> Those windows users just could not understand taking time to figure
> out how to get things working again instead of 'just reboot
> already'... :)
Like you had to do?
Usually the online update works fine, but occasionally it doesn't.
More common on a new release than a mature release. I use to reboot any
time I got a new kernel, but then I learned that was not really
necessary. My Centos servers may go 6 mo between reboots.
Well take care.
11:32 p.m.
On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
You did online updates? This is the reason why offline updates is
the
default now, because doing updates without a reboot can cause weird
situations like this.
Ok, you maniacs finally did it, you made a Linux suck as hard as
Windows. I'm out.
11:45 p.m.
On 06/01/2018 09:32 PM, John Morris wrote:
On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
> You did online updates? This is the reason why offline updates is the
> default now, because doing updates without a reboot can cause weird
> situations like this.
Ok, you maniacs finally did it, you made a Linux suck as hard as
Windows. I'm out.
Seriously? This discussion comes up regularly. In most cases online
updates work, but sometimes there are issues. Read the past threads for
more info, but it's an extremely hard problem to make it always work for
very obvious reasons when you think about what's happening.
4:09 a.m.
On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
On 06/01/2018 09:32 PM, John Morris wrote:
> On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
>
> > You did online updates? This is the reason why offline updates is the
> > default now, because doing updates without a reboot can cause weird
> > situations like this.
>
> Ok, you maniacs finally did it, you made a Linux suck as hard as
> Windows. I'm out.
Seriously? This discussion comes up regularly. In most cases online
updates work, but sometimes there are issues. Read the past threads for
more info, but it's an extremely hard problem to make it always work for
very obvious reasons when you think about what's happening.
I rely on tracer (using the dnf plugin) to tell me when I need to
reboot. Are you saying this is unreliable?
poc
7:03 a.m.
On 06/02/18 17:09, Patrick O'Callaghan wrote:
On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
> On 06/01/2018 09:32 PM, John Morris wrote:
>> On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
>>
>>> You did online updates? This is the reason why offline updates is the
>>> default now, because doing updates without a reboot can cause weird
>>> situations like this.
>> Ok, you maniacs finally did it, you made a Linux suck as hard as
>> Windows. I'm out.
> Seriously? This discussion comes up regularly. In most cases online
> updates work, but sometimes there are issues. Read the past threads for
> more info, but it's an extremely hard problem to make it always work for
> very obvious reasons when you think about what's happening.
I rely on tracer (using the dnf plugin) to tell me when I need to
reboot. Are you saying this is unreliable?
Where did Sam say anything about tracer?
FWIW, I don't use the tracer dnf plugin since I use the nVidia drivers from rpmfusion
and akmods. It may have been improved. But when I was using it and a kernel update
happened the tracer process would keep the rpmdb locked so when the nVidia mods were
compiled they failed to install.
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
8:22 a.m.
On Sat, 2018-06-02 at 20:03 +0800, Ed Greshko wrote:
On 06/02/18 17:09, Patrick O'Callaghan wrote:
> On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
> > On 06/01/2018 09:32 PM, John Morris wrote:
> > > On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
> > >
> > > > You did online updates? This is the reason why offline updates is
the
> > > > default now, because doing updates without a reboot can cause weird
> > > > situations like this.
> > >
> > > Ok, you maniacs finally did it, you made a Linux suck as hard as
> > > Windows. I'm out.
> >
> > Seriously? This discussion comes up regularly. In most cases online
> > updates work, but sometimes there are issues. Read the past threads for
> > more info, but it's an extremely hard problem to make it always work for
> > very obvious reasons when you think about what's happening.
>
> I rely on tracer (using the dnf plugin) to tell me when I need to
> reboot. Are you saying this is unreliable?
>
Where did Sam say anything about tracer?
He didn't. I merely state that it it's useful to know when a reboot is
necessary and when it isn't, which is the difference between online and
offline updates.
FWIW, I don't use the tracer dnf plugin since I use the nVidia
drivers from rpmfusion
and akmods. It may have been improved. But when I was using it and a kernel update
happened the tracer process would keep the rpmdb locked so when the nVidia mods were
compiled they failed to install.
I haven't had problems but I don't use the Nvidia drivers now. Back
when I did use them I also had locking issues, though I never
associated them with tracer specifically.
poc
8:40 a.m.
On 06/02/18 21:22, Patrick O'Callaghan wrote:
On Sat, 2018-06-02 at 20:03 +0800, Ed Greshko wrote:
> On 06/02/18 17:09, Patrick O'Callaghan wrote:
>> On Fri, 2018-06-01 at 21:45 -0700, Samuel Sieb wrote:
>>> On 06/01/2018 09:32 PM, John Morris wrote:
>>>> On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
>>>>
>>>>> You did online updates? This is the reason why offline updates is
the
>>>>> default now, because doing updates without a reboot can cause weird
>>>>> situations like this.
>>>> Ok, you maniacs finally did it, you made a Linux suck as hard as
>>>> Windows. I'm out.
>>> Seriously? This discussion comes up regularly. In most cases online
>>> updates work, but sometimes there are issues. Read the past threads for
>>> more info, but it's an extremely hard problem to make it always work for
>>> very obvious reasons when you think about what's happening.
>> I rely on tracer (using the dnf plugin) to tell me when I need to
>> reboot. Are you saying this is unreliable?
>>
> Where did Sam say anything about tracer?
He didn't. I merely state that it it's useful to know when a reboot is
necessary and when it isn't, which is the difference between online and
offline updates.
I see. Then I'm confused as to your question. What are you asking about
reliability or what do you think Sam is suggesting is unreliable?
> FWIW, I don't use the tracer dnf plugin since I use the nVidia drivers from
rpmfusion
> and akmods. It may have been improved. But when I was using it and a kernel update
> happened the tracer process would keep the rpmdb locked so when the nVidia mods were
> compiled they failed to install.
I haven't had problems but I don't use the Nvidia drivers now. Back
when I did use them I also had locking issues, though I never
associated them with tracer specifically.
I took the time and effort to prove, at least to myself, that the asynchronous or
independent nature of the akmod process and the tracer-plugin could cause problems.
It was very variable since it depended on the number and nature of the updates.
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
10:57 a.m.
On Sat, 2018-06-02 at 21:40 +0800, Ed Greshko wrote:
>>>> Seriously? This discussion comes up regularly. In
most cases online
>>>> updates work, but sometimes there are issues. Read the past threads for
>>>> more info, but it's an extremely hard problem to make it always work
for
>>>> very obvious reasons when you think about what's happening.
>>> I rely on tracer (using the dnf plugin) to tell me when I need to
>>> reboot. Are you saying this is unreliable?
>>>
>> Where did Sam say anything about tracer?
> He didn't. I merely state that it it's useful to know when a reboot is
> necessary and when it isn't, which is the difference between online and
> offline updates.
I see. Then I'm confused as to your question. What are you asking about
reliability or what do you think Sam is suggesting is unreliable?
Sam seems to suggest that rebooting is the only way to be sure of
avoiding problems. I'm wondering if he's discounting the use of tracer
as a way to do this more selectively, and if so is it because he thinks
tracer is unreliable?
>
>> FWIW, I don't use the tracer dnf plugin since I use the nVidia drivers from
rpmfusion
>> and akmods. It may have been improved. But when I was using it and a kernel
update
>> happened the tracer process would keep the rpmdb locked so when the nVidia mods
were
>> compiled they failed to install.
> I haven't had problems but I don't use the Nvidia drivers now. Back
> when I did use them I also had locking issues, though I never
> associated them with tracer specifically.
>
>
I took the time and effort to prove, at least to myself, that the asynchronous or
independent nature of the akmod process and the tracer-plugin could cause problems.
It was very variable since it depended on the number and nature of the updates.
There was certainly a race condition related to locking the RPM
database, so it's possible that tracer was causing this, though I don't
know if anyone ever tracked it down. One wonders why it only seemed to
affect akmod packages, but perhaps it's to do with the complicated
scripts they run.
poc
11:10 a.m.
On 06/02/2018 08:57 AM, Patrick O'Callaghan wrote:
Sam seems to suggest that rebooting is the only way to be sure of
avoiding problems. I'm wondering if he's discounting the use of tracer
as a way to do this more selectively, and if so is it because he thinks
tracer is unreliable?
It is the only 100% reliable way. As I said, most of the time it's fine
and tracer probably helps as well, although I've never used it.
4:29 p.m.
On 06/02/18 23:57, Patrick O'Callaghan wrote:
Sam seems to suggest that rebooting is the only way to be sure of
avoiding problems. I'm wondering if he's discounting the use of tracer
as a way to do this more selectively, and if so is it because he thinks
tracer is unreliable?
The one thing I will note about tracer is that sometimes it tells you that you should
logout/login. However, there are some user processes that by default persist across
logouts/logins. If those processes are ones that will result in unstable behavior
they will not be restarted. I would venture to say that a certain number of people
wouldn't re-run tracer to verify.
FWIW, I've also added "KillUserProcesses=yes" to my logind.conf to eliminate
those
persistent processes.
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
10:44 a.m.
On Fri, Jun 01, 2018 at 09:45:50PM -0700, Samuel Sieb wrote:
On 06/01/2018 09:32 PM, John Morris wrote:
> On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
>
> > You did online updates? This is the reason why offline updates is the
> > default now, because doing updates without a reboot can cause weird
> > situations like this.
>
> Ok, you maniacs finally did it, you made a Linux suck as hard as
> Windows. I'm out.
Seriously? This discussion comes up regularly.
See: 2001 or so unless you had upgraded to a new gblic there wasn't a
need to reboot Linux machines. Most of the times it was enough to log
in/out of your X. And that was it. And that approach was, AFAICS, what
John Morris probably was referring to.
I think this topic comes up again and again because Fedora isn't
aggressive enough to communicate about how much the Fedora (Linux as a
whole?) upgrade process has changed over the last 15 yrs or so. And
unless the Fedora responsibles don't say it loud and clear that their
OS nowadays has become very similar to modern Windows when it comes to
the need to reboot after upgrades, this topic will come up
endlessly. At least until the last user who saw Linux in 2001 will
have ceased to use that OS, from whatever reasons.
In most cases online updates work, but sometimes there are issues.
Read the past threads for more info, but it's an extremely hard
problem to make it always work for very obvious reasons when you
think about what's happening.
Stick to the documentation about how to decently upgrade your system,
and Fedora guys: Say it to your users, e.g.:
0: Get out of X,
1: start a tty as root
2: start a tmux session
3: upgrade
4: reboot
And if someone really doesn't want to reboot: do at least a
"dnf needs-restarting"
And make it crystal clear to users that the very last Fedora version
is unstable, and that we need to be prepared for problems with this
version. And BTW: that's true for all software.
Look at this "Fedora-is-such-a-totally-great-OS" entrance page to
Fedora:
https://getfedora.org/
After reading this page: Is anyone really surprised when users, after
installing the system, are pissed at times when realizing reality?
It all comes down to a lack of clear communication by the Fedora
management with their users about what Fedora is, how much it has
changed, and why.
Regards
Wolfgang
11:17 a.m.
On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
See: 2001 or so unless you had upgraded to a new gblic there
wasn't a
need to reboot Linux machines. Most of the times it was enough to log
in/out of your X. And that was it. And that approach was, AFAICS, what
John Morris probably was referring to.
From the other threads on this topic, this was not entirely true. And
now, there are many more moving parts so the chance of running into a
problem are higher. If you update libraries, you have restart all the
services that use them. And your point about logging out of X defeats
most of the purpose of doing a live update anyway. Most people want to
do it to avoid closing their open applications. And updating something
like LibreOffice or Firefox while it's running is just asking for trouble.
11:49 a.m.
On Sat, Jun 02, 2018 at 09:17:36AM -0700, Samuel Sieb wrote:
On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> See: 2001 or so unless you had upgraded to a new gblic there wasn't a
> need to reboot Linux machines. Most of the times it was enough to log
> in/out of your X. And that was it. And that approach was, AFAICS, what
> John Morris probably was referring to.
From the other threads on this topic, this was not entirely true. And now,
there are many more moving parts so the chance of running into a problem are
higher. If you update libraries, you have restart all the services that use
them. And your point about logging out of X defeats most of the purpose of
doing a live update anyway. Most people want to do it to avoid closing
their open applications. And updating something like LibreOffice or Firefox
while it's running is just asking for trouble.
I'm not sure about what you mean with "Live Update": Is this sort of
update able to restart services in a running system (X even?) if
needed, and without the need to reboot?
Wolfgang
4:43 p.m.
On Sat, 2018-06-02 at 18:49 +0200, Wolfgang Pfeiffer wrote:
On Sat, Jun 02, 2018 at 09:17:36AM -0700, Samuel Sieb wrote:
> On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> > See: 2001 or so unless you had upgraded to a new gblic there wasn't a
> > need to reboot Linux machines. Most of the times it was enough to log
> > in/out of your X. And that was it. And that approach was, AFAICS, what
> > John Morris probably was referring to.
>
> From the other threads on this topic, this was not entirely true. And now,
> there are many more moving parts so the chance of running into a problem are
> higher. If you update libraries, you have restart all the services that use
> them. And your point about logging out of X defeats most of the purpose of
> doing a live update anyway. Most people want to do it to avoid closing
> their open applications. And updating something like LibreOffice or Firefox
> while it's running is just asking for trouble.
I'm not sure about what you mean with "Live Update": Is this sort of
update able to restart services in a running system (X even?) if
needed, and without the need to reboot?
As has been said, this is an ongoing debate. Linux follows Unix in not
forcing you to reboot except when switching to a new kernel (though
rebooting if glibc changes is strongly encouraged). Running apps will
continue to use old libraries even when new ones are installed and an
old library will hang around until the last reference to it disappears,
while new processes will use the new version. Unix (and Linux) has
always worked like that. This is what some are calling 'live updating'
or 'online updating'. In an earlier time we just called it 'updating'.
The (relatively new) tracer program is designed to tell you when a
process is using libraries whose packages have been updated since the
process started (and hence that the library itself may now be
obsolete), so you can decide if you want to restart them when
convenient. In some cases it recommends that you reboot the system, but
it's up to you when you do it.
poc
4:56 p.m.
On 06/03/18 05:43, Patrick O'Callaghan wrote:
As has been said, this is an ongoing debate. Linux follows Unix in
not
forcing you to reboot except when switching to a new kernel (though
rebooting if glibc changes is strongly encouraged). Running apps will
continue to use old libraries even when new ones are installed and an
old library will hang around until the last reference to it disappears,
while new processes will use the new version. Unix (and Linux) has
always worked like that. This is what some are calling 'live updating'
or 'online updating'. In an earlier time we just called it 'updating'.
The (relatively new) tracer program is designed to tell you when a
process is using libraries whose packages have been updated since the
process started (and hence that the library itself may now be
obsolete), so you can decide if you want to restart them when
convenient. In some cases it recommends that you reboot the system, but
it's up to you when you do it.
What you've said is not 100% accurate.
While the majority of time you can delay rebooting and/or logout/login I have
observed times that delaying too long after many varied updates can and will result
in an unstable system with somethings not working quite right for no apparent
reason. A reboot fixes it.
So, it is nice to think that one can run forever without rebooting after updates it
isn't always the case. Yes, YMMV. But I know I've been bitten by waiting
"too" long
to reboot after multiple updates.
Oh, and let's not forget the times (twice in recent memory) where updates to KDE
Plasma resulted in not being able to logout or even reboot from the menus. In that
case one needed to know about "init 6". :-) :-)
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
8:30 p.m.
Allegedly, on or about 3 June 2018, Ed Greshko sent:
Oh, and let's not forget the times (twice in recent memory)
where
updates to KDE Plasma resulted in not being able to logout or even
reboot from the menus. In that case one needed to know about "init
6". :-) :-)
While some will argue that you should, or shouldn't have to, reboot
after an update (I'm strongly in the you shouldn't have to, until you
really must, camp), having a system wedge after an update to the point
that you can't logout/reboot has to be a serious fault.
--
[tim@localhost ~]$ uname -rsvp
Linux 4.16.7-100.fc26.x86_64 #1 SMP Wed May 2 21:45:56 UTC 2018 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
Sorry, no viruses was included with this email, please read the rm
and fdisc man files to learn how to seriously mangle your own system.
8:41 p.m.
On 06/03/18 09:30, Tim via users wrote:
Allegedly, on or about 3 June 2018, Ed Greshko sent:
> Oh, and let's not forget the times (twice in recent memory) where
> updates to KDE Plasma resulted in not being able to logout or even
> reboot from the menus. In that case one needed to know about "init
> 6". :-) :-)
While some will argue that you should, or shouldn't have to, reboot
after an update (I'm strongly in the you shouldn't have to, until you
really must, camp), having a system wedge after an update to the point
that you can't logout/reboot has to be a serious fault.
Not so serious. I was going to logout anyway so doing a reboot didn't take all
that
much more time. And, now that I think about it, I probably didn't have to do an
"init 6". I probably could have logged out with the obscure command.
qdbus org.kde.ksmserver /KSMServer logout 0 3 3
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
4:57 a.m.
On Sun, 2018-06-03 at 05:56 +0800, Ed Greshko wrote:
On 06/03/18 05:43, Patrick O'Callaghan wrote:
> As has been said, this is an ongoing debate. Linux follows Unix in not
> forcing you to reboot except when switching to a new kernel (though
> rebooting if glibc changes is strongly encouraged). Running apps will
> continue to use old libraries even when new ones are installed and an
> old library will hang around until the last reference to it disappears,
> while new processes will use the new version. Unix (and Linux) has
> always worked like that. This is what some are calling 'live updating'
> or 'online updating'. In an earlier time we just called it
'updating'.
> The (relatively new) tracer program is designed to tell you when a
> process is using libraries whose packages have been updated since the
> process started (and hence that the library itself may now be
> obsolete), so you can decide if you want to restart them when
> convenient. In some cases it recommends that you reboot the system, but
> it's up to you when you do it.
What you've said is not 100% accurate.
While the majority of time you can delay rebooting and/or logout/login I have
observed times that delaying too long after many varied updates can and will result
in an unstable system with somethings not working quite right for no apparent
reason. A reboot fixes it.
So, it is nice to think that one can run forever without rebooting after updates it
isn't always the case. Yes, YMMV. But I know I've been bitten by waiting
"too" long
to reboot after multiple updates.
What you said I said is not 100% accurate. I did not say that you can
postpone reboots indefinitely, but that you can decide when it's
convenient to reboot (or restart certain processes as the case may be).
This implies that the user needs to have some idea of what he's doing.
If he's not sure, by all means reboot, but the system doesn't force him
to if it's not necessary.
poc
5:21 a.m.
On 06/03/18 17:57, Patrick O'Callaghan wrote:
On Sun, 2018-06-03 at 05:56 +0800, Ed Greshko wrote:
> On 06/03/18 05:43, Patrick O'Callaghan wrote:
>> As has been said, this is an ongoing debate. Linux follows Unix in not
>> forcing you to reboot except when switching to a new kernel (though
>> rebooting if glibc changes is strongly encouraged). Running apps will
>> continue to use old libraries even when new ones are installed and an
>> old library will hang around until the last reference to it disappears,
>> while new processes will use the new version. Unix (and Linux) has
>> always worked like that. This is what some are calling 'live updating'
>> or 'online updating'. In an earlier time we just called it
'updating'.
>> The (relatively new) tracer program is designed to tell you when a
>> process is using libraries whose packages have been updated since the
>> process started (and hence that the library itself may now be
>> obsolete), so you can decide if you want to restart them when
>> convenient. In some cases it recommends that you reboot the system, but
>> it's up to you when you do it.
>
> What you've said is not 100% accurate.
>
> While the majority of time you can delay rebooting and/or logout/login I have
> observed times that delaying too long after many varied updates can and will result
> in an unstable system with somethings not working quite right for no apparent
> reason. A reboot fixes it.
>
> So, it is nice to think that one can run forever without rebooting after updates it
> isn't always the case. Yes, YMMV. But I know I've been bitten by waiting
"too" long
> to reboot after multiple updates.
What you said I said is not 100% accurate. I did not say that you can
postpone reboots indefinitely, but that you can decide when it's
convenient to reboot (or restart certain processes as the case may be).
This implies that the user needs to have some idea of what he's doing.
If he's not sure, by all means reboot, but the system doesn't force him
to if it's not necessary.
I may not have expressed it quite right. But it is *not* always true that "you can
decided when it's convenient to reboot". The system may, and has for me,
decided
that it no long wished to do what I expected of it and thus decided for me that I
should reboot it. No matter if it were convenient or not. :-)
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
5:55 a.m.
On Sun, 2018-06-03 at 18:21 +0800, Ed Greshko wrote:
On 06/03/18 17:57, Patrick O'Callaghan wrote:
> On Sun, 2018-06-03 at 05:56 +0800, Ed Greshko wrote:
> > On 06/03/18 05:43, Patrick O'Callaghan wrote:
> > > As has been said, this is an ongoing debate. Linux follows Unix in not
> > > forcing you to reboot except when switching to a new kernel (though
> > > rebooting if glibc changes is strongly encouraged). Running apps will
> > > continue to use old libraries even when new ones are installed and an
> > > old library will hang around until the last reference to it disappears,
> > > while new processes will use the new version. Unix (and Linux) has
> > > always worked like that. This is what some are calling 'live
updating'
> > > or 'online updating'. In an earlier time we just called it
'updating'.
> > > The (relatively new) tracer program is designed to tell you when a
> > > process is using libraries whose packages have been updated since the
> > > process started (and hence that the library itself may now be
> > > obsolete), so you can decide if you want to restart them when
> > > convenient. In some cases it recommends that you reboot the system, but
> > > it's up to you when you do it.
> >
> > What you've said is not 100% accurate.
> >
> > While the majority of time you can delay rebooting and/or logout/login I have
> > observed times that delaying too long after many varied updates can and will
result
> > in an unstable system with somethings not working quite right for no apparent
> > reason. A reboot fixes it.
> >
> > So, it is nice to think that one can run forever without rebooting after
updates it
> > isn't always the case. Yes, YMMV. But I know I've been bitten by
waiting "too" long
> > to reboot after multiple updates.
>
> What you said I said is not 100% accurate. I did not say that you can
> postpone reboots indefinitely, but that you can decide when it's
> convenient to reboot (or restart certain processes as the case may be).
> This implies that the user needs to have some idea of what he's doing.
> If he's not sure, by all means reboot, but the system doesn't force him
> to if it's not necessary.
>
I may not have expressed it quite right. But it is *not* always true that "you can
decided when it's convenient to reboot". The system may, and has for me,
decided
that it no long wished to do what I expected of it and thus decided for me that I
should reboot it. No matter if it were convenient or not. :-)
All I can say is that has never happened to me in over 40 years of
using Unix and Linux. The specific case you mention meant you had to
logout of your DE, not that you had to reboot. I agree that rebooting
was probably what I would have done in the same circumstances, simply
because it's easier than thinking about it, but sometimes it really
isn't convenient and you are never forced to do it. Even changing glibc
or installing a new kernel doesn't force you.
However I think we're now splitting hairs. My point is that the system
should not take these decisions for you but let you decide for
yourself.
poc
11:39 a.m.
On Sat, Jun 02, 2018 at 10:43:39PM +0100, Patrick O'Callaghan wrote:
On Sat, 2018-06-02 at 18:49 +0200, Wolfgang Pfeiffer wrote:
> On Sat, Jun 02, 2018 at 09:17:36AM -0700, Samuel Sieb wrote:
> > On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> > > See: 2001 or so unless you had upgraded to a new gblic there wasn't a
> > > need to reboot Linux machines. Most of the times it was enough to log
> > > in/out of your X. And that was it. And that approach was, AFAICS, what
> > > John Morris probably was referring to.
> >
> > From the other threads on this topic, this was not entirely true. And now,
> > there are many more moving parts so the chance of running into a problem are
> > higher. If you update libraries, you have restart all the services that use
> > them. And your point about logging out of X defeats most of the purpose of
> > doing a live update anyway. Most people want to do it to avoid closing
> > their open applications. And updating something like LibreOffice or Firefox
> > while it's running is just asking for trouble.
>
> I'm not sure about what you mean with "Live Update": Is this sort of
> update able to restart services in a running system (X even?) if
> needed, and without the need to reboot?
As has been said, this is an ongoing debate. Linux follows Unix in not
forcing you to reboot except when switching to a new kernel (though
rebooting if glibc changes is strongly encouraged). Running apps will
continue to use old libraries even when new ones are installed and an
old library will hang around until the last reference to it disappears,
while new processes will use the new version. Unix (and Linux) has
always worked like that. This is what some are calling 'live updating'
or 'online updating'. In an earlier time we just called it 'updating'.
The (relatively new) tracer program is designed to tell you when a
process is using libraries whose packages have been updated since the
process started (and hence that the library itself may now be
obsolete), so you can decide if you want to restart them when
convenient. In some cases it recommends that you reboot the system, but
it's up to you when you do it.
Thanks for explaining, and to everyone else in this thread: I'll try
to keep sticking to a reboot after larger updates, I think .. ;)
And for those not so happy with tracer, there's also another tool:
dnf.plugin.needs_restarting ("dnf needs-restarting")
Thanks again,
Wolfgang
6:01 p.m.
On Tue, Jun 05, 2018 at 06:39:35PM +0200, Wolfgang Pfeiffer wrote:
Thanks for explaining, and to everyone else in this thread: I'll
try
to keep sticking to a reboot after larger updates, I think .. ;)
And for those not so happy with tracer, there's also another tool:
dnf.plugin.needs_restarting ("dnf needs-restarting")
Thanks for that information about both dnf and tracer :)
I just ran a dnf upgrade.
dnf needs-restarting shows better information than tracer for me with Fedora 27
(*not* 28).
On my server:
# dnf needs-restarting
2350 : /usr/local/bin/mythbackend --logpath /var/log/mythtv --loglevel notice
2395 : kded5 [kdeinit5]
2484 : kwin_x11 -session 10dad9ced3000145075233200000050340000_1452052580_997550
2505 : /usr/bin/krunner
2507 : /usr/bin/plasmashell
2578 : /usr/bin/konsole -session 10dad9ced3000145075236000000050340011_1452052577_900110
2684 : mythwelcome
2938 : /usr/bin/akonadi_mailfilter_agent --identifier akonadi_mailfilter_agent
2942 : /usr/bin/akonadi_newmailnotifier_agent --identifier akonadi_newmailnotifier_agent
3059 : /usr/local/bin/mythfrontend
3062 : /usr/libexec/drkonqi -platform xcb -display :0 --appname baloo_file_extractor
--apppath /usr/bin --signal 11 --pid 2529 --appversion 5.46.0 --programname Baloo File
Extractor --bugaddress submit(a)bugs.kde.org --startupid 0
Versus:
# tracer -a
You should restart:
* These applications rebooting your computer:
kernel
And on my desktop (OS X running virtual box, and also running Fedora 27), neither of
them works, but I can still use "lsof -d DEL -a /"
The desktop shows:
# dnf needs-restarting
Failed to read PID 8706's smaps.
# tracer -a | wc
0 0 0
# lsof -d DEL -a / | wc
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
lsof: WARNING: can't stat() fuse file system /run/user/1000/doc
Output information may be incomplete.
44 353 4094
-- Patrick
7:44 a.m.
On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan wrote:
On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
> And for those not so happy with tracer, there's also another tool:
> dnf.plugin.needs_restarting ("dnf needs-restarting")
AFAIK tracer is a rewritten and expanded version of needs-restarting.
Ed Greshko a little earler in this thread was writing about rpm
database lockings that might be related to tracer. And you also
weren't sure in your answer about the issue, IIUC. That was the main
reason I mentioned "dnf needs-restarting" .. Just in case someone is
trying to avoid usage of tracer at any cost ... :)
And no: I do not have specific knowledge about "dnf needs-restarting":
just used it a few times ..
Regards,
Wolfgang
10:47 a.m.
On Wed, 2018-06-06 at 14:44 +0200, Wolfgang Pfeiffer wrote:
On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan
wrote:
> On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
> > And for those not so happy with tracer, there's also another tool:
> > dnf.plugin.needs_restarting ("dnf needs-restarting")
>
> AFAIK tracer is a rewritten and expanded version of needs-restarting.
Ed Greshko a little earler in this thread was writing about rpm
database lockings that might be related to tracer. And you also
weren't sure in your answer about the issue, IIUC. That was the main
reason I mentioned "dnf needs-restarting" .. Just in case someone is
trying to avoid usage of tracer at any cost ... :)
And no: I do not have specific knowledge about "dnf needs-restarting":
just used it a few times ..
IIRC needs-restarting also locks the RPM database, but otherwise I'm
not really clear on the differences, except that apparently tracer
supports other package managers as well as dnf. It also seems to be
trying to offer more interactivity about what to restart and why, but I
don't generally bother with that.
poc
11:55 a.m.
On 06/06/18 23:47, Patrick O'Callaghan wrote:
On Wed, 2018-06-06 at 14:44 +0200, Wolfgang Pfeiffer wrote:
> On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan wrote:
>> On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
>>> And for those not so happy with tracer, there's also another tool:
>>> dnf.plugin.needs_restarting ("dnf needs-restarting")
>> AFAIK tracer is a rewritten and expanded version of needs-restarting.
> Ed Greshko a little earler in this thread was writing about rpm
> database lockings that might be related to tracer. And you also
> weren't sure in your answer about the issue, IIUC. That was the main
> reason I mentioned "dnf needs-restarting" .. Just in case someone is
> trying to avoid usage of tracer at any cost ... :)
>
> And no: I do not have specific knowledge about "dnf needs-restarting":
> just used it a few times ..
IIRC needs-restarting also locks the RPM database, but otherwise I'm
not really clear on the differences, except that apparently tracer
supports other package managers as well as dnf. It also seems to be
trying to offer more interactivity about what to restart and why, but I
don't generally bother with that.
To reiterate. The only reason I don't use the tracer plugin is that it runs
*automatically* and, depending on the number and type of updates can interfere with
the also automatic process of updating the nVidia kmod packages. Certainly the same
problem could happen if you manually run needs-restarting right after an upgrade that
includes a kernel upgrade. But, presumably, you'd know better. :-)
--
Conjecture is just a conclusion based on incomplete information. It isn't a fact.
3:54 a.m.
On Thu, 2018-06-07 at 00:55 +0800, Ed Greshko wrote:
On 06/06/18 23:47, Patrick O'Callaghan wrote:
> On Wed, 2018-06-06 at 14:44 +0200, Wolfgang Pfeiffer wrote:
> > On Wed, Jun 06, 2018 at 12:29:02AM +0100, Patrick O'Callaghan wrote:
> > > On Tue, 2018-06-05 at 18:39 +0200, Wolfgang Pfeiffer wrote:
> > > > And for those not so happy with tracer, there's also another
tool:
> > > > dnf.plugin.needs_restarting ("dnf needs-restarting")
> > >
> > > AFAIK tracer is a rewritten and expanded version of needs-restarting.
> >
> > Ed Greshko a little earler in this thread was writing about rpm
> > database lockings that might be related to tracer. And you also
> > weren't sure in your answer about the issue, IIUC. That was the main
> > reason I mentioned "dnf needs-restarting" .. Just in case someone is
> > trying to avoid usage of tracer at any cost ... :)
> >
> > And no: I do not have specific knowledge about "dnf
needs-restarting":
> > just used it a few times ..
>
> IIRC needs-restarting also locks the RPM database, but otherwise I'm
> not really clear on the differences, except that apparently tracer
> supports other package managers as well as dnf. It also seems to be
> trying to offer more interactivity about what to restart and why, but I
> don't generally bother with that.
>
To reiterate. The only reason I don't use the tracer plugin is that it runs
*automatically* and, depending on the number and type of updates can interfere with
the also automatic process of updating the nVidia kmod packages. Certainly the same
problem could happen if you manually run needs-restarting right after an upgrade that
includes a kernel upgrade. But, presumably, you'd know better. :-)
Sure.
poc
4:28 p.m.
On Sat, 2018-06-02 at 09:17 -0700, Samuel Sieb wrote:
On 06/02/2018 08:44 AM, Wolfgang Pfeiffer wrote:
> See: 2001 or so unless you had upgraded to a new gblic there wasn't a
> need to reboot Linux machines. Most of the times it was enough to log
> in/out of your X. And that was it. And that approach was, AFAICS, what
> John Morris probably was referring to.
From the other threads on this topic, this was not entirely true. And
now, there are many more moving parts so the chance of running into a
problem are higher. If you update libraries, you have restart all the
services that use them.
That's what tracer is for. My earlier comment was to ask if you were
aware of some problem with tracer, but you've since clarified that you
don't use it, so the question is moot.
And your point about logging out of X defeats
most of the purpose of doing a live update anyway. Most people want to
do it to avoid closing their open applications. And updating something
like LibreOffice or Firefox while it's running is just asking for trouble.
Most apps don't care, but tracer will tell you anyway and let you
decide.
Also, I usually have a VM running (Windows 10) that I prefer not to
have to restart just because I updated one of Linux's libraries that
the VM doesn't depend on. This might even mean restarting my desktop
session, which I can do without the VM even noticing. Forcing updates
to be done offline is using a sledgehammer to break a nut.
poc
11:43 p.m.
On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
Also, I usually have a VM running (Windows 10) that I prefer not to
have to restart just because I updated one of Linux's libraries that
the VM doesn't depend on. This might even mean restarting my desktop
session, which I can do without the VM even noticing. Forcing updates
to be done offline is using a sledgehammer to break a nut.
By default, libvirt and qemu will pause the VM and save it when you
reboot. On startup, it resumes from where it left off.
4:52 a.m.
On Sat, 2018-06-02 at 21:43 -0700, Samuel Sieb wrote:
On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
> Also, I usually have a VM running (Windows 10) that I prefer not to
> have to restart just because I updated one of Linux's libraries that
> the VM doesn't depend on. This might even mean restarting my desktop
> session, which I can do without the VM even noticing. Forcing updates
> to be done offline is using a sledgehammer to break a nut.
By default, libvirt and qemu will pause the VM and save it when you
reboot. On startup, it resumes from where it left off.
That doesn't work for me as I'm using VFIO with graphics passthrough.
My conjecture is that the GPU state cannot be saved and restored. This
seems to be the case even with native Windows, which only permits
hibernation in restricted cirumstances, mainly in laptops.
poc
8:29 a.m.
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
> Also, I usually have a VM running (Windows 10) that I prefer not to
> have to restart just because I updated one of Linux's libraries that
> the VM doesn't depend on. This might even mean restarting my desktop
> session, which I can do without the VM even noticing. Forcing updates
> to be done offline is using a sledgehammer to break a nut.
By default, libvirt and qemu will pause the VM and save it when you
reboot. On startup, it resumes from where it left off.
This has NOT been my experience with my F21 image i qemu. Is there some
setting I need for this?
I am tired of also restarting my F21 image. Yes there is little I do in
it; it is more a toy thing...
8:37 a.m.
Robert Moskowitz wrote:
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
>> Also, I usually have a VM running (Windows 10) that I prefer not to
>> have to restart just because I updated one of Linux's libraries that
>> the VM doesn't depend on. This might even mean restarting my desktop
>> session, which I can do without the VM even noticing. Forcing updates
>> to be done offline is using a sledgehammer to break a nut.
>
> By default, libvirt and qemu will pause the VM and save it when you
> reboot. On startup, it resumes from where it left off.
This has NOT been my experience with my F21 image i qemu. Is there some
setting I need for this?
I am tired of also restarting my F21 image.
My memory may be foggy, but the implementation basically hibernates the VM's
then resumes on restart. So, this may only work if hiberation is available
and working in the VM (ie, there is sufficient swap available, etc...)
-- rex
12:12 p.m.
On Sun, 2018-06-03 at 08:37 -0500, Rex Dieter wrote:
Robert Moskowitz wrote:
>
>
> On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> > On 06/02/2018 02:28 PM, Patrick O'Callaghan wrote:
> > > Also, I usually have a VM running (Windows 10) that I prefer not to
> > > have to restart just because I updated one of Linux's libraries that
> > > the VM doesn't depend on. This might even mean restarting my desktop
> > > session, which I can do without the VM even noticing. Forcing updates
> > > to be done offline is using a sledgehammer to break a nut.
> >
> > By default, libvirt and qemu will pause the VM and save it when you
> > reboot. On startup, it resumes from where it left off.
>
> This has NOT been my experience with my F21 image i qemu. Is there some
> setting I need for this?
>
> I am tired of also restarting my F21 image.
My memory may be foggy, but the implementation basically hibernates the VM's
then resumes on restart. So, this may only work if hiberation is available
and working in the VM (ie, there is sufficient swap available, etc...)
AFAIK that is correct. However not all VMs are able to hibernate even
if enough space is available.
poc
12:19 p.m.
On 06/03/2018 06:37 AM, Rex Dieter wrote:
Robert Moskowitz wrote:
> On 06/03/2018 12:43 AM, Samuel Sieb wrote:
>> By default, libvirt and qemu will pause the VM and save it when you
>> reboot. On startup, it resumes from where it left off.
>
> This has NOT been my experience with my F21 image i qemu. Is there some
> setting I need for this?
>
> I am tired of also restarting my F21 image.
My memory may be foggy, but the implementation basically hibernates the VM's
then resumes on restart. So, this may only work if hiberation is available
and working in the VM (ie, there is sufficient swap available, etc...)
No, it's a qemu function that saves the currently used VM memory and
state. You do need to have enough free disk space available to be able
to store that. The VM OS doesn't get notified about it, other than
probably noticing that the clock time suddenly jumps unexpectedly.
4:40 a.m.
On Sun, 2018-06-03 at 10:19 -0700, Samuel Sieb wrote:
On 06/03/2018 06:37 AM, Rex Dieter wrote:
> Robert Moskowitz wrote:
> > On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> > > By default, libvirt and qemu will pause the VM and save it when you
> > > reboot. On startup, it resumes from where it left off.
> >
> > This has NOT been my experience with my F21 image i qemu. Is there some
> > setting I need for this?
> >
> > I am tired of also restarting my F21 image.
>
> My memory may be foggy, but the implementation basically hibernates the VM's
> then resumes on restart. So, this may only work if hiberation is available
> and working in the VM (ie, there is sufficient swap available, etc...)
No, it's a qemu function that saves the currently used VM memory and
state. You do need to have enough free disk space available to be able
to store that. The VM OS doesn't get notified about it, other than
probably noticing that the clock time suddenly jumps unexpectedly.
In my case suddenly rebooting the host *is* detected by the guest
(running Windows 10). I notice this because on reconnecting to it after
a reboot it is always on the login screen, not on the desktop where I
left it.
poc
12:21 p.m.
On 06/04/2018 02:40 AM, Patrick O'Callaghan wrote:
On Sun, 2018-06-03 at 10:19 -0700, Samuel Sieb wrote:
> No, it's a qemu function that saves the currently used VM memory and
> state. You do need to have enough free disk space available to be able
> to store that. The VM OS doesn't get notified about it, other than
> probably noticing that the clock time suddenly jumps unexpectedly.
In my case suddenly rebooting the host *is* detected by the guest
(running Windows 10). I notice this because on reconnecting to it after
a reboot it is always on the login screen, not on the desktop where I
left it.
You did say that you were using VFIO, so it won't work anyway.
But did you enable and start the "libvirt-guests" service?
12:58 p.m.
On Mon, 2018-06-04 at 10:21 -0700, Samuel Sieb wrote:
On 06/04/2018 02:40 AM, Patrick O'Callaghan wrote:
> On Sun, 2018-06-03 at 10:19 -0700, Samuel Sieb wrote:
> > No, it's a qemu function that saves the currently used VM memory and
> > state. You do need to have enough free disk space available to be able
> > to store that. The VM OS doesn't get notified about it, other than
> > probably noticing that the clock time suddenly jumps unexpectedly.
>
> In my case suddenly rebooting the host *is* detected by the guest
> (running Windows 10). I notice this because on reconnecting to it after
> a reboot it is always on the login screen, not on the desktop where I
> left it.
You did say that you were using VFIO, so it won't work anyway.
Indeed.
But did you enable and start the "libvirt-guests" service?
AFAIK it has always been enabled and running:
systemctl status libvirt-guests
● libvirt-guests.service - Suspend/Resume Running libvirt Guests
Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled; vendor preset:
disabled)
Active: active (exited) since Mon 2018-06-04 13:22:56 BST; 5h 30min ago
Docs: man:libvirtd(8)
https://libvirt.org
Process: 1375 ExecStart=/usr/libexec/libvirt-guests.sh start (code=exited,
status=0/SUCCESS)
Main PID: 1375 (code=exited, status=0/SUCCESS)
Jun 04 13:22:43 bree systemd[1]: Starting Suspend/Resume Running libvirt Guests...
Jun 04 13:22:53 bree libvirt-guests.sh[1375]: Resuming guests on default URI...
Jun 04 13:22:56 bree libvirt-guests.sh[1375]: Resuming guest NewWin10: done
Jun 04 13:22:56 bree systemd[1]: Started Suspend/Resume Running libvirt Guests.
So it tells me the Win10 guest has been resumed. However internally the
guest will presumably have panicked and restarted because the GPU was
reset by the host reboot. (I'm not enough of a Windows user to be able
to tell when it restarted but if anyone knows I can check).
poc
11:13 a.m.
On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan wrote:
So it tells me the Win10 guest has been resumed. However internally
the
guest will presumably have panicked and restarted because the GPU was
reset by the host reboot. (I'm not enough of a Windows user to be able
to tell when it restarted but if anyone knows I can check).
I'd try 'eventvwr' in a cmd.exe or whatever shell is available. Might
work only with admin permissions - not being sure ..
That at least according to my notes was the W10 (Pro) log viewer
around two yrs ago. IIRC I could even fine-tune the logs as to what I
wanted the log system to show me about the OS ..
6:25 p.m.
On Tue, 2018-06-05 at 18:13 +0200, Wolfgang Pfeiffer wrote:
On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan
wrote:
> So it tells me the Win10 guest has been resumed. However internally the
> guest will presumably have panicked and restarted because the GPU was
> reset by the host reboot. (I'm not enough of a Windows user to be able
> to tell when it restarted but if anyone knows I can check).
I'd try 'eventvwr' in a cmd.exe or whatever shell is available. Might
work only with admin permissions - not being sure ..
Thanks, I found it under the Management Console. Understanding it is
another matter. It's even more obscure than the systemd journal.
poc
7:05 a.m.
On Wed, Jun 06, 2018 at 12:25:03AM +0100, Patrick O'Callaghan wrote:
On Tue, 2018-06-05 at 18:13 +0200, Wolfgang Pfeiffer wrote:
> On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan wrote:
>
> > So it tells me the Win10 guest has been resumed. However internally the
> > guest will presumably have panicked and restarted because the GPU was
> > reset by the host reboot. (I'm not enough of a Windows user to be able
> > to tell when it restarted but if anyone knows I can check).
>
> I'd try 'eventvwr' in a cmd.exe or whatever shell is available. Might
> work only with admin permissions - not being sure ..
Thanks, I found it under the Management Console. Understanding it is
another matter. It's even more obscure than the systemd journal.
Again: in my time I started that tool (and only that, IIRC - not the
whole Management Console) from the command line - if google serves me
right it's "eventvwr.msc"
To search for reboots I'd click the "Find" menu, right hand side-bar,
if Google images is correct, and then search for "clean" - because
that's the word, IIRC, the logs use to announce that some disk is
"clean" after a reboot (!).
Good luck!
HTH
Wolfgang
--
"The most overlooked advantage of owning a computer is that if they
foul up there's no law against whacking them around a bit."
- Eric Porterfield ?
7:40 a.m.
On Wed, 2018-06-06 at 14:05 +0200, Wolfgang Pfeiffer wrote:
On Wed, Jun 06, 2018 at 12:25:03AM +0100, Patrick O'Callaghan
wrote:
> On Tue, 2018-06-05 at 18:13 +0200, Wolfgang Pfeiffer wrote:
> > On Mon, Jun 04, 2018 at 06:58:11PM +0100, Patrick O'Callaghan wrote:
> >
> > > So it tells me the Win10 guest has been resumed. However internally the
> > > guest will presumably have panicked and restarted because the GPU was
> > > reset by the host reboot. (I'm not enough of a Windows user to be
able
> > > to tell when it restarted but if anyone knows I can check).
> >
> > I'd try 'eventvwr' in a cmd.exe or whatever shell is available.
Might
> > work only with admin permissions - not being sure ..
>
> Thanks, I found it under the Management Console. Understanding it is
> another matter. It's even more obscure than the systemd journal.
Again: in my time I started that tool (and only that, IIRC - not the
whole Management Console) from the command line - if google serves me
right it's "eventvwr.msc"
To search for reboots I'd click the "Find" menu, right hand side-bar,
if Google images is correct, and then search for "clean" - because
that's the word, IIRC, the logs use to announce that some disk is
"clean" after a reboot (!).
In fact there's a 'Kernel boot' event which coincides with the last
time I rebooted the host, so it looks like it is forcing a guest reboot
either directly or implicitly through a GPU reset. There's also a
'Kernel power' event with a comment saying the kernel was rebooted
unexpectedly, though curiously this is timestamped 5 seconds *after*
the reboot event (probably just means the log was committed after
rebooting).
poc
8:04 a.m.
On Wed, Jun 06, 2018 at 01:40:59PM +0100, Patrick O'Callaghan wrote:
On Wed, 2018-06-06 at 14:05 +0200, Wolfgang Pfeiffer wrote:
>
> To search for reboots I'd click the "Find" menu, right hand side-bar,
> if Google images is correct, and then search for "clean" - because
> that's the word, IIRC, the logs use to announce that some disk is
> "clean" after a reboot (!).
In fact there's a 'Kernel boot' event which coincides with the last
time I rebooted the host, so it looks like it is forcing a guest reboot
either directly or implicitly through a GPU reset. There's also a
'Kernel power' event with a comment saying the kernel was rebooted
unexpectedly,
If that "unexpectedly" means the system crashed, I'd investigate
... ;)
Again: there should also be some "health" line (or something like
that) about your client disk in these logs, after reboot - tho I've
heard, IIRC, that NTFS were rather robust when it comes to
crashes. But I never could verify the latter.
though curiously this is timestamped 5 seconds *after*
the reboot event (probably just means the log was committed after
rebooting).
Same with Linux journalctl, at times: e.g. the system starting sleep
mode is tagged with times when the machine is actually up and running
again, after sleep-mode ...
Good luck!
Wolfgang
11:03 a.m.
On Wed, 2018-06-06 at 15:04 +0200, Wolfgang Pfeiffer wrote:
On Wed, Jun 06, 2018 at 01:40:59PM +0100, Patrick O'Callaghan
wrote:
> On Wed, 2018-06-06 at 14:05 +0200, Wolfgang Pfeiffer wrote:
> >
> > To search for reboots I'd click the "Find" menu, right hand
side-bar,
> > if Google images is correct, and then search for "clean" - because
> > that's the word, IIRC, the logs use to announce that some disk is
> > "clean" after a reboot (!).
>
> In fact there's a 'Kernel boot' event which coincides with the last
> time I rebooted the host, so it looks like it is forcing a guest reboot
> either directly or implicitly through a GPU reset. There's also a
> 'Kernel power' event with a comment saying the kernel was rebooted
> unexpectedly,
If that "unexpectedly" means the system crashed, I'd investigate
... ;)
As I said earlier, my conjecture is that it reboots because a hardware
reset has affected the GPU. Recall that my setup is different from most
normal users'. I have a second GPU (Nvidia GTX-1050) assigned
exclusively to the VM (so not visible to Linux) and used via VFIO, i.e.
the Windows drivers access it directly with no emulation. When the host
reboots, the host hardware reset will also reset the Nvidia card, but
a) Linux won't know about it, and b) Windows, even if frozen and
restored by KVM/QEMU, will suddenly find the state of the GPU to have
reset under its feet.
[Note that even if QEMU explicitly signalled Windows to hibernate, this
still wouldn't work because the Windows Nvidia driver doesn't support
saving and restoring the state of the GPU. As far as I can see, a
physical Windows desktop machine with this configuration would not be
able to hibernate and restore, essentially for the same reason.]
So (and this is a guess) Windows decides something is wrong and reboots
itself to get to a known state. It probably does this after being
frozen and restored by KVM/QEMU, but the effect is the same.
Again: there should also be some "health" line (or
something like
that) about your client disk in these logs, after reboot - tho I've
heard, IIRC, that NTFS were rather robust when it comes to
crashes. But I never could verify the latter.
> though curiously this is timestamped 5 seconds *after*
> the reboot event (probably just means the log was committed after
> rebooting).
Same with Linux journalctl, at times: e.g. the system starting sleep
mode is tagged with times when the machine is actually up and running
again, after sleep-mode ...
Sure. Makes sense.
poc
12:16 p.m.
On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> By default, libvirt and qemu will pause the VM and save it when you
> reboot. On startup, it resumes from where it left off.
This has NOT been my experience with my F21 image i qemu. Is there some
setting I need for this?
I am tired of also restarting my F21 image. Yes there is little I do in
it; it is more a toy thing...
Try enabling (and starting?) the "libvirt-guests" service.
12:42 p.m.
On 06/03/2018 01:16 PM, Samuel Sieb wrote:
On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
> On 06/03/2018 12:43 AM, Samuel Sieb wrote:
>> By default, libvirt and qemu will pause the VM and save it when you
>> reboot. On startup, it resumes from where it left off.
>
> This has NOT been my experience with my F21 image i qemu. Is there
> some setting I need for this?
>
> I am tired of also restarting my F21 image. Yes there is little I do
> in it; it is more a toy thing...
Try enabling (and starting?) the "libvirt-guests" service.
OK, thanks. I did this and made a note for the future. Will see the
next reboot what happens...
7:02 a.m.
New subject: QEMU suspend works - Re: F28 - Today's updates messed up writing to
USB
Finally rebooted last night after a kernel update...
On 06/03/2018 01:16 PM, Samuel Sieb wrote:
On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
> On 06/03/2018 12:43 AM, Samuel Sieb wrote:
>> By default, libvirt and qemu will pause the VM and save it when you
>> reboot. On startup, it resumes from where it left off.
>
> This has NOT been my experience with my F21 image i qemu. Is there
> some setting I need for this?
>
> I am tired of also restarting my F21 image. Yes there is little I do
> in it; it is more a toy thing...
Try enabling (and starting?) the "libvirt-guests" service.
I noticed that the shutdown was taking real time, so did an <ALT-d> and
saw the messages of suspending the QEMU running image. After restart
and getting a few things running, I opened the Virtual Machine Manager,
and there was my image already up and running. Only had to open the
window to it and log back in.
Saved me a good piece of time. THANKS!
Though I suspect this only works when rebooting or powering off. Not if
your system crashes due to things like overheating (problem I was having
with my old system)!
7:50 a.m.
New subject: QEMU suspend works - Re: F28 - Today's updates messed up
writing to USB
On Sun, 2018-06-10 at 08:02 -0400, Robert Moskowitz wrote:
Finally rebooted last night after a kernel update...
On 06/03/2018 01:16 PM, Samuel Sieb wrote:
> On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
> > On 06/03/2018 12:43 AM, Samuel Sieb wrote:
> > > By default, libvirt and qemu will pause the VM and save it when you
> > > reboot. On startup, it resumes from where it left off.
> >
> > This has NOT been my experience with my F21 image i qemu. Is there
> > some setting I need for this?
> >
> > I am tired of also restarting my F21 image. Yes there is little I do
> > in it; it is more a toy thing...
>
> Try enabling (and starting?) the "libvirt-guests" service.
I noticed that the shutdown was taking real time, so did an <ALT-d> and
saw the messages of suspending the QEMU running image. After restart
and getting a few things running, I opened the Virtual Machine Manager,
and there was my image already up and running. Only had to open the
window to it and log back in.
Assuming you were logged into the guest when doing the host shutdown,
then if you had to log back in, the guest can't have been suspended and
resumed from where it left off.
poc
8:28 a.m.
New subject: QEMU suspend works - Re: F28 - Today's updates messed up writing
to USB
On 06/10/2018 08:50 AM, Patrick O'Callaghan wrote:
On Sun, 2018-06-10 at 08:02 -0400, Robert Moskowitz wrote:
> Finally rebooted last night after a kernel update...
>
> On 06/03/2018 01:16 PM, Samuel Sieb wrote:
>> On 06/03/2018 06:29 AM, Robert Moskowitz wrote:
>>> On 06/03/2018 12:43 AM, Samuel Sieb wrote:
>>>> By default, libvirt and qemu will pause the VM and save it when you
>>>> reboot. On startup, it resumes from where it left off.
>>> This has NOT been my experience with my F21 image i qemu. Is there
>>> some setting I need for this?
>>>
>>> I am tired of also restarting my F21 image. Yes there is little I do
>>> in it; it is more a toy thing...
>> Try enabling (and starting?) the "libvirt-guests" service.
> I noticed that the shutdown was taking real time, so did an <ALT-d> and
> saw the messages of suspending the QEMU running image. After restart
> and getting a few things running, I opened the Virtual Machine Manager,
> and there was my image already up and running. Only had to open the
> window to it and log back in.
Assuming you were logged into the guest when doing the host shutdown,
then if you had to log back in, the guest can't have been suspended and
resumed from where it left off.
I was logged in, but at the time, the session was locked. It sure
seemed to be where I left it.
I did a grep of suspend on the messages log:
Jun 9 23:36:58 lx121e systemd[1]: Stopping Suspend/Resume Running
libvirt Guests...
Jun 9 23:37:02 lx121e libvirt-guests.sh[26912]: Suspending guests on
default URI...
Jun 9 23:37:03 lx121e libvirt-guests.sh[26912]: Suspending fedora21: ...
Jun 9 23:37:08 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
135.802 MiB
Jun 9 23:37:13 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
319.096 MiB
Jun 9 23:37:18 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
488.785 MiB
Jun 9 23:37:24 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
666.404 MiB
Jun 9 23:37:29 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
804.281 MiB
Jun 9 23:37:34 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
977.524 MiB
Jun 9 23:37:38 lx121e libvirt-guests.sh[26912]: Suspending fedora21: done
Jun 9 23:37:38 lx121e systemd[1]: Stopped Suspend/Resume Running
libvirt Guests.
Jun 9 23:38:36 lx121e systemd[1]: Starting Suspend/Resume Running
libvirt Guests...
Jun 9 23:38:58 lx121e systemd[1]: Started Suspend/Resume Running
libvirt Guests.
9:21 a.m.
New subject: QEMU suspend works - Re: F28 - Today's updates messed up
writing to USB
On Sun, 2018-06-10 at 09:28 -0400, Robert Moskowitz wrote:
> Assuming you were logged into the guest when doing the host
shutdown,
> then if you had to log back in, the guest can't have been suspended and
> resumed from where it left off.
I was logged in, but at the time, the session was locked. It sure
seemed to be where I left it.
That would be consistent then. When you say you logged in, you meant
that you reconnected to the locked session.
I did a grep of suspend on the messages log:
Jun 9 23:36:58 lx121e systemd[1]: Stopping Suspend/Resume Running
libvirt Guests...
Jun 9 23:37:02 lx121e libvirt-guests.sh[26912]: Suspending guests on
default URI...
Jun 9 23:37:03 lx121e libvirt-guests.sh[26912]: Suspending fedora21: ...
Jun 9 23:37:08 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
135.802 MiB
Jun 9 23:37:13 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
319.096 MiB
Jun 9 23:37:18 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
488.785 MiB
Jun 9 23:37:24 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
666.404 MiB
Jun 9 23:37:29 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
804.281 MiB
Jun 9 23:37:34 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
977.524 MiB
Jun 9 23:37:38 lx121e libvirt-guests.sh[26912]: Suspending fedora21: done
Jun 9 23:37:38 lx121e systemd[1]: Stopped Suspend/Resume Running
libvirt Guests.
Jun 9 23:38:36 lx121e systemd[1]: Starting Suspend/Resume Running
libvirt Guests...
Jun 9 23:38:58 lx121e systemd[1]: Started Suspend/Resume Running
libvirt Guests.
That's all from the host's viewpoint, which isn't under discussion.
What would be interesting is if the guest noticed anything in its own
logs.
poc
12:44 p.m.
New subject: QEMU suspend works - Re: F28 - Today's updates messed up writing
to USB
On 06/10/2018 10:21 AM, Patrick O'Callaghan wrote:
On Sun, 2018-06-10 at 09:28 -0400, Robert Moskowitz wrote:
>> Assuming you were logged into the guest when doing the host shutdown,
>> then if you had to log back in, the guest can't have been suspended and
>> resumed from where it left off.
> I was logged in, but at the time, the session was locked. It sure
> seemed to be where I left it.
That would be consistent then. When you say you logged in, you meant
that you reconnected to the locked session.
> I did a grep of suspend on the messages log:
>
> Jun 9 23:36:58 lx121e systemd[1]: Stopping Suspend/Resume Running
> libvirt Guests...
> Jun 9 23:37:02 lx121e libvirt-guests.sh[26912]: Suspending guests on
> default URI...
> Jun 9 23:37:03 lx121e libvirt-guests.sh[26912]: Suspending fedora21: ...
> Jun 9 23:37:08 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
> 135.802 MiB
> Jun 9 23:37:13 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
> 319.096 MiB
> Jun 9 23:37:18 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
> 488.785 MiB
> Jun 9 23:37:24 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
> 666.404 MiB
> Jun 9 23:37:29 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
> 804.281 MiB
> Jun 9 23:37:34 lx121e libvirt-guests.sh[26912]: Suspending fedora21:
> 977.524 MiB
> Jun 9 23:37:38 lx121e libvirt-guests.sh[26912]: Suspending fedora21: done
> Jun 9 23:37:38 lx121e systemd[1]: Stopped Suspend/Resume Running
> libvirt Guests.
> Jun 9 23:38:36 lx121e systemd[1]: Starting Suspend/Resume Running
> libvirt Guests...
> Jun 9 23:38:58 lx121e systemd[1]: Started Suspend/Resume Running
> libvirt Guests.
That's all from the host's viewpoint, which isn't under discussion.
What would be interesting is if the guest noticed anything in its own
logs.
Challenge is the clock is off in the image, and it is a pain setting it
right. Doing some time math I kind of figured out the difference and I
found:
Jun 8 20:01:02 localhost systemd: Starting Paths.
Jun 8 20:01:02 localhost systemd: Reached target Paths.
Jun 8 20:01:02 localhost systemd: Starting Timers.
Jun 8 20:01:02 localhost systemd: Reached target Timers.
Jun 8 20:01:02 localhost systemd: Starting Sockets.
Jun 8 20:01:02 localhost systemd: Reached target Sockets.
Jun 8 20:01:02 localhost systemd: Starting Basic System.
Jun 8 20:01:02 localhost systemd: Reached target Basic System.
Jun 8 20:01:02 localhost systemd: Starting Default.
Jun 8 20:01:02 localhost systemd: Reached target Default.
Jun 8 20:01:02 localhost systemd: Startup finished in 121ms.
Jun 8 20:01:02 localhost systemd: Stopping Default.
Jun 8 20:01:02 localhost systemd: Stopped target Default.
Jun 8 20:01:02 localhost systemd: Stopping Basic System.
Jun 8 20:01:02 localhost systemd: Stopped target Basic System.
Jun 8 20:01:02 localhost systemd: Stopping Paths.
Jun 8 20:01:02 localhost systemd: Stopped target Paths.
Jun 8 20:01:02 localhost systemd: Stopping Timers.
Jun 8 20:01:02 localhost systemd: Stopped target Timers.
Jun 8 20:01:02 localhost systemd: Stopping Sockets.
Jun 8 20:01:02 localhost systemd: Stopped target Sockets.
Jun 8 20:01:02 localhost systemd: Starting Shutdown.
Jun 8 20:01:02 localhost systemd: Reached target Shutdown.
Jun 8 20:01:02 localhost systemd: Starting Exit the Session...
Jun 8 20:01:02 localhost systemd: Received SIGRTMIN+24 from PID 23967
(kill).
Jun 8 20:05:21 localhost kernel: [459152.884132] clocksource tsc: mask:
0xffffffffffffffff max_cycles: 0x170398369a9, max_idle_ns: 440795249683 ns
Jun 8 20:05:22 localhost kernel: clocksource tsc: mask:
0xffffffffffffffff max_cycles: 0x170398369a9, max_idle_ns: 440795249683 ns
The 20:01 corresponds with the main OS shutting down and 20:05 the
restart time.
10:23 p.m.
On 06/02/2018 12:45 AM, Samuel Sieb wrote:
On 06/01/2018 09:32 PM, John Morris wrote:
> On Fri, 2018-06-01 at 11:30 -0700, Samuel Sieb wrote:
>
>> You did online updates? This is the reason why offline updates is the
>> default now, because doing updates without a reboot can cause weird
>> situations like this.
>
> Ok, you maniacs finally did it, you made a Linux suck as hard as
> Windows. I'm out.
Seriously? This discussion comes up regularly. In most cases online
updates work, but sometimes there are issues. Read the past threads
for more info, but it's an extremely hard problem to make it always
work for very obvious reasons when you think about what's happening.
There have always been times, particularly with driver updates and
particularly early in a release where things just don't work after an
update and reboot is required.
That is part of the reason I normally wait at least 3 mo after a new
release comes out to move to it. But this time fan failures on my old
system (regularly getting to 100C and shutting off) forced me to another
unit and the current release.
2154
days inactive
2163
days old
58 comments
10 participants
participants (10)
-
Ed Greshko -
Ed Greshko -
John Morris -
Patrick Mansfield -
Patrick O'Callaghan -
Rex Dieter -
Robert Moskowitz -
Samuel Sieb -
Tim -
Wolfgang Pfeiffer