On Fri, 2006-Jan-27 06:56:47 +1100, Peter Jeremy wrote:
On my recent -current, I've noticed that /var is filling up with
unreferenced files.
Updated data point: The files do disappear on a clean shutdown
so the kernel seems to be aware that they have no name but
neither fstat nor lsof can find any processes holding them open.
I have a core dump demonstrating the problem and will poke around
in it as a background task.
You know it occured to me that a process that is not in the process list
would still work..
could be an easy way to effect a rootkit if one had root access.
wouldn't show up in ps, fstat etc.
Re: vn_fullpath question. ... i.e. fstat thread.... vn_fullpathis a kernel API, not a user API, so can only be invoked from ... DragonFly BSD project (derived from FreeBSD 4) have added ... "That's what I love about GUIs: They make simple tasks easier,... (freebsd-hackers)
Re: fstat broken ? ... In message, Joseph Koshy writes: ...fstat was digging around in the kernel after stuff it shouldn't ever ... (freebsd-current)
Re: fstat triggered INVARIANTS panic in memrw() ... I wonder if fstat is racing with a tty ... > Devices may not be to blame; I was able to trigger this by running ... > An interesting datapoint is that none of the non-i386 package machines... The i386 kernel is just not handling it ... (freebsd-current)
Re: fstat broken ? ... +> In message, Joseph Koshy writes: ... +> fstat was digging around in the kernel after stuff it shouldn't ever ... (freebsd-current)
fstat triggered INVARIANTS panic ... I ran fstat | more on a SMP 6.0 machine with kernel from about a month ... Note the deadc0de in generic_copyout. ... brokenness of panicand related code on SMP machines.... (freebsd-current)
