Date: Thu, 23 Aug 2012 16:50:13 +0200 From: Polytropon <freebsd@edvax.de> To: kpneal@pobox.com Cc: freebsd-questions <freebsd-questions@freebsd.org>, Andy Wodfer <wodfer@gmail.com> Subject: Re: /tmp filesystem full Message-ID: <20120823165013.f131bcf0.freebsd@edvax.de> In-Reply-To: <20120823135408.GA76656@neutralgood.org> References: <201208221934.q7MJYfwM063804@mail.r-bonomi.com> <1345664911.2501.8.camel@z6000.lenzicasa> <CAHu1Y72xwNevgKQ8eVYYOzGC80-511DtDe8kJMWbYJm5Tq28CA@mail.gmail.com> <20120822232112.07ac3517@gumby.homeunix.com> <20120822232907.34fc82fc@gumby.homeunix.com> <CAHu1Y71Y_cxv_qgQaMmzdx5kZHtXGuLGaxx9QQAE8QBWGL3fUA@mail.gmail.com> <20120823031754.0b52bed6@gumby.homeunix.com> <CAHu1Y72OdQqxEeehj_ST1pCa4_3QPiT3PqNej4m-psn22bEu2w@mail.gmail.com> <CABgB0xTYFOjC1dgCQxR_E3Aq5M0aKo_ttfk7LmuxQJBkvCvUzA@mail.gmail.com> <20120823135408.GA76656@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 23 Aug 2012 09:54:08 -0400, kpneal@pobox.com wrote:
> On Thu, Aug 23, 2012 at 11:04:02AM +0200, Andy Wodfer wrote:
> > Can't seem to figure out the problem with MAXPATHLEN.
> >
> > locate: integer out of +-MAXPATHLEN (1024): 1029
> >
> >
> > In my /etc/locate.rc I have pruned several directories (even the most
> > obvious) - still the locate DB exeeds well over 1GB before outputting this
> > error message.
> >
> > I have moved the tmp dir for locate to /usr/tmp which works fine (changed
> > in locate script) and there is no problems with diskspace here.
> >
> > the find awk command suggested earlier in this thread didn't give me a
> > better clue about what's happening.
> >
> > Anyone have any other ideas what I can try to find out why locate fails?
>
> I'm starting to wonder if you have a corrupt filesystem. Do you have
> a large number of files or something? My locate database is about three
> megs in size. Granted, I don't have that much data to index.
On my home system, it's 16 GB, but that's still far away from
any gigabyte "barrier"...
> A loop in the filesystem will eventually result in a path that is
> too long. Use fsck to diagnose a corrupt filesystem if you are using
> UFS/UFS2.
Performing a file system check is a good advice, just to make
sure there's not a file system inconsistency that triggers some
abnormal behaviour. Note that _repairing_ a potential defect
should be done in single user mode ("boot -s") on the unmounted
partitions.
> If you don't mind a teeny bit of scripting then you can get close to
> the problem with a find command that runs a short python script:
>
> find / -exec scriptname {} \;
>
> Where scriptname is an executable file with contents something like this:
>
> # /usr/local/bin/python
>
> import sys
>
> for x in sys.argv[1:]:
> if len(x) > 900: # make higher or lower as needed
> sys.stdout.write(x + "\n")
> sys.stdout.flush()
>
> This script takes all command line arguments to it and prints them
> out if the length of the argument exceeds 900 characters. The find
> command I gave above should run this script and give it each
> filename as it comes across it.
In short and which system tools only:
% find / -type d | awk 'length > 900'
And with storing a list for further reference:
% find / -type d | awk 'length > 900' > /tmp/longpaths.txt
Also note that this test only considers path names. In case
you have long _file_ names (or names containing corrupt characters
maybe), that could also be a problem, as the locate command also
records those, if I remember correctly. You can change the "-type d"
to "-type f" to test for file names (_including_ the path).
See "man find" for details.
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120823165013.f131bcf0.freebsd>