Re: startxwin.exe no longer exists?
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 mat...@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/
Re: startxwin.exe no longer exists?
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/
Re: startxwin.exe no longer exists?
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 mat...@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/
Re: startxwin.exe no longer exists?
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/
Re: startxwin.exe no longer exists?
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 mat...@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/
