[arch-general] Upgrading while using a package (WAS: Re: pacman -Syu -- then tons of kio and kbuildsycoca warnings. Bug or coincidence?)
On 10/13/2010 11:03 PM, David Rosenstrauch wrote:
On 10/09/2010 12:57 AM, David C. Rankin wrote:
Guys, just updated and got a slew of warning dumped back to konsole:
Nothing strange to me at all: you're upgrading qt while you're in KDE (which uses qt). It's never a good idea to upgrade a package while it's being used. If you're upgrading a daemon, shut down the daemon first; if you're upgrading qt, exit KDE first; if you're upgrading the kernel, udev, etc., drop to single user mode first.
I didn't know that, nor did I read that somewhere on the wiki. Why is this? Aren't programs copied to memory (i.e. loaded) before being used? In that case, isn't the upgraded version left alone until it is loaded the next time the program is started? Where can I find more on this? Thanks, Diederick -- http://www.diederickdevries.net/
Am 14.10.2010 08:40, schrieb diederick:
On 10/13/2010 11:03 PM, David Rosenstrauch wrote:
On 10/09/2010 12:57 AM, David C. Rankin wrote:
Guys, just updated and got a slew of warning dumped back to konsole:
Nothing strange to me at all: you're upgrading qt while you're in KDE (which uses qt). It's never a good idea to upgrade a package while it's being used. If you're upgrading a daemon, shut down the daemon first; if you're upgrading qt, exit KDE first; if you're upgrading the kernel, udev, etc., drop to single user mode first.
I didn't know that, nor did I read that somewhere on the wiki. Why is this? Aren't programs copied to memory (i.e. loaded) before being used? In that case, isn't the upgraded version left alone until it is loaded the next time the program is started? Where can I find more on this?
Thanks, Diederick
Hello, in general you are right, but you never know. Programs are doing something. Some may reload data files even or program code at runtime. Regards Stefan
On Thu, 14 Oct 2010 09:09:27 +0200, Stefan Husmann <stefan-husmann@t-online.de> wrote:
Am 14.10.2010 08:40, schrieb diederick:
On 10/13/2010 11:03 PM, David Rosenstrauch wrote:
On 10/09/2010 12:57 AM, David C. Rankin wrote:
Guys, just updated and got a slew of warning dumped back to konsole:
Nothing strange to me at all: you're upgrading qt while you're in KDE (which uses qt). It's never a good idea to upgrade a package while it's being used. If you're upgrading a daemon, shut down the daemon first; if you're upgrading qt, exit KDE first; if you're upgrading the kernel, udev, etc., drop to single user mode first.
I didn't know that, nor did I read that somewhere on the wiki. Why is this? Aren't programs copied to memory (i.e. loaded) before being used? In that case, isn't the upgraded version left alone until it is loaded the next time the program is started? Where can I find more on this?
Thanks, Diederick
Hello,
in general you are right, but you never know. Programs are doing something. Some may reload data files even or program code at runtime.
Right. In your earlier post, you specifically mention the kernel. Would you say that it is safe to install a new kernel in multi user mode if I reboot right after installation, while not using modprobe et al. between the installation and the reboot? And if not, why is single user mode safer? Thanks for your quick response, Diederick -- http://www.diederickdevries.net/
On Thu, 14 Oct 2010 11:37:43 +0200, diederick <diederick@diederickdevries.net> wrote:
On Thu, 14 Oct 2010 09:09:27 +0200, Stefan Husmann <stefan-husmann@t-online.de> wrote:
Am 14.10.2010 08:40, schrieb diederick:
On 10/13/2010 11:03 PM, David Rosenstrauch wrote:
On 10/09/2010 12:57 AM, David C. Rankin wrote:
Guys, just updated and got a slew of warning dumped back to konsole:
Nothing strange to me at all: you're upgrading qt while you're in KDE (which uses qt). It's never a good idea to upgrade a package while it's being used. If you're upgrading a daemon, shut down the daemon first; if you're upgrading qt, exit KDE first; if you're upgrading the kernel, udev, etc., drop to single user mode first.
I didn't know that, nor did I read that somewhere on the wiki. Why is this? Aren't programs copied to memory (i.e. loaded) before being used? In that case, isn't the upgraded version left alone until it is loaded the next time the program is started? Where can I find more on this?
Thanks, Diederick
Hello,
in general you are right, but you never know. Programs are doing something. Some may reload data files even or program code at runtime.
Right. In your earlier post, you specifically mention the kernel. Would you say that it is safe to install a new kernel in multi user mode if I reboot right after installation, while not using modprobe et al. between the installation and the reboot? And if not, why is single user mode safer?
Thanks for your quick response, Diederick
Oops, that should have been: "In the earlier post, the kernel was mentioned specifically..." Sorry for that. Diederick -- http://www.diederickdevries.net/
Am 14.10.2010 11:37, schrieb diederick:
Hello,
in general you are right, but you never know. Programs are doing something. Some may reload data files even or program code at runtime.
Right. In your earlier post, you specifically mention the kernel. Would you say that it is safe to install a new kernel in multi user mode if I reboot right after installation, while not using modprobe et al. between the installation and the reboot? And if not, why is single user mode safer?
Thanks for your quick response, Diederick
There's no "one case fits all" answer here. You always have to consider files that are in memory vs. files that will be loaded from the hard drive. Any application binary and shared library that this binary uses are kept in memory - regardless if the files are deleted or overwritten while they are running (same holds for _open_ data files). However, applications can dynamically load and unload libraries (man dlopen) and data files. If you replace an existing library or data file with a new one that is incompatible with the currently running version of the application, you will have failures. Qt and KDE are known to fail if you perform a major upgrade while applications are still running, while minor upgrades usually work. The same holds for the kernel: The kernel and the currently used modules are kept in memory. However, modules may be loaded at any time (for example if you plug in a new device that hasn't been used before). If you perform a minor kernel update, the modules are likely to still be compatible and you won't notice it. If you perform a major update, the modules will not even be in the right path, leading to failure (popular example: pacman -Syu and try to use a USB flash drive afterwards, then come to #archlinux and rant about why Arch does not support flash drives). My recommendations: 1) If you are upgrading your desktop environment, exit your session, quit your login manager and upgrade from the text console. I advise to run pacman -Sywu from the desktop and when the download finishes, run pacman -Su from the text console. 2) Put all kernel-related packages on --ignore until you are planning to reboot. If you are not going to reboot, a kernel update will have no effect anyway.
On Thu, 14 Oct 2010 12:09:38 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
Am 14.10.2010 11:37, schrieb diederick:
Hello,
in general you are right, but you never know. Programs are doing something. Some may reload data files even or program code at runtime.
Right. In your earlier post, you specifically mention the kernel. Would you say that it is safe to install a new kernel in multi user mode if I reboot right after installation, while not using modprobe et al. between the installation and the reboot? And if not, why is single user mode safer?
Thanks for your quick response, Diederick
There's no "one case fits all" answer here. You always have to consider files that are in memory vs. files that will be loaded from the hard drive.
Any application binary and shared library that this binary uses are kept in memory - regardless if the files are deleted or overwritten while they are running (same holds for _open_ data files). However, applications can dynamically load and unload libraries (man dlopen) and data files. If you replace an existing library or data file with a new one that is incompatible with the currently running version of the application, you will have failures. Qt and KDE are known to fail if you perform a major upgrade while applications are still running, while minor upgrades usually work.
The same holds for the kernel: The kernel and the currently used modules are kept in memory. However, modules may be loaded at any time (for example if you plug in a new device that hasn't been used before). If you perform a minor kernel update, the modules are likely to still be compatible and you won't notice it. If you perform a major update, the modules will not even be in the right path, leading to failure (popular example: pacman -Syu and try to use a USB flash drive afterwards, then come to #archlinux and rant about why Arch does not support flash drives).
My recommendations: 1) If you are upgrading your desktop environment, exit your session, quit your login manager and upgrade from the text console. I advise to run pacman -Sywu from the desktop and when the download finishes, run pacman -Su from the text console. 2) Put all kernel-related packages on --ignore until you are planning to reboot. If you are not going to reboot, a kernel update will have no effect anyway.
Very clear. Thanks! Diederick -- http://www.diederickdevries.net/
It would appear that on Oct 14, Thomas Bächler did say:
My recommendations: 1) If you are upgrading your desktop environment, exit your session, quit your login manager and upgrade from the text console. I advise to run pacman -Sywu from the desktop and when the download finishes, run pacman -Su from the text console.
OK, pardon my intrusion, but NOW I'm curious... I can understand the advantage of running "pacman -Su" from a text console (By which I don't mean using <ctrl>+<alt>+<F[1-6]> while the gui is still running.). It just makes sense, especially when pacman is expressly not a gui app. I can also understand that it might be better to run "pacman -Sywu" first as a separate operation. But why run the latter from the gui???
2) Put all kernel-related packages on --ignore until you are planning to reboot. If you are not going to reboot, a kernel update will have no effect anyway.
As a general rule I always reboot after any "pacman -Su" operation. If I wasn't prepared to reboot, I wouldn't upgrade my system. -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
On Tue, Oct 19, 2010 at 8:35 AM, Joe(theWordy)Philbrook <jtwdyp@ttlc.net> wrote:
It would appear that on Oct 14, Thomas Bächler did say:
My recommendations: 1) If you are upgrading your desktop environment, exit your session, quit your login manager and upgrade from the text console. I advise to run pacman -Sywu from the desktop and when the download finishes, run pacman -Su from the text console.
OK, pardon my intrusion, but NOW I'm curious...
I can understand the advantage of running "pacman -Su" from a text console (By which I don't mean using <ctrl>+<alt>+<F[1-6]> while the gui is still running.). It just makes sense, especially when pacman is expressly not a gui app. I can also understand that it might be better to run "pacman -Sywu" first as a separate operation. But why run the latter from the gui???
The idea behind doing the upgrade in 2 operations and doing "pacman -Sywu" in the GUI is that it allows you to continue working in the GUI while the packages are being downloaded. So you don't waste time in the console waiting for pacman to download the packages. Of course, if you are not using the GUI or don't mind waiting, then you can just run "pacman -Syu" in the console.
2) Put all kernel-related packages on --ignore until you are planning to reboot. If you are not going to reboot, a kernel update will have no effect anyway.
As a general rule I always reboot after any "pacman -Su" operation. If I wasn't prepared to reboot, I wouldn't upgrade my system.
-- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
On 10/14/2010 01:40 AM, diederick wrote:
On 10/09/2010 12:57 AM, David C. Rankin wrote:
Guys, just updated and got a slew of warning dumped back to konsole:
Nothing strange to me at all: you're upgrading qt while you're in KDE (which uses qt). It's never a good idea to upgrade a package while it's being used. If you're upgrading a daemon, shut down the daemon first; if you're upgrading qt, exit KDE first; if you're upgrading the kernel, udev, etc., drop to single user mode first.
Just to add a little food for thought to the issue. In my original post, the host being updated is 'nirvana' which is my primary home server. All updates are done via ssh from another laptop. What occurred was -- kde4.5.2 was evidently left running on the server. What makes the kio and kbuildsycoca output remarkable at all is that this is the first time since Apr. '09 with Arch in the 50-100 updates I've done, and the first time since 1999 with Mandrake and then SuSE that I have ever had any spurious kio or kbuildsycoca output during an update (pacman -Syu, YaST, zypper, rpmdrake, etc.) regardless of which desktop was running. I have updated Qt from withing kde/kde4 many times, so it was a real curiosity to me. I may have just been lucky all these times. I'll add DR's advise to my list of 'oops - can't do that with kde4' -- tips. I'm sure the issue isn't a pacman or Arch issue, the issue is most likely that kde4 still has the debug flag set in everything so it writes everything to stderr on any change, update, rebuild whatever where stable desktops just write errors to stderr. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (6)
-
David C. Rankin
-
diederick
-
Eric Bélanger
-
Joe(theWordy)Philbrook
-
Stefan Husmann
-
Thomas Bächler