public inbox for
help / color / mirror / Atom feed
From: mathog <>
Subject: Re: startxwin.exe no longer exists?
Date: Wed, 17 Dec 2014 19:02:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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."



David Mathog
Manager, Sequence Analysis Facility, Biology Division, Caltech

Unsubscribe info:
Problem reports:

      reply	other threads:[~2014-12-17 19:02 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
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 [this message]

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:

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

  git send-email \ \ \ \

* 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).