David Woodhouse <[email protected]> wrote:
>
> On Thu, 2006-01-12 at 19:59 -0800, Andrew Morton wrote:
> > applied, or with all of David's patches applied, an FC5-test1 machine hangs
> > during the login process (local vt or sshd). An FC1 machine doesn't
> > exhibit the problem.
>
> So the 'successful' login reported at 19:21:45 never actually completed
> and gave you a shell?
Yup.
> I can't make out which process it is that's misbehaving... and your
> login was pid 2292 but I don't see your SysRq-T output going up that
> far. Am I missing something?
Yes, that dmesg output seems to have been truncated.
Here's another one, better:
http://www.zip.com.au/~akpm/linux/patches/stuff/dmesg
Note that I have /bin/zsh in /etc/passwd.
> I note you're running auditd -- FC5-test1 enabled syscall auditing by
> default.
This is basically the fc5-t1 .config, only it has selinux turned off due to
earlier problems. Suggest you base testing on my config-sony.
> Does the problem persist if you prevent the auditd initscript
> from starting up?
<chkconfig auditd off>
<reboot>
<problem persists>
> If so, let's turn auditing back on
<chkconfig auditd on>
> and actually make
> use of it -- assuming the offending process is actually one of your own
> after the login has changed uid, can you set an audit rule to log all
> syscalls from your own userid? (add '-Aexit,always -Fuid=500'
> to /etc/audit.rules, assuming 500 is your own uid). Then show me the
> appropriate section from /var/log/audit/audit.log.
<does that>
<reboots>
<logs in>
You wouldn't believe how much stuff that produces. Or maybe you would.
<several minutes pass, disk LED flashing>
<crap starts scrolling past too fast to read. Some complaint from auditd, afaict>
<does alt-SUB>
<grabs the last bit of auditd.log>
http://www.zip.com.au/~akpm/linux/patches/stuff/auditd.log
That looks like the crap I saw scrolling past. How come it came out on the
console after a few minutes?
> I tested both with and without audit on PPC -- David, did you test this
> patch with auditing enabled on i386?
>
> Will attempt to reproduce locally... I've _also_ seen login hangs on
> current linus trees but they've been different (and on that machine I
> haven't had the TIF_RESTORE_SIGMASK patches either). It happens on disk
> activity though -- after 'rpm -i <kernelpackage>' the whole machine
> locks up and I have no more file system access. If your SysRq-T got to
> the disk, I suspect you aren't seeing the same problem.
Sounds like the jens-barrier-bug. Fixed in current -linus.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
