RE: X application fails
Thank You all for your help. I Copied the fonts for HPUX to the fonts directory for Cygwin/X. It works very well now. Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Paulus Sent: Monday, April 11, 2005 2:57 PM To: cygwin-xfree@cygwin.com Subject: RE: X application fails Another option, if it's only 1 app you have problems with is to run an X VNC Server session on your hpux box and then run the VNC Client on your windows box to see the app. I was having some problems with Sun's Workshop Debugger under Cygwin/X, and that was my solution. On Mon, 11 Apr 2005 14:47:01 -0500, Terry Dabbs wrote: >No, Exactly the same error. Unfortunately, the only information I got >from Agilent was that they couldn't get it to work either, in the past. >They said it DOES work on linux with their application (isn't it >virtually the same?). In any case thanks for replying. If you have an >idea for a direction I could go with this, that would be helpful, >otherwise I'll have to try other Xservers. >Terry > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Terry Dabbs >Sent: Friday, April 08, 2005 12:29 PM >To: cygwin-xfree@cygwin.com >Subject: RE: X application fails > >Thanks, I won't be able to try it until Monday. On vacation today, so >no direct access. I will let you know... >Terry >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gottwald >Sent: Friday, April 08, 2005 3:41 AM >To: cygwin-xfree@cygwin.com >Subject: Re: X application fails >On Thu, 7 Apr 2005, Terry Dabbs wrote: >> I'm new to cygwin/X. I installed the cygwin/X package, and an using >> it >> with the expectation it will provide a display for hpux clients. >> >> What does work: >> - I use either startxwin.bat -or- startxwin.sh, type xhost + in the >> shell, then go to the hpux machine and set the display, send "xrdb" >> commands, and "xterm" runs on my pc from the hpux client. Logging in >> with XDMCP works, it looks very good. >> >> What does not work: >> I have an X application, Agilent's HPSmarttest, which runs OK with >> reflections XDMCP, but with both methods above it gives the error >> message (in a window on the display server!) that it "can not create >> background window". Since it works using "Reflections", I assume >> there >> is some setting, or something that is not set by default. >Maybe it's a problem with the missing 8bit colorplane on Cygwin/X >server. >You might try to run Cygwin/X in 8bit mode (XWin -depth 8 -fullscreen) >bye > ago >-- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723
RE: X application fails
Another option, if it's only 1 app you have problems with is to run an X VNC Server session on your hpux box and then run the VNC Client on your windows box to see the app. I was having some problems with Sun's Workshop Debugger under Cygwin/X, and that was my solution. On Mon, 11 Apr 2005 14:47:01 -0500, Terry Dabbs wrote: >No, Exactly the same error. Unfortunately, the only information I got >from Agilent was that they couldn't get it to work either, in the past. >They said it DOES work on linux with their application (isn't it >virtually the same?). In any case thanks for replying. If you have an >idea for a direction I could go with this, that would be helpful, >otherwise I'll have to try other Xservers. >Terry > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Terry Dabbs >Sent: Friday, April 08, 2005 12:29 PM >To: cygwin-xfree@cygwin.com >Subject: RE: X application fails > >Thanks, I won't be able to try it until Monday. On vacation today, so no >direct access. I will let you know... >Terry >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gottwald >Sent: Friday, April 08, 2005 3:41 AM >To: cygwin-xfree@cygwin.com >Subject: Re: X application fails >On Thu, 7 Apr 2005, Terry Dabbs wrote: >> I'm new to cygwin/X. I installed the cygwin/X package, and an using it >> with the expectation it will provide a display for hpux clients. >> >> What does work: >> - I use either startxwin.bat -or- startxwin.sh, type xhost + in the >> shell, then go to the hpux machine and set the display, send "xrdb" >> commands, and "xterm" runs on my pc from the hpux client. Logging in >> with XDMCP works, it looks very good. >> >> What does not work: >> I have an X application, Agilent's HPSmarttest, which runs OK with >> reflections XDMCP, but with both methods above it gives the error >> message (in a window on the display server!) that it "can not create >> background window". Since it works using "Reflections", I assume there >> is some setting, or something that is not set by default. >Maybe it's a problem with the missing 8bit colorplane on Cygwin/X >server. >You might try to run Cygwin/X in 8bit mode (XWin -depth 8 -fullscreen) >bye > ago >-- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723
RE: X application fails
No, Exactly the same error. Unfortunately, the only information I got from Agilent was that they couldn't get it to work either, in the past. They said it DOES work on linux with their application (isn't it virtually the same?). In any case thanks for replying. If you have an idea for a direction I could go with this, that would be helpful, otherwise I'll have to try other Xservers. Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terry Dabbs Sent: Friday, April 08, 2005 12:29 PM To: cygwin-xfree@cygwin.com Subject: RE: X application fails Thanks, I won't be able to try it until Monday. On vacation today, so no direct access. I will let you know... Terry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Gottwald Sent: Friday, April 08, 2005 3:41 AM To: cygwin-xfree@cygwin.com Subject: Re: X application fails On Thu, 7 Apr 2005, Terry Dabbs wrote: > I'm new to cygwin/X. I installed the cygwin/X package, and an using it > with the expectation it will provide a display for hpux clients. > > What does work: > - I use either startxwin.bat -or- startxwin.sh, type xhost + in the > shell, then go to the hpux machine and set the display, send "xrdb" > commands, and "xterm" runs on my pc from the hpux client. Logging in > with XDMCP works, it looks very good. > > What does not work: > I have an X application, Agilent's HPSmarttest, which runs OK with > reflections XDMCP, but with both methods above it gives the error > message (in a window on the display server!) that it "can not create > background window". Since it works using "Reflections", I assume there > is some setting, or something that is not set by default. Maybe it's a problem with the missing 8bit colorplane on Cygwin/X server. You might try to run Cygwin/X in 8bit mode (XWin -depth 8 -fullscreen) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
On Mon, 11 Apr 2005, Chuck Theobald wrote: > Interestingly, the suggestion that root needs to own /tmp/.X11-unix is > impossible, as root is an "invalid user". This is a message left over from the unix versions of Xorg. I'm just too lazy to go through the whole get a patch into the stable branch of Xorg to address this message. If anybody cares, file a patch at bugs.freedesktop.org and fight the security considerations of the xorg board. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
This one bit me as well when trying to set up WinXPSP2 machines for a lab environment. The solution I settled on was to use Windows Security settings to grant "Everyone" "Full Control" over c:\cygwin\tmp. This works. I too wasted time chasing down the suggestions and searching in vain in the archives. The mkgroup/mkpasswd thing does not work if you are not an Administrator, and even so, mkpasswd fails with a "mkpasswd (257): [1745] The procedure number is out of range." Interestingly, the suggestion that root needs to own /tmp/.X11-unix is impossible, as root is an "invalid user". Chuck At 05:57 AM 4/11/2005, Alan J. Flavell wrote: We have encountered a problem when different non-admin users try to use Cygwin/X on the same Windows system (at different times, I mean). This is with a standard Cygwin/X installation, as far as I can tell, so I'm rather surprised by how little discussion I found of this in the archives. After one normal user has run Cygwin/X, the next user gets told that s/he can't write to /tmp/.X11-unix/X0 The reason seems to be that the directory /tmp/.X11-unix has the "t" bit set (drwxrwxrwt), which means that normal users aren't allowed to mess with files that they don't own. Thus, the first user creates X0 with their ownership, the "file" then hangs around till the second user tries to run Cygwin/X, and they get told they can't overwrite it. The problem can be trivially resolved by removing the "t" bit from the directory - but presumably that represents a security exposure? If you want a specific release: we were chiefly using 6.8.1.0-9, but the problem is not confined to that release. This item in the archives seems to be only tangentially relevant: http://sourceware.org/ml/cygwin-xfree/2005-03/msg00058.html whose Subject is "using cygwin/x as non-administrator doesn't work" (which is not exactly the problem that we are getting, since the *first* non-administrator has no problems starting Cygwin/X as many times as they want to - the problem is with the second - and subsequent - users). The response in the archive is a bit vague: | You can allow other users to write to /tmp/.X11-unix, or have a /tmp | directory for every user where the user can create files at will. The first part of that would "solve" a problem that we haven't got: the issue is *not* that ordinary users can't write to the *directory*, -but- that, by virtue of the "t" bit, they can't interfere with files left there by someone else. Hence this standoff with X0. The second part of the suggestion presumably involves symlinking /tmp to something which has the user name in it, so that /tmp is a different actual path for each user? Is there some concrete, tried-and-tested, advice for resolving this situation, by whatever means, please? (And if it's entirely reliable, how about folding it into the released product?). Then there's this comment in the covering mail: | I suspect that this is due to having turned off the "Server" service | in XP. What was that about, please, and could it represent an alternative resolution of the problem which we are experiencing? thanks for any constructive advice. As a secondary point, could I mention some misleading trails? As someone had said in earlier discussion in the mail archives, it seems that this line in the log: _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root is a red-herring and should be ignored. And furthermore, that the subsequent lines _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running represents an incorrect deduction based on the preceding error - the server is *not* already running. The system also offered us this advice, in the course of investigations: Your group is currently "mkpasswd". This indicates that the /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] > /etc/passwd mkgroup -l [-d] > /etc/group Note that the -d switch is necessary for domain users. which, after consulting documentation and archives, we concluded was not a solution to our problem (albeit possibly a useful thing to do for unrelated reasons). Initially, time was wasted trying to follow-up these misleading diagnostics in the mistaken belief that they would resolve the original problem - would it be feasible to at least re-word them so that they don't lay false trails? But that's a side-issue. -- Chuck Theobald System Administrator The Robert and Beverly Lewis Center for Neuroimaging University of Oregon P: 541-346-0343 F: 541-346-0345
Re: How do I get titlebars on client application windows in non-multiwindow mode?
On Mon, 11 Apr 2005, Gary Taylor wrote: > I've recently installed cygwin-xfree 6.8.2.0-1 and > cannot figure out how to get titlebars on my windows. > > > How is this done? Start a window manager. Twm is installed with xorg-x11-bin but you may also install windowmaker or fvwm2. > REM Windows NT/2000/XP/2003 > echo startxwin.bat - Starting on Windows > NT/2000/XP/2003 > > :STARTUP > run XWin -clipboard -silent-dup-error run twm > run xterm -geometry 80x25+4-4 -title test -sl 1000 -sb > -rightbar -ms blue -fg black -bg white -e > /usr/bin/bash -l -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
How do I get titlebars on client application windows in non-multiwindow mode?
I've recently installed cygwin-xfree 6.8.2.0-1 and cannot figure out how to get titlebars on my windows. How is this done? Thank-you, Gary --- ~ cat startwin.bat @echo off SET DISPLAY=127.0.0.1:0.0 SET CYGWIN_ROOT=\cygwin SET PATH=.;%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%PATH% SET XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults SET XCMSDB=/usr/X11R6/lib/X11/Xcms.txt SET XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB SET XNLSPATH=/usr/X11R6/lib/X11/locale if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP/2003 echo startxwin.bat - Starting on Windows NT/2000/XP/2003 :STARTUP run XWin -clipboard -silent-dup-error REM Startup an xterm, using bash as the shell. run xterm -geometry 80x25+4+4 -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l run xterm -geometry 80x25-4-4 -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l run xterm -geometry 80x25-4 -title -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l run xterm -geometry 80x25+4-4 -title test -sl 1000 -sb -rightbar -ms blue -fg black -bg white -e /usr/bin/bash -l --- Cygwin Configuration Diagnostics Current System Time: Mon Apr 11 08:28:44 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem\ c:\j2sdk1.4.2_02\bin c:\Program Files\Common Files\GTK\2.0\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 12967(garyta) GID: 10545(mkgroup-l-d) 10545(mkgroup-l-d) Output from C:\cygwin\bin\id.exe (ntsec) UID: 12967(garyta) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 1006(Debugger Users)10545(mkgroup-l-d) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\garyta' MAKE_MODE = `unix' PWD = `/home/garyta' USER = `garyta' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\garyta\Application Data' CLIENTNAME = `Console' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `Q:' HOMEPATH = `\' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\DC-BHM1' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PRINTER = `ActiveTouch Document Loader' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 3, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0803' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\garyta\LOCALS~1\Temp' TERM = `xterm' TMP = `c:\DOCUME~1\garyta\LOCALS~1\Temp' USERNAME = `garyta' USERPROFILE = `C:\Documents and Settings\garyta' WINDIR = `C:\WINDOWS' WINDOWID = `168114600' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/mnt/NX/fonts (default) = `C:\Program Files\NX Client for Windows\usr\X11R6\lib\X11\fonts' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/tmp (default) = `C:\Documents and Settings\garyta\.nx\tmp' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/mnt/NX/fonts (default) = `C:\Program Files\NX Client for Windows\usr\X11R6\lib\X11\fonts' HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\cygwin\usr\X11R6\lib\X
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
I guess in /usr/X11R6/bin/startxwin.bat, they circumvent the problem by removing the .X11-unix directory at start: :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix P. Alan J. Flavell wrote: >We have encountered a problem when different non-admin users try to >use Cygwin/X on the same Windows system (at different times, I mean). >This is with a standard Cygwin/X installation, as far as I can tell, >so I'm rather surprised by how little discussion I found of this in >the archives. > >After one normal user has run Cygwin/X, the next user gets told that >s/he can't write to /tmp/.X11-unix/X0 > >The reason seems to be that the directory /tmp/.X11-unix has >the "t" bit set (drwxrwxrwt), which means that normal users >aren't allowed to mess with files that they don't own. > >Thus, the first user creates X0 with their ownership, the "file" then >hangs around till the second user tries to run Cygwin/X, and they get >told they can't overwrite it. > >The problem can be trivially resolved by removing the "t" bit from the >directory - but presumably that represents a security exposure? > >If you want a specific release: we were chiefly using 6.8.1.0-9, but >the problem is not confined to that release. > > >This item in the archives seems to be only tangentially relevant: > >http://sourceware.org/ml/cygwin-xfree/2005-03/msg00058.html > >whose Subject is "using cygwin/x as non-administrator doesn't work" >(which is not exactly the problem that we are getting, since the >*first* non-administrator has no problems starting Cygwin/X as many >times as they want to - the problem is with the second - and >subsequent - users). > >The response in the archive is a bit vague: > >| You can allow other users to write to /tmp/.X11-unix, or have a /tmp >| directory for every user where the user can create files at will. > >The first part of that would "solve" a problem that we haven't got: >the issue is *not* that ordinary users can't write to the *directory*, >-but- that, by virtue of the "t" bit, they can't interfere with files >left there by someone else. Hence this standoff with X0. > >The second part of the suggestion presumably involves symlinking /tmp >to something which has the user name in it, so that /tmp is a >different actual path for each user? > >Is there some concrete, tried-and-tested, advice for resolving this >situation, by whatever means, please? (And if it's entirely reliable, >how about folding it into the released product?). > >Then there's this comment in the covering mail: > >| I suspect that this is due to having turned off the "Server" service >| in XP. > >What was that about, please, and could it represent an alternative >resolution of the problem which we are experiencing? > >thanks for any constructive advice. > > >As a secondary point, could I mention some misleading trails? > >As someone had said in earlier discussion in the mail archives, it >seems that this line in the log: > > _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root > >is a red-herring and should be ignored. And furthermore, that >the subsequent lines > > _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed > _XSERVTransMakeAllCOTSServerListeners: server already running > >represents an incorrect deduction based on the preceding error - the >server is *not* already running. > >The system also offered us this advice, in the course of >investigations: > > Your group is currently "mkpasswd". This indicates that > the /etc/passwd (and possibly /etc/group) files should be rebuilt. > See the man pages for mkpasswd and mkgroup then, for example, run > mkpasswd -l [-d] > /etc/passwd > mkgroup -l [-d] > /etc/group > Note that the -d switch is necessary for domain users. > >which, after consulting documentation and archives, we concluded >was not a solution to our problem (albeit possibly a useful thing to >do for unrelated reasons). > >Initially, time was wasted trying to follow-up these misleading >diagnostics in the mistaken belief that they would resolve the >original problem - would it be feasible to at least re-word them so >that they don't lay false trails? But that's a side-issue. > > >
Re: Non-admin users, /tmp/.X11-unix/X0 permissions
On Mon, 11 Apr 2005, Alan J. Flavell wrote: > whose Subject is "using cygwin/x as non-administrator doesn't work" > (which is not exactly the problem that we are getting, since the > *first* non-administrator has no problems starting Cygwin/X as many > times as they want to - the problem is with the second - and > subsequent - users). > > The response in the archive is a bit vague: > > | You can allow other users to write to /tmp/.X11-unix, or have a /tmp > | directory for every user where the user can create files at will. > > The first part of that would "solve" a problem that we haven't got: > the issue is *not* that ordinary users can't write to the *directory*, > -but- that, by virtue of the "t" bit, they can't interfere with files > left there by someone else. Hence this standoff with X0. > > The second part of the suggestion presumably involves symlinking /tmp > to something which has the user name in it, so that /tmp is a > different actual path for each user? You could assign each user a different /tmp path via mount mount -buf 'd:\temp\$USER' /tmp This way the files don't interfere > _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root > > is a red-herring and should be ignored. And furthermore, that > the subsequent lines > > _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed > _XSERVTransMakeAllCOTSServerListeners: server already running > > represents an incorrect deduction based on the preceding error - the > server is *not* already running. On unix the xserver is installed as setuid root and can handle those permission problems by overruling the permissions with its root permissions. On cygwin this is not possible. Does it help if the t flag is cleared? Then we could create the directory without the flag instead. I don't care for filesystem security on windows anyway. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Non-admin users, /tmp/.X11-unix/X0 permissions
We have encountered a problem when different non-admin users try to use Cygwin/X on the same Windows system (at different times, I mean). This is with a standard Cygwin/X installation, as far as I can tell, so I'm rather surprised by how little discussion I found of this in the archives. After one normal user has run Cygwin/X, the next user gets told that s/he can't write to /tmp/.X11-unix/X0 The reason seems to be that the directory /tmp/.X11-unix has the "t" bit set (drwxrwxrwt), which means that normal users aren't allowed to mess with files that they don't own. Thus, the first user creates X0 with their ownership, the "file" then hangs around till the second user tries to run Cygwin/X, and they get told they can't overwrite it. The problem can be trivially resolved by removing the "t" bit from the directory - but presumably that represents a security exposure? If you want a specific release: we were chiefly using 6.8.1.0-9, but the problem is not confined to that release. This item in the archives seems to be only tangentially relevant: http://sourceware.org/ml/cygwin-xfree/2005-03/msg00058.html whose Subject is "using cygwin/x as non-administrator doesn't work" (which is not exactly the problem that we are getting, since the *first* non-administrator has no problems starting Cygwin/X as many times as they want to - the problem is with the second - and subsequent - users). The response in the archive is a bit vague: | You can allow other users to write to /tmp/.X11-unix, or have a /tmp | directory for every user where the user can create files at will. The first part of that would "solve" a problem that we haven't got: the issue is *not* that ordinary users can't write to the *directory*, -but- that, by virtue of the "t" bit, they can't interfere with files left there by someone else. Hence this standoff with X0. The second part of the suggestion presumably involves symlinking /tmp to something which has the user name in it, so that /tmp is a different actual path for each user? Is there some concrete, tried-and-tested, advice for resolving this situation, by whatever means, please? (And if it's entirely reliable, how about folding it into the released product?). Then there's this comment in the covering mail: | I suspect that this is due to having turned off the "Server" service | in XP. What was that about, please, and could it represent an alternative resolution of the problem which we are experiencing? thanks for any constructive advice. As a secondary point, could I mention some misleading trails? As someone had said in earlier discussion in the mail archives, it seems that this line in the log: _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root is a red-herring and should be ignored. And furthermore, that the subsequent lines _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running represents an incorrect deduction based on the preceding error - the server is *not* already running. The system also offered us this advice, in the course of investigations: Your group is currently "mkpasswd". This indicates that the /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] > /etc/passwd mkgroup -l [-d] > /etc/group Note that the -d switch is necessary for domain users. which, after consulting documentation and archives, we concluded was not a solution to our problem (albeit possibly a useful thing to do for unrelated reasons). Initially, time was wasted trying to follow-up these misleading diagnostics in the mistaken belief that they would resolve the original problem - would it be feasible to at least re-word them so that they don't lay false trails? But that's a side-issue. --
Re: cmdtool from Solaris standard package generates some errors presented on the console and nothing more
Well, then I will try my luck with people from Solaris newsgroup. Thank you for your help, nevertheless On Apr 11, 2005 12:09 PM, Alexander Gottwald <[EMAIL PROTECTED]> wrote: > On Mon, 11 Apr 2005, Ariel Burbaickij wrote: > > > Thank you for quick response. > > I observed it in non-multiwindow mode, so > > I guess the question should be other way > > round ;-) > > Then I'd expect it to be a bug in cmdtool. The windowed > mode is very simple and all applications should work fine > with it. I had observed several strange errors with > solaris tools if some fonts were not available or the > display was running in 16 bit color mode. But none of them > match the error message. > > bye > ago > -- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723 >
Re: cmdtool from Solaris standard package generates some errors presented on the console and nothing more
On Mon, 11 Apr 2005, Ariel Burbaickij wrote: > Thank you for quick response. > I observed it in non-multiwindow mode, so > I guess the question should be other way > round ;-) Then I'd expect it to be a bug in cmdtool. The windowed mode is very simple and all applications should work fine with it. I had observed several strange errors with solaris tools if some fonts were not available or the display was running in 16 bit color mode. But none of them match the error message. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: cmdtool from Solaris standard package generates some errors presented on the console and nothing more
Thank you for quick response. I observed it in non-multiwindow mode, so I guess the question should be other way round ;-) On Apr 11, 2005 11:14 AM, Alexander Gottwald <[EMAIL PROTECTED]> wrote: > On Mon, 11 Apr 2005, Ariel Burbaickij wrote: > > > Hello dear mailing list participants, > > while trying to open cmdtool in te X11 > > displayback mode directed towards > > machine with cygwin X free environment > > running I get following: > > X Error of failed request: BadWindow (invalid Window parameter) > > Major opcode of failed request: 7 (X_ReparentWindow) > > Resource id in failed request: 0x3a > > Serial number of failed request: 48 > > Current serial number in output stream: 50 > > > > What does it mean and How can I hope with it? > > > > Would be glad to get some help from you. > > Quite a strange error. Maybe it tries to set the window parent to > some windowmanager window which does not exist in multiwindow mode. > Or it expects the CDE desktop to be present. > > does it happen in non-multiwindow mode too? > > bye > ago > -- > [EMAIL PROTECTED] > http://www.gotti.org ICQ: 126018723 >
Re: cmdtool from Solaris standard package generates some errors presented on the console and nothing more
On Mon, 11 Apr 2005, Ariel Burbaickij wrote: > Hello dear mailing list participants, > while trying to open cmdtool in te X11 > displayback mode directed towards > machine with cygwin X free environment > running I get following: > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 7 (X_ReparentWindow) > Resource id in failed request: 0x3a > Serial number of failed request: 48 > Current serial number in output stream: 50 > > What does it mean and How can I hope with it? > > Would be glad to get some help from you. Quite a strange error. Maybe it tries to set the window parent to some windowmanager window which does not exist in multiwindow mode. Or it expects the CDE desktop to be present. does it happen in non-multiwindow mode too? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
cmdtool from Solaris standard package generates some errors presented on the console and nothing more
Hello dear mailing list participants, while trying to open cmdtool in te X11 displayback mode directed towards machine with cygwin X free environment running I get following: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 7 (X_ReparentWindow) Resource id in failed request: 0x3a Serial number of failed request: 48 Current serial number in output stream: 50 What does it mean and How can I hope with it? Would be glad to get some help from you. With Best Regards Ariel Burbaickij
Yr mail has been received
Yr mail has been received
