[opensuse] what to do after zypper dup
12.3 Hi I have some repos which need updating so I run zypper dup. If I run zypper up, they don't get updated. After the show, I get: There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs. and then: You may wish to restart these processes. Say there are 10 processes. Is there something like: zypper restart-processes-after-dup? Normally I can reboot or dup when we have fewer users, but what if I can't? Thanks, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Sep 14, 2013 at 9:11 AM, lynn
12.3 Hi I have some repos which need updating so I run zypper dup. If I run zypper up, they don't get updated.
After the show, I get: There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs. and then: You may wish to restart these processes.
Say there are 10 processes. Is there something like: zypper restart-processes-after-dup?
Normally I can reboot or dup when we have fewer users, but what if I can't? Thanks, L x
Lynn, I'm going to ignore your "zypper dup" comment. That is not best practice, but it does not relate to the rest of your question. It is not big a deal most of the time to leave programs running after zypper. It just means that programs that are running have not gotten the benefits of the update yet. If for instance you have just upgraded a database like mysql and you want the new version to be useable without a reboot, then manually running rcmysql restart. If not, your update won't really be usable until the next reboot. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 14/09/2013 15:36, Greg Freemyer a écrit :
If not, your update won't really be usable until the next reboot.
and you get sometime surprising results when a library is needed. I often wonder why Thunderbird is behaving erratically before I remember I just updated :-) jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 09/14/2013 09:11 AM:
12.3 Hi I have some repos which need updating so I run zypper dup. If I run zypper up, they don't get updated.
Personally I don't think you should be doing that. Do you really understand the difference between 'up' and 'dup'? When there is a update that I want/need which 'up' isn't giving me I can bring it in using zypper install package.revision If you simple try zypper install package it will tell you that a later revision exists and the full command to install it. That you see items in 'dup' that aren't in 'up' might simply be that you have settings on the priority levels of distributions set to make it come out that way. In this case it becomes an all or nothing.
After the show, I get: There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs. and then: You may wish to restart these processes.
This makes perfect sense. First, recall that Linux does not delete a file that is being help open. We often use this trick to autodelete temporary files. q.v. If there is a program already running that uses a library at revision level 8 and suddenly it has to use the same library with revision level 9 then unpredictable things are going to happen. BAD! So we don't let that happen. This is much clearer if you think in term of something like editing a text file with SED. If the file suddenly changes then the edits you made are no longer to make any sense. What was line 132 is now line 166 and changing what is now 132 becomes a mistake. The application already has the library/8 or its own binary 'open' and continues to use that. If the program exits (or is killed) and is restarted then it uses the new binary of library. Please note that it says "you *MAY* want to restart these processes". That *MAY* is important. You may be quite happy running the older versions for now. The changes in the new version may not be critical. That answers the "what if I can't reboot" case for a lot of instances - you don't need to restart the processes. In many more instances you may only need to log out and in again to start over all the user GUI applications, including the X server. What's left? Systems process and the kernel. Restarting the kernel needs a reboot just as installing a new kernel as part of installing a new distribution needs a reboot. No way around that. The issue is "how critical?" If something is failing then the users are demanding it being fixed so a reboot is necessary -- what they are doing isn't working anyway. If its not critical then waiting for scheduled PM -- you do schedule PM, don't you? - is the way to go. Heck, isn't this what 'scheduled PM' amounts to anyway? Other system processes are easier to restart with systemd, I've found, but again its an issue of scheduling. Paying attention to when things like cron jobs get started; email flow; ... it all depends on what you are running. Maybe you're not a full load 7/24 so you can come in at 4am to restart the sshd. Otherwise it has to be scheduled. If you are a 7/24 system then maybe you should be running HA or hot-failover so that one machine can be updated then cut over for any further new jobs and let the ones on the other expire. Certainly with a connectionless protocol like HTTP(s) having multiple servers and load balancing for a 7/24 is good practice and would facilitate updates that happen as a matter of course.
Say there are 10 processes. Is there something like: zypper restart-processes-after-dup?
I most certainly hope not!
Normally I can reboot or dup when we have fewer users, but what if I can't?
The simple answer is "it may not matter' The longer answer is that "it if does matter that much then the users will be wanting it so they will put up with logging off for the reboot". Unless you have things messed up then its not as if a reboot is going to take long. My slowest server, the one that has to restart a huge DNS table, normally reboots in around 2 minutes. If I simply pull the plug so it has to run the FSCKs (in parallel of course) that might stretch to 5 minutes. That's less time that it takes to to take the lift down to the 2nd floor, go to the cafeteria, get a coffee and come back. YMMV. One place I worked there was a coffee hutch just down the corridor from my cubicle but the machine took about a minute to make a fresh cup. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-09-14 10:15 (GMT-0400) Anton Aylward composed:
Restarting the kernel needs a reboot just as installing a new kernel as part of installing a new distribution needs a reboot. No way around that.
??? http://en.wikipedia.org/wiki/Kexec -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata said the following on 09/14/2013 11:01 AM:
On 2013-09-14 10:15 (GMT-0400) Anton Aylward composed:
Restarting the kernel needs a reboot just as installing a new kernel as part of installing a new distribution needs a reboot. No way around that.
ROTFLMAO! <quote> This avoids the long times associated with a full reboot </quote> *WHAT* long times? Then we have <quote> the new kernel will overwrite the memory of the currently running one, while it is still executing </quote> At the very least that means tables and pointers and the state of processes. Thanks you, Felix, but when I do a risk assessment, the risk of annoying people with corrupted kernel tables causing lost or corrupted work vs the the risk of annoying them by asking them to logout for a reboot that will take maybe 2 minutes ... I'd go for the latter. People will get over that more easily than they will corrupted data. And anyway, getting back to the OP's issue: kernel updates are rarer than updates to libraries and applications. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/09/13 17:23, Anton Aylward wrote:
Felix Miata said the following on 09/14/2013 11:01 AM:
On 2013-09-14 10:15 (GMT-0400) Anton Aylward composed:
Restarting the kernel needs a reboot just as installing a new kernel as part of installing a new distribution needs a reboot. No way around that.
ROTFLMAO!
<quote> This avoids the long times associated with a full reboot </quote>
*WHAT* long times?
Indeed - and from the docs it seems kesec goes through the software shutdown/restart procedures and only omits the hardware/bios reset. For me, reboot takes 50seconds to KDE log on screen *including* the grub timeout, so skipping the hardware reset would save save at most 10 seconds. Even if I'm really in a hurry, what's the difference? Especially since all services need to be stopped anyway... Dylan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 9/14/2013 9:53 AM, Dylan wrote:
On 14/09/13 17:23, Anton Aylward wrote:
Felix Miata said the following on 09/14/2013 11:01 AM:
On 2013-09-14 10:15 (GMT-0400) Anton Aylward composed:
Restarting the kernel needs a reboot just as installing a new kernel as part of installing a new distribution needs a reboot. No way around that.
ROTFLMAO!
<quote> This avoids the long times associated with a full reboot </quote>
*WHAT* long times?
Indeed - and from the docs it seems kesec goes through the software shutdown/restart procedures and only omits the hardware/bios reset. For me, reboot takes 50seconds to KDE log on screen *including* the grub timeout, so skipping the hardware reset would save save at most 10 seconds. Even if I'm really in a hurry, what's the difference? Especially since all services need to be stopped anyway...
Dylan
That is fine for YOU. But with a multi-user machine, or won that is serving some other clients as a file-server or database server, you frequently need to roll the machine to replace modules that are continuously in use by multiple users. This isn't a new problem, its been around for as long as I've been using linux. Old versions of some critical software don't always mix well with new versions. The old executable will usually run just fine, but if it makes occasional use of some configuration file, it may try to open the new version, sometimes with bad results. Virtually anything having to do with Gnome or KDE you can simply log out, and log back in again. But for services provided across the network, this doesn't work. If you can't be down, then don't update. Its that simple. Or at least don't update until a scheduled maintenance window. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/09/13 21:14, John Andersen wrote:
On 9/14/2013 9:53 AM, Dylan wrote:
On 14/09/13 17:23, Anton Aylward wrote:
Felix Miata said the following on 09/14/2013 11:01 AM:
On 2013-09-14 10:15 (GMT-0400) Anton Aylward composed:
Restarting the kernel needs a reboot just as installing a new kernel as part of installing a new distribution needs a reboot. No way around that.
ROTFLMAO!
<quote> This avoids the long times associated with a full reboot </quote>
*WHAT* long times?
Indeed - and from the docs it seems kesec goes through the software shutdown/restart procedures and only omits the hardware/bios reset. For me, reboot takes 50seconds to KDE log on screen *including* the grub timeout, so skipping the hardware reset would save save at most 10 seconds. Even if I'm really in a hurry, what's the difference? Especially since all services need to be stopped anyway...
Dylan
That is fine for YOU.
My comments related to the supposed saving in boot time with kexec... When it comes to 'critical' services, they should be balanced across more than one machine with appropriate update schedules etc... that's nothing to do with kexec...
But with a multi-user machine, or won that is serving some other clients as a file-server or database server, you frequently need to roll the machine to replace modules that are continuously in use by multiple users.
This isn't a new problem, its been around for as long as I've been using linux. Old versions of some critical software don't always mix well with new versions. The old executable will usually run just fine, but if it makes occasional use of some configuration file, it may try to open the new version, sometimes with bad results.
Virtually anything having to do with Gnome or KDE you can simply log out, and log back in again.
But for services provided across the network, this doesn't work.
If you can't be down, then don't update. Its that simple.
Or at least don't update until a scheduled maintenance window.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----Original Message-----
From: Anton Aylward
On 2013-09-14 10:15 (GMT-0400) Anton Aylward composed:
Restarting the kernel needs a reboot just as installing a new kernel as part of installing a new distribution needs a reboot. No way around that.
ROTFLMAO! <quote> This avoids the long times associated with a full reboot </quote> *WHAT* long times? -----Original Message----- For instance, the time some systems spent in their BIOS HP is notoriously known for it, even when disabling mem-check. And i'm not talking about seconds...... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Use "zypper ps" to list the processes that need to be restarted.
Look to the left in the PID columns and remember the processes number
for that service.
Then use "pstree -p PID" and replace PID with the actual PID (seen in
the output of "zypper ps") of the service you're interested in.
Then that should give you an idea of the service to restart. Those can
be restarted with either systemctl or rc... commands.
Like for postgresql you could use either "systemctl restart
postgresql.service" or "rcpostgresql restart" - and the restart
commands, whichever you choose, need to be run as root (ie, with
sudo).
Each time you restart a service, run "zypper ps" to see what's left.
'Rinse and repeat'
SaultDon
Donovan
On Sat, Sep 14, 2013 at 6:11 AM, lynn
12.3 Hi I have some repos which need updating so I run zypper dup. If I run zypper up, they don't get updated.
After the show, I get: There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs. and then: You may wish to restart these processes.
Say there are 10 processes. Is there something like: zypper restart-processes-after-dup?
Normally I can reboot or dup when we have fewer users, but what if I can't? Thanks, L x
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Anton Aylward -
Dylan -
Felix Miata -
Greg Freemyer -
Hans Witvliet -
jdd -
John Andersen -
lynn -
Saulteau Don