Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Upgrading Perl in production environment

by Sprad (Hermit)
on Mar 19, 2004 at 17:15 UTC ( [id://338054]=perlquestion: print w/replies, xml ) Need Help??

Sprad has asked for the wisdom of the Perl Monks concerning the following question:

We're currently using Perl 5.6, and I'd like to move to 5.8 for the safe signals. I'm not the only Perl user in the company, though, so I need to make sure that the switch won't do any harm. How can I find out what sort of things might break going from 5.6 to 5.8?

And in a more general sense, what are some good practices to follow when doing a version upgrade?

---
A fair fight is a sign of poor planning.

Replies are listed 'Best First'.
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

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.
      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.
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

      Actually, the SYS::sigaction module is more friendly and quite easy to use. It is a wrapper for the POSIX::sigaction module.
        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

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...
      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

        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..

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.

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.

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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://338054]
Approved by Thelonius
Front-paged by coreolyn
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2024-03-28 20:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found