Hy there,
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
Is that possible?
Regards,
Lutz Griesbach IT Administrator
tel +49.40.325587.701 fax +49.40.325587.999
lutz.griesbach@coremedia.com
CoreMedia Ludwig-Erhard-Str. 18 20459 Hamburg, Germany www.coremedia.com
CoreMedia AG Executive Board: Sören Stamer (CEO), Dr. Klemens Kleiminger (CFO) Supervisory Board: Prof. Dr. Florian Matthes (Chairman) Trade Register: Amtsgericht Hamburg, HR B 76277 -------------------------------------------------------
Griesbach, Lutz wrote:
Hy there,
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
Is that possible?
A few questions for you.
1. Nightly updates are not enabled by default. Why did you turn it on when your box has issues? 2. Aren't prudent admins supposed to test updates before applying them to production boxes?
Oh, c'mon!
If I want to talk about professional honor, I'd prefer a different list.
I know, that they're switched of by default - but I didn't set up this machine and I have rarely any documentation about it. Somebody (my predecessor) enabled nightly updates and I thought, there might be a reason for it. Until last night I didn't even know, somebody has enabled it.
Also I didn't now, that nightly updates include upgrades and this doesn't makes sense to me either. Who wants to get 193 packages including kernel, glibc and the like, without any notice over night on his machine?
So, I thought it might be possible to stick in the release during nightly updates, but your educational answer doesn't help much.
Thanks anyway, I disabled it.
-----Ursprüngliche Nachricht----- Von: centos-bounces@centos.org [mailto:centos-bounces@centos.org] Im Auftrag von vandaman2002-rt@yahoo.co.uk Gesendet: Donnerstag, 2. Oktober 2008 13:22 An: CentOS mailing list Betreff: Re: [CentOS] Nightly yum update did an "upgrade"
Griesbach, Lutz wrote:
Hy there,
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
Is that possible?
A few questions for you.
1. Nightly updates are not enabled by default. Why did you turn it on when your box has issues? 2. Aren't prudent admins supposed to test updates before applying them to production boxes?
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Griesbach, Lutz wrote:
Oh, c'mon!
If I want to talk about professional honor, I'd prefer a different list. So, I thought it might be possible to stick in the release during nightly updates, but your educational answer doesn't help much.
Get out of your high horse. You are running a server with automatic updates and then talk of "professional honor" and "educational answer"? Try RTFM.
Why being so offensive? May be i ask stupid Questions, but you're the one judging me without knowing any background.
With RTFM you are right, I read the man pages and disabled nightly updates. Thank you for your help.
Lutz Griesbach -------------------------------------------------------
-----Ursprüngliche Nachricht----- Von: centos-bounces@centos.org [mailto:centos-bounces@centos.org] Im Auftrag von vandaman2002-rt@yahoo.co.uk Gesendet: Donnerstag, 2. Oktober 2008 14:10 An: CentOS mailing list Betreff: Re: AW: [CentOS] Nightly yum update did an "upgrade"
Griesbach, Lutz wrote:
Oh, c'mon!
If I want to talk about professional honor, I'd prefer a different list. So, I thought it might be possible to stick in the release during nightly updates, but your educational answer doesn't help much.
Get out of your high horse. You are running a server with automatic updates and then talk of "professional honor" and "educational answer"? Try RTFM.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Griesbach, Lutz wrote: . .
Don't top post, please.
With RTFM you are right, I read the man pages and disabled nightly updates. Thank you for your help.
Did you leave it so it at least notifies you of available updates? Better than ignoring updates altogether.
-tkb
Griesbach, Lutz wrote:
Oh, c'mon!
If I want to talk about professional honor, I'd prefer a
different list.
So, I thought it might be possible to stick in the release during nightly updates, but your educational answer doesn't help much.
Get out of your high horse. You are running a server with automatic updates and then talk of "professional honor" and "educational answer"? Try RTFM.
I think he was inferring that you insulting him did not help the question.
On a lighter side, I run with auto update on. I think it solves two issues.
1- it forces me to get the update/upgrade right away 2- it forces me to be on my toes incase it screws anything up as I have to immediately fix it.
By not having it update I can sit on my butt and perhaps never do it. It is easy to relax on your laurels as an admin. It is easier to read all the data from previous people who have had issues and fixed things..it is a test of your skills to be the first to figure it out.
Then it is back to pizza and watching cnbc as the stocks fall.....
On a lighter side,.....
On Thu, Oct 2, 2008 at 7:56 AM, Bob Hoffman bob@bobhoffman.com wrote:
[From vandaman2002-rt(at)yahoo.com:]
Griesbach, Lutz wrote:
Oh, c'mon!
If I want to talk about professional honor, I'd prefer a
different list.
So, I thought it might be possible to stick in the release during nightly updates, but your educational answer doesn't help much.
Get out of your high horse. You are running a server with automatic updates and then talk of "professional honor" and "educational answer"? Try RTFM.
I think he was inferring that you insulting him did not help the question.
A few thoughts:
1) Perhaps Mr (Ms?) vandaman was offended by the lengthy signature with all the bells and whistles from Lutz. I remember when I first started on this list, all I had was my name and title, which happened to be "Linux Kernel Engineer," and I caught a fair amount of flack for /that/.
2) Such a level of disdain and discord is not really appropriate for a first response on the list unless the question is banally stupid, and this one, which appears here often enough, isn't quite that low.
3) Suggestion for Lutz (and vandaman): both of you are relatively new to this list. In general, it is considered good netiquette to lurk for a while and see what posts and responses look like before plunging in and offending people, intentionally or not.
4) If you are really, truly looking for a quick answer, an email list is not the place to ask first - google is your friend, and email list archives are a good resource to look through as well. In this particular case, the subject has come up often (probably because many, perhaps most, members do NOT use google or the email archives).
5) Bottom post, trim responses, be polite, no html, etc., etc. - remember those last few posts right here on this email list? The guidelines are right there in a link when you sign up, and you AGREED to them, so you ought to read them and take heed, too.
"So play /nice/." (Woody, "Toy Story")
Nazdrovyeh!
mhr
On Thu, Oct 2, 2008 at 10:23 AM, MHR mhullrich@gmail.com wrote:
I remember when I first started on this list, all I had was my name and title, which happened to be "Linux Kernel Engineer," and I caught a fair amount of flack for /that/.
I remember those days very well, Mark. And I wondered why when you removed that title. Don't think I've ever given you hard time... :-D
Akemi
On Thu, Oct 2, 2008 at 10:36 AM, Akemi Yagi amyagi@gmail.com wrote:
I remember those days very well, Mark. And I wondered why when you removed that title. Don't think I've ever given you hard time... :-D
Now you know, and no, I don't think you've ever been other than polite and helpful. Though, to be perfectly accurate, it was one of our resident grouches whom I shall not name here that advised me privately what it was about my posts that was irritating most of the top level folks, and my sig was just one of a few.
mhr
- Bottom post, trim responses, be polite, no html, etc., etc. -
remember those last few posts right here on this email list? The guidelines are right there in a link when you sign up, and you AGREED to them, so you ought to read them and take heed, too.
I'm sorry form my Top-Posts here, (I'd like to blame on this lookOut(TM) Client, I'm writing with but frankly - i just forgot it.)
Hope this issue clarified now.
I'd like come back to topic and ask another question. Hope you don't mind. I did already a research but couldn't find anything useful.
4.7 ist out since Sept 13th. What exactly triggers the update on October 2nd? If I run nightly updates, shouldn't it happened exactly when the release is out or, at least, when the mirrors are up to date?
Regards,
Lutz
Lutz Griesbach wrote on Thu, 2 Oct 2008 19:42:49 +0200:
4.7 ist out since Sept 13th. What exactly triggers the update on October 2nd? If I run nightly updates, shouldn't it happened exactly when the release is out or, at least, when the mirrors are up to date?
Again, there is no such thing as an "upgrade" or a "release" in terms of updates. It was *not* what you call "upgrade" that caused your problem. It was an update, not necessarily belonging to 4.7 at all, or it was not related to updates at all. There might also have been a kernel update on Sept. 14 and you didn't reboot since then. Which, for whatever reason lead to your problem. I think you do not know at all that your problem is related to "4.7", so stop telling so! Stop thinking in terms of "upgrades", there is just a continous line of updates that every half year or so gets a bit streamlined and "boxed" into a release.
Kai
Lutz Griesbach wrote on Thu, 2 Oct 2008 13:54:32 +0200:
Also I didn't now, that nightly updates include upgrades and this doesn't makes sense to me either. Who wants to get 193 packages including kernel, glibc and the like, without any notice over night on his machine?
So, you thought you would get no update of the kernel, glibc etc. during the whole half year of a major version cycle?
Kai
On Thu, Oct 02, 2008 at 01:54:32PM +0200, Griesbach, Lutz wrote:
Please wrap your lines at a reasonable length; 72 to 76 characters is good, thanks!
Also I didn't now, that nightly updates include upgrades and this doesn't makes sense to me either. Who wants to get 193 packages including
What do you think the difference is between "update" and "upgrade" ?
A minor release (eg going from 4.6 to 4.7) is _merely_ a stick in the sand. Kernel updates happen frequently even within a minor release number.
From the OS perspective there's no difference.
On Thu, 2008-10-02 at 13:11 +0200, Griesbach, Lutz wrote:
Hy there,
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
Hi,
Personally I enable nightly updates but disable the updating of certain packages (services) that the server provides. For this I use the 'exclude' statement in the /etc/yum.conf file. On all servers I include excluding the kernel and glibc. If these are to be upgraded, and require a reboot, then I'll do them when it is convenient to me. Other services, such as exim (MTA), freeradius (RADIUS), squid (web cache), etc are likewise disabled on the relevant servers. Again, if they are to be upgraded, then I will do them when it is convenient and without disrupting the current service.
John.
Lutz Griesbach wrote on Thu, 2 Oct 2008 13:11:25 +0200:
Is that possible?
No. And it wouldn't help you. There is no such thing as an "upgrade" in reality. An "upgrade" to 4.7 is just an update to the bunch of rpms that is considered to be "4.7". e.g. *any* update of dhcrelay might create the problem you saw.
Kai
Ok, i only tried "upgrade" once manually to get another box from centos4.4 to a 4.5 ( and I ran into this http://bugs.centos.org/view.php?id=2557 ) and thought, the difference between update and upgrade is like the debian based "apt-get upgrade" and "apt-get dist-upgrade".
The man page states this as well, vandaman is right, I should have RTFM, but I was a bit in a hurry and I thought, I could get some quick help here.
-----Ursprüngliche Nachricht----- Von: centos-bounces@centos.org [mailto:centos-bounces@centos.org] Im Auftrag von Kai Schaetzl Gesendet: Donnerstag, 2. Oktober 2008 14:38 An: centos@centos.org Betreff: Re: [CentOS] Nightly yum update did an "upgrade"
Lutz Griesbach wrote on Thu, 2 Oct 2008 13:11:25 +0200:
Is that possible?
No. And it wouldn't help you. There is no such thing as an "upgrade" in reality. An "upgrade" to 4.7 is just an update to the bunch of rpms that is considered to be "4.7". e.g. *any* update of dhcrelay might create the problem you saw.
Kai
Griesbach, Lutz wrote:
Ok, i only tried "upgrade" once manually to get another box from centos 4..4 to a 4.5 ( and I ran into this http://bugs.centos.org/view.php?id=2557 ) and thought, the difference between update and upgrade is like the debian based "apt-get upgrade" and "apt-get dist-upgrade".
The man page states this as well, vandaman is right, I should have RTFM, but I was a bit in a hurry and I thought, I could get some quick help here.
That bug is unreproducible because you have manually altered the yum configuration so in reality its a self-induced problem not a "bug". If you are new to using a mailing list follow some of these guidelines :- http://lists.centos.org/pipermail/centos/2008-October/065626.html
vandaman2002-rt@yahoo.co.uk wrote:
That bug is unreproducible because you have manually altered the yum configuration so in reality its a self-induced problem not a "bug". If you are new to using a mailing list follow some of these guidelines :- http://lists.centos.org/pipermail/centos/2008-October/065626.html
Like wrapping lines at a reasonable length?
IOW: Please tone down a bit.
Cheers,
Ralph
vandaman2002-rt@yahoo.co.uk wrote:
That bug is unreproducible because you have manually altered the yum configuration so in reality its a self-induced problem not a "bug". If you are new to using a mailing list follow some of these guidelines :- http://lists.centos.org/pipermail/centos/2008-October/065626.html
ok, so you chased down Lutz's machine, broke into it and were able to verify his yum configs are changed or did you pull that one out of thin air. Its either that, or I am missing something cause I dont see him posting anything that would indicate his yum configs are changed.
I do suspect something is not right, since the 4.7 updates took as long as they did to get to his machine. They have been 'out there' for a fair few weeks now. And the concern that live updates within the distro broke a production machine is very much there.
Karanbir Singh wrote:
ok, so you chased down Lutz's machine, broke into it and were able to verify his yum configs are changed or did you pull that one out of thin air.
I do suspect something is not right, since the 4.7 updates took as long as they did to get to his machine. They have been 'out there' for a fair few weeks now. And the concern that live updates within the distro broke a production machine is very much there.
From the notes on the "bug" you would have to have 4.5/os/$basearch/
instead of $releasever/os/$basearch/ to get the "bug". Also yum update or upgrade should not break anything unless you have packages from elsewhere and murked about with the configs. I have looked on the last month's list and not seen :-
- people whose machines took weeks to autoupdate. - people whose production machines were broken by 4.6 to 4.7
Clearly Lutz's situation is unique and he has not told us the whole story.
Regards, Vandaman.
Vandaman wrote:
From the notes on the "bug" you would have to have 4.5/os/$basearch/
instead of $releasever/os/$basearch/ to get the "bug".
And you assume that since he is seeing similar effects, he must also have done the exact same thing ?
Also yum update or upgrade should not break anything unless you have packages from elsewhere and murked about with the configs.
Not sure what your definition of 'murked' is - but if you mean to imply that he has changed the default configs for software and services he has on the machine to make it work in his environment as he might want them to, I have news for you : almost everyone does that. Once installed its normal to config the software to work as you want it to.
I have looked on the last month's list and not seen :-
- people whose machines took weeks to autoupdate.
- people whose production machines were broken by 4.6 to 4.7
Clearly Lutz's situation is unique and he has not told us the whole story.
you seem to realise that now, however that fact eluded you completely with your first reply to his email. And as Ralph has already pointed out to you in this thread, a tone down would be welcome.
On Fri, 2008-10-03 at 23:23 +0100, Karanbir Singh wrote:
Vandaman wrote:
From the notes on the "bug" you would have to have 4.5/os/$basearch/
instead of $releasever/os/$basearch/ to get the "bug".
And you assume that since he is seeing similar effects, he must also have done the exact same thing ?
Also yum update or upgrade should not break anything unless you have packages from elsewhere and murked about with the configs.
Forget that bug, it was a totally differnet machine and i don't want this mixed up here, may be it was my fault, it doesn't matter.
I have looked on the last month's list and not seen :-
- people whose machines took weeks to autoupdate.
- people whose production machines were broken by 4.6 to 4.7
Clearly Lutz's situation is unique and he has not told us the whole story.
You don't wanna hear the whole story, i can tell you... :)
From my point of view, i wouldn't let do a productive machine such
an update unattended, that's why i switched it off (as i already said, i didn't know, it was turned on). Neither yum nor I can presume the impact. Not that i blame yum for it, i don't expect it can foresee all complexities of any installed software.
i'd like to monitor every update in a downtime window (for productive machines!), just to be save i don't run into trouble, when the box is needed. I also wouldn't do any "dist-upgrade" in debian or install service Packs on windows (forgive me _that_ analogy...) without watching it.
For my own curiosity, i'd like to know the reason, why it took almost 3 weeks before the updates hit the machine. The Base Repository gets its mirrorlist from "mirrorlist.centos.org". I can post it, if you want. What might be interesting is the fact, that there is also the "dag" repository (http://dag.wieers.com) enabled, where the nagios-nrpe package comes from.
For the dhcrelay issue: The update brought dhcp.x86_64 7:3.0.1-62.EL4 and in the messages i have an entry with succeeded TERM signal
Oct 2 04:14:02 trainer dhcrelay: dhcrelay -TERM succeeded
shouldn't it get -HUP Signal or completely restarted?
Regards
Lutz
On Thu, Oct 2, 2008 at 5:56 AM, Griesbach, Lutz lutz.griesbach@coremedia.com wrote:
Ok, i only tried "upgrade" once manually to get another box from centos4.4 to a 4.5 ( and I ran into this http://bugs.centos.org/view.php?id=2557 ) and thought, the difference between update and upgrade is like the debian based "apt-get upgrade" and "apt-get dist-upgrade".
The man page states this as well, vandaman is right, I should have RTFM, but I was a bit in a hurry and I thought, I could get some quick help here.
No. And it wouldn't help you. There is no such thing as an "upgrade" in reality. An "upgrade" to 4.7 is just an update to the bunch of rpms that is considered to be "4.7". e.g. *any* update of dhcrelay might create the problem you saw.
Regarding "update" versus "upgrade", I'd like to give reference to this forum thread:
http://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id...
It boils down to Seth Vidal's own words,
"upgrade/update do the same thing unless you've gone out of your way to disable obsoletes in your yum.conf"
and who else can say more about yum than Mr. Vidal? :-D
Akemi
Akemi Yagi wrote:
http://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id...
It boils down to Seth Vidal's own words,
"upgrade/update do the same thing unless you've gone out of your way to disable obsoletes in your yum.conf"
and who else can say more about yum than Mr. Vidal? :-D
Just want to point out that Seth is potentially wrong on that. He has very little to do with yum on CentOS and is often only commenting on whats the latest version of yum. Also as was clarified at the time of release for 5.2, there are lots of ways in which an update and an upgrade could give you different results.
On Fri, Oct 3, 2008 at 7:13 AM, Karanbir Singh mail-lists@karan.org wrote:
Also as was clarified at the time of release for 5.2, there are lots of ways in which an update and an upgrade could give you different results.
This 'update vs upgrade' question is almost a FAQ. It will be very helpful if you recite/describe the differences in this thread. Then we can update the forum, too.
Akemi
Akemi Yagi wrote:
This 'update vs upgrade' question is almost a FAQ. It will be very helpful if you recite/describe the differences in this thread. Then we can update the forum, too.
one of the commands has its behaviour changed depending on what the configured value for an option is, the other works exactly the same irrespective of what that value might be. To me, thats a massive difference. Also value of that option has changed over the course of yum's history on CentOS3/4/5, so you cant really force / expect everyone to always only have the latest policy enforced. Specially for something like yum, where site specific and machine specific configs are common placed.
on 10-2-2008 4:11 AM Griesbach, Lutz spake the following:
Hy there,
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
Is that possible?
Regards,
As far as yum and the machine are concerned, an update of one package or 200 is still an update. There are no versions 4.6 or 4.7 in a strict technical sense, they are all CentOS 4. They are just a point in time that the updates are frozen long enough so new install CD's/DVD's can be built.
Yum has no way to tell the difference either. You should turn off automatic updates, and do them all manually, and maybe join the announce list to be notified of new updates.
Scott Silva wrote:
on 10-2-2008 4:11 AM Griesbach, Lutz spake the following:
Hy there,
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
Is that possible?
Regards,
As far as yum and the machine are concerned, an update of one package or 200 is still an update. There are no versions 4.6 or 4.7 in a strict technical sense, they are all CentOS 4. They are just a point in time that the updates are frozen long enough so new install CD's/DVD's can be built.
DING, DING, DING ... That is the correct answer.
CentOS-4 is the release. If you do any updates when you have any CentOS-4 installed, you will get all the releases.
The POTENTIAL difference between "update" and "upgrade" is that upgrade will also include "obsoleted" files and "update" has the potential to NOT include obsoleted files. There is no difference in the default setup between update and upgrade. To get a difference, you need to set obsoletes flag in yum.conf to something other than its default value (obsoletes=1). If obsoletes is set to 0 instead of 1, then --update does not install packages that obsolete other packages.
The dist-upgrade analogy that you are looking for does not exist in CentOS ... we do not support real upgrades (that is from CentOS-3.x to CentOS-4.x) via yum at all.
4.1 or 4.2 or 4.3 or 4.x (any number for x) are all CentOS-4 and as Scott said, .1 or .2 or .3 are only a point in time freezing to allow for he spinning of a new ISO set for install. This is the same behavior that you would see if updating a RHEL machine against RHN as well.
Yum has no way to tell the difference either. You should turn off automatic updates, and do them all manually, and maybe join the announce list to be
Now ... an upgrade from 4.5 or 4.6 to 4.7 should not have broken your machine either, so we need to figure out why it did.
Johnny Hughes wrote:
Now ... an upgrade from 4.5 or 4.6 to 4.7 should not have broken your machine either, so we need to figure out why it did.
The server CD contains 4.4 and if you use yum you should be able to get to 4.7 without any problems. Its a different story if you have packages from other repos that could potentially overwite base so you end up with something else not CentOS.
Someone else has just posted his yum got broken by messing about with other repos trying to upgrade php. It is likely python, sqlite were all overwritten. As the CentOS wiki says if you break something from 3rd/4th party repos you get to keep the pieces.
Regards, Vandaman.
Vandaman wrote:
Johnny Hughes wrote:
Now ... an upgrade from 4.5 or 4.6 to 4.7 should not have broken your machine either, so we need to figure out why it did.
The server CD contains 4.4 and if you use yum you should be able to get to 4.7 without any problems. Its a different story if you have packages from other repos that could potentially overwite base so you end up with something else not CentOS.
Someone else has just posted his yum got broken by messing about with other repos trying to upgrade php. It is likely python, sqlite were all overwritten. As the CentOS wiki says if you break something from 3rd/4th party repos you get to keep the pieces.
Regards, Vandaman.
Ummmm. I s'pect Johnny Hughes, to whom you replied, understands repo mixing. http://www.centos.org/modules/tinycontent/index.php?id=2
Robert wrote:
Ummmm. I s'pect Johnny Hughes, to whom you replied, understands repo mixing.
Yeah Johnny understands repo mixing alright it was for the benefit of those who don't. Johnny has had to deal with City Managers threatening to call the FBI over CentOS see http://www.theregister.co.uk/2006/03/24/tuttle_centos/ so he knows much more than you think.
Regards, Vandaman.
Is there someone that can explain why I get incorrect results on centos 4.6 and 4.7 but not on centos 5.2??
The date "2008-10-26 +1 days" should results in 2008-10-27
On centos 4.6 -------------- test000:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d" 2008-10-26 test000:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-26 test000:/% uname -a Linux test000... 2.6.9-67.ELsmp #1 SMP Fri Nov 16 12:48:03 EST 2007 i686 i686 i386 GNU/Linux
On centos 4.7 -------------- test001:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d" 2008-10-26 test001:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-26 test001:/% uname -a Linux test001... 2.6.9-78.0.1.ELsmp #1 SMP Tue Aug 5 11:02:47 EDT 2008 i686 athlon i386 GNU/Linux
On centos 5.2 -------------- test002:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-27 test002:/% uname -a Linux test002... 2.6.18-92.1.10.el5 #1 SMP Tue Aug 5 07:42:41 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
On Sat, Oct 04, 2008 at 09:48:28PM +0200, Thomas Johansson wrote:
Is there someone that can explain why I get incorrect results on centos 4.6 and 4.7 but not on centos 5.2??
test000:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d" 2008-10-26 test000:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-26
My initial immediate guess would be daylight savings related; if in your timezone the clock goes back on the 26th then 2008-10-26 (which means 00:00) + 24 hours would only be 2008-10-26 23:00.
You can see this if you don't specify the format string
centos4.7$ date -d "2008-11-01 +1 days" Sun Nov 2 00:00:00 EDT 2008 centos4.7$ date -d "2008-11-02 +1 days" Sun Nov 2 23:00:00 EST 2008
However, in Centos5.2...
centos5.2$ date -d "2008-11-01 +1 days" Sun Nov 2 00:00:00 EDT 2008 centos5.2$ date -d "2008-11-02 +1 days" Mon Nov 3 00:00:00 EST 2008
Why the difference in behaviour, I dunno. But if this _IS_ your problem then you can specify 4am as the time to add 1 day to.
centos4.7$ date -d "2008-11-01 04:00 +1 days" "+%Y-%m-%d" 2008-11-02 centos4.7$ date -d "2008-11-02 04:00 +1 days" "+%Y-%m-%d" 2008-11-03
That'll work on both :-)
Stephen Harris wrote:
On Sat, Oct 04, 2008 at 09:48:28PM +0200, Thomas Johansson wrote:
Is there someone that can explain why I get incorrect results on centos 4.6 and 4.7 but not on centos 5.2??
test000:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d" 2008-10-26 test000:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-26
My initial immediate guess would be daylight savings related; if in your timezone the clock goes back on the 26th then 2008-10-26 (which means 00:00) + 24 hours would only be 2008-10-26 23:00.
That was my problem. Became confused when i got different behavior on centos 4 and centos 5. Problem solved! Thank you!
To avoid that kind of trouble i moved to perl for the date functionality in my script. That solution is also more portable across my different *nix platforms.
On Sat, 2008-10-04 at 21:48 +0200, Thomas Johansson wrote:
<snip>
On centos 4.6
test000:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d" 2008-10-26 test000:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-26 test000:/% uname -a Linux test000... 2.6.9-67.ELsmp #1 SMP Fri Nov 16 12:48:03 EST 2007 i686 i686 i386 GNU/Linux
On centos 4.7
test001:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d" 2008-10-26 test001:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-26
I just typed the above in on the console on my 4.7 node. WFM.
test001:/% uname -a Linux test001... 2.6.9-78.0.1.ELsmp #1 SMP Tue Aug 5 11:02:47 EDT 2008 i686 athlon i386 GNU/Linux
My kernel doesn't have the "smp", but otherwise matches.
<snip>
Another posted the possibility of TZ issues. Seems unlikely to me since you are providing a date string that does not require the system time zone information. It just converts to the binary offset value from the epoch, adds the binary equivalent of a day in seconds (IIRC) and formats the results as a string.
Maybe some library (like the ones used by asctime, ctime, ...) which are section 3 system calls (those used buy programs like date) are out of sync? Have you tried the rpm --verify to see if any discrepancies are reported?
HTH
On Sat, 2008-10-04 at 16:26 -0400, William L. Maltby wrote:
<snip>
On centos 4.7
test001:/% date -d "2008-10-25 +1 days" "+%Y-%m-%d" 2008-10-26 test001:/% date -d "2008-10-26 +1 days" "+%Y-%m-%d" 2008-10-26
I just typed the above in on the console on my 4.7 node. WFM.
test001:/% uname -a Linux test001... 2.6.9-78.0.1.ELsmp #1 SMP Tue Aug 5 11:02:47 EDT 2008 i686 athlon i386 GNU/Linux
My kernel doesn't have the "smp", but otherwise matches.
<snip>
Another posted the possibility of TZ issues. Seems unlikely to me since you are providing a date string that does not require the system time zone information. It just converts to the binary offset value from the epoch, adds the binary equivalent of a day in seconds (IIRC) and formats the results as a string.
Maybe some library (like the ones used by asctime, ctime, ...) which are section 3 system calls (those used buy programs like date) are out of sync? Have you tried the rpm --verify to see if any discrepancies are reported?
BTW, rpm -q --whatprovides /bin/date over here indicates coreutils-5.2.1-31.8.el4
I've not run the prerequisites for that, but there should be several specific libraries versions that must be in place. If one or more of those libraries has been updated from another repositiry or corrupted, that may be your problem.
Another thought: sometimes folks have a local alias or a similarly named command in an earlier part of $PATH (e.g. export PATH=$HOME/bin:$PATH) and then we (they) forget they did that. Or they inherit a system from another who made a similar modification. "whereis" date should reveal if that is the case.
Griesbach, Lutz wrote:
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
Is that possible?
No, the updates aren't nicely separated into ones that will break the services you happen to need and ones that won't. On the other hand it is pretty rare for a Centos update to break anything, so you might want to investigate the actual problem you had.
Want I normally do for critical servers is: yum install yum-downloadonly Then periodically yum -y --downloadonly which can run unattended, be ssh'd to a bunch of machines in a loop, etc. since it won't install anything. Then when you have time to babysit the actual install and reboot if it's a kernel or libc update, do the 'yum -y update' which will go quickly since the packages are already downloaded. Having a similar system to test first is always a good idea, but I can't think of anything in years where a Centos update actually caused a problem that couldn't be fixed quickly if you watched the rpmsave/rpmnew files from the installs.
Les Mikesell wrote on Thu, 02 Oct 2008 14:58:40 -0500:
No, the updates aren't nicely separated into ones that will break the services you happen to need and ones that won't.
Nice picture. I imagine them sitting around the table and rolling some dice to determine which ones to break this time.
Kai
Kai Schaetzl wrote:
Les Mikesell wrote on Thu, 02 Oct 2008 14:58:40 -0500:
No, the updates aren't nicely separated into ones that will break the services you happen to need and ones that won't.
Nice picture. I imagine them sitting around the table and rolling some dice to determine which ones to break this time.
That's an easy one: bind or samba. But not in a fifty-fifty fashion, it's bind more often >:)
Cheers,
Ralph
Hi,
Griesbach, Lutz wrote:
Hy there,
i have a centos (4.?) Box with nightly yum update enabled. Last night, it did an upgrade to 4.7 leading to several problem i.e. not respawning the dhcrelay, which is needed on this box.
ok, so there is something I dont understand here. You have yum nightly update enabled, but your machine only updated yesterday from 4.<something> to the latest in 4.7 ? What mirrors are you using that are so far adrift of the main mirror.centos.org ?
Can I control the update policy not to upgrade to new releases in the nightly updates? I would like do to nightly updates, but make release upgrades manual (I get a new kernel, so I have to reboot anyway).
The real problem I see here is that updates within a release are not supposed to break things. So, what you really need to do is workout what apps broke and why, then I'd request you to file bug reports against those packages at http://bugs.centos.org/
On Fri, 2008-10-03 at 15:23 +0100, Karanbir Singh wrote:
The real problem I see here is that updates within a release are not supposed to break things. So, what you really need to do is workout what apps broke and why, then I'd request you to file bug reports against those packages at http://bugs.centos.org/
JohnStanley Writes:
Karan, not to add fuel to the already burning fire but,,,,, If the OS contains ONLY CentOs Bits then it should not Break. 2nd But is,,,If the CentOs install contains Third Party RPMs then on yun update it most likely going to Kill those apps. IE, Proprietery Applications. I personally many times have had to disable yum update because of this.
Also I do fully understand what you mean by saying updates in the release are not supposed to break things but it happens all to often. Only way I know of now to stop that is to use the yum excludes.
John wrote:
If the OS contains ONLY CentOs Bits then it should not Break.
I dont see how this is relevant to this thread, the *only* bit of real info passed down from the OP is dhcrelay, which comes from the dhcp suite, and I am unaware of anyone shipping a different dhcp suite.
Also I do fully understand what you mean by saying updates in the release are not supposed to break things but it happens all to often.
And I hope you are being a good community member and submitting bug reports so something can be done about that...
Only way I know of now to stop that is to use the yum excludes.
err ? yum exclude=* ? yes, thats one way to stop updates. Or do you mean to imply exclude the software you are using on the machine ? which, to me, is silly - since arent those the bits of software you *really* do want bugfix / security fix/ updates for, since they are in production and therefore pose the largest targest.
Karanbir Singh wrote:
Also I do fully understand what you mean by saying
updates in the
release are not supposed to break things but it
happens all to often.
And I hope you are being a good community member and submitting bug reports so something can be done about that...
Wow you are spending an "awful" amount of time on this issue.Without hard evidence from Lutz its going nowhere. All of this because someone quoted Seth on probably what is the latest release of yum?
Regards, Vandaman.
On Fri, 2008-10-03 at 23:32 +0100, Karanbir Singh wrote: JohnStanley Writes:
And I hope you are being a good community member and submitting bug reports so something can be done about that...
Yes...
err ? yum exclude=* ? yes, thats one way to stop updates. Or do you mean to imply exclude the software you are using on the machine ? which, to me, is silly - since arent those the bits of software you *really* do want bugfix / security fix/ updates for, since they are in production and therefore pose the largest targest.
What I have to do with one a particular business is use yum excludes. I take and exclude all the RPMs that are dependancies for one specific application. I have really no choice in the matter of doing so although I do know there are security risks in do so. My problem is I can't have the machines os breaking the app. Then in turn when that happens I have to explain why. CEOs are money hungry people that want 24/7 uptime and do not care how. In the end I have to do what I am told by the CEO or have no job. I know the importance of them, but telling upper management is a whole-nother story.
I did miss the dhcrelay didnot see that, I apologize for that. It should not have broken.
-
Akemi Yagi -
Bob Hoffman -
Griesbach, Lutz -
John -
John Horne -
Johnny Hughes -
Kai Schaetzl -
Karanbir Singh -
Les Mikesell -
Lutz Griesbach
-
MHR -
Ralph Angenendt -
Ralph Angenendt -
Robert -
Scott Silva -
Stephen Harris -
Thomas Johansson -
Toby Bluhm -
Vandaman -
vandaman2002-rt＠yahoo.co.uk
-
William L. Maltby