graceful handling of perl upgrades on server?

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

I have a server that runs Debian, and recently when I did an apt-get upgrade, it upgraded perl from 5.8 to 5.10. What hadn't occurred to me was that I had some scripts that were still running, which had been initialized with @INC set to all the proper paths for 5.8. I didn't notice until several weeks later that they were crashing with errors whenever they were invoked. The solution was simply to restart the scripts. I have a list of tests that I always do after an upgrade, and now this is on my list. But is there some simpler/easier/graceful/automagic way to approach this? Another issue that creates hassles is that I use apt for all the perl modules that are packaged for debian, and cpan for the rest; sometimes apt and cpan step on each other's toes.

---

Thanks, everyone, for the replies! Wow, I really learned a lot from this discussion -- both about perl and about unix :-)

Comment on graceful handling of perl upgrades on server?

Replies are listed 'Best First'.
Re: graceful handling of perl upgrades on server? by Tanktalus (Canon) on Dec 09, 2009 at 21:56 UTC
Whenever I upgrade running processes, I check lsof. Specifically, `lsof \| grep DEL.*lib \| less -S` (as root). Any process there (the first column) needs to be considered for restarting at your earliest opportunity. Generally, this includes a lot of my desktop apps which I worry about less, since I just log out and log back in and they'll all be reloaded (sometimes, this includes kwin, or even X, which pretty much necessitates this approach). Others are simply a restart of their file in /etc/init.d. This applies to all processes, not just perl. It just so happens that it will probably solve your perl question, too, as the perl executable is one of the open files that will be missing.	[reply] [d/l]
Re^2: graceful handling of perl upgrades on server? by bcrowell2 (Friar) on Dec 09, 2009 at 22:33 UTC
Aha -- that's good to know, thanks! Using lsof as you suggested, I notice that all my getty processes have a deleted version of libc open. Seems strange, since I'd think that that would have caused getty to crash, making it impossible for me to log in.	[reply]
Re^3: graceful handling of perl upgrades on server? by eye (Chaplain) on Dec 10, 2009 at 07:43 UTC
Deleting (unlinking) files doesn't make them go away. If something has the file open, it will prevent re-allocation of the files resources until the file is closed. libc should still be accessible to getty and any other application using it (including the OS). Note that an unlinked file cannot be closed and re-opened even within the same process.	[reply]
Re: graceful handling of perl upgrades on server? by trwww (Priest) on Dec 09, 2009 at 21:57 UTC
But is there some simpler/easier/graceful/automagic way to approach this? My procedure is to never use the system perl for my applications. It is extremely easy to build a seperate perl, and it avoids an entire class of problems like the one you describe. See Re: 2nd Perl installation on Mac OSX for how and blaming perl for not using a build policy for why.	[reply]
Re: graceful handling of perl upgrades on server? by leighsharpe (Monk) on Dec 10, 2009 at 02:18 UTC
To avoid having apt and cpan step on each other's toes, don't install from cpan. Instead, use dh-make-perl to download packages from cpan and make a .deb out of them. Then install from the .deb. That way, you get all the advantages of apt, plus all the variety of cpan. A brief overview can be found here.	[reply]
Re: graceful handling of perl upgrades on server? by rowdog (Curate) on Dec 10, 2009 at 01:30 UTC
Look before you leap. You should always look at what you are upgrading before you say yes. When you do say yes, you should expect anything that gets upgraded to break.	[reply]
Re: graceful handling of perl upgrades on server? by shawnhcorey (Friar) on Dec 10, 2009 at 14:51 UTC
All daemons should be written so that they periodically die and restart. That way any forgotten file handles are closed, zombie children are removed, memory leaks vanish, and a general clean-up is done.	[reply]