On Aug 13 20:24, Andy Koppe wrote:
> 2009/8/13 Corinna Vinschen:
> > I just tried that on W7 and W7 64. I can't reproduce any specific
> > slowness starting with he second invocation of rxvt, incuding writing
> > the utmp entry. The startup time is always the same, roughly a second,
> > regardless of the number of already open rxvt windows.
>
> I tried it again briefly last night. It only happened when logged in
> as an administrator, not as a limited user. That's with UAC enabled.
> Didn't try disabling. Reproduced both with 'rxvt' and 'mintty -u', and
> timed the delay to about 15 seconds.
That's really a long time.
> Trying to investigate further now, I can no longer reproduce it.
> That's without having changed anything, knowingly anyway. Gah.
>
> This is on:
> CYGWIN_NT-6.1-WOW64 Tobermory 1.7.0(0.212/5/3) 2009-08-11 11:07 i686 Cygwin
Scotch enthusiast?
> And here's the mintty code that (sometimes) triggers the problem:
>
> ut.ut_type = USER_PROCESS;
> ut.ut_pid = pid;
> ut.ut_time = time(0);
> char *dev = ptsname(fd);
> if (dev) {
> if (strncmp(dev, "/dev/", 5) == 0)
> dev += 5;
> strncpy(ut.ut_line, dev ?: "?", sizeof ut.ut_line);
> if (strncmp(dev, "pty", 3) == 0 || strncmp(dev, "tty", 3) == 0)
> dev += 3;
> strncpy(ut.ut_id, dev ?: "?", sizeof ut.ut_id);
> }
> strncpy(ut.ut_user, (pw ? pw->pw_name : 0) ?: "?", sizeof ut.ut_user);
> login(&ut);
>
> Must be the login() that does it. My uneducated guess is that it's
> some sort of file access timeout regarding /var/run/utmp.
I don't see anything in login which could explain this, unless it's
a wait for a lock. There's a function locked_append which utilizes
a POSIX file lock to coordinate appending to the utmp file. I tried
a couple of tests like starting a lot of rxvt's in a tight bash loop,
but I don't see any such hang.
What you could do is this. Build a Cygwin DLL without optimization so
that it's easily debuggable and install the cygwin1.dbg file alongside
of the DLL. Since the delay is so long, 15 secs, you could have enough
time to attach to the process via gdb and examine the thread call
stacks. Maybe that gives us a clue.
I'm wondering anyway if it's really necessary to use fcntl locks for
this function. Using a simple mutex looks more than sufficient.
> A couple of other things I noticed. When starting 'rxvt' or 'mintty
> -u' as a limited user, no utmp entry is created, which seems to be due
> to /var/run/utmp being owned by an administrator ("Fish"):
>
> $ ls -l /var/run/utmp
> -rw-r--r-- 1 Fish root 3080 Aug 13 19:56 /var/run/utmp
>
> After deleting that file and touching it from the limited user account
> ("Andy"), both were able to create utmp entries:
Yep. /var/run/utmp is created by setup.exe with default 0644 permissions.
Of course, one of the postinstall scripts could set the permissions to
0666, but I'm not sure admins will like the idea. In theory, the utmp
file was supposed to be used by sshd, telnet, rlogin and the likes, not
by local processes...
> $ w
> 20:17:08 up 43 min, 3 users, load average: 0.00, 0.00, 0.00
> USER TTY LOGIN@ IDLE JCPU PCPU WHAT
> Fish tty5 20:11 986days 0.00s 0.09s -bash
> Fish tty6 20:11 986days 0.00s 0.21s -bash
> Andy tty4 20:11 986days 0.00s 0.07s -bash
>
> And of course I haven't been logged in for three years, so I guess the
> IDLE field isn't implemented?
Actually I don't now where `w' gets the idle information from. The utmp
file has standard utmp layout, per /usr/include/sys/utmp.h.
I just see that I still didn't care for IPv6 addresses in utmpx. Looks
like the utmp file finally has to change its layout. Baeh. Yet another
point for the ever-growing TODO list.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
