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

Ok, so my system isn't dead but it's doing weird things since I last used CPAN.pm. To be fair, though, I did something weird to it, so maybe we're even.

My question is whether CPAN.pm had anything to do with it, or did something else happen on my system (like a Fedora update over the weekend, for example) to cause the weird behavior. Otherwise, this isn't a perl question so feel free to ignore all the extra details that I'm about to give.

I have CPAN.pm configured to install everything in ~/perl and I always run it as myself (not root), so my assumption would be that I couldn't have inadvertantly stomped on any system files.

On Friday, I was installing Net::SSH::Perl via cpan.pm, which drew in a large number of prerequisites & dependencies. In the middle of this I frantically hit ctrl-C to interrupt the process because I was being forced to leave (my wife called telling me I was already late).

On Monday, I discovered that tcsh won't run for me anymore (that's the shell I happen to like to use... don't try to change my mind). Whenever I try to run it, it seg faults.

This is as far as I could narrow it down, and my only question is whether my mess-up using CPAN.pm could have possibly caused this (and if so, what are your thoughts on how to fix it):

  • - From a root prompt, I couldn't su to my own username.... I would just get a root promt again (later discovered that tcsh was crashing with a segmentation fault.)
  • - when I changed my shell (chsh) to something other than tcsh (csh is linked to tcsh), I could su to my username, but I could not run tcsh from there (segmentation fault)
  • - when logged in as root, I could run tcsh just fine.
  • - my home directory is normally NFS mounted from a central file server. When I replace it with a "real" local directory, then tcsh doesn't have any problem. I've tried chaning the way nfs mounts the directory (automount vs. hard mount, etc) but none of that makes a difference. There's nothing wrong with the mount, though... I can see/access all files & directories ok, no delays or network errors.
  • - tried rebooting, but no improvement
  • - tried removing my .tcshrc & .login, no improvement
  • - the system /etc/csh.cshrc and /etc/csh.login files are executed to completion before the seg fault occurs.

    Any insight would be appreciated. Thanks!

    • Replies are listed 'Best First'.
    Re: Can CPAN.pm kill my system?
    by xdg (Monsignor) on Oct 25, 2005 at 13:39 UTC

      CPAN.pm can do anything that the user running it can do. A "test.t" file could erase all your files, or replace your binaries with trojans. (Actually, even installing as root could create trojans.) Not running CPAN.pm as root is a very good thing.

      Given your situation, you couldn't have stomped on system files, most likely. I'd try creating a new user and seeing if that new user can run tcsh. If so, then it's reasonable to conclude that something in the CPAN install might have caused some local problem for your original username -- something in ~/bin maybe? That said, I have a hard time understanding what it could have done. You might see if there are any outstanding processes -- I find that hitting CTRL-C in the middle of a test run often leaves perl running in the background chewing up processor cycles. Again -- not sure what impact that would have, but it's worth checking. Have you rebooted the machine?

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

    		[reply]
    Re: Can CPAN.pm kill my system?
    by Perl Mouse (Chaplain) on Oct 25, 2005 at 14:23 UTC
      My question is whether CPAN.pm had anything to do with it, or did something else happen on my system (like a Fedora update over the weekend, for example) to cause the weird behavior.
      I don't know about you, but if I use CPAN on Friday, and over the weekend an upgrade of my OS might have happened, and on Monday, my system is acting up, my (non-root) use of CPAN wouldn't be the first thing I'd consider as the cause of the problems.

      Having said that, I always run CPAN with a dedicated user (often called 'cpan' or the uninspiring 'perladmin'). The worse it can do is silently replacing files in site_lib with Trojans, but that shouldn't effect tcsh.

      Perl --((8:>*
    		[reply]
        Thanks for your replies. I feel better now. :)

        Actually, that reminds me of some CPAN.pm questions/issues I noticed. I'll post them as a separate thread.

        Thanks again.

    		[reply]
    Re: Can CPAN.pm kill my system?
    by blazar (Canon) on Oct 25, 2005 at 13:32 UTC
      I don't know. I don't think so. I heartily hope not so. I hope someone else, more knowledgeable than me, will shed more light on this. I'm sure nothing similar ever happened for me on any machine I've worked with. (Certainly no Fedora one... yet!)
    		[reply]
    Re: Can CPAN.pm kill my system?
    by bluto (Curate) on Oct 25, 2005 at 15:24 UTC
      When testing, make sure you find *all* files that tcsh may access (i.e. the man page also talks about: .cshdirs, .history, .cshrc, and others in the FILES section).

      my home directory is normally NFS mounted from a central file server.

      My sympathies. :-) Are the tcsh related files on NFS the exact same ones as on the local directory you tested?

      tried removing my .tcshrc & .login, no improvement

      Make sure you remove all of the tcsh related files (as above). See if the mtime on any of these has changed unexpectedly and/or compare to a backup.

      Are any filesystems full, esp your home dir or /tmp?

    		[reply]
        Thanks for the suggestion.

        I discovered that .history was causing the problem. I don't know yet what it was about the file that did this, or how it got corrupt, but removing the file and letting tcsh recreate it has solved the problem.

        Thanks again. I appreciate your help.
        Mischief managed.

    		[reply]

          It would be nice if you'd run strace on tcsh while having the "bad" history file in place.

          This way you may have a chance to find out more about the crash, and maybe fill a bug report too ;-)

          Dodge This!
    		[reply]
          I've seen something similar with zsh when I start another shell (e.g. ksh) and it writes into the same history file since they seem to have different formats. I now setup separate history files depending on what shell I'm using (e.g. ".history_zsh"). I don't know if tcsh supports changing the name, nor if CPAN could cause this, so YMMV.
    		[reply]

    Back to Seekers of Perl Wisdom