Originally posted by uid313
View Post
Announcement
Collapse
No announcement yet.
Canonical Rolls Out Its Own Kernel Livepatching Service For Ubuntu
Collapse
X
-
Code::~$ sudo canonical-livepatch enable ___2016/10/19 11:09:41 Error executing enable?auth-token=___. Connection to the daemon failed: Put http://127.0.0.1/enable?auth-token=___: dial unix /var/snap/canonical-livepatch/15/livepatchd-priv.sock: connect: no such file or directory :~$ canonical-livepatch status Connection to the daemon failed: Get http://127.0.0.1/status?verbose=false: dial unix /var/snap/canonical-livepatch/15/livepatchd.sock: connect: no such file or directory
Comment
-
After succefull install of snap I get:~$ sudo canonical-livepatch enable ___2016/10/19 11:09:41 Error executing enable?auth-token=___. Connection to the daemon failed: Put http://127.0.0.1/enable?auth-token=___: dial unix /var/snap/canonical-livepatch/15/livepatchd-priv.sock: connect: no such file or directory :~$ canonical-livepatch status Connection to the daemon failed: Get http://127.0.0.1/status?verbose=false: dial unix /var/snap/canonical-livepatch/15/livepatchd.sock: connect: no such
Comment
-
I understand why some people are afraid to reset their servers. But to be frank, if you don't have a redundant solution for customer facing applications, perhaps you are doing something wrong. And perhaps if you are paying someone money so you don't have to 'reset' the computer perhaps there is also something wrong happening. I understand the real world, but it seems like the per node pricing is a tad on the appeal to lazy deep pockets.
Comment
-
Originally posted by pcxmac View PostI understand why some people are afraid to reset their servers. But to be frank, if you don't have a redundant solution for customer facing applications, perhaps you are doing something wrong. And perhaps if you are paying someone money so you don't have to 'reset' the computer perhaps there is also something wrong happening. I understand the real world, but it seems like the per node pricing is a tad on the appeal to lazy deep pockets.
Comment
-
Originally posted by peppercats View PostExcuse my ignorance in this area, but wouldn't it be possible to accomplish the same thing with kexec and hibernate?- Memory of the currently running kernel is overwritten by the new kernel, while the old one is still executing.
- The new kernel will usually expect all hardware devices to be in a well defined state, in which they are after a system reboot because the system firmware resets them to a "sane" state. Bypassing a real reboot may leave devices in an unknown state, and the new kernel will have to recover from that.
Also, these implementations are supposed to patch the kernel without blowing up applications that are still using the features being patched, with a kexec you would risk blowing them up.
Comment
Comment