Re: /var full
Paul Schmehl wrote: --On June 18, 2008 11:59:49 PM -0400 Sahil Tandon [EMAIL PROTECTED] wrote: Also, what is the output of 'df -i /var'? # df -i /var/ Filesystem 1K-blocksUsed Avail Capacity iusedifree %iused Mounted on /dev/da1s1d 283737842 5397568 255641248 2% 20350 366736640% /var See recent thread on FreeBSD Forums for context: http://www.freebsdforums.org/forums/printthread.php?t=58071 Thanks. At least I know I'm not the only one to have run into this oddity. I'm not that knowledgeable of inodes. My understanding is they are destroyed once a file is no longer in use. Is that correct? Is there any sort of history kept of file system activity that would identify what filename was identified by the inumbers listed in dmesg.today? Or is that vain hope? This is a 6.2 RELEASE system. (Looks like it's time to upgrade to 7.0 STABLE.) I am not in any which way certain changing major revision numbers will affect the file system in any which way. I am also not very knowledgeable in regards to inodes, but I do know that they can run out before disk space does. From what I understand, 1MB of filespace will take up X inodes. If 1MB of file size is fragmented, it could take up X multiplied by N number of inodes, that could include a large portion of wasted whitespace. Please correct me if I am wrong. Off the top of my head, with no testing or researching behind me, what happens if: - stop mysqld - note perms of filesystem - cp -R /var/db /another/location/with/space - rm -r /var/db/* - fsck /dev/location-of-var - cp -R /copy/of/db/dir /var/db - reset perms - start mysqld ... does that free up some inodes? Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
Steve Bertrand writes: I am not in any which way certain changing major revision numbers will affect the file system in any which way. I am also not very knowledgeable in regards to inodes, but I do know that they can run out before disk space does. It is my understanding that is certainly possible. However, it is usually limited to a small set of well-known cases of that generate many small files; the canonical example is a news server (e.g. inn) though a mail server (or the database back-end thereto) might also qualify. Off the top of my head, with no testing or researching behind me, what happens if: - stop mysqld - note perms of filesystem - cp -R /var/db /another/location/with/space - rm -r /var/db/* - fsck /dev/location-of-var Ahem - dismount partition before fsck, yes? Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
Steve Bertrand writes: I am not in any which way certain changing major revision numbers will affect the file system in any which way. I am also not very knowledgeable in regards to inodes, but I do know that they can run out before disk space does. It is my understanding that is certainly possible. However, it is usually limited to a small set of well-known cases of that generate many small files; the canonical example is a news server (e.g. inn) though a mail server (or the database back-end thereto) might also qualify. Off the top of my head, with no testing or researching behind me, what happens if: - stop mysqld - note perms of filesystem - cp -R /var/db /another/location/with/space - rm -r /var/db/* - fsck /dev/location-of-var Ahem - dismount partition before fsck, yes? Well, of course as you please ;) Thanks for pointing out my mis-step. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
--On Thursday, June 19, 2008 02:28:31 -0400 Steve Bertrand [EMAIL PROTECTED] wrote: Paul Schmehl wrote: --On June 18, 2008 11:59:49 PM -0400 Sahil Tandon [EMAIL PROTECTED] wrote: Also, what is the output of 'df -i /var'? # df -i /var/ Filesystem 1K-blocksUsed Avail Capacity iusedifree %iused Mounted on /dev/da1s1d 283737842 5397568 255641248 2% 20350 366736640% /var See recent thread on FreeBSD Forums for context: http://www.freebsdforums.org/forums/printthread.php?t=58071 Thanks. At least I know I'm not the only one to have run into this oddity. I'm not that knowledgeable of inodes. My understanding is they are destroyed once a file is no longer in use. Is that correct? Is there any sort of history kept of file system activity that would identify what filename was identified by the inumbers listed in dmesg.today? Or is that vain hope? This is a 6.2 RELEASE system. (Looks like it's time to upgrade to 7.0 STABLE.) I am not in any which way certain changing major revision numbers will affect the file system in any which way. I am also not very knowledgeable in regards to inodes, but I do know that they can run out before disk space does. From what I understand, 1MB of filespace will take up X inodes. If 1MB of file size is fragmented, it could take up X multiplied by N number of inodes, that could include a large portion of wasted whitespace. Please correct me if I am wrong. I wouldn't be the one to correct you. My knowledge of inodes is rudimentary at best. :-) Off the top of my head, with no testing or researching behind me, what happens if: - stop mysqld - note perms of filesystem - cp -R /var/db /another/location/with/space - rm -r /var/db/* - fsck /dev/location-of-var - cp -R /copy/of/db/dir /var/db - reset perms - start mysqld ... does that free up some inodes? As you can see from the df -i I posted (to which you responded), inode exhaustion is not an issue. I'm leaning toward some sort of bug in mysql version 5.0.51 which creates a temporary file (in the wrong place) and then doesn't release it until it exhausts the space on the drive. In any case, I'm going to report it to the mysql folks as such and hope they can figure out what the cause is. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
On Jun 19, 2008, at 9:40 AM, Paul Schmehl wrote: As you can see from the df -i I posted (to which you responded), inode exhaustion is not an issue. You are probably right about that, but could you also post the result of sudo tunefs -p /var That won't tell us what is in use, but it will confirm whether /var was set up with funky parameters or not. Also, the last time I ran out of inodes, the error messages made it clear that that was what was happening instead of merely giving a disk full error. I'm leaning toward some sort of bug in mysql version 5.0.51 which creates a temporary file (in the wrong place) and then doesn't release it until it exhausts the space on the drive. In any case, I'm going to report it to the mysql folks as such and hope they can figure out what the cause is. That would be my guess. I haven't seen a mention of that of the mysql lists, but I don't follow the lists closely. (For the most part, I just go and clean out the mail folder they collect in every week or so.) Cheers, -j -- Jeffrey Goldberghttp://www.goldmark.org/jeff/
Re: /var full
--On Thursday, June 19, 2008 11:09:57 -0500 Jeffrey Goldberg [EMAIL PROTECTED] wrote: On Jun 19, 2008, at 9:40 AM, Paul Schmehl wrote: As you can see from the df -i I posted (to which you responded), inode exhaustion is not an issue. You are probably right about that, but could you also post the result of sudo tunefs -p /var # tunefs -p /var tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) That won't tell us what is in use, but it will confirm whether /var was set up with funky parameters or not. Also, the last time I ran out of inodes, the error messages made it clear that that was what was happening instead of merely giving a disk full error. I'm leaning toward some sort of bug in mysql version 5.0.51 which creates a temporary file (in the wrong place) and then doesn't release it until it exhausts the space on the drive. In any case, I'm going to report it to the mysql folks as such and hope they can figure out what the cause is. That would be my guess. I haven't seen a mention of that of the mysql lists, but I don't follow the lists closely. (For the most part, I just go and clean out the mail folder they collect in every week or so.) I looked all over their website and didn't see a place or an email address to submit bug reports unless you're an enterprise customer. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
Paul Schmehl wrote: I'm leaning toward some sort of bug in mysql version 5.0.51 which creates a temporary file (in the wrong place) and then doesn't release it until it exhausts the space on the drive. In any case, I'm going to report it to the mysql folks as such and hope they can figure out what the cause is. try to find the file with # fstat | grep var This will give a list with inodes for open files (the 6th column). # find /var -inum inode will the display the file (unless it has been deleted while still open - seen that once: restarting mysql probably will resolve that). Peter -- http://www.boosten.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
--On Thursday, June 19, 2008 20:02:59 +0200 Peter Boosten [EMAIL PROTECTED] wrote: Paul Schmehl wrote: I'm leaning toward some sort of bug in mysql version 5.0.51 which creates a temporary file (in the wrong place) and then doesn't release it until it exhausts the space on the drive. In any case, I'm going to report it to the mysql folks as such and hope they can figure out what the cause is. try to find the file with # fstat | grep var This will give a list with inodes for open files (the 6th column). # find /var -inum inode Interesting. From the last section of entries in dmesg.today: pid 73721 (dd), uid 2 inumber 27131920 on /var: filesystem full pid 730 (mysqld), uid 88 inumber 27132148 on /var: filesystem full # find /var/ -inum 27132148 /var/db/mysql/buttercup3-bin.31 # ls -lsa /var/db/mysql/buttercup3-bin.31 15856 -rw-rw 1 mysql mysql 16208184 Jun 19 03:28 /var/db/mysql/buttercup3-bin.31 # find /var/ -inum 27131920 /var/db/entropy/saved-entropy.6 # ls -lsa /var/db/entropy/saved-entropy.6 2 -r 1 operator operator 2048 Jun 19 17:33 /var/db/entropy/saved-entropy.6 So it could have been something else entirely, and when those files tried to write to /var it was already full? Why is operator running dd? Is it trying to fix the problem? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
Paul Schmehl wrote: --On Thursday, June 19, 2008 20:02:59 +0200 Peter Boosten [EMAIL PROTECTED] wrote: Paul Schmehl wrote: I'm leaning toward some sort of bug in mysql version 5.0.51 which creates a temporary file (in the wrong place) and then doesn't release it until it exhausts the space on the drive. In any case, I'm going to report it to the mysql folks as such and hope they can figure out what the cause is. try to find the file with # fstat | grep var This will give a list with inodes for open files (the 6th column). # find /var -inum inode Interesting. From the last section of entries in dmesg.today: pid 73721 (dd), uid 2 inumber 27131920 on /var: filesystem full pid 730 (mysqld), uid 88 inumber 27132148 on /var: filesystem full # find /var/ -inum 27132148 /var/db/mysql/buttercup3-bin.31 # ls -lsa /var/db/mysql/buttercup3-bin.31 15856 -rw-rw 1 mysql mysql 16208184 Jun 19 03:28 /var/db/mysql/buttercup3-bin.31 Do you replicate this mysql server to another? If not, comment the log-bin directive in my.cnf. That'll take care of these binary logfiles. Peter So it could have been something else entirely, and when those files tried to write to /var it was already full? My first thought: mysql is just reporting something wrong, but isn't actually causing it. I've seen a partition filling up once by a deleted, yet open apache log file. No df nor du reported a full disk, yet it was. Restarting apache did the trick. Peter -- http://www.boosten.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
Paul Schmehl [EMAIL PROTECTED] wrote: At 10PM (local time) this evening, a server started reporting that /var was full. When I ssh'd in to the server to investigate, df said /var was at 2% full (5.1G) and dh reported the same (5.1G). /var/log/dmesg.today is full of messages listing multiple entries with the same inode number followed by one entry listing dd as the culprit. +pid 730 (mysqld), uid 88 inumber 7089166 on /var: filesystem full [...] Was this some sort of temporary glitch? Or something more ominous? Why would toor be running dd? Is it some sort of file recovery routine triggered by filesystem full messages? This appears to be mysql-related: http://dev.mysql.com/doc/refman/5.0/en/temporary-files.html Also, what is the output of 'df -i /var'? See recent thread on FreeBSD Forums for context: http://www.freebsdforums.org/forums/printthread.php?t=58071 -- Sahil Tandon [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
--On June 18, 2008 10:45:57 PM -0500 Paul Schmehl [EMAIL PROTECTED] wrote: Why would toor be running dd? Is it some sort of file recovery routine triggered by filesystem full messages? Sheesh - that's operator, not toor, of course. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var full
--On June 18, 2008 11:59:49 PM -0400 Sahil Tandon [EMAIL PROTECTED] wrote: Paul Schmehl [EMAIL PROTECTED] wrote: At 10PM (local time) this evening, a server started reporting that /var was full. When I ssh'd in to the server to investigate, df said /var was at 2% full (5.1G) and dh reported the same (5.1G). /var/log/dmesg.today is full of messages listing multiple entries with the same inode number followed by one entry listing dd as the culprit. +pid 730 (mysqld), uid 88 inumber 7089166 on /var: filesystem full [...] Was this some sort of temporary glitch? Or something more ominous? Why would toor be running dd? Is it some sort of file recovery routine triggered by filesystem full messages? This appears to be mysql-related: I gathered that from the error messages. http://dev.mysql.com/doc/refman/5.0/en/temporary-files.html Hmmm..tmpdir is not defined in /etc/my.cnf, so if I'm reading this right, mysqld *should* use /tmp for its temporary files. This server has a /tmp partition that is 3.2GB, so that should be more than ample space *if* mysqld is really using it. It appears that it may be using /var/tmp instead, which would be incorrect behavior *if* I'm reading their docs right. But this /var partition is 300GB, so that's a really, really huge temporary file. Also, what is the output of 'df -i /var'? # df -i /var/ Filesystem 1K-blocksUsed Avail Capacity iusedifree %iused Mounted on /dev/da1s1d 283737842 5397568 255641248 2% 20350 366736640% /var See recent thread on FreeBSD Forums for context: http://www.freebsdforums.org/forums/printthread.php?t=58071 Thanks. At least I know I'm not the only one to have run into this oddity. I'm not that knowledgeable of inodes. My understanding is they are destroyed once a file is no longer in use. Is that correct? Is there any sort of history kept of file system activity that would identify what filename was identified by the inumbers listed in dmesg.today? Or is that vain hope? This is a 6.2 RELEASE system. (Looks like it's time to upgrade to 7.0 STABLE.) Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
Warren wrote: im trying to get cacti working, but since im using a small P2 300 machine with a small hdd my /var has suddenly become full and im wodering what is safe and not safe so to speak to del in the /var dir .. the following are the dir's i have. --- cut drwxr-xr-x 2 rootwheel 512 Feb 7 03:09 log drwxrwxr-x 3 rootmail 512 Feb 4 21:41 mail these two directories are probably the ones you want to look at, some logfiles might have grown pretty big, and maybe there's loads of mail in /var/mail ? (switching to email for your users in their home-dirs is an idea) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
On Mon, 7 Feb 2005 11:20 pm, albi wrote: Warren wrote: im trying to get cacti working, but since im using a small P2 300 machine with a small hdd my /var has suddenly become full and im wodering what is safe and not safe so to speak to del in the /var dir .. the following are the dir's i have. --- cut drwxr-xr-x 2 rootwheel 512 Feb 7 03:09 log drwxrwxr-x 3 rootmail 512 Feb 4 21:41 mail these two directories are probably the ones you want to look at, some logfiles might have grown pretty big, and maybe there's loads of mail in /var/mail ? (switching to email for your users in their home-dirs is an idea) Sadly neither the log dir nor mail had much in it since they where the 1st 2 i also thought of. -- Yours Sincerely Shinjii http://www.shinji.nq.nu ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
Warren wrote: Sadly neither the log dir nor mail had much in it since they where the 1st 2 i also thought of. what about /var/tmp ? also, a du -h /var might help ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
On Mon, 7 Feb 2005 11:34 pm, albi wrote: Warren wrote: Sadly neither the log dir nor mail had much in it since they where the 1st 2 i also thought of. what about /var/tmp ? also, a du -h /var might help awesome .. i was wondering about a command to list the stuff inthe individual dir's and it seems some old packages that have been de-installed ahev remnets and a lot of them in the /var/db port totalling a significant amount of Meg. Thanks for the help. -- Yours Sincerely Shinjii http://www.shinji.nq.nu ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
Warren wrote: im trying to get cacti working, but since im using a small P2 300 machine with a small hdd my /var has suddenly become full and im wodering what is safe and not safe so to speak to del in the /var dir .. the following are the dir's i have. drwxr-xr-x 2 rootwheel 512 Feb 24 2004 account drwxr-xr-x 4 rootwheel 512 Aug 8 2004 at drwxr-x--- 2 rootwheel 512 Feb 5 03:01 backups drwxr-x--- 2 rootwheel 512 Aug 8 2004 crash drwxr-x--- 3 rootwheel 512 Aug 8 2004 cron drwxr-xr-x 10 rootwheel 512 Feb 6 20:51 db dr-xr-xr-x 2 rootwheel 512 Feb 24 2004 empty drwx-- 2 rootwheel 512 Feb 24 2004 heimdal drwxr-xr-x 2 rootwheel 512 Feb 7 03:09 log drwxrwxr-x 3 rootmail 512 Feb 4 21:41 mail drwxr-xr-x 2 daemon wheel 512 Aug 8 2004 msgs drwxr-xr-x 5 rootwheel 512 Oct 3 22:26 named drwxr-xr-x 2 rootwheel 512 Feb 24 2004 preserve drwxr-xr-x 5 rootwheel 512 Feb 5 12:15 run drwxrwxr-x 2 rootdaemon512 Feb 24 2004 rwho drwx--x--- 4 rootuucp 512 Jan 21 22:40 smtpd drwxr-xr-x 8 rootwheel 512 Aug 8 2004 spool drwxrwxrwt 7 rootwheel 512 Feb 6 19:52 Although you have now found your solution, I'd recommend for such a question to submit the output of 'du -d1' instead - this will show which directories are using up the space. Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
On Tue, 8 Feb 2005 12:19 am, Erik Norgaard wrote: Warren wrote: im trying to get cacti working, but since im using a small P2 300 machine with a small hdd my /var has suddenly become full and im wodering what is safe and not safe so to speak to del in the /var dir Although you have now found your solution, I'd recommend for such a question to submit the output of 'du -d1' instead - this will show which directories are using up the space. Cheers, Erik enterprise# du -d1 /var 2 /var/.snap 2 /var/account 6 /var/at 16 /var/backups 4 /var/crash 8 /var/cron 32946 /var/db 2 /var/empty 2 /var/heimdal 2 /var/log 4 /var/mail 4 /var/msgs 2 /var/preserve 40 /var/run 2 /var/rwho 185556 /var/spool 5376/var/tmp 20 /var/yp 26 /var/named 28 /var/smtpd 224050 /var -- Yours Sincerely Shinjii http://www.shinji.nq.nu ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
On Mon, 7 Feb 2005 22:48:41 +1000, Warren [EMAIL PROTECTED] wrote: im trying to get cacti working, but since im using a small P2 300 machine with a small hdd my /var has suddenly become full and im wodering what is safe and not safe so to speak to del in the /var dir .. the following are the dir's i have. -- Yours Sincerely Shinjii http://www.shinji.nq.nu I went through /var cleaning this up myself yesterday. I found the httpd-access.log and httpd-error.log was quite large and wouldn't turn over after a certain date or size. I also saw the snmpd.log was getting pretty big. I see that you've checked mail already. My cacti user mailbox was quite large as well. ...just a few more things to check... -- Just my $.02, your mileage may vary, batteries not included, etc ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
On Monday 07 February 2005 13:48, Warren wrote: i was wondering about a command to list the stuff inthe individual dir's and it seems some old packages that have been de-installed ahev remnets and a lot of them in the /var/db port totalling a significant amount of Meg. Thanks for the help. 'Filelight' is a handy application to quickly pinpoint disk hogging directories. It makes a kind of pie chart of the harddisk, with the ability to descend into subdirectories with a click. It's in the sysutils ports. For a quick example of how it looks, see http://methylblue.com/filelight/filelight.png PS. Running 'portsclean' with various options can also free substantial amounts of harddisk space! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full
On Monday 07 February 2005 10:16 pm, Luyt wrote: On Monday 07 February 2005 13:48, Warren wrote: i was wondering about a command to list the stuff inthe individual dir's and it seems some old packages that have been de-installed ahev remnets and a lot of them in the /var/db port totalling a significant amount of Meg. Thanks for the help. 'Filelight' is a handy application to quickly pinpoint disk hogging directories. It makes a kind of pie chart of the harddisk, with the ability to descend into subdirectories with a click. It's in the sysutils ports. For a quick example of how it looks, see http://methylblue.com/filelight/filelight.png Firelight is awesome! Thanks for mentioning it. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full ?
Hi. I don't know if this is going to be of much use, but I encountered the same problem on 5.3-STABLE only 48 hours after upgrading from 4.10. My problem was that KDE was storing more crap than the law should allow on /var/tmp My solution was to create a symbolic link from /var/tmp to /usr/tmp I see that you only have 1.3 meg in /var/tmp so at best this is only going to help a very little. I also create a symbolic link from /var/db/locate.database to /usr/db/locate.database, as this usually eats up about 5 meg for me. I think that the REAL solution is arrived at during initial install by allocating 2 or 3 times the default partition size for /var. But I don't ever think of that until AFTER I've configured the system :) Finally, my biggest problem is that many users leave email in their inbox at /var/mail. I use openwebmail, so I just set quotas to keep that problem in check, since sendmail won't let me use symbolic links for entries in /var/mail. good luck! lane On Saturday 29 January 2005 16:48, GRF . wrote: I am running FBSD 5.2.1 and my /var partition is giving me cannot write to disk errors, disk is full. I cleared out what I could and got it down to about 98% but I have some strange findings which I will show below. [/var] df -h FilesystemSize Used Avail Capacity Mounted on /dev/ad0s1a 248M55M 173M24%/ devfs 1.0K 1.0K 0B 100%/dev /dev/ad0s1e 248M38K 228M 0%/tmp /dev/ad0s1f70G53G11G83%/usr /dev/ad0s1d 248M 223M 4.5M98%/var #cd /var # du -hd1 2.0K./account 6.0K./at 16K./backups 4.0K./crash 390K./cron 5.8M./db 2.0K./empty 2.0K./heimdal 508K./log 1.9M./mail 4.0K./msgs 2.0K./preserve 40K./run 2.0K./rwho 66K./spool 1.3M./tmp 20K./yp 2.0K./games 1.0M./ftp 394K./usermin 2.0K./.snap 11M. Now how can /var be 11Meg and also fill up 98% or 223 Meg at the same time? What is eating up my partition space? Uptime is 149 days and I suppose I'm due for a reboot but I have others with processes going on the box and I hate to reboot. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var Full ?
On Sat, Jan 29, 2005 at 05:48:26PM -0500, GRF . wrote: I am running FBSD 5.2.1 and my /var partition is giving me cannot write to disk errors, disk is full. I cleared out what I could and got it down to about 98% but I have some strange findings which I will show below. [/var] df -h FilesystemSize Used Avail Capacity Mounted on /dev/ad0s1a 248M55M 173M24%/ devfs 1.0K 1.0K 0B 100%/dev /dev/ad0s1e 248M38K 228M 0%/tmp /dev/ad0s1f70G53G11G83%/usr /dev/ad0s1d 248M 223M 4.5M98%/var #cd /var # du -hd1 2.0K./account 6.0K./at 16K./backups 4.0K./crash 390K./cron 5.8M./db 2.0K./empty 2.0K./heimdal 508K./log 1.9M./mail 4.0K./msgs 2.0K./preserve 40K./run 2.0K./rwho 66K./spool 1.3M./tmp 20K./yp 2.0K./games 1.0M./ftp 394K./usermin 2.0K./.snap 11M. Now how can /var be 11Meg and also fill up 98% or 223 Meg at the same time? What is eating up my partition space? Uptime is 149 days and I suppose I'm due for a reboot but I have others with processes going on the box and I hate to reboot. Why are you due for a reboot? I'd at least aim for 200+ days, and then probably more. Files that are deleted in UNIX but still held open by a process will take up all their space still, but not show up in du since they've been deleted from the filesystem. Once the process closes the file or exits the space will be deleted. If you can figure out which process it is, then try killing the process. sysutils/lsof is a great utility for telling you about deleted files and how much space they take up. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
