public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: mathog <mathog@caltech.edu>
To: cygwin-xfree@cygwin.com
Subject: Re: startxwin.exe no longer exists?
Date: Wed, 17 Dec 2014 17:29:00 -0000	[thread overview]
Message-ID: <9439619875edc65b1e7152b743ad5553@saf.bio.caltech.edu> (raw)
In-Reply-To: <CACoZoo1uEoC=28qEm2j2YBEv1g-DCJy-97muhg6dFLR6VJKFJw@mail.gmail.com>

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
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/


  reply	other threads:[~2014-12-17 17:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-13 16:20 Will Parsons
2014-12-13 18:17 ` Marco Atzeri
2014-12-16  2:50   ` Will Parsons
2014-12-16  2:56     ` Larry Hall (Cygwin-X)
2014-12-16  3:30       ` Will Parsons
2014-12-16  3:35         ` Larry Hall (Cygwin-X)
2014-12-16 14:29     ` Mark Hansen
2014-12-16 16:00     ` Erik Soderquist
2014-12-16 16:36       ` rcunningham
2014-12-16 17:06         ` Erik Soderquist
2014-12-16 17:23           ` rcunningham
2014-12-16 22:58           ` Will Parsons
2014-12-16 23:39             ` Erik Soderquist
2014-12-17 17:29               ` mathog [this message]
2014-12-17 17:40                 ` Erik Soderquist
2014-12-17 17:52                   ` mathog
2014-12-17 18:36                     ` Erik Soderquist
2014-12-17 19:02                       ` mathog

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9439619875edc65b1e7152b743ad5553@saf.bio.caltech.edu \
    --to=mathog@caltech.edu \
    --cc=cygwin-xfree@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).