Delete a directory, crash the system

[Da Rock]

On 03/25/15 00:16, Benjamin Kaduk wrote:
> On Mon, 23 Mar 2015, Da Rock wrote:
>
>> Unfortunately, fsck isn't helping - foreground or otherwise. All it shows on
>> every single fs is inode 4 recovery which doesn't sound quite right. And
> Have you posted the exact output in a previous message (could you send a
> link)?
Not precisely, but the message is just a flash and there is no copying 
of it. Anyway, inode 4 is the .sujournal file as expected; this means 
there is an issue with the softupdates. Could this be narrowing it down 
(the OP to this was also in this age of enlightenment, SU came in with 
8.x didn't it?)?
>
>> again, it is only showing during updates to ports being built. I'm
> Er, what is only showing up?  The panics?
> Surely you are not only running fsck while building ports...
Yes, the panics.

Sorry, I thought that was obvious seeing as the alternative is impossible :)
>
>> investigating further, but it may be just a corrupt file in pkg system.
>>
>> Incidentally, I'm not suggesting an absolute fix for the issue as such, but a
>> better means of handling it rather than crashing the system. The posts on this
> Understood.  But, there will always be some types of error which are truly
> unrecoverable, and there is no real option other than to panic.  (Which is
> not to say that your situation is necessarily one of them.)
That I get, and given this may be an issue with SU it may well be 
warranted. What can we do to narrow this down, as obviously one cannot 
be sitting watching exactly what happens for the hours required while 
building ports. Your bound to look away for just a second and miss it 
even if you did try! :D
>
>> If I discover anything more I'll keep everyone posted :)
So I did some fiddling with fsck, fsdb, find and stat; and got nowhere. 
I ran fsck again and it gave me not much again. It did hint at some 
files in the ports tree, so I cleaned up the ports tree to fresh install 
point, ran fsck again and rebooted. So far so good, but I'm keeping my 
fingers crossed still.

This doesn't help the panics - they're still a pita when they happen. It 
does help me resolve the issue this time though. But initiating this 
error in testing is damn near impossible. What can we document here as a 
way to gather data to determine how to resolve this issue? Given my luck 
with this, its bound to happen again at some point :)