X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 14 Aug 2009 09:55:32 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: rxvt slow to get the prompt if another rxvt is already open on 	windows 7 64bit
Message-ID: <20090814075532.GA32408@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <OFF8856A17 DOT 6A45AEC3-ONC1257610 DOT 003F1C23-C1257610 DOT 00410ECA AT bechtle DOT com> <416096c60908120535k26a6aed6t925eba2ce45e6dd7 AT mail DOT gmail DOT com> <20090813143755 DOT GA18635 AT calimero DOT vinschen DOT de> <416096c60908131224p87439c4k4dfd873f2b141eef AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <416096c60908131224p87439c4k4dfd873f2b141eef@mail.gmail.com>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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