Re: Upgrading Perl in production environment
by Abigail-II (Bishop) on Mar 19, 2004 at 17:39 UTC
|
Well, you could read perldelta, and keep tracks of the reported bugs on perlbug, but that doesn't mean you detect
all things that break your programs.
But there are things you can do. First is to have a testing
environment, and a solid test suite. This hopefully unearth
things that break. But testing only determines breakage, it
doesn't resolve them.
A better approach is to have each application (or set of applications) carry its own version of Perl. That is, you
package an appropriate run-time environment of perl with
your application. Then, if one application needs a newer
version of Perl, no other application will break. Installing
newer versions of modules won't break other applications.
One can easily have different 'types' (64-bit ints, threads, dynamic library) of perl as well this way.
Abigail | [reply] [Watch: Dir/Any] |
Re: Upgrading Perl in production environment
by tinita (Parson) on Mar 19, 2004 at 17:31 UTC
|
i would install the new version parallel to the old. so you're
safe in the way that you have the running version in case you need it.
then you can either link the new executables to /usr/bin/perl* (or such) and let the old version be callable
through perlx.y.z, or let the old version be the default.
that depends on how many users and scripts there are relying
on perl, so go and ask before changing anything.
infos on changes are found in perldelta.
update: and, of course, be sure to get a stable
version. | [reply] [Watch: Dir/Any] |
|
This is a good thing for pretty much any software on production boxes. I always install things into their own directory and then symlink them to where they're needed. Of course there are times when symlinks wont do what you want but I've run into fewer and fewer of those.
| [reply] [Watch: Dir/Any] |
Re: Upgrading Perl in production environment
by chip (Curate) on Mar 19, 2004 at 17:29 UTC
|
Read the "perl58delta" document in the 5.8.x distribution. It will tell you what's different, in roughly descending order of possible problems. And if you go for 5.8.1, 5.8.2, etc. you should also check "perl581delta", "perl582delta", etc.
PS: You should be sure it's 5.8.1 or later if you're interested in safe signals, because 5.8.1 supports safe and unsafe signals with a command line option, as well as through POSIX::sigaction. Older versions could only do unsafe signals through sigaction. (I know this because I submitted the sigaction patch. :-))
OTOH, there's no reason not to get 5.8.3 anyway...
-- Chip Salzenberg, Free-Floating Agent of Chaos
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Actually, the SYS::sigaction module is more friendly and quite easy to use. It is a wrapper for the POSIX::sigaction module.
| [reply] [Watch: Dir/Any] |
|
Sys::SigAction isn't evil, but it's kind of pointless, IMO. A whole module just to avoid a few SigAction object accessor calls? Hardly worth the trouble.
-- Chip Salzenberg, Free-Floating Agent of Chaos
| [reply] [Watch: Dir/Any] |
|
Re: Upgrading Perl in production environment
by jfroebe (Parson) on Mar 19, 2004 at 17:26 UTC
|
Watch out for the signal handling changes! version 5.8x uses deferred signal delivery.. meaning that certain system calls may not be interrupted or aborted. There are workarounds for using the old behavior... | [reply] [Watch: Dir/Any] |
|
There's a reason the unsafe signals are called "unsafe". It's been my loud opinion for a long time that Perl should never have had unsafe signals ... there is never an excuse for Perl dumping core, and with unsafe signals, Perl dumps core. If you're lucky.
-- Chip Salzenberg, Free-Floating Agent of Chaos
| [reply] [Watch: Dir/Any] |
|
Actually it is best to have both with deferred as the default. Why? Because sometimes it is better to fail completely and restart the process then to hang forever. This would be primarily useful in production environments where time is the critical factor (i.e. Trading systems).
update
I guess I should have been more clear... the scripts for maintenance mostly and information gathering not for the trading itself.
The maintenance windows tend to be very short. If a scripts hangs on say a gethostbyaddr() then abort the call, and retry the gethostbyaddr().. if the script goes down, start the entire job over.
If the process normally takes 10 mins and if the script hangs on 9 mins 59seconds, then I would rather risk restarting that hanging operation then having to start all over again... if it goes down, then I will start it all over again.
I'm using "trading systems" as an example..
| [reply] [Watch: Dir/Any] |
|
|
|
Re: Upgrading Perl in production environment
by pbeckingham (Parson) on Mar 19, 2004 at 17:26 UTC
|
Threading might potentially be a breakage point, but there is a published change list for the Perl 5.8.x release that you should study. Look at the 'perlxxxxdelta' pods that are available.
| [reply] [Watch: Dir/Any] |
Re: Upgrading Perl in production environment
by dragonchild (Archbishop) on Mar 19, 2004 at 18:32 UTC
|
Whenever I install Perl, it always installs to /usr/local/bin/perl5.x.x-blahblah, where blahblah is something like 64, thread, etc. I then symlink /usr/local/bin/perl to whichever I feel is the appropriate default. But, various apps can choose to pick a different Perl, should they choose. (I do the same thing with every Unix app, actually.)
Then, test-suites are good things.
(Plus, you do have an identical dev for your prod where you can test these changes, right?)
------
We are the carpenters and bricklayers of the Information Age.
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] [Watch: Dir/Any] |
Re: Upgrading Perl in production environment
by stvn (Monsignor) on Mar 20, 2004 at 03:00 UTC
|
I am surprised that no one has mentioned this yet. But any compiled modules (XS) will need to be re-compiled, 5.6 modules are not be binary compatable with 5.8.
-stvn
| [reply] [Watch: Dir/Any] |