2:38 a.m.
Hi All,
Is there a way to reload or restart the kernel without
having to reboot?
Many thanks,
-T
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When we ask for advice, we are usually looking for an accomplice.
-- Charles Varlet de La Grange
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3:45 a.m.
On 2020-09-26 01:41, Patrick O'Callaghan wrote:
On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
> Hi All,
>
> Is there a way to reload or restart the kernel without
> having to reboot?
No.
poc
Poop!
Thank you for the confirmation.
Is the file system part of the kernel? If not, is there
a way to restart it without rebooting?
-T
5:20 a.m.
On Sat, 2020-09-26 at 01:45 -0700, ToddAndMargo via users wrote:
On 2020-09-26 01:41, Patrick O'Callaghan wrote:
> On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
> > Hi All,
> >
> > Is there a way to reload or restart the kernel without
> > having to reboot?
>
> No.
>
> poc
Poop!
Thank you for the confirmation.
Is the file system part of the kernel? If not, is there
a way to restart it without rebooting?
Depends what you mean by "the file system". Some filesystems are
reloadable (either as a module or as FUSE), but others aren't. The
underlying filesystem layer is a fixed part of the kernel.
Maybe if you explained what you're trying to do, someone might be able
to help.
poc
6:11 p.m.
On 2020-09-26 03:20, Patrick O'Callaghan wrote:
On Sat, 2020-09-26 at 01:45 -0700, ToddAndMargo via users wrote:
> On 2020-09-26 01:41, Patrick O'Callaghan wrote:
>> On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
>>> Hi All,
>>>
>>> Is there a way to reload or restart the kernel without
>>> having to reboot?
>>
>> No.
>>
>> poc
>
> Poop!
>
> Thank you for the confirmation.
>
> Is the file system part of the kernel? If not, is there
> a way to restart it without rebooting?
Depends what you mean by "the file system". Some filesystems are
reloadable (either as a module or as FUSE), but others aren't. The
underlying filesystem layer is a fixed part of the kernel.
Maybe if you explained what you're trying to do, someone might be able
to help.
poc
FC 32, x64
Ext4
Xfce 4.14
Occasionally, my computers slows down. I have not been
able to pin down why. Top shows very little memory usage.
A 1 hour, 12 minute dump (dump/restore) takes 15 hours
when this happens. Pop up menus start to lag behind
the mouse
I am trying to get around the reboot thing.
-T
A reboot ALWAYS fixes the issue.
6:22 p.m.
Usually that slow down is swapping. Have you checked to see how much
swap is in use?
I have machines with 10gb of ram and that is not enough and used to
get slowdowns prior to me setting up earlyoom. With earlyoom it
generally kills sets of firefox tabs and generally works ok, but I
have had things get bad enough that it keeps killing the tab I want to
view and then I have to find someone else to kill so I have enough
ram.
if you have sysstat / sar installed it would have data you could view
with sar -S that would tell you if it is swapping/paging.
vmstat 1
swpd column, that is the numberof kb swapped, the higher it gets the
uglier it gets.
And if it is the most likely memory usage, rebooting the kernel would
not fix anything as memory consumption is mostly a userspace problem.
On Sat, Sep 26, 2020 at 6:12 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 2020-09-26 03:20, Patrick O'Callaghan wrote:
> > On Sat, 2020-09-26 at 01:45 -0700, ToddAndMargo via users wrote:
> >> On 2020-09-26 01:41, Patrick O'Callaghan wrote:
> >>> On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
> >>>> Hi All,
> >>>>
> >>>> Is there a way to reload or restart the kernel without
> >>>> having to reboot?
> >>>
> >>> No.
> >>>
> >>> poc
> >>
> >> Poop!
> >>
> >> Thank you for the confirmation.
> >>
> >> Is the file system part of the kernel? If not, is there
> >> a way to restart it without rebooting?
> >
> > Depends what you mean by "the file system". Some filesystems are
> > reloadable (either as a module or as FUSE), but others aren't. The
> > underlying filesystem layer is a fixed part of the kernel.
> >
> > Maybe if you explained what you're trying to do, someone might be able
> > to help.
> >
> > poc
>
> FC 32, x64
> Ext4
> Xfce 4.14
>
> Occasionally, my computers slows down. I have not been
> able to pin down why. Top shows very little memory usage.
>
> A 1 hour, 12 minute dump (dump/restore) takes 15 hours
> when this happens. Pop up menus start to lag behind
> the mouse
>
> I am trying to get around the reboot thing.
>
> -T
>
> A reboot ALWAYS fixes the issue.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
7:44 p.m.
> On 2020-09-26 03:20, Patrick O'Callaghan wrote:
>> On Sat, 2020-09-26 at 01:45 -0700, ToddAndMargo via users wrote:
>>> On 2020-09-26 01:41, Patrick O'Callaghan wrote:
>>>> On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
>>>>> Hi All,
>>>>>
>>>>> Is there a way to reload or restart the kernel without
>>>>> having to reboot?
>>>>
>>>> No.
>>>>
>>>> poc
>>> Poop!
>>>
>>> Thank you for the confirmation.
>>>
>>> Is the file system part of the kernel? If not, is there
>>> a way to restart it without rebooting?
>> Depends what you mean by "the file system". Some
filesystems are
>> reloadable (either as a module or as FUSE), but others aren't. The
>> underlying filesystem layer is a fixed part of the kernel.
>>
>> Maybe if you explained what you're trying to do, someone might be able
>> to help.
>>
>> poc
>
> FC 32, x64
> Ext4
> Xfce 4.14
>
> Occasionally, my computers slows down. I have not been
> able to pin down why. Top shows very little memory usage.
>
> A 1 hour, 12 minute dump (dump/restore) takes 15 hours
> when this happens. Pop up menus start to lag behind
> the mouse
>
> I am trying to get around the reboot thing.
>
> -T
>
> A reboot ALWAYS fixes the issue.
On 2020-09-26 16:22, Roger Heflin wrote:
Usually that slow down is swapping. Have you checked to see how
much
swap is in use?
top - 17:39:41 up 1:55, 1 user, load average: 0.26, 0.37, 0.37
Tasks: 245 total, 2 running, 243 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.6 us, 0.8 sy, 0.0 ni, 95.2 id, 0.2 wa, 0.2 hi, 0.1 si,
0.0 st
MiB Mem : 15896.7 total, 11478.9 free, 1867.8 used, 2550.0 buff/cache
MiB Swap: 8031.0 total, 8031.0 free, 0.0 used. 13333.0 avail Mem
I have machines with 10gb of ram and that is not enough and used to
get slowdowns prior to me setting up earlyoom. With earlyoom it
generally kills sets of firefox tabs and generally works ok, but I
have had things get bad enough that it keeps killing the tab I want to
view and then I have to find someone else to kill so I have enough
ram.
When it happens, it is instant
if you have sysstat / sar installed it would have data you could
view
with sar -S that would tell you if it is swapping/paging.
vmstat 1
swpd column, that is the numberof kb swapped, the higher it gets the
uglier it gets.
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
r b swpd free buff cache si so bi bo in cs us sy
id wa st
1 0 0 11738732 150112 2474552 0 0 70 21 289 516 3
2 95 0 0
0 0 0 11749568 150112 2462464 0 0 0 0 615 1458 1
1 97 0 0
0 0 0 11749708 150112 2462464 0 0 0 0 488 1016 1
1 98 0 0
1 0 0 11749820 150128 2462464 0 0 0 296 478 1185 1
1 98 0 0
0 0 0 11749820 150128 2462480 0 0 0 0 477 1068 2
1 98 0 0
0 0 0 11749568 150128 2462464 0 0 0 8 480 1043 1
1 99 0 0
0 0 0 11749048 150144 2462464 0 0 0 244 693 1425 2
1 97 0 0
And if it is the most likely memory usage, rebooting the kernel would
not fix anything as memory consumption is mostly a userspace problem.
Also, the mouse chasing the pop up menues has nothing
to do with the file system.
I am at a loss. If it was a hardware issue, a reboot would not fix it.
And my almost identical shop computer does not do this.
5:29 a.m.
On Sat, 2020-09-26 at 17:44 -0700, ToddAndMargo via users wrote:
> And if it is the most likely memory usage, rebooting the kernel
would
> not fix anything as memory consumption is mostly a userspace problem.
Also, the mouse chasing the pop up menues has nothing
to do with the file system.
I am at a loss. If it was a hardware issue, a reboot would not fix it.
There are several things you can test to try to narrow it down:
- Log out and in again
- Restart the DE without rebooting
- Try a different DE
poc
6:26 a.m.
On 2020-09-27 03:29, Patrick O'Callaghan wrote:
On Sat, 2020-09-26 at 17:44 -0700, ToddAndMargo via users wrote:
> > And if it is the most likely memory usage, rebooting the kernel would
>
> > not fix anything as memory consumption is mostly a userspace problem.
>
>
>
> Also, the mouse chasing the pop up menues has nothing
>
> to do with the file system.
>
>
>
>
>
> I am at a loss. If it was a hardware issue, a reboot would not fix it.
There are several things you can test to try to narrow it down:
- Log out and in again
- Restart the DE without rebooting
- Try a different DE
poc
Have not tried the log out and back in thing.
What is a "DE"
7:33 a.m.
On Sun, 2020-09-27 at 04:26 -0700, ToddAndMargo via users wrote:
On 2020-09-27 03:29, Patrick O'Callaghan wrote:
> On Sat, 2020-09-26 at 17:44 -0700, ToddAndMargo via users wrote:
> > > And if it is the most likely memory usage, rebooting the kernel would
> >
> > > not fix anything as memory consumption is mostly a userspace problem.
> >
> >
> >
> > Also, the mouse chasing the pop up menues has nothing
> >
> > to do with the file system.
> >
> >
> >
> >
> >
> > I am at a loss. If it was a hardware issue, a reboot would not fix it.
>
> There are several things you can test to try to narrow it down:
> - Log out and in again
> - Restart the DE without rebooting
> - Try a different DE
>
> poc
Have not tried the log out and back in thing.
What is a "DE"
Desktop Environment, i.e. the GUI and associated stuff you use to
interact with the system. You said you were using Xfce. You could try
KDE or Gnome among others as a test. If they're installed, it's just a
matter of selecting one from the login screen. Your other software
should continue to work.
poc
6:40 a.m.
From the vmstat, all of the time is idle, you do not have any wait,
generally if you have a disk having issues the iowait will go up, but
you have zero.
Also from vmstat, the system time is low.
So the gui gets slow, a reboot clears it, does it clear up?
You might want to include a messages file from +=5 minutes of the the
issue happening.
Weird kernel bugs causing kernel lock issues would produce this
behavior, and would don't usually show on vmstat, but they can be seen
in the messages file.
On Sat, Sep 26, 2020 at 7:51 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> >> On 2020-09-26 03:20, Patrick O'Callaghan wrote:
> >>> On Sat, 2020-09-26 at 01:45 -0700, ToddAndMargo via users wrote:
> >>>> On 2020-09-26 01:41, Patrick O'Callaghan wrote:
> >>>>> On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users
wrote:
> >>>>>> Hi All,
> >>>>>>
> >>>>>> Is there a way to reload or restart the kernel without
> >>>>>> having to reboot?
> >>>>>
> >>>>> No.
> >>>>>
> >>>>> poc
>
>
> >>>> Poop!
> >>>>
> >>>> Thank you for the confirmation.
> >>>>
> >>>> Is the file system part of the kernel? If not, is there
> >>>> a way to restart it without rebooting?
>
>
> >>> Depends what you mean by "the file system". Some filesystems
are
> >>> reloadable (either as a module or as FUSE), but others aren't. The
> >>> underlying filesystem layer is a fixed part of the kernel.
> >>>
> >>> Maybe if you explained what you're trying to do, someone might be
able
> >>> to help.
> >>>
> >>> poc
>
> >>
> >> FC 32, x64
> >> Ext4
> >> Xfce 4.14
> >>
> >> Occasionally, my computers slows down. I have not been
> >> able to pin down why. Top shows very little memory usage.
> >>
> >> A 1 hour, 12 minute dump (dump/restore) takes 15 hours
> >> when this happens. Pop up menus start to lag behind
> >> the mouse
> >>
> >> I am trying to get around the reboot thing.
> >>
> >> -T
> >>
> >> A reboot ALWAYS fixes the issue.
>
> On 2020-09-26 16:22, Roger Heflin wrote:
> > Usually that slow down is swapping. Have you checked to see how much
> > swap is in use?
>
> top - 17:39:41 up 1:55, 1 user, load average: 0.26, 0.37, 0.37
>
> Tasks: 245 total, 2 running, 243 sleeping, 0 stopped, 0 zombie
>
> %Cpu(s): 3.6 us, 0.8 sy, 0.0 ni, 95.2 id, 0.2 wa, 0.2 hi, 0.1 si,
> 0.0 st
>
> MiB Mem : 15896.7 total, 11478.9 free, 1867.8 used, 2550.0 buff/cache
>
> MiB Swap: 8031.0 total, 8031.0 free, 0.0 used. 13333.0 avail Mem
>
>
> >
> > I have machines with 10gb of ram and that is not enough and used to
> > get slowdowns prior to me setting up earlyoom. With earlyoom it
> > generally kills sets of firefox tabs and generally works ok, but I
> > have had things get bad enough that it keeps killing the tab I want to
> > view and then I have to find someone else to kill so I have enough
> > ram.
>
> When it happens, it is instant
>
> > if you have sysstat / sar installed it would have data you could view
> > with sar -S that would tell you if it is swapping/paging.
> >
> > vmstat 1
> > swpd column, that is the numberof kb swapped, the higher it gets the
> > uglier it gets.
>
> $ vmstat 1
> procs -----------memory---------- ---swap-- -----io---- -system--
> ------cpu-----
> r b swpd free buff cache si so bi bo in cs us sy
> id wa st
> 1 0 0 11738732 150112 2474552 0 0 70 21 289 516 3
> 2 95 0 0
> 0 0 0 11749568 150112 2462464 0 0 0 0 615 1458 1
> 1 97 0 0
> 0 0 0 11749708 150112 2462464 0 0 0 0 488 1016 1
> 1 98 0 0
> 1 0 0 11749820 150128 2462464 0 0 0 296 478 1185 1
> 1 98 0 0
> 0 0 0 11749820 150128 2462480 0 0 0 0 477 1068 2
> 1 98 0 0
> 0 0 0 11749568 150128 2462464 0 0 0 8 480 1043 1
> 1 99 0 0
> 0 0 0 11749048 150144 2462464 0 0 0 244 693 1425 2
> 1 97 0 0
>
>
> >
> > And if it is the most likely memory usage, rebooting the kernel would
> > not fix anything as memory consumption is mostly a userspace problem.
>
> Also, the mouse chasing the pop up menues has nothing
> to do with the file system.
>
>
> I am at a loss. If it was a hardware issue, a reboot would not fix it.
>
> And my almost identical shop computer does not do this.
>
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
5:21 a.m.
On Sat, 2020-09-26 at 16:11 -0700, ToddAndMargo via users wrote:
On 2020-09-26 03:20, Patrick O'Callaghan wrote:
> On Sat, 2020-09-26 at 01:45 -0700, ToddAndMargo via users wrote:
> > On 2020-09-26 01:41, Patrick O'Callaghan wrote:
> > > On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
> > > > Hi All,
> > > >
> > > > Is there a way to reload or restart the kernel without
> > > > having to reboot?
> > >
> > > No.
> > >
> > > poc
> >
> > Poop!
> >
> > Thank you for the confirmation.
> >
> > Is the file system part of the kernel? If not, is there
> > a way to restart it without rebooting?
>
> Depends what you mean by "the file system". Some filesystems are
> reloadable (either as a module or as FUSE), but others aren't. The
> underlying filesystem layer is a fixed part of the kernel.
>
> Maybe if you explained what you're trying to do, someone might be able
> to help.
>
> poc
FC 32, x64
Ext4
Xfce 4.14
Occasionally, my computers slows down. I have not been
able to pin down why. Top shows very little memory usage.
A 1 hour, 12 minute dump (dump/restore) takes 15 hours
when this happens. Pop up menus start to lag behind
the mouse
I am trying to get around the reboot thing.
-T
A reboot ALWAYS fixes the issue.
It's highly likely that the issue is not being fixed by the kernel
rebooting as by processes being killed and restarted, which is what
happens when you reboot. A live reboot that doesn't restart processes
is probably not going to help.
poc
11:23 p.m.
ToddAndMargo via users writes:
A reboot ALWAYS fixes the issue.
That's probably because it reinitializes *all* the data structures, in
the kernel, in system processes, and in user processes. Evidently
clearing state is what fixes your problem.
I am trying to get around the reboot thing.
Loading the kernel is very fast. What takes time is initializing
hardware and all the data structures. Since you don't know where the
problem is, that's really the only sure way.
Somebody (quite possibly you, since you're the one with direct access
to the machine) needs to find out what aspect of state (probably not
swap from your data) is causing the slowdown. Have you checked for
bitcoin miners? ;-)
5:41 a.m.
On Sun, 2020-09-27 at 21:40 -0700, ToddAndMargo via users wrote:
although Firefox is slow to open tabs, by what is new about that?
How many do you have open?
--
uname -rsvp
Linux 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
11:54 p.m.
On 2020-09-27 21:23, Stephen J. Turnbull wrote:
Somebody (quite possibly you, since you're the one with direct
access
to the machine) needs to find out what aspect of state (probably not
swap from your data) is causing the slowdown
How do I do that?
Also, I ran
# lynis audit system
and
# /usr/bin/chkrootkit
No malware located
7:49 a.m.
On Sat, Sep 26, 2020 at 04:11:33PM -0700, ToddAndMargo via users wrote:
FC 32, x64
Ext4
Xfce 4.14
Occasionally, my computers slows down. I have not been
able to pin down why. Top shows very little memory usage.
A 1 hour, 12 minute dump (dump/restore) takes 15 hours
when this happens. Pop up menus start to lag behind
the mouse
I am trying to get around the reboot thing.
-T
A reboot ALWAYS fixes the issue.
Brendan Gregg has written several good talks and documents about
various Linux performance measurement tools. You might want to see
what the kernel is doing when you see sluggish behavior.
http://brendangregg.com/linuxperf.html
It does require some deep spelunking into the kernel internals, but it
is actually quite amazing what the kernel has for monitoring its
activities. I use it quite often to debug filesystem behavior, just
poke around /sys/kernel/debug/tracing/events/.
https://www.kernel.org/doc/html/v5.8/trace/events.html
From my experience, as an end user providing feedback, the kernel
developers really like it when you can point out a particular syscall
from the trace output that is misbehaving.
--
Jonathan Billings <billings(a)negate.org>
7:24 a.m.
On 2020-09-28 05:49, Jonathan Billings wrote:
On Sat, Sep 26, 2020 at 04:11:33PM -0700, ToddAndMargo via users
wrote:
> FC 32, x64
> Ext4
> Xfce 4.14
>
> Occasionally, my computers slows down. I have not been
> able to pin down why. Top shows very little memory usage.
>
> A 1 hour, 12 minute dump (dump/restore) takes 15 hours
> when this happens. Pop up menus start to lag behind
> the mouse
>
> I am trying to get around the reboot thing.
>
> -T
>
> A reboot ALWAYS fixes the issue.
Brendan Gregg has written several good talks and documents about
various Linux performance measurement tools. You might want to see
what the kernel is doing when you see sluggish behavior.
http://brendangregg.com/linuxperf.html
It does require some deep spelunking into the kernel internals, but it
is actually quite amazing what the kernel has for monitoring its
activities. I use it quite often to debug filesystem behavior, just
poke around /sys/kernel/debug/tracing/events/.
Anything is particular to look at?
https://www.kernel.org/doc/html/v5.8/trace/events.html
From my experience, as an end user providing feedback, the kernel
developers really like it when you can point out a particular syscall
from the trace output that is misbehaving.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8:49 a.m.
On Tue, 29 Sep 2020 at 09:26, ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 2020-09-28 05:49, Jonathan Billings wrote:
> On Sat, Sep 26, 2020 at 04:11:33PM -0700, ToddAndMargo via users wrote:
>> FC 32, x64
>> Ext4
>> Xfce 4.14
>>
>> Occasionally, my computers slows down. I have not been
>> able to pin down why. Top shows very little memory usage.
>>
>> A 1 hour, 12 minute dump (dump/restore) takes 15 hours
>> when this happens. Pop up menus start to lag behind
>> the mouse
>>
>> I am trying to get around the reboot thing.
>>
>> -T
>>
>> A reboot ALWAYS fixes the issue.
>
> Brendan Gregg has written several good talks and documents about
> various Linux performance measurement tools. You might want to see
> what the kernel is doing when you see sluggish behavior.
>
> http://brendangregg.com/linuxperf.html
>
This is an excellent site. For starters, though, bpytop gives an overview
that
may help focus your investigation.
> It does require some deep spelunking into the kernel internals, but it
> is actually quite amazing what the kernel has for monitoring its
> activities. I use it quite often to debug filesystem behavior, just
> poke around /sys/kernel/debug/tracing/events/.
Anything is particular to look at?
For starters: temperature spikes (numerous utilities, including bpytop) and
disk
errors (smartmontools). This doesn't appear to be a widespread problem,
so
you should think about malware, uncommon hardware, uncommon software.
If you have the resources to swap out the storage and start with a fresh
install
to see if the problem goes away that would help narrow the search.
>
> https://www.kernel.org/doc/html/v5.8/trace/events.html
>
> From my experience, as an end user providing feedback, the kernel
> developers really like it when you can point out a particular syscall
> from the trace output that is misbehaving.
Very true.
--
George N. White III
3:51 a.m.
On 2020-09-26 01:41, Patrick O'Callaghan wrote:
On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
> Hi All,
>
> Is there a way to reload or restart the kernel without
> having to reboot?
No.
poc
Somewhere I read that they were working on the ability
to start a new kernel after a dnf upgrde without rebooting.
That ever happen?
4:53 a.m.
On 9/26/20 5:51 PM, ToddAndMargo via users wrote:
On 2020-09-26 01:41, Patrick O'Callaghan wrote:
> On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
>> Hi All,
>>
>> Is there a way to reload or restart the kernel without
>> having to reboot?
>
> No.
>
> poc
Somewhere I read that they were working on the ability
to start a new kernel after a dnf upgrde without rebooting.
That ever happen?
Hope you can provide any references :)
It sounds interesting.
--
Regards,
W.H.Jeon
5:25 a.m.
On Sat, 2020-09-26 at 01:51 -0700, ToddAndMargo via users wrote:
On 2020-09-26 01:41, Patrick O'Callaghan wrote:
> On Sat, 2020-09-26 at 00:38 -0700, ToddAndMargo via users wrote:
> > Hi All,
> >
> > Is there a way to reload or restart the kernel without
> > having to reboot?
>
> No.
>
> poc
Somewhere I read that they were working on the ability
to start a new kernel after a dnf upgrde without rebooting.
That ever happen?
There is a long-standing project that aims to do something like that (
https://github.com/dynup/kpatch), but AFAIK it's not production quality
so far. Personally, I'm sceptical that it will ever be useful except in
very constrained conditions. For one thing, it's not clear that there's
much demand for it.
poc
10:45 a.m.
Patrick O'Callaghan writes:
On Sat, 2020-09-26 at 01:51 -0700, ToddAndMargo via users wrote:
> Somewhere I read that they were working on the ability
> to start a new kernel after a dnf upgrde without rebooting.
> That ever happen?
There is a long-standing project that aims to do something like that (
https://github.com/dynup/kpatch), but AFAIK it's not production quality
so far. Personally, I'm sceptical that it will ever be useful except in
very constrained conditions. For one thing, it's not clear that there's
much demand for it.
No, that's not what this is trying to do. Not even close.
This project attempts to implement the ability to patch the running kernel,
in a number of limited situations.
This is nowhere close to loading a brand new kernel and somehow seamlessly
switching to it.
10:56 a.m.
On Sat, 2020-09-26 at 11:45 -0400, Sam Varshavchik wrote:
Patrick O'Callaghan writes:
> On Sat, 2020-09-26 at 01:51 -0700, ToddAndMargo via users wrote:
>
> > Somewhere I read that they were working on the ability
> > to start a new kernel after a dnf upgrde without rebooting.
> > That ever happen?
>
> There is a long-standing project that aims to do something like that (
> https://github.com/dynup/kpatch), but AFAIK it's not production quality
> so far. Personally, I'm sceptical that it will ever be useful except in
> very constrained conditions. For one thing, it's not clear that there's
> much demand for it.
No, that's not what this is trying to do. Not even close.
This project attempts to implement the ability to patch the running kernel,
in a number of limited situations.
This is nowhere close to loading a brand new kernel and somehow seamlessly
switching to it.
Fair enough. I was never that interested so didn't take the trouble to
read the details.
poc
11:17 a.m.
On Sat, 2020-09-26 at 11:45 -0400, Sam Varshavchik wrote:
Patrick O'Callaghan writes:
> There is a long-standing project that aims to do something like that (
> https://github.com/dynup/kpatch), but AFAIK it's not production quality
> so far. Personally, I'm sceptical that it will ever be useful except in
> very constrained conditions. For one thing, it's not clear that there's
> much demand for it.
No, that's not what this is trying to do. Not even close.
This project attempts to implement the ability to patch the running kernel,
in a number of limited situations.
This is nowhere close to loading a brand new kernel and somehow seamlessly
switching to it.
For completeness, I'll mention that there are solutions that
semantically reboot into a brand new kernel but transfer the userspace
state to it with a minimum of actual downtime:
https://criu.org/Seamless_kernel_upgrade
This is like hibernating and immediately resuming except that the
userspace state is transferred in a format that is compatible across
kernel versions. However, it's unclear if any of these solutions are
reasonable for typical end users.
Matt
10:43 a.m.
ToddAndMargo via users writes:
Somewhere I read that they were working on the ability
to start a new kernel after a dnf upgrde without rebooting.
That ever happen?
Highly unlikely that this will ever happen, for a whole variety of technical
reasons. This is pretty much a technical impossibility.
9:14 a.m.
On Sat, Sep 26, 2020 at 01:51:59AM -0700, ToddAndMargo via users wrote:
Somewhere I read that they were working on the ability
to start a new kernel after a dnf upgrde without rebooting.
The reason we want to do this is to avoid the need to re-enter your disk
encryption passphrase. It'll still mean everything restarts in this case.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:08 a.m.
在 2020-09-26星期六的 00:38 -0700，ToddAndMargo via users写道：
Hi All,
Is there a way to reload or restart the kernel without
having to reboot?
You can reload the whole OS by kexec, which is not considered as
reboot
(technically) since you don't redo the whole booting process and
directly go to new kernel. (and all userspace process are killed, just
like a normal reboot)
But I am pretty sure that this isn't the answer you are looking for, if
you are finding a way to replace/change the current kernel without
affecting userland, yes, but it can be tricky. We have kpatch and
similar things, they are not that powerful to handle all kernel updates
(those live patch tools are mostly for security patches, and if the
update add/removed a kernel func, changed a internel structure, they
may not work). They can override methods and can't do further things,
yet.
Many thanks,
-T
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When we ask for advice, we are usually looking for an accomplice.
-- Charles Varlet de La Grange
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
1298
days inactive
1301
days old
30 comments
12 participants
participants (12)
-
George N. White III -
Jonathan Billings -
Matt McCutchen -
Matthew Miller -
nico＠niconi.org -
Patrick O'Callaghan -
Roger Heflin -
Sam Varshavchik -
Stephen J. Turnbull -
Tim -
ToddAndMargo -
WooHyung Jeon