Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
... ?! Is it really necessary to *reboot* because two desktop components have been upgraded? Shouldn't a logout/login be enough? This sounds like overkill, specially if you're the only one using the computer (i.e. there are no other users using those libraries/services besides you -- *if* you're using them). I don't even use Evolution!
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
I used to be proud of Linux only needing a reboot when the kernel (or some key component) was upgraded. This is sadly feeling like "those good old times" :-(
Regards,
Andre
On 08/31/2010 03:17 PM, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
... ?! Is it really necessary to *reboot* because two desktop components have been upgraded? Shouldn't a logout/login be enough? This sounds like overkill, specially if you're the only one using the computer (i.e. there are no other users using those libraries/services besides you -- *if* you're using them). I don't even use Evolution!
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
I used to be proud of Linux only needing a reboot when the kernel (or some key component) was upgraded. This is sadly feeling like "those good old times" :-(
Regards,
Andre
It was bound to happen. Way too many daemons are running linked with libraries that just got updated. That said, I think that unless you want to boot with the updated kernel, you can get away with just doing;
sudo init 1 Once you are in the single user shell, issue
init 5
This will at least get you running the the latest apps and libs while staying with the currently booted kernel.
On Tue, 2010-08-31 at 15:47 -0700, JD wrote:
On 08/31/2010 03:17 PM, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
... ?! Is it really necessary to *reboot* because two desktop components have been upgraded? Shouldn't a logout/login be enough? This sounds like overkill, specially if you're the only one using the computer (i.e. there are no other users using those libraries/services besides you -- *if* you're using them). I don't even use Evolution!
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
I used to be proud of Linux only needing a reboot when the kernel (or some key component) was upgraded. This is sadly feeling like "those good old times" :-(
Regards,
Andre
It was bound to happen. Way too many daemons are running linked with libraries that just got updated. That said, I think that unless you want to boot with the updated kernel, you can get away with just doing;
sudo init 1 Once you are in the single user shell, issue
init 5
This will at least get you running the the latest apps and libs while staying with the currently booted kernel.
In this particulary case, why not just an evolution --force-shutdown? This will shutdown evolution-data-server. As simple as that.
On 08/31/2010 04:48 PM, kalinix wrote:
On Tue, 2010-08-31 at 15:47 -0700, JD wrote:
On 08/31/2010 03:17 PM, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
... ?! Is it really necessary to *reboot* because two desktop components have been upgraded? Shouldn't a logout/login be enough? This sounds like overkill, specially if you're the only one using the computer (i.e. there are no other users using those libraries/services besides you -- *if* you're using them). I don't even use Evolution!
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
I used to be proud of Linux only needing a reboot when the kernel (or some key component) was upgraded. This is sadly feeling like "those good old times" :-(
Regards,
Andre
It was bound to happen. Way too many daemons are running linked with libraries that just got updated. That said, I think that unless you want to boot with the updated kernel, you can get away with just doing;
sudo init 1 Once you are in the single user shell, issue
init 5
This will at least get you running the the latest apps and libs while staying with the currently booted kernel.
In this particulary case, why not just an evolution --force-shutdown? This will shutdown evolution-data-server. As simple as that.
Is this thread only about evolution updates?
Why not just only apply updates when you feel like rebooting? That's what I do. I've lived without them my whole life, a few more days won't hurt anything.
Of course, I also turn off the annoying packagekit app that is like an animated paperclip tapping on my screen saying:
"Hey! There's updates! Don't you want to apply updates! Com'on, it will be fun! Let's go update the system! You don't have anything better to do".
On Tue, 2010-08-31 at 20:20 -0400, Tom Horsley wrote:
Why not just only apply updates when you feel like rebooting? That's what I do. I've lived without them my whole life, a few more days won't hurt anything.
Of course, I also turn off the annoying packagekit app that is like an animated paperclip tapping on my screen saying:
"Hey! There's updates! Don't you want to apply updates! Com'on, it will be fun! Let's go update the system! You don't have anything better to do".
http://www.imagepoop.com/image/660/I-Reboot-As-Much-As-I-Get-Laid.html
:))
On Tue, Aug 31, 2010 at 22:37, kalinix calin.kalinix.cosma@gmail.comwrote:
On Tue, 2010-08-31 at 20:20 -0400, Tom Horsley wrote:
Why not just only apply updates when you feel like rebooting? That's what I do. I've lived without them my whole life, a few more days won't hurt anything.
Of course, I also turn off the annoying packagekit app that is like an animated paperclip tapping on my screen saying:
"Hey! There's updates! Don't you want to apply updates! Com'on, it will be fun! Let's go update the system! You don't have anything better to do".
http://www.imagepoop.com/image/660/I-Reboot-As-Much-As-I-Get-Laid.html
:))
Hahaha... awesome! :-) ... oh, wait a minute... damn it! :-/
On Tue, 31 Aug 2010 20:20:23 -0400, Tom wrote:
Of course, I also turn off the annoying packagekit app that is like an animated paperclip tapping on my screen saying:
"Hey! There's updates! Don't you want to apply updates! Com'on, it will be fun! Let's go update the system! You don't have anything better to do".
I've tried hard not to turn it off in F13 and F14 Branched, so I could test it, … but it is just plain annoying to see it fail due to a broken dependency and then refuse to remove itself from the notification area. That's too much of a distraction for me.
On 1 September 2010 11:26, Michael Schwendt mschwendt@gmail.com wrote:
I've tried hard not to turn it off in F13 and F14 Branched, so I could test it, … but it is just plain annoying to see it fail due to a broken dependency and then refuse to remove itself from the notification area. That's too much of a distraction for me.
Can't you just change the preferences to check for updates "Never"?
Also, you forgot to point to bugzillas in your email. Removing itself from the icon after a failed dep update is probably a sane thing to do.
Richard.
On Wed, 1 Sep 2010 11:41:50 +0100, Richard wrote:
I've tried hard not to turn it off in F13 and F14 Branched, so I could test it, … but it is just plain annoying to see it fail due to a broken dependency and then refuse to remove itself from the notification area. That's too much of a distraction for me.
Can't you just change the preferences to check for updates "Never"?
?? Also with F13? Then I could return to running "yum -y update --skip-broken" instead of letting an autostarted desktop app be "more convenient". Right?
Also, you forgot to point to bugzillas in your email.
There is no bugzilla ticket about it, because I simply don't have the time to open tickets for _every_ issue I run into and have - package maintainers possibly ignore the tickets for months, and - dist EOL bug autoclosing scripts force me to re-examine dozens of issues.
So, typically I open only a limited number of tickets, and only if there is progress, I will consider reporting further issues.
For some things it's simply much more easier to just disable it and move on. Eventually, there will be another user to notice and report the same issue, and that will spread the load. Or it's on some todo-list already. Time will tell. Problems, such as the package list view paging up and down automatically (and wildly) during download even if the user wants to scroll manually, is a UI issue that won't go unnoticed forever.
Removing itself from the icon after a failed dep update is probably a sane thing to do.
Richard.
On 1 September 2010 12:08, Michael Schwendt mschwendt@gmail.com wrote:
Then I could return to running "yum -y update --skip-broken" instead of letting an autostarted desktop app be "more convenient". Right?
Up to you.
Also, you forgot to point to bugzillas in your email.
There is no bugzilla ticket about it, because I simply don't have the time to open tickets for _every_ issue I run into and have
Then please don't send sarky emails to users@lists.fedoraproject.org
Thanks,
Richard.
On Thu, 2 Sep 2010 08:02:40 +0100, Richard wrote:
Also, you forgot to point to bugzillas in your email.
There is no bugzilla ticket about it, because I simply don't have the time to open tickets for _every_ issue I run into and have
Then please don't send sarky emails to users@lists.fedoraproject.org
No idea where you've found sarcasm in my mails in this thread. Rather I could call one of your mails "sarky" (the one quoted at the very top). [And just for completeness, I've not been s_n_arky either.]
I will continue to participate on this list whenever I like to. There has been a comment about "turn[ing] off the annoying packagekit app", and that has prompted me to reply to it. Often, it makes a lot of sense to talk about something before submitting a problem report.
On Tue, 2010-08-31 at 17:04 -0700, JD wrote:
In this particulary case, why not just an evolution --force-shutdown? This will shutdown evolution-data-server. As simple as that.
Is this thread only about evolution updates?
the OP complained about two components, which happened to be evolution related. And moreover, the second component, libgtkhtml only deals with evolution itself, not even the data-server. So I gave him a simpler solution to avoid from entering runlevel 1 and then re-entering runlevel 5 (geez, you always do this when you update your system?). That's why I wrote in my post "in this particular case".
But of course, if you think that finding which daemon should be updated, killing it and then restarting (as linux always worked, even before the fancy, candy-eyed, gui apps that make it looks like crappy windows) is a little bit overkill, a simple reboot would save you from this pain. As a matter of fact, those gui apps were meant exactly for this.
BTW, this reminded me to reboot to load the latest kernel... I was 4 releases behind ;)
On 08/31/2010 05:31 PM, kalinix wrote:
On Tue, 2010-08-31 at 17:04 -0700, JD wrote:
In this particulary case, why not just an evolution --force-shutdown? This will shutdown evolution-data-server. As simple as that.
Is this thread only about evolution updates?
the OP complained about two components, which happened to be evolution related. And moreover, the second component, libgtkhtml only deals with evolution itself, not even the data-server. So I gave him a simpler solution to avoid from entering runlevel 1 and then re-entering runlevel 5 (geez, you always do this when you update your system?). That's why I wrote in my post "in this particular case".
But of course, if you think that finding which daemon should be updated, killing it and then restarting (as linux always worked, even before the fancy, candy-eyed, gui apps that make it looks like crappy windows) is a little bit overkill, a simple reboot would save you from this pain. As a matter of fact, those gui apps were meant exactly for this.
BTW, this reminded me to reboot to load the latest kernel... I was 4 releases behind ;)
Ala tha OP that compared linux to windows as far as the frequent reboots required after updates: perhaps Linux should be renamed Winux :) :) Just kidding :)
Hi Calin,
On Tue, Aug 31, 2010 at 20:48, kalinix calin.kalinix.cosma@gmail.com wrote:
In this particulary case, why not just an evolution --force-shutdown? This will shutdown evolution-data-server. As simple as that.
Yes, it's simple. So simple it should have been handled automatically by the upgrade *without a reboot* ;-)
I appreciate all the tips (really), but my point is not specifically about Evolution, it's just that I believe reboots are being required unnecessarily. Upgrades could and should be smarter. It seems we're stepping backwards.
Regards,
Andre
Hi JD,
On Tue, Aug 31, 2010 at 19:47, JD jd1008@gmail.com wrote:
On 08/31/2010 03:17 PM, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
... ?! Is it really necessary to *reboot* because two desktop components have been upgraded? Shouldn't a logout/login be enough? This sounds like overkill, specially if you're the only one using the computer (i.e. there are no other users using those libraries/services besides you -- *if* you're using them). I don't even use Evolution!
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
I used to be proud of Linux only needing a reboot when the kernel (or some key component) was upgraded. This is sadly feeling like "those good old times" :-(
Regards,
Andre
It was bound to happen. Way too many daemons are running linked with libraries that just got updated. That said, I think that unless you want to boot with the updated kernel, you can get away with just doing;
sudo init 1 Once you are in the single user shell, issue
init 5
This will at least get you running the the latest apps and libs while staying with the currently booted kernel.
Yes, it's slightly better than a reboot, but still more "drastic" than it should be IMHO. In this particular case (and many others I've seen recently), a simple logout should be enough AFAICS.
Regards,
Andre
On 08/31/2010 05:56 PM, Andre Costa wrote:
Hi JD,
On Tue, Aug 31, 2010 at 19:47, JDjd1008@gmail.com wrote:
On 08/31/2010 03:17 PM, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
... ?! Is it really necessary to *reboot* because two desktop components have been upgraded? Shouldn't a logout/login be enough? This sounds like overkill, specially if you're the only one using the computer (i.e. there are no other users using those libraries/services besides you -- *if* you're using them). I don't even use Evolution!
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
I used to be proud of Linux only needing a reboot when the kernel (or some key component) was upgraded. This is sadly feeling like "those good old times" :-(
Regards,
Andre
It was bound to happen. Way too many daemons are running linked with libraries that just got updated. That said, I think that unless you want to boot with the updated kernel, you can get away with just doing;
sudo init 1 Once you are in the single user shell, issue
init 5
This will at least get you running the the latest apps and libs while staying with the currently booted kernel.
Yes, it's slightly better than a reboot, but still more "drastic" than it should be IMHO. In this particular case (and many others I've seen recently), a simple logout should be enough AFAICS.
Regards,
Andre
A simple logout will not kill the many daemons and processes that are still running AND linked to the older, just replaced libraries. Furthermore, the very daemons themelves may have been replaced. Such is life when you use a bleeding edge distro like Fedora. There are other distros that do not issue so many updates so frequently. Try Centos.
On Tue, 2010-08-31 at 18:50 -0700, JD wrote:
A simple logout will not kill the many daemons and processes that are still running AND linked to the older, just replaced libraries.
But, in this case, when you logout, your use of the evolution data server /should/ completely exit (there's no need for it to still be doing something for when you're not there). And it should be free to restart. Though, if you had multiple users logged in, rebooting does become the simple way around it.
I do notice that there's often a variety of lingering things, sometimes, when you log out, that ought to quit, but don't.
On 09/01/2010 04:24 AM, Tim wrote:
On Tue, 2010-08-31 at 18:50 -0700, JD wrote:
A simple logout will not kill the many daemons and processes that are still running AND linked to the older, just replaced libraries.
But, in this case, when you logout, your use of the evolution data server /should/ completely exit (there's no need for it to still be doing something for when you're not there). And it should be free to restart. Though, if you had multiple users logged in, rebooting does become the simple way around it.
I do notice that there's often a variety of lingering things, sometimes, when you log out, that ought to quit, but don't.
That is true iff evolution daemon only starts when you login, and dies when you logout; AND iff evolution is your only concern.
On Tue, 2010-08-31 at 19:17 -0300, Andre Costa wrote:
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
needs-restarting ("yum install yum-utils" if you don't have it). This will catch everything except the kernel, but that one is obvious.
poc
On Tue, Aug 31, 2010 at 20:17, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2010-08-31 at 19:17 -0300, Andre Costa wrote:
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
needs-restarting ("yum install yum-utils" if you don't have it). This will catch everything except the kernel, but that one is obvious.
That's nice, I didn't know needs-restarting, it will definitely be useful (it is installed). Thks =)
Still, my point is: this kind of check should be handled automatically by the upgrade process, and the user should only be asked to reboot if there's *really* need to do so. Eg. right now, after those two upgrades I mentioned, that read "reboot me!" icon is sitting on my notification panel, but if I run 'needs-restarting' this is what I get:
3478 : /usr/libexec/clock-applet--oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory--oaf-ior-fd=42 3484 : /usr/sbin/restorecond-u 3501 : pidgin
Aside from restorecond, it's obvious I don't need to restart because clock-applet and pidgin were upgraded... :-/ (and even restorecond might not require a reboot).
Andre
On Tue, 2010-08-31 at 21:43 -0300, Andre Costa wrote:
On Tue, Aug 31, 2010 at 20:17, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2010-08-31 at 19:17 -0300, Andre Costa wrote:
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
needs-restarting ("yum install yum-utils" if you don't have it). This will catch everything except the kernel, but that one is obvious.
That's nice, I didn't know needs-restarting, it will definitely be useful (it is installed). Thks =)
Still, my point is: this kind of check should be handled automatically by the upgrade process, and the user should only be asked to reboot if there's *really* need to do so. Eg. right now, after those two upgrades I mentioned, that read "reboot me!" icon is sitting on my notification panel, but if I run 'needs-restarting' this is what I get:
3478 : /usr/libexec/clock-applet--oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory--oaf-ior-fd=42 3484 : /usr/sbin/restorecond-u 3501 : pidgin
Aside from restorecond, it's obvious I don't need to restart because clock-applet and pidgin were upgraded... :-/ (and even restorecond might not require a reboot).
Andre
Andre, I think needs-restarting means those applications need to be restarted, not you need to restart the whole system to update those applications. As well as 'reboot me' should means exactly that: reboot that particular application. I never ever saw a linux system which has to be rebooted in order to update pidgin.
On Tue, Aug 31, 2010 at 21:59, kalinix calin.kalinix.cosma@gmail.com wrote:
On Tue, 2010-08-31 at 21:43 -0300, Andre Costa wrote:
On Tue, Aug 31, 2010 at 20:17, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2010-08-31 at 19:17 -0300, Andre Costa wrote:
Isn't there any more clever way of determining if a reboot is really necessary? Or maybe at least the message should be less "demanding", I don't know... it really seems unneeded.
needs-restarting ("yum install yum-utils" if you don't have it). This will catch everything except the kernel, but that one is obvious.
That's nice, I didn't know needs-restarting, it will definitely be useful (it is installed). Thks =)
Still, my point is: this kind of check should be handled automatically by the upgrade process, and the user should only be asked to reboot if there's *really* need to do so. Eg. right now, after those two upgrades I mentioned, that read "reboot me!" icon is sitting on my notification panel, but if I run 'needs-restarting' this is what I get:
3478 : /usr/libexec/clock-applet--oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory--oaf-ior-fd=42 3484 : /usr/sbin/restorecond-u 3501 : pidgin
Aside from restorecond, it's obvious I don't need to restart because clock-applet and pidgin were upgraded... :-/ (and even restorecond might not require a reboot).
Andre
Andre, I think needs-restarting means those applications need to be restarted, not you need to restart the whole system to update those applications.
Yes, that's what I understood as well. This is what I tried to evidence with my example.
As well as 'reboot me' should means exactly that: reboot that particular application.
Exactly. These userspace apps should be restated automatically after the upgrade, without bothering the user with a "reboot your computer to make sure any changes will be applied" warning.
I never ever saw a linux system which has to be rebooted in order to update pidgin.
Amen. If it ever happens, it will be time to move on to something else... ;-)
Andre
On Tue, 2010-08-31 at 22:15 -0300, Andre Costa wrote:
Andre, I think needs-restarting means those applications need to be restarted, not you need to restart the whole system to update those applications.
Yes, that's what I understood as well. This is what I tried to evidence with my example.
As well as 'reboot me' should means exactly that: reboot that particular application.
Exactly. These userspace apps should be restated automatically after the upgrade, without bothering the user with a "reboot your computer to make sure any changes will be applied" warning.
Well you must admit that is not a very nice feeling to see that your text editor, or your mail client just restarted, in the middle of something extremely important, or even better, your pidgin restarted right in the middle of a conference with your boss :) . That's why it gives you the option to restart those particular applications at your own will. And I emphasize: those specific applications, not the entire system. I don't know about the other message (and my personal opinion is you can completely forget about it), as I only use yum, but I can tell you this: before restarting my system (F13) this evening in order to load the latest kernel, I had at least 40 days uptime, with an fully up to date system (except of course for kernel which was 4 releases old).
So my advice is: restart only those applications that show up in needs-restarting and forget about reboots, until a new kernel is released. And switch to yum :)
I never ever saw a linux system which has to be rebooted in order to update pidgin.
Amen. If it ever happens, it will be time to move on to something else... ;-)
Andre
On Tue, 2010-08-31 at 22:15 -0300, Andre Costa wrote:
These userspace apps should be restated automatically after the upgrade, without bothering the user with a "reboot your computer to make sure any changes will be applied" warning.
Suddenly restarting apps without consulting the user is the last thing we need. Even the "please reboot" message is simply a suggestion, and if you use yum directly rather than via PK you won't even see it.
poc
Why use the application anyway? It's faster from xterm.
On 8/31/10, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2010-08-31 at 22:15 -0300, Andre Costa wrote:
These userspace apps should be restated automatically after the upgrade, without bothering the user with a "reboot your computer to make sure any changes will be applied" warning.
Suddenly restarting apps without consulting the user is the last thing we need. Even the "please reboot" message is simply a suggestion, and if you use yum directly rather than via PK you won't even see it.
poc
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
On Wed, Sep 1, 2010 at 00:11, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2010-08-31 at 22:15 -0300, Andre Costa wrote:
These userspace apps should be restated automatically after the upgrade, without bothering the user with a "reboot your computer to make sure any changes will be applied" warning.
Suddenly restarting apps without consulting the user is the last thing we need. Even the "please reboot" message is simply a suggestion, and if you use yum directly rather than via PK you won't even see it.
That's a good point (also made by Calin a couple of messages ago), it's obviously not practical, I would hate it as well. Please forget I even suggested that ;-)
Still, AFAICS a reboot shouldn't be necessary on such cases.
Andre
On Tue August 31 2010, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
what about ksplice?? I've heard about it, but don't know if it is ready yet..
On Tue, 2010-08-31 at 21:02 -0400, Paul Cartwright wrote:
On Tue August 31 2010, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
what about ksplice?? I've heard about it, but don't know if it is ready yet..
-- Paul Cartwright Registered Linux user # 367800
ksplice works only for kernels. And make several modules out of the deltas between the kernel release, which will be loaded in the older kernel. So you'll end up with, let's say 2.6.33.6-147 and a bunch of modules covering the patches up to the 2.6.33.8-149. Technically you are at 2.6.33.8-149. Practically you still run 2.6.33.6-147 (with improvements :) ).
kalinix wrote:
ksplice works only for kernels. And make several modules out of the deltas between the kernel release, which will be loaded in the older kernel. So you'll end up with, let's say 2.6.33.6-147 and a bunch of modules covering the patches up to the 2.6.33.8-149. Technically you are at 2.6.33.8-149. Practically you still run 2.6.33.6-147 (with improvements :) ).
What exactly is ksplice meant to do? I yum-installed it today, and then ran "yum update" which installed a new kernel. I expected this to start running, but it didn't. Admittedly I didn't read any instructions.
On Wed, 1 Sep 2010 15:31:43 -0500 Timothy Murphy gayleard@eircom.net wrote:
kalinix wrote:
ksplice works only for kernels. And make several modules out of the deltas between the kernel release, which will be loaded in the older kernel. So you'll end up with, let's say 2.6.33.6-147 and a bunch of modules covering the patches up to the 2.6.33.8-149. Technically you are at 2.6.33.8-149. Practically you still run 2.6.33.6-147 (with improvements :) ).
What exactly is ksplice meant to do? I yum-installed it today, and then ran "yum update" which installed a new kernel. I expected this to start running, but it didn't. Admittedly I didn't read any instructions.
Sounds very cool, and I had not heard of it before today also, but here is the results of yum info ksplice:
Summary : Patching a Linux kernel without reboot URL : http://ksplice.com License : GPLv2 Description : Ksplice allows system administrators to apply security patches to : the Linux kernel without having to reboot. Ksplice takes as input : a source code change in unified diff format and the kernel source : code to be patched, and it applies the patch to the corresponding : running kernel. The running kernel does not need to have been : prepared in advance in any way.
Is it too good to be true?
Ranjan
On Wed, Sep 01, 2010 at 15:45:51 -0500, Ranjan Maitra maitra@iastate.edu wrote:
Is it too good to be true?
You can read more about it at Linux Weekly New. One article is: http://lwn.net/Articles/340477/
Ranjan Maitra wrote:
What exactly is ksplice meant to do? I yum-installed it today, and then ran "yum update" which installed a new kernel. I expected this to start running, but it didn't. Admittedly I didn't read any instructions.
Sounds very cool, and I had not heard of it before today also, but here is the results of yum info ksplice:
Summary : Patching a Linux kernel without reboot URL : http://ksplice.com License : GPLv2 Description : Ksplice allows system administrators to apply security patches to : the Linux kernel without having to reboot. Ksplice takes as : input a source code change in unified diff format and the : kernel source code to be patched, and it applies the patch : to the corresponding running kernel. The running kernel does : not need to have been prepared in advance in any way.
Is it too good to be true?
Sorry, but it sounds to me as though it is much easier to re-boot.
On 09/01/2010 06:14 PM, Timothy Murphy wrote:
Ranjan Maitra wrote:
What exactly is ksplice meant to do? I yum-installed it today, and then ran "yum update" which installed a new kernel. I expected this to start running, but it didn't. Admittedly I didn't read any instructions.
Sounds very cool, and I had not heard of it before today also, but here is the results of yum info ksplice:
Summary : Patching a Linux kernel without reboot URL : http://ksplice.com License : GPLv2 Description : Ksplice allows system administrators to apply security patches to : the Linux kernel without having to reboot. Ksplice takes as : input a source code change in unified diff format and the : kernel source code to be patched, and it applies the patch : to the corresponding running kernel. The running kernel does : not need to have been prepared in advance in any way.
Is it too good to be true?
Sorry, but it sounds to me as though it is much easier to re-boot.
For most users, yes, much easier to reboot. But there are hundreds if not thousand of situations where a reboot is out of the question. If you have not worked in very large database center with thousands of clients all over the world, you will understand why sometimes a reboot would be out of the question.
On Wed, 2010-09-01 at 21:31 +0100, Timothy Murphy wrote:
kalinix wrote:
ksplice works only for kernels. And make several modules out of the deltas between the kernel release, which will be loaded in the older kernel. So you'll end up with, let's say 2.6.33.6-147 and a bunch of modules covering the patches up to the 2.6.33.8-149. Technically you are at 2.6.33.8-149. Practically you still run 2.6.33.6-147 (with improvements :) ).
What exactly is ksplice meant to do? I yum-installed it today, and then ran "yum update" which installed a new kernel. I expected this to start running, but it didn't. Admittedly I didn't read any instructions.
-- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
ksplice and yum update are two entirely different things. Let's say you are running kernel 2.6.33.6-147: yum update downloads and install the latest kernel release of your vendor of choice (e.g. Fedora's kernel 2.6.33.8-149) from your vendor's repository; ksplice update downloads only deltas between 2.6.33.6-147 and 2.6.33.8-149, compiled as modules, and apply them on the current running kernel. The deltas are downloaded from ksplice site, therefore are compiled by them. So if you ran yum update you just downloaded and installed the latest Fedora kernel, which needs reboot.
kalinix wrote:
What exactly is ksplice meant to do? I yum-installed it today, and then ran "yum update" which installed a new kernel. I expected this to start running, but it didn't. Admittedly I didn't read any instructions.
ksplice and yum update are two entirely different things. Let's say you are running kernel 2.6.33.6-147: yum update downloads and install the latest kernel release of your vendor of choice (e.g. Fedora's kernel 2.6.33.8-149) from your vendor's repository; ksplice update downloads only deltas between 2.6.33.6-147 and 2.6.33.8-149, compiled as modules, and apply them on the current running kernel. The deltas are downloaded from ksplice site, therefore are compiled by them. So if you ran yum update you just downloaded and installed the latest Fedora kernel, which needs reboot.
I yum-installed ksplice under Fedora-13. I don't seem to have any application called "ksplice", so how do I run "ksplice update" as you suggest?
On Thu, 2010-09-02 at 12:15 +0100, Timothy Murphy wrote:
kalinix wrote:
What exactly is ksplice meant to do? I yum-installed it today, and then ran "yum update" which installed a new kernel. I expected this to start running, but it didn't. Admittedly I didn't read any instructions.
ksplice and yum update are two entirely different things. Let's say you are running kernel 2.6.33.6-147: yum update downloads and install the latest kernel release of your vendor of choice (e.g. Fedora's kernel 2.6.33.8-149) from your vendor's repository; ksplice update downloads only deltas between 2.6.33.6-147 and 2.6.33.8-149, compiled as modules, and apply them on the current running kernel. The deltas are downloaded from ksplice site, therefore are compiled by them. So if you ran yum update you just downloaded and installed the latest Fedora kernel, which needs reboot.
I yum-installed ksplice under Fedora-13. I don't seem to have any application called "ksplice", so how do I run "ksplice update" as you suggest?
-- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Actually I wasn't very clear: the update command is 'uptrack-upgrade'. If you want to see the updates you can see them with uptrack-show.
If you're using X, you can see the patches with uptrack-manager
HTH,
On Tue, 2010-08-31 at 21:02 -0400, Paul Cartwright wrote:
On Tue August 31 2010, Andre Costa wrote:
Latest F13 upgrades include two packages that "require" a restart: evolution-data-server and GtkHTML.
what about ksplice?? I've heard about it, but don't know if it is ready yet..
-- Paul Cartwright Registered Linux user # 367800
P.S. Yes is ready and free for fedora users :)
Why not just do reboots at 3 in the morning and it just won't matter all that much. I just have a cron script in /etc/cron.daily that checks to see if /var/log/yum has changed since the last reboot and then it does a reboot if nobody is logged in. If I had certain long-running programs that needed to finish, I'd have to check for those too, but I don't.
-wolfgang
On Tue, Aug 31, 2010 at 22:08, Wolfgang S. Rupprecht wolfgang.rupprecht@gmail.com wrote:
Why not just do reboots at 3 in the morning and it just won't matter all that much. I just have a cron script in /etc/cron.daily that checks to see if /var/log/yum has changed since the last reboot and then it does a reboot if nobody is logged in. If I had certain long-running programs that needed to finish, I'd have to check for those too, but I don't.
It would work. But that's still not fixing the cause, only dealing with the consequences.
(BTW: I don't leave my computer on continuously, so I know upgrades will be effective tomorrow. It just feels plain wrong ;-))
Andre
On 08/31/2010 09:08 PM, Wolfgang S. Rupprecht wrote:
Why not just do reboots at 3 in the morning and it just won't matter all that much. I just have a cron script in /etc/cron.daily that checks to
No! I'm often doing something at 3AM (granted I *should* be going to bed before that time), and I hate it when I'm working on something the the system goes down for a reboot without asking first....
see if /var/log/yum has changed since the last reboot and then it does a reboot if nobody is logged in. If I had certain long-running programs that needed to finish, I'd have to check for those too, but I don't.
Well, that's slightly better than the MS way of doing it. (Yes, I have been on my wife's computer when it decided that it was time to reboot with 2 users logged in.)
-wolfgang
"Kevin J. Cummings" cummings@kjchome.homeip.net writes:
On 08/31/2010 09:08 PM, Wolfgang S. Rupprecht wrote:
Why not just do reboots at 3 in the morning and it just won't matter all that much. I just have a cron script in /etc/cron.daily that checks to
No! I'm often doing something at 3AM (granted I *should* be going to bed before that time), and I hate it when I'm working on something the the system goes down for a reboot without asking first....
I've been there too. It used to just do a "shutdown -r +3 'a quick reboot for yum'", but even with the 3 minute warning a pending reboot was a real pain in the neck. I'd often be funbling with "ps" trying frantically to locate the shutdown so I could kill it before it killed me. ;-)
For the curious, here is my script. It has served me well for a few years.
-wolfgang
#!/bin/sh ############################################################################### ## ## ## File: reboot-if-needed ## ## Author: Wolfgang S. Rupprecht wolfgang@wsrcc.com ## ## Created: Wed Dec 3 16:20:29 PST 2008 ## ## Contents: reboot a host if needed ## ## ## ## Copyright (c) 2008 Wolfgang S. Rupprecht. ## ## All rights reserved. ## ## ## ## $Id$ ###############################################################################
# install reboot-if-needed /etc/cron.daily/zzzz-reboot-if-needed
# boot.log is a file we can expect to exist and is at most as old as # the last boot-time. If yum.log is newer, we have installed or # deleted something. It is best to reboot to make sure all the new # files get used and the disk space for the old files gets freed up.
# was: /var/run/crond.pid for < fedora-12, where boot.log never was touched. # # The cron rpm sometimes gets updated by yum and this will cause cron # to be restarted and the pid file to be touched. Use boot.log if # possible.
if [ /var/log/yum.log -nt /var/log/boot.log ] then
# Don't reboot if someone is logged in. if [ -n "$(w -h)" ] then logger -i -s -t 'reboot-if-needed' 'Please reboot for newly installed files' exit fi
logger -i -s -t 'reboot-if-needed' 'a quick reboot for newly installed files (via yum)' shutdown -r +3 'a quick reboot for newly installed files (via yum)'
fi
# # end #
On 09/01/2010 04:19 PM, Wolfgang S. Rupprecht wrote:
"Kevin J. Cummings"cummings@kjchome.homeip.net writes:
On 08/31/2010 09:08 PM, Wolfgang S. Rupprecht wrote:
Why not just do reboots at 3 in the morning and it just won't matter all that much. I just have a cron script in /etc/cron.daily that checks to
No! I'm often doing something at 3AM (granted I *should* be going to bed before that time), and I hate it when I'm working on something the the system goes down for a reboot without asking first....
I've been there too. It used to just do a "shutdown -r +3 'a quick reboot for yum'", but even with the 3 minute warning a pending reboot was a real pain in the neck. I'd often be funbling with "ps" trying frantically to locate the shutdown so I could kill it before it killed me. ;-)
FWIW, a simple "shutdown -c" should cancel a running shutdown process.
-
Andre Costa -
Bruno Wolff III -
JD -
Jonathan Beatty -
kalinix -
Kevin Cummings -
Michael Schwendt -
Patrick O'Callaghan -
PaulCartwright -
Ranjan Maitra -
Richard Hughes -
Robert Nichols -
Tim -
Timothy Murphy -
Tom Horsley -
Wolfgang S. Rupprecht