/home/.cpan/ fills up with garbage

[sehh]

Reading the output of /scripts/upcp that runs daily on my server, i noticed
that the script downloads the SAME files over and over again, uncompresses them
under /home/.cpan and just leaves them there, re-doing the same thing the next
day (runs via a cron job).

As a result, my /home/.cpan directory is about 200MB right now!!!

Here is an example of the files under /home/.cpan/build:

drwx------ 9 root root 4096 Sep 4 05:37 Mail-SPF-v2.005-aP6YWH/
-rw-r--r-- 1 root root 1322 Sep 4 05:37 Mail-SPF-v2.005-aP6YWH.yml
drwx------ 9 root root 4096 Sep 25 05:01 Mail-SPF-v2.005-aXgiMR/
-rw-r--r-- 1 root root 1322 Sep 25 05:01 Mail-SPF-v2.005-aXgiMR.yml
drwx------ 9 root root 4096 Sep 24 04:59 Mail-SPF-v2.005-axvQQv/
-rw-r--r-- 1 root root 1322 Sep 24 04:59 Mail-SPF-v2.005-axvQQv.yml

of course that continues for several pages and includes LOADS of other perl
packages, not just Mail-SPF.

Here is a part of the /scripts/upcp output:

Running install for module 'Mail::SPF'
Running make for J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.005.tar.gz
Checksum for
/home/.cpan/sources/authors/id/J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.005.tar.gz ok
Mail-SPF-v2.005/
Mail-SPF-v2.005/INSTALL
Mail-SPF-v2.005/CHANGES
Mail-SPF-v2.005/SIGNATURE
Mail-SPF-v2.005/lib/

... etc... (removed to make this shorter)

Installing /usr/share/man/man3/Mail::SPF::Record.3
Installing /usr/share/man/man3/Mail::SPF::MacroString.3
Skipping /usr/sbin/spfd (unchanged)
Skipping /usr/bin/spfquery (unchanged)
Writing /usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Mail/SPF/.packlist
JMEHNLE/mail-spf/Mail-SPF-v2.005.tar.gz
/usr/bin/make install UNINST=1 -- OK
Mail::SPF::Query is up to date (1.999.1).

So the update scripts downloads a newer version, uncompresses it in a new
directory, it ignores the fact that it has already downloaded the same file for
several weeks now, compiles and tries to install it but fails for some reason.
It goes on to re-do the same procedure the next time /scripts/upcp runs.

Any help would be appreciated.

[verdon]

Good catch, I just checked mine and have nearly 900 tarballs and dirs in there, totaling almost a GB in space. I'd like to hear from someone with a little more knowledge than me, but I suspect it's probably safe to just delete the entire dir. My guess is that it will recreate itself as needed. I am just guessing though

[sehh]

I know that its definitely safe to delete the contents of the /home/.cpan/build/ directory, but i am not sure about the others.

[chirpy]

You can safely delete the /home/.cpan/ directory. It will be recreated when upcp installs updates to perl modules. IIRC, whether file sare removed is down to CPAN.pm configuration.

[sehh]

Now you are just trying to pass the problem to Perl and we know that its not a Perl problem but a cPanel script bug (/scripts/upcp?).

Since its "upcp" that executes and updates perl/cpan along with its own modules and scripts, then its up to the "upcp" script itself to clean the /home/.cpan/ directory.

Unless you put a big warning on cPanel that says "oh yeah, we forgot to tell you that its the admins responsibility to clean several GIGS of garbage from /home/.cpan/ because we can't spend 10 min to fix our script".

[cPanelDavidG]

Now you are just trying to pass the problem to Perl and we know that its not a Perl problem but a cPanel script bug (/scripts/upcp?).

Since its "upcp" that executes and updates perl/cpan along with its own modules and scripts, then its up to the "upcp" script itself to clean the /home/.cpan/ directory.

Unless you put a big warning on cPanel that says "oh yeah, we forgot to tell you that its the admins responsibility to clean several GIGS of garbage from /home/.cpan/ because we can't spend 10 min to fix our script".

If you feel strongly about this, I'd recommend creating a feature request about this at http://bugzilla.cpanel.net

[sehh]

I've opened several bug reports, most of them are marked as "enhancements" by your staff and left there for years and years, you can look at them yourself, you'll find that most are never fixed.

I've already opened a ticket in the bugzilla, and guess what.. it was marked as an "enhancement" as well... no big surprise there. Ticket number is 5935 in case you'd like to check.

Sorry if i'm being sarcastic, but i'm tired of the complete lack of support. Sure, there is support for those paying for it or for the very big customers but for the rest of us i don't see anything happening any time soon.

[cPanelDavidG]

I've opened several bug reports, most of them are marked as "enhancements" by your staff and left there for years and years, you can look at them yourself, you'll find that most are never fixed.

I've already opened a ticket in the bugzilla, and guess what.. it was marked as an "enhancement" as well... no big surprise there. Ticket number is 5935 in case you'd like to check.

Sorry if i'm being sarcastic, but i'm tired of the complete lack of support. Sure, there is support for those paying for it or for the very big customers but for the rest of us i don't see anything happening any time soon.

If you believe it to be a support issue rather than a bug/feature request, then submit a support ticket rather than a bug report/feature request.

[Website Rob]

While we're at it, how about claification on; remove / no remove, the following within the 'home' dir:

cpanel-rpmstor/
cpapachebuild/ << this I would presume must/should stay
.cpcpan/
cprestore/
cptmp/
cpzendinstall/
MySQL-install

[verdon]

While we're at it, how about claification on; remove / no remove, the following within the 'home' dir:

I've never had some of these, so don't really know but I would bet they pretty much all fall into the same category.

[sehh]

I believe that /home/cprestore is used when a user clicks on the "backup my cpanel" option. cPanel generates a compressed archive of the home directory of the user and places it in there, then it allows the user to download it.

Unfortunately those archives are never deleted or at least i've never seen cPanel delete them and its a well known trick to actually store whole GIGs for free because anything stored like that doesn't count against the users quota.

So yes its safe to delete, unless one of your users is actively downloading a backup archive.