Re: [Haifux] Login console freezes: Eli's weekly riddle
On 28/10/10 17:59, Eli Billauer wrote: Hi, PAM did indeed cross my mind as a suspect. Unfortunately, I have no /var/log/auth* logfiles. As a matter of fact, I don't have any log messages related to authentication. In my very old Redhat 7.3, I had pam_unix messages in /var/log/messages telling me who has changed user ID. On Fedora 12, nothing is mentioned about becoming root in /var/log/messages, and I can't see any directory or file in /var/log that seems to contain that information. Maybe under the audit directory, but the files there are not really human readable. Just some random thought - perchance the two are not independent? Maybe you have a PAM configuration problems that causes both the lack of logs AND the slow login? Also, did you try public key authentication via ssh to see whether that one is faster? Any idea of where my authenticate mechanism keeps its logs? Should probably have been where your authentication mechanism keeps the config files that tell it where to generate the logs. Give a man a fish, and he'll eat for a day. Teach him how to cook, and he'll die starving, dreaming of all the wonderful things he could have cooked, had only he had a fish And why a kernel upgrade would have any effect? Like I said. I suspect the configuration was broken even before the upgrade. rantIn the past, I clearly recall just upgrading my kernel and all was fine. Where are those days?/rant I'm sorry, you mistagged the above. We employ a strict four pages minimum on rants. Soap box addresses between one and four pages should carry the bicker tag. Complaints over two lines long should carry the hidepark tag. This two sentences should have carried the whine tag. whineThere used to be a time when you could expect old timers to read the list's FAQ/whine Shachar P.s. You did say Fedora 12, as in RedHat based distribution, as in tons and tons of patches over the vanilla kernel, right? What kernel did you upgrade to? Was it vanilla? Sh. -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Login console freezes: Eli's weekly riddle
Hello, Even though it would be fun (??!!) to dig into the authentication mechanism, isn't the fact that failing to open /dev/tty takes 30 seconds enough to blame the kernel alone? Or the same time to open /dev/pts/0? Could there be any explanation for this except for a kernel bug? And yes, I'm using Fedora 12 with a 2.6.36 vanilla kernel. I'm a wild guy. But so was my 2.6.35, which has no particular problems, except for what happens when the disk is accessed heavily. So the freeze thing lies in what happened in the gap between two vanillas. And as a side remark, I've had two null pointer oopses when logging out the GUI console. The caller seems to be selinux_socket_unix_stream_connect(). Oopses. I think I'm going to post a kernel patch which paints the screen background blue. My current standpoint is that I've seen enough to know who to blame, and that leaves me with the possibility to post a kernel bug report (unless someone tells me I'll make a fool of myself doing so) or just wait until a kernel patch emerges. As I logout or boot very rarely, I can live with this issue for a month or two. Please correct me if I'm wrong. Thanks, Eli Shachar Shemesh wrote: On 28/10/10 17:59, Eli Billauer wrote: Hi, PAM did indeed cross my mind as a suspect. Unfortunately, I have no /var/log/auth* logfiles. As a matter of fact, I don't have any log messages related to authentication. In my very old Redhat 7.3, I had pam_unix messages in /var/log/messages telling me who has changed user ID. On Fedora 12, nothing is mentioned about becoming root in /var/log/messages, and I can't see any directory or file in /var/log that seems to contain that information. Maybe under the audit directory, but the files there are not really human readable. Just some random thought - perchance the two are not independent? Maybe you have a PAM configuration problems that causes both the lack of logs AND the slow login? Also, did you try public key authentication via ssh to see whether that one is faster? Any idea of where my authenticate mechanism keeps its logs? Should probably have been where your authentication mechanism keeps the config files that tell it where to generate the logs. Give a man a fish, and he'll eat for a day. Teach him how to cook, and he'll die starving, dreaming of all the wonderful things he could have cooked, had only he had a fish And why a kernel upgrade would have any effect? Like I said. I suspect the configuration was broken even before the upgrade. rantIn the past, I clearly recall just upgrading my kernel and all was fine. Where are those days?/rant I'm sorry, you mistagged the above. We employ a strict four pages minimum on rants. Soap box addresses between one and four pages should carry the bicker tag. Complaints over two lines long should carry the hidepark tag. This two sentences should have carried the whine tag. whineThere used to be a time when you could expect old timers to read the list's FAQ/whine Shachar P.s. You did say Fedora 12, as in RedHat based distribution, as in tons and tons of patches over the vanilla kernel, right? What kernel did you upgrade to? Was it vanilla? Sh. -- Web: http://www.billauer.co.il ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Login console freezes: Eli's weekly riddle
Maxim Kovgan wrote:
1) I hope I didn't miss a sentence in one of the emails I've searched the google
for 48 hours for similar problem...
I always check Google first. Just to find out that it's adapting itself
to common people. For example, looking for pts, I get hits on the
word points. Looks like we're loosing Google too.
As for the arguments about TTYs blocking, I don't think that is relevant
during the open() call. Opening a TTY/PTY is doing nothing except
allocating memory and registering stuff, as far as I know. No reason it
should take any time. Unless...
Since there's a little kernel hacker hiding in me, I decided to put
printk's all over the pty.c file. I ended up with 37 of them, and here's
the interesting part (in the modified code):
snip
static int ptmx_open(struct inode *inode, struct file *filp)
{
struct tty_struct *tty;
int retval;
int index;
nonseekable_open(inode, filp);
/* find a device that is not in use. */
printk(KERN_ALERT 34: pty_open to lock\n);
tty_lock();
printk(KERN_ALERT 35: pty_open locked\n);
snip
OK, so I wrote pty_code where it should be ptmx_open. But the
numbers are the real identifiers.
And here's a small snippet from my /var/log/messages:
Oct 29 16:14:34 ocho kernel: 02: pty_close to lock 880200f48800
Oct 29 16:14:34 ocho kernel: 03: pty_close did lock 880200f48800
Oct 29 16:14:58 ocho kernel: 34: pty_open to lock
Oct 29 16:15:13 ocho kernel: 35: pty_open locked
Hmmm... 15 seconds to acquire a lock. On other 34-35 pairs this took
no-time, of course. In case you wonder, tty_lock() and tty_unlock() gets
and releases the global mutex for all TTY related stuff. Introduced
somewhere between my old 2.6.35 and 2.6.36. Could it have something to
do with my problem?
Or maybe, it has something to do with pty_close() looking like this (the
printks above omitted)?
static void (struct tty_struct *tty, struct file *filp)
{
[ ... do the stuff, but no hassle with locks... ]
tty_*un*lock();
tty_vhangup(tty-link);
tty_lock();
}
}
Hmmm... Calling tty_unlock() first and then tty_lock(). And then return.
Maybe I missed something here, but this doesn't look good to me. I
didn't get it wrong. All other calls are lock(), then unlock(). Of course.
I've sent a little note to the relevant kernel maintainer about this. In
the meanwhile, I'll stick to my older kernel. Had enough with those oopses.
Thanks to Guy again for that little tip.
Eli
--
Web: http://www.billauer.co.il
___
Haifux mailing list
Haifux@haifux.org
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
