This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rxvt slow to get the prompt if another rxvt is already open on windows 7 64bit


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]