X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_HELO_PASS,TW_TV,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Message-ID: <29900929.post@talk.nabble.com> Date: Wed, 6 Oct 2010 14:15:28 -0700 (PDT) From: davidstvz To: cygwin AT cygwin DOT com Subject: Re: cygwin + xwin in win7 as unprivileged user? In-Reply-To: <4CACE56D.8000505@dronecode.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <29889419 DOT post AT talk DOT nabble DOT com> <29897721 DOT post AT talk DOT nabble DOT com> <4CACB164 DOT 70706 AT dronecode DOT org DOT uk> <29899035 DOT post AT talk DOT nabble DOT com> <4CACE56D DOT 8000505 AT dronecode DOT org DOT uk> X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com It's a multiuser windows 7 lab environment where the only thing I can count on is that the individual users will do whatever they want to. I'm having to forcibly kill the x-windows process rather than just use a plain signal termination. It's ignoring a vanilla taskkill. I haven't tried kill from inside cygwin. >> On 06/10/2010 16:10, davidstvz wrote: >>> I have done additional testing on this problem and it seems that the >>> first >>> user to login and run 'startxwin' owns all of the log and lock files and >>> this is what is causing the problem. The first user can continue using >>> xwin >>> without issues, but no other users can do it after that. >>> >>> If someone would upgrade xwin to to make these file names unique for >>> each >>> user it should solve the problem. Meanwhile, I'm envisioning several >>> workarounds. >> >> The log file issue is discussed and a workaround given at [1] >> >> The lock file should be removed on xwin exit, so should not be a problem >> unless xwin is crashing for you, in which case report that problem. >> >> Making the lock file name unique per user is a non-solution, as it >> prevents it >> from locking against multiple simultaneous uses of the same display >> number. >> >> [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00090.html > > Ah, I see how that is a non-solution. I should stick to what I know. > > In any case, XWin is not crashing per se, instead when I type "exit" from > the initial xterminal and exit cygwin (or press the windows close button) > it > remains running in the background. So to open it again, I have to first > terminate it from the task manager which I suppose qualifies as a crash. Is there some reason why you can't use the 'Exit' menu item from the right-click menu of the X icon in the system tray area? XWin should also respond by shutting down cleanly if you send it SIGTERM, e.g. 'killall XWin' > I've solved the problem by scheduling a task to delete the log and lock > files when any user logs in (well, to mostly delete; windows refuses to > let > me delete the socket file descriptor so I had to rename it to a random > number). -- View this message in context: http://old.nabble.com/cygwin-%2B-xwin-in-win7-as-unprivileged-user--tp29889419p29900929.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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