Re: Too many open files
On 26/03/2012 02:19, C. P. Ghost wrote:
On Sun, Mar 25, 2012 at 6:46 PM, Prabhpal S. Mavi
prabh...@digital-infotech.net wrote:
Greetings Friends,
have anyone has come across this warning / error? This occurs when i ssh
to my FreeBSD 9.0 System. any help would be greatly appreciated.
Warning:
/usr/share/games/fortune/freebsd-tips.dat: Too many open files in system
[mavi@titan ~]$ su
su: pam_start: system error
Thanks / Regards
Prabhpal
What does this command say on your system?
% sysctl kern.maxfiles kern.maxfilesperproc kern.openfiles
You may have exceeded the maximum number of open files
in the system. Maybe some ill-conceived program that doesn't
close non-needed connections, files, etc is at fault? It's easy
to open more and more files, and to gradually fill the open
files descriptor table in the kernel this way.
-cpghost.
From knowing that you have too many files open you can increase the
maxfile numbers - but if you want to know what uses them try this -
lsof -n | awk '{print $2 \t $1}' | sort | uniq -c | sort
lsof outputs open file info, awk then gives us the PID and proc name
which gets sorted and uniq gives a count of each which we sort to have
the largest file count at the bottom of the list. What you end up with
is a list of two numbers and a name - count of files open followed by
the PID and proc name that has them open.
The catch is that it also includes network connections (I know how to
list only network but not sure how to exclude them)
ps ax | grep PID
will show you the full program name if it has been shortened.
lsof -p PID
will show all the open files for PID
Not sure if this is the best way but it works for me.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Too many open files
Hello Shane,
thanks for your valuable response, this is brilliant. this is what i was
exactly looking for. very good command indeed.
Grateful for your kind assistance
Thanks / Regards
On 26/03/2012 02:19, C. P. Ghost wrote:
On Sun, Mar 25, 2012 at 6:46 PM, Prabhpal S. Mavi
prabh...@digital-infotech.net wrote:
Greetings Friends,
have anyone has come across this warning / error? This occurs when i
ssh
to my FreeBSD 9.0 System. any help would be greatly appreciated.
Warning:
/usr/share/games/fortune/freebsd-tips.dat: Too many open files in
system
[mavi@titan ~]$ su
su: pam_start: system error
Thanks / Regards
Prabhpal
What does this command say on your system?
% sysctl kern.maxfiles kern.maxfilesperproc kern.openfiles
You may have exceeded the maximum number of open files
in the system. Maybe some ill-conceived program that doesn't
close non-needed connections, files, etc is at fault? It's easy
to open more and more files, and to gradually fill the open
files descriptor table in the kernel this way.
-cpghost.
From knowing that you have too many files open you can increase the
maxfile numbers - but if you want to know what uses them try this -
lsof -n | awk '{print $2 \t $1}' | sort | uniq -c | sort
lsof outputs open file info, awk then gives us the PID and proc name
which gets sorted and uniq gives a count of each which we sort to have
the largest file count at the bottom of the list. What you end up with
is a list of two numbers and a name - count of files open followed by
the PID and proc name that has them open.
The catch is that it also includes network connections (I know how to
list only network but not sure how to exclude them)
ps ax | grep PID
will show you the full program name if it has been shortened.
lsof -p PID
will show all the open files for PID
Not sure if this is the best way but it works for me.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Too many open files
Hi!
From knowing that you have too many files open you can increase the
maxfile numbers - but if you want to know what uses them try this -
lsof -n | awk '{print $2 \t $1}' | sort | uniq -c | sort
On my system, it shows interesting numbers for firefox-instances:
3895 4150 firefox-b
4160 72958 firefox-b
4240 3594 firefox-b
4320 4232 firefox-b
4431 89391 firefox-b
This seems to come from threads, where lsof shows the same
descriptor as open for multiple times, even if it comes from the
same process memory.
For example for pid 4232:
lsof -n | grep icon-theme.cache | grep 4232 | wc -l
firefox-b 4232 pi txt VREG 0,102 10784
924293 /usr/local/share/icons/hicolor/icon-theme.cache
This happens on 8.1-REL-p5 amd64. So the method is not fail-safe
for the real number of open files.
--
p...@opsec.eu+49 171 3101372 8 years to go !
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Too many open files
On 26/03/2012 09:56, Kurt Jaeger wrote:
From knowing that you have too many files open you can increase the
maxfile numbers - but if you want to know what uses them try this -
lsof -n | awk '{print $2 \t $1}' | sort | uniq -c | sort
On my system, it shows interesting numbers for firefox-instances:
3895 4150 firefox-b
4160 72958 firefox-b
4240 3594 firefox-b
4320 4232 firefox-b
4431 89391 firefox-b
This seems to come from threads, where lsof shows the same
descriptor as open for multiple times, even if it comes from the
same process memory.
For example for pid 4232:
lsof -n | grep icon-theme.cache | grep 4232 | wc -l
firefox-b 4232 pi txt VREG 0,102
10784 924293 /usr/local/share/icons/hicolor/icon-theme.cache
This happens on 8.1-REL-p5 amd64. So the method is not fail-safe
for the real number of open files.
Does 'procstat -fa' give better results for you?
It seems to be one of those little hidden secrets that FreeBSD comes
with a bunch of native applications that provide pretty much equivalent
functionality to lsof(1). See: fstat(1), procstat(1), sockstat(1).
Which is odd, given that since these sort of applications have to read
and interpret kernel memory -- an action for which there isn't a nice
well defined ABI -- the application has to be kept rigorously in synch
with the kernel it is used against. Something that is intrinsically
easier to do when kernel and application are compiled at the same time
and from the same source tree.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: Too many open files
Hi!
lsof -n | awk '{print $2 \t $1}' | sort | uniq -c | sort
On my system, it shows interesting numbers for firefox-instances:
[...]
Does 'procstat -fa' give better results for you?
Yes, much better.
--
p...@opsec.eu+49 171 3101372 8 years to go !
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9-STABLE + Infiniband - incorrect interface counters
On Saturday, March 24, 2012 7:52:08 am Alex Tutubalin wrote: Hi, I'm playing with two FreeBSD 9-STABLE boxes connected via 10Gbps Infiniband (more details below) in Infiniband connected mode. I see incorrect interface statistics (e.g. in netstat output), output counters are 2x more than expected. EXAMPLE, ftp transfer of 1 GiB file: ftp put file /dev/null local: file remote: /dev/null 229 Entering Extended Passive Mode (|||57978|) 150 Opening BINARY mode data connection for '/dev/null'. 100% |***| 953 MiB 390.43 MiB/s 00:00 ETA 226 Transfer complete. 10 bytes sent in 00:02 (390.13 MiB/s) Netstat on receiving side, counters are correct (for input): lexa@home-gw:/home/lexa# netstat -I ib1 5 input (ib1) output packets errs idrops bytespackets errs bytes colls 0 0 0 0 0 0 0 0 13955 0 0 222688126 9027 01192796 0 48921 0 0 780832960 32129 04240596 0 0 0 0 0 0 0 80 0 Sum of bytes (input) is 1003521086, as expected. Netstat on sending size, output is 2x more: lexa@new-gw:/home/lexa# netstat -I ib0 5 input (ib0) output packets errs idrops bytespackets errs bytes colls 1 0 0100 0 0 0 0 41162 0 02305210 62878 0 2008325984 0 1 0 0100 0 0 0 0 It looks like packet count is correct (13955+48921=62876, two packets missed somewhere), while byte count is exact 2x more. Yes, this is a bug. if_obytes already gets incremented in IFQ_HANDOFF(), so the IB code doesn't need to do it again. Try the patch at www.freebsd.org/~jhb/patches/ipoib_obytes.patch I can't speak to the MTU issue though. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ACPI Issues in 8-STABLE and on
All I was wondering if anyone has looking into this ACPI issue noted back in 2010. http://lists.freebsd.org/pipermail/freebsd-acpi/2010-February/006332.html I attempted to upgrade a 7-STABLE DL385g1 with 4G of ram to 9-STABLE and it was a disaster. The box was able to boot once and then on a normal reboot the root filesystem was corrupted beyond repair ( most likely unrelated , but some unknown issue with su+j *) and the system would not get past the point noted in the a fore mentioned thread . I tried to boot this box with 8.2-RELASE amd64 same issue, 9.0-BETA1 , same issue, 9.0-RELEASE same issue , and 9.0-STABLE as I pointed out worked intermittently. So the end result is that this box now only reliably runs 7.0-RELEASE - 7.4-RELEASE and 7-STABLE , 6.2-RELEASE - 6.4-RELEASE and 6-STABLE but nothing else. As a side test , NetBSD 6.0 beta amd64 boots with out issues on this box as well as DragonFlyBSD 3.01 amd64. So my solutions are to migrate back to 7-STABLE or use Net or Dfly. Does anyone know what the root issue is here ? * The su-j issue was most likely caused by me not properly converting the old su slice to su+j . I think I may have done a tunefs -j enable before I did a tunefs -n disable fsck . -- mark saad | nones...@longcount.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ACPI Issues in 8-STABLE and on
Hi, Have you filed PRs for this? It seems like something you could easily(!) find the offending commit(s) by doing kernel builds of -HEAD around the time that 8 was branched off. If 8.0-RELEASE fails but 7-STABLE does, that's a good starting point to determine the lower/upper bounds for the -HEAD commit(s) that broke things for you. It would be really appreciated if you were able to help track this down as I doubt the ACPI developers have the hardware. Thanks! Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
upgrade to 8.3 from 7.2 static root mountpoint disappeared
I just did an upgrade from an old 7.2 installation to 8.3-RC2 last night, and the kernel was only able to mount root from a ufsid label and could not detect any bsdlabels. The 7.2 installation used static bsdlabeled disks (/dev/ad0s1a etc). This seemed to be an unexpected change (I had to get the remote datacenter to connect an ipkvm to fix the problem), particularly because the 7.2 kernel never loaded geom_label but somehow the partitions ended up with labels quite mysteriously; the box was originally installed from 6.x-R from 2006. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
