Discussion:
startxwin.exe no longer exists?
(too old to reply)
Will Parsons
2014-12-12 18:07:15 UTC
Permalink
For several years now I have been starting X windows by clicking on an
icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It
has recently ceased to work because apparently startxwin.exe no longer
exists. Somehow I missed where this was removed, so what is the
recommended way of starting X from a desktop icon now?

I seem to recall that startxwin.exe was introduced some time ago
because using a script to start X was inadequate somehow, but I don't
remember the details, so what changed?

--
Will


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Marco Atzeri
2014-12-13 18:17:07 UTC
Permalink
On 12/12/2014 7:07 PM, Will Parsons wrote:
> For several years now I have been starting X windows by clicking on an
> icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It
> has recently ceased to work because apparently startxwin.exe no longer
> exists. Somehow I missed where this was removed, so what is the
> recommended way of starting X from a desktop icon now?
>
> I seem to recall that startxwin.exe was introduced some time ago
> because using a script to start X was inadequate somehow, but I don't
> remember the details, so what changed?
>
https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg00004.html

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Will Parsons
2014-12-16 02:49:56 UTC
Permalink
Marco Atzeri wrote:
>
> On 12/12/2014 7:07 PM, Will Parsons wrote:
>> For several years now I have been starting X windows by clicking on an
>> icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It
>> has recently ceased to work because apparently startxwin.exe no longer
>> exists. Somehow I missed where this was removed, so what is the
>> recommended way of starting X from a desktop icon now?
>>
>> I seem to recall that startxwin.exe was introduced some time ago
>> because using a script to start X was inadequate somehow, but I don't
>> remember the details, so what changed?
>>
> https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg00004.html

OK - so what I get from that is that whatever problems were associated
with the original shell script have been solved and startxwin is now a
shell script again. But, my basic question is unanswered - how do I
start an X session from an icon? Obviously, simply replacing the link
to startxwin.exe to startxwin will not work, so I copied the shortcut
from the start menu to the desktop and tried it (after renaming my
.xinitrc and .startxwinrc files to avoid any problems with the change
of model).

If I click on the icon, I *do* get an X session (along with an xterm
that I don't need), but if try (e.g.) to start emacs under mintty, I
get a non-X emacs, with an error message:

Display :0 unavailable, simulating -nw

Sure, display :0 is unavailable; checking DISPLAY in the (unwanted)
xterm shows DISPLAY is set to :5. Why's that I wonder?

Further investigation shows ls -ltr /tmp:

-r--r--r-- 1 william None 11 Nov 28 17:43 /tmp/.X0-lock
-r--r--r-- 1 william None 11 Dec 13 17:43 /tmp/.X1-lock
-r--r--r-- 1 william None 11 Dec 13 17:55 /tmp/.X2-lock
-r--r--r-- 1 william None 11 Dec 13 19:22 /tmp/.X3-lock
-r--r--r-- 1 william None 11 Dec 15 16:53 /tmp/.X4-lock
-r--r--r-- 1 william None 11 Dec 15 17:00 /tmp/.X5-lock

Interesting. It looks like every time I start an X session a lock
file is created and doesn't get deleted, so the display number keeps
changing. This doesn't look right, so how do I avoid it?

--
Will


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Larry Hall (Cygwin-X)
2014-12-16 02:56:11 UTC
Permalink
On 12/15/2014 09:49 PM, Will Parsons wrote:
> Marco Atzeri wrote:
>>
>> On 12/12/2014 7:07 PM, Will Parsons wrote:
>>> For several years now I have been starting X windows by clicking on an
>>> icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It
>>> has recently ceased to work because apparently startxwin.exe no longer
>>> exists. Somehow I missed where this was removed, so what is the
>>> recommended way of starting X from a desktop icon now?
>>>
>>> I seem to recall that startxwin.exe was introduced some time ago
>>> because using a script to start X was inadequate somehow, but I don't
>>> remember the details, so what changed?
>>>
>> https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg00004.html
>
> OK - so what I get from that is that whatever problems were associated
> with the original shell script have been solved and startxwin is now a
> shell script again. But, my basic question is unanswered - how do I
> start an X session from an icon? Obviously, simply replacing the link
> to startxwin.exe to startxwin will not work, so I copied the shortcut
> from the start menu to the desktop and tried it (after renaming my
> .xinitrc and .startxwinrc files to avoid any problems with the change
> of model).
>
> If I click on the icon, I *do* get an X session (along with an xterm
> that I don't need), but if try (e.g.) to start emacs under mintty, I
> get a non-X emacs, with an error message:
>
> Display :0 unavailable, simulating -nw
>
> Sure, display :0 is unavailable; checking DISPLAY in the (unwanted)
> xterm shows DISPLAY is set to :5. Why's that I wonder?
>
> Further investigation shows ls -ltr /tmp:
>
> -r--r--r-- 1 william None 11 Nov 28 17:43 /tmp/.X0-lock
> -r--r--r-- 1 william None 11 Dec 13 17:43 /tmp/.X1-lock
> -r--r--r-- 1 william None 11 Dec 13 17:55 /tmp/.X2-lock
> -r--r--r-- 1 william None 11 Dec 13 19:22 /tmp/.X3-lock
> -r--r--r-- 1 william None 11 Dec 15 16:53 /tmp/.X4-lock
> -r--r--r-- 1 william None 11 Dec 15 17:00 /tmp/.X5-lock
>
> Interesting. It looks like every time I start an X session a lock
> file is created and doesn't get deleted, so the display number keeps
> changing. This doesn't look right, so how do I avoid it?

You will get one lock file for every instance of the server you are running.
To remove the lock files, kill all instances of the server and remove any
remaining lock files. Then you can start a single session.


--
Larry

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Will Parsons
2014-12-16 03:30:21 UTC
Permalink
Larry Hall (Cygwin-X) wrote:
> On 12/15/2014 09:49 PM, Will Parsons wrote:
>> Marco Atzeri wrote:
>>>
>>> On 12/12/2014 7:07 PM, Will Parsons wrote:
>>>> For several years now I have been starting X windows by clicking on an
>>>> icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It
>>>> has recently ceased to work because apparently startxwin.exe no longer
>>>> exists. Somehow I missed where this was removed, so what is the
>>>> recommended way of starting X from a desktop icon now?
>>>>
>>>> I seem to recall that startxwin.exe was introduced some time ago
>>>> because using a script to start X was inadequate somehow, but I don't
>>>> remember the details, so what changed?
>>>>
>>> https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg00004.html
>>
>> OK - so what I get from that is that whatever problems were associated
>> with the original shell script have been solved and startxwin is now a
>> shell script again. But, my basic question is unanswered - how do I
>> start an X session from an icon? Obviously, simply replacing the link
>> to startxwin.exe to startxwin will not work, so I copied the shortcut
>> from the start menu to the desktop and tried it (after renaming my
>> .xinitrc and .startxwinrc files to avoid any problems with the change
>> of model).
>>
>> If I click on the icon, I *do* get an X session (along with an xterm
>> that I don't need), but if try (e.g.) to start emacs under mintty, I
>> get a non-X emacs, with an error message:
>>
>> Display :0 unavailable, simulating -nw
>>
>> Sure, display :0 is unavailable; checking DISPLAY in the (unwanted)
>> xterm shows DISPLAY is set to :5. Why's that I wonder?
>>
>> Further investigation shows ls -ltr /tmp:
>>
>> -r--r--r-- 1 william None 11 Nov 28 17:43 /tmp/.X0-lock
>> -r--r--r-- 1 william None 11 Dec 13 17:43 /tmp/.X1-lock
>> -r--r--r-- 1 william None 11 Dec 13 17:55 /tmp/.X2-lock
>> -r--r--r-- 1 william None 11 Dec 13 19:22 /tmp/.X3-lock
>> -r--r--r-- 1 william None 11 Dec 15 16:53 /tmp/.X4-lock
>> -r--r--r-- 1 william None 11 Dec 15 17:00 /tmp/.X5-lock
>>
>> Interesting. It looks like every time I start an X session a lock
>> file is created and doesn't get deleted, so the display number keeps
>> changing. This doesn't look right, so how do I avoid it?
>
> You will get one lock file for every instance of the server you are running.
> To remove the lock files, kill all instances of the server and remove any
> remaining lock files. Then you can start a single session.

well, I *had* killed them. Are you saying I need to manually remove
these old lock files? I suppose I can come up with a way of
semi-automating this, but it doesn't seem like it should be necessary.
Is this a matter of X sessions not properly exiting?

--
Will


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Larry Hall (Cygwin-X)
2014-12-16 03:35:29 UTC
Permalink
On 12/15/2014 10:30 PM, Will Parsons wrote:
> Larry Hall (Cygwin-X) wrote:
>> On 12/15/2014 09:49 PM, Will Parsons wrote:
>>> Marco Atzeri wrote:
>>>>
>>>> On 12/12/2014 7:07 PM, Will Parsons wrote:
>>>>> For several years now I have been starting X windows by clicking on an
>>>>> icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It
>>>>> has recently ceased to work because apparently startxwin.exe no longer
>>>>> exists. Somehow I missed where this was removed, so what is the
>>>>> recommended way of starting X from a desktop icon now?
>>>>>
>>>>> I seem to recall that startxwin.exe was introduced some time ago
>>>>> because using a script to start X was inadequate somehow, but I don't
>>>>> remember the details, so what changed?
>>>>>
>>>> https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg00004.html
>>>
>>> OK - so what I get from that is that whatever problems were associated
>>> with the original shell script have been solved and startxwin is now a
>>> shell script again. But, my basic question is unanswered - how do I
>>> start an X session from an icon? Obviously, simply replacing the link
>>> to startxwin.exe to startxwin will not work, so I copied the shortcut
>>> from the start menu to the desktop and tried it (after renaming my
>>> .xinitrc and .startxwinrc files to avoid any problems with the change
>>> of model).
>>>
>>> If I click on the icon, I *do* get an X session (along with an xterm
>>> that I don't need), but if try (e.g.) to start emacs under mintty, I
>>> get a non-X emacs, with an error message:
>>>
>>> Display :0 unavailable, simulating -nw
>>>
>>> Sure, display :0 is unavailable; checking DISPLAY in the (unwanted)
>>> xterm shows DISPLAY is set to :5. Why's that I wonder?
>>>
>>> Further investigation shows ls -ltr /tmp:
>>>
>>> -r--r--r-- 1 william None 11 Nov 28 17:43 /tmp/.X0-lock
>>> -r--r--r-- 1 william None 11 Dec 13 17:43 /tmp/.X1-lock
>>> -r--r--r-- 1 william None 11 Dec 13 17:55 /tmp/.X2-lock
>>> -r--r--r-- 1 william None 11 Dec 13 19:22 /tmp/.X3-lock
>>> -r--r--r-- 1 william None 11 Dec 15 16:53 /tmp/.X4-lock
>>> -r--r--r-- 1 william None 11 Dec 15 17:00 /tmp/.X5-lock
>>>
>>> Interesting. It looks like every time I start an X session a lock
>>> file is created and doesn't get deleted, so the display number keeps
>>> changing. This doesn't look right, so how do I avoid it?
>>
>> You will get one lock file for every instance of the server you are running.
>> To remove the lock files, kill all instances of the server and remove any
>> remaining lock files. Then you can start a single session.
>
> well, I *had* killed them. Are you saying I need to manually remove
> these old lock files? I suppose I can come up with a way of
> semi-automating this, but it doesn't seem like it should be necessary.
> Is this a matter of X sessions not properly exiting?

Yes, that is correct. In general, you shouldn't see this.

--
Larry

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Mark Hansen
2014-12-16 14:29:09 UTC
Permalink
On 12/15/2014 6:49 PM, Will Parsons wrote:
> Marco Atzeri wrote:
>>
>> On 12/12/2014 7:07 PM, Will Parsons wrote:
>>> For several years now I have been starting X windows by clicking on an
>>> icon on my desktop that is a link to C:\cygwin\bin\startxwin.exe. It
>>> has recently ceased to work because apparently startxwin.exe no longer
>>> exists. Somehow I missed where this was removed, so what is the
>>> recommended way of starting X from a desktop icon now?
>>>
>>> I seem to recall that startxwin.exe was introduced some time ago
>>> because using a script to start X was inadequate somehow, but I don't
>>> remember the details, so what changed?
>>>
>> https://cygwin.com/ml/cygwin-xfree-announce/2014-11/msg00004.html
>
> OK - so what I get from that is that whatever problems were associated
> with the original shell script have been solved and startxwin is now a
> shell script again. But, my basic question is unanswered - how do I
> start an X session from an icon? Obviously, simply replacing the link
> to startxwin.exe to startxwin will not work, so I copied the shortcut
> from the start menu to the desktop and tried it (after renaming my
> .xinitrc and .startxwinrc files to avoid any problems with the change
> of model).

Here is the content of the desktop shortcut that I use:

C:\Apps\cygwin\bin\run.exe /usr/bin/bash.exe -l -c "/usr/bin/startxwin.exe -- -emulate3buttons 100 -multiwindow -clipboard -swcursor"

I have this set to run when I log into the machine and it works fine.


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Erik Soderquist
2014-12-16 16:00:01 UTC
Permalink
<snip>
>
> Sure, display :0 is unavailable; checking DISPLAY in the (unwanted)
> xterm shows DISPLAY is set to :5. Why's that I wonder?
>
> Further investigation shows ls -ltr /tmp:
>
> -r--r--r-- 1 william None 11 Nov 28 17:43 /tmp/.X0-lock
> -r--r--r-- 1 william None 11 Dec 13 17:43 /tmp/.X1-lock
> -r--r--r-- 1 william None 11 Dec 13 17:55 /tmp/.X2-lock
> -r--r--r-- 1 william None 11 Dec 13 19:22 /tmp/.X3-lock
> -r--r--r-- 1 william None 11 Dec 15 16:53 /tmp/.X4-lock
> -r--r--r-- 1 william None 11 Dec 15 17:00 /tmp/.X5-lock
>
> Interesting. It looks like every time I start an X session a lock
> file is created and doesn't get deleted, so the display number keeps
> changing. This doesn't look right, so how do I avoid it?
>
> --
> Will

What I do is specify the display on the command line. If it fails, I
check for an existing operational session with the same display. If
it exists, I simply exit the script. If not, I free the lock file and
retry the X server start on the chosen display.

-- Erik

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
rcunningham
2014-12-16 16:32:15 UTC
Permalink
On 12/16/2014 8:00 AM, Erik Soderquist wrote:
> <snip>
>> Sure, display :0 is unavailable; checking DISPLAY in the (unwanted)
>> xterm shows DISPLAY is set to :5. Why's that I wonder?
>>
>> Further investigation shows ls -ltr /tmp:
>>
>> -r--r--r-- 1 william None 11 Nov 28 17:43 /tmp/.X0-lock
>> -r--r--r-- 1 william None 11 Dec 13 17:43 /tmp/.X1-lock
>> -r--r--r-- 1 william None 11 Dec 13 17:55 /tmp/.X2-lock
>> -r--r--r-- 1 william None 11 Dec 13 19:22 /tmp/.X3-lock
>> -r--r--r-- 1 william None 11 Dec 15 16:53 /tmp/.X4-lock
>> -r--r--r-- 1 william None 11 Dec 15 17:00 /tmp/.X5-lock
>>
>> Interesting. It looks like every time I start an X session a lock
>> file is created and doesn't get deleted, so the display number keeps
>> changing. This doesn't look right, so how do I avoid it?
>>
>> --
>> Will
> What I do is specify the display on the command line. If it fails, I
> check for an existing operational session with the same display. If
> it exists, I simply exit the script. If not, I free the lock file and
> retry the X server start on the chosen display.
>
> -- Erik

Shouldn't the startxwin script check for running instances and delete
all lock-files related to non-existent instances? Why must this be a
manual operation?


The prior startxwin.exe "just worked", and this new replacement script
is clearly creating problems for previously happy CygwinX users, where
no problems existed before (or, at least the problems weren't visible
and didn't affect normal use).

I would have preferred to have seen startxwin.exe retained, and this new
script phased in gradually, perhaps as "startxwin_new" in the first
release. Then, when startxwin_new stabilizes, rename the executable to
startxwin_old.exe and the script to startxwin. Several updates later,
quietly remove startxwin_old.exe.

It seems nonsensical to treat all CygwinX users as alpha testers. I'm
more than willing to help test new features, but not in the dark: Make
it very clear when significant subsystems are being evolved, and provide
a way to try the new without losing the old.

For now, can startxwin.exe be restored under some name?

-BobC


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Erik Soderquist
2014-12-16 17:06:18 UTC
Permalink
<snip>

> Shouldn't the startxwin script check for running instances and delete all
> lock-files related to non-existent instances? Why must this be a manual
> operation?

I generally recommend against automagic cleanup of lock files from
dead sessions being a general default because that also wipes out
warning that something went wrong. I do it in my situation because I
have it on (essentially) dumb terminals where the session working is
much more important than knowing something went wrong, and the dumb
terminals are on flaky power, so most of the dead sessions are due to
power failure anyway.

> The prior startxwin.exe "just worked", and this new replacement script is
> clearly creating problems for previously happy CygwinX users, where no
> problems existed before (or, at least the problems weren't visible and
> didn't affect normal use).

I actually have no experience with startxwin; I always called the X
server directly with the options I wanted. However, I can say that
freeing of lock files is the job of the process that created the lock
files. If you kill the process, stray lock files are a normal
expectation.

> I would have preferred to have seen startxwin.exe retained, and this new
> script phased in gradually, perhaps as "startxwin_new" in the first release.
> Then, when startxwin_new stabilizes, rename the executable to
> startxwin_old.exe and the script to startxwin. Several updates later,
> quietly remove startxwin_old.exe.
>
> It seems nonsensical to treat all CygwinX users as alpha testers. I'm more
> than willing to help test new features, but not in the dark: Make it very
> clear when significant subsystems are being evolved, and provide a way to
> try the new without losing the old.

The changes were announced, and the announcement already sited in this
thread. Having read the announcement again, it looks like the
replacement has as one of its goals bringing the X system more in line
with general X and *nix standards, which, as far as I know, has always
been a general goal of the entire Cygwin set of projects.

> For now, can startxwin.exe be restored under some name?
>
> -BobC

That part I can't speak to except perhaps to pull it from an old
version. I'm not part of the CygwinX team, and have no say in the
matter.

-- Erik

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
rcunningham
2014-12-16 17:22:15 UTC
Permalink
On 12/16/2014 9:06 AM, Erik Soderquist wrote:
> <snip>
>
>> Shouldn't the startxwin script check for running instances and delete all
>> lock-files related to non-existent instances? Why must this be a manual
>> operation?
> I generally recommend against automagic cleanup of lock files from
> dead sessions being a general default because that also wipes out
> warning that something went wrong. I do it in my situation because I
> have it on (essentially) dumb terminals where the session working is
> much more important than knowing something went wrong, and the dumb
> terminals are on flaky power, so most of the dead sessions are due to
> power failure anyway.

Then the script should provide a popup (via zenity, yad, dialog, or
whatever) that informs the user that a prior session crashed, and offer
a "Continue/Abort" choice. Don't force casual X users to learn about
lock-files. By default, also provide a popup whenever a running server
is detected, to avoid redundant servers being launched inadvertently.

Help normal users get on with their work, rather than providing a
surprisingly different environment requiring specialized knowledge to
resolve.

>> The prior startxwin.exe "just worked", and this new replacement script is
>> clearly creating problems for previously happy CygwinX users, where no
>> problems existed before (or, at least the problems weren't visible and
>> didn't affect normal use).
> I actually have no experience with startxwin; I always called the X
> server directly with the options I wanted. However, I can say that
> freeing of lock files is the job of the process that created the lock
> files. If you kill the process, stray lock files are a normal
> expectation.

Evidently, that isn't being done. But the prior startxwin.exe never, in
my experience, created the issues of the new startxwin script.

>> I would have preferred to have seen startxwin.exe retained, and this new
>> script phased in gradually, perhaps as "startxwin_new" in the first release.
>> Then, when startxwin_new stabilizes, rename the executable to
>> startxwin_old.exe and the script to startxwin. Several updates later,
>> quietly remove startxwin_old.exe.
>>
>> It seems nonsensical to treat all CygwinX users as alpha testers. I'm more
>> than willing to help test new features, but not in the dark: Make it very
>> clear when significant subsystems are being evolved, and provide a way to
>> try the new without losing the old.
> The changes were announced, and the announcement already sited in this
> thread. Having read the announcement again, it looks like the
> replacement has as one of its goals bringing the X system more in line
> with general X and *nix standards, which, as far as I know, has always
> been a general goal of the entire Cygwin set of projects.

I never used this list until AFTER the update killed my previously
stable CygwinX environment.

It is silly to expect all CygwinX users to actively monitor a list just
to avoid getting their systems broken.

-BobC

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Will Parsons
2014-12-16 22:58:21 UTC
Permalink
Erik Soderquist wrote:
><snip>
>
>> Shouldn't the startxwin script check for running instances and delete all
>> lock-files related to non-existent instances? Why must this be a manual
>> operation?
>
> I generally recommend against automagic cleanup of lock files from
> dead sessions being a general default because that also wipes out
> warning that something went wrong. I do it in my situation because I
> have it on (essentially) dumb terminals where the session working is
> much more important than knowing something went wrong, and the dumb
> terminals are on flaky power, so most of the dead sessions are due to
> power failure anyway.

Apparently not. If I start an X session (using the standard menu item
under the start menu) and manually shut it down, the lock file is not
deleted.

>> The prior startxwin.exe "just worked", and this new replacement script is
>> clearly creating problems for previously happy CygwinX users, where no
>> problems existed before (or, at least the problems weren't visible and
>> didn't affect normal use).

Yes, startxwin.exe "just worked", and the replacement doesn't.

> I actually have no experience with startxwin; I always called the X
> server directly with the options I wanted.

What do you mean "directly"? From a mintty or such?

> However, I can say that
> freeing of lock files is the job of the process that created the lock
> files. If you kill the process, stray lock files are a normal
> expectation.

No they're not, unless you restrict "kill" to mean "kill -9" or
equivalent. If you kill a process using just "kill", or bu shutting
it down normally, it should clean up its lock file.

>> I would have preferred to have seen startxwin.exe retained, and this new
>> script phased in gradually, perhaps as "startxwin_new" in the first release.
>> Then, when startxwin_new stabilizes, rename the executable to
>> startxwin_old.exe and the script to startxwin. Several updates later,
>> quietly remove startxwin_old.exe.
>>
>> It seems nonsensical to treat all CygwinX users as alpha testers. I'm more
>> than willing to help test new features, but not in the dark: Make it very
>> clear when significant subsystems are being evolved, and provide a way to
>> try the new without losing the old.
>
> The changes were announced, and the announcement already sited in this
> thread. Having read the announcement again, it looks like the
> replacement has as one of its goals bringing the X system more in line
> with general X and *nix standards, which, as far as I know, has always
> been a general goal of the entire Cygwin set of projects.

Then it's not succeeding. Shutting down X normally under *nix does not
result in left-over lock files.

--
Will


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Erik Soderquist
2014-12-16 23:39:03 UTC
Permalink
<snip>
> Apparently not. If I start an X session (using the standard menu item
> under the start menu) and manually shut it down, the lock file is not
> deleted.

On a clean shutdown, the process should clean up its lock files; if it
isn't, that needs to looked at and/or reported. The only caveat to
that I'm aware of is if a debug flag is set, files the process uses
may be intentionally left behind. However, it doesn't sound like you
would be setting such flags.

<snip>
>> I actually have no experience with startxwin; I always called the X
>> server directly with the options I wanted.
>
> What do you mean "directly"? From a mintty or such?

Windows .bat/.cmd files, custom crafted shortcut on the desktop,
windows registry changes... depends on the situation. The one I
referenced with the dumb terminals and flaky power is a registry call
in autorun starting a .cmd file.

>> However, I can say that freeing of lock files is the job
>> of the process that created the lock files. If you kill
>> the process, stray lock files are a normal expectation.
>
> No they're not, unless you restrict "kill" to mean "kill -9" or
> equivalent. If you kill a process using just "kill", or by shutting
> it down normally, it should clean up its lock file.

My apologies; I was only considering kill -9 as 'kill the process'.
You are correct, kill -15 is also a kill, but should allow the process
to exit cleanly.

<snip>
>> ... bringing the X system more in line with general X and
> *nix standards, which, as far as I know, has always
>> been a general goal of the entire Cygwin set of projects.
>
> Then it's not succeeding. Shutting down X normally under *nix does not
> result in left-over lock files.

I will certainly agree that shutting down X cleanly should not leave
stray lock files behind. I can also say that I'm not experiencing
that issue. My best guess (and this is only a guess) is that
something is causing X to crash as it shuts down on your system,
causing the lock files to be left behind.

-- Erik

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
mathog
2014-12-17 17:29:47 UTC
Permalink
On 16-Dec-2014 15:39, Erik Soderquist wrote:
> My best guess (and this is only a guess) is that
> something is causing X to crash as it shuts down on your system,
> causing the lock files to be left behind.

There is no reason that should happen unless the startxwin script also
crashes - and that basically should never happen. The script should
clean up any mess that the binary might leave, and it should handle all
conditions that might result from some process it has started crashing.
That is, in the script (pseudocode):

# If there is an existing lock file:
# Test is there also an existing X11 binary process?
# yes - abort with message: X11 server already running
# no - remove lock file
##########
# do whatever housekeeping is needed
# then start binary
/path/X11_server_binary $args
#no matter how binary exits...
rm /path/.X*lock

The only time a script might not have a chance to run the last command
is if it starts the server via "nohup binary &", assuming such a thing
is even possible in cygwin, and then exits without waiting around for
the binary to exit. Or, of course, if the whole system crashes, but
that isn't the issue the end users are having.

Regards,

David Mathog
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Erik Soderquist
2014-12-17 17:40:20 UTC
Permalink
<snip>
> There is no reason that should happen unless the startxwin script also
> crashes - and that basically should never happen. The script should clean
> up any mess that the binary might leave, and it should handle all conditions
> that might result from some process it has started crashing. That is, in
> the script (pseudocode):
>
> # If there is an existing lock file:
> # Test is there also an existing X11 binary process?
> # yes - abort with message: X11 server already running
> # no - remove lock file
> ##########
> # do whatever housekeeping is needed
> # then start binary
> /path/X11_server_binary $args
> #no matter how binary exits...
> rm /path/.X*lock
>
> The only time a script might not have a chance to run the last command is if
> it starts the server via "nohup binary &", assuming such a thing is even
> possible in cygwin, and then exits without waiting around for the binary to
> exit. Or, of course, if the whole system crashes, but that isn't the issue
> the end users are having.

So you want your script to completely mask and/or destroy any evidence
that something crashed?? That is very counter-productive toward
anything resembling fixing a problem or even discovering a problem
exists.

Also, as the X server is not bound to a tty, it forks to the
background on its own anyway, so your pseudocode example would delete
the lock file just after the X server started.

>
> Regards,
>
> David Mathog


-- Erik

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
mathog
2014-12-17 17:52:19 UTC
Permalink
On 17-Dec-2014 09:40, Erik Soderquist wrote:
> <snip>
>> There is no reason that should happen unless the startxwin script also
>> crashes - and that basically should never happen. The script should
>> clean
>> up any mess that the binary might leave, and it should handle all
>> conditions
>> that might result from some process it has started crashing. That is,
>> in
>> the script (pseudocode):
>>
>> # If there is an existing lock file:
>> # Test is there also an existing X11 binary process?
>> # yes - abort with message: X11 server already running
>> # no - remove lock file
>> ##########
>> # do whatever housekeeping is needed
>> # then start binary
>> /path/X11_server_binary $args
>> #no matter how binary exits...
>> rm /path/.X*lock
>>
>> The only time a script might not have a chance to run the last command
>> is if
>> it starts the server via "nohup binary &", assuming such a thing is
>> even
>> possible in cygwin, and then exits without waiting around for the
>> binary to
>> exit. Or, of course, if the whole system crashes, but that isn't the
>> issue
>> the end users are having.
>
> So you want your script to completely mask and/or destroy any evidence
> that something crashed??

No, that is the log file, this is the lock file. It should rotate the
log file from the previous run and delete the lock file.

>
> Also, as the X server is not bound to a tty, it forks to the
> background on its own anyway, so your pseudocode example would delete
> the lock file just after the X server started.

In that case the the script needs to retrieve the PID of the forked
process and wait for it to exit.

Regards,

David Mathog
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Erik Soderquist
2014-12-17 18:35:57 UTC
Permalink
<snip>
>> So you want your script to completely mask and/or destroy any evidence
>> that something crashed??
>
>
> No, that is the log file, this is the lock file. It should rotate the log
> file from the previous run and delete the lock file.

How often do you check your log files for crashes when you have your
script hiding the fact that it crashed from you?

>
>>
>> Also, as the X server is not bound to a tty, it forks to the
>> background on its own anyway, so your pseudocode example would delete
>> the lock file just after the X server started.
>
>
> In that case the the script needs to retrieve the PID of the forked process
> and wait for it to exit.


I would much rather have the binary process clean up after itself like
it is supposed to, and figure out why the binary process is failing to
do so when it doesn't than have a script that hides such failures from
me.

To each its own though.

-- Erik

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
mathog
2014-12-17 19:02:23 UTC
Permalink
On 17-Dec-2014 10:35, Erik Soderquist wrote:

> How often do you check your log files for crashes when you have your
> script hiding the fact that it crashed from you?

Fine, have the script emit a warning when this situation is encountered.
Personally I have never seen the X11 server crash between "shut down"
and removing the lock file. I have seen it crash while running - and
that was pretty evident since all my X11 windows disappeared, no need to
look for a lock file!
>
>>
>>>
>>> Also, as the X server is not bound to a tty, it forks to the
>>> background on its own anyway, so your pseudocode example would delete
>>> the lock file just after the X server started.
>>
>>
>> In that case the the script needs to retrieve the PID of the forked
>> process
>> and wait for it to exit.
>
>
> I would much rather have the binary process clean up after itself like
> it is supposed to, and figure out why the binary process is failing to
> do so when it doesn't than have a script that hides such failures from
> me.

Sure, the binary SHOULD work like that, but what others have said is
that it is not always doing so. Hence, the script should pick up the
pieces if the binary failed to do so. The script need not "hide"
anything, it can emit warning messages on any and all conditions. At
start up:

"Found orphan lock file and removed it. Possible crash during
previous X11 server session. Starting X11 server normally."

at shut down:

"X11 server process exited abnormally. Orphan lock file removed."

etc.

Regards,

David Mathog
***@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Continue reading on narkive:
Loading...