Fgfs.pid: Difference between revisions
m (https://sourceforge.net/p/flightgear/mailman/search/?q=%22fgfs.pid%22&mail_list=all) |
(Switch to the {{forum url}} template for all forum links. The links within {{cite web}} have been excluded.) |
||
| Line 56: | Line 56: | ||
For the archives, the two relevant forum threads are: | For the archives, the two relevant forum threads are: {{forum url|t=31746}} {{forum url|t=31720}} Note that forum user commsbiff partly confirmed theombie fgfs.pid file being the issue and SkinnierSteve fully confirmed it. A few more tests on fresh $FG_HOME's with navigation cache errors after an upgrade should confirm this without doubt.<ref>{{cite web | ||
|url = https://sourceforge.net/p/flightgear/mailman/message/35692101/ | |url = https://sourceforge.net/p/flightgear/mailman/message/35692101/ | ||
|title = <nowiki> Re: [Flightgear-devel] Windows nav-cache permission issue </nowiki> | |title = <nowiki> Re: [Flightgear-devel] Windows nav-cache permission issue </nowiki> | ||
Latest revision as of 11:02, 6 June 2019
| This article is a stub. You can help the wiki by expanding it. |
fgfs.pid
bit of insight on the commonly reported failures on the forum about the Nav-cache being read-only. It looks as if the whole nav-cache thing may have been completely mis-leading - the problem is nothing to do with the nav-cache at all, it’s unfortunate that the error mentioned it, since that has rather distracted from finding the solution. (All of the above assuming we have found the solution, which is still uncertain but looking quite likely). The actual problem seems to be the fgfs.pid file we use to ensure only one copy of FGFS is running with write-access to FG_HOME - all other copies run with read-only access. On POSIX I use standard open+unlink behaviour to create the PID file but ensure we don’t ever get stale ones, even if the system crashes. I then used Google / StackOverflow to find equivalent code for Windows - CreateFile with a ‘delete file on close’ flag. However, it looks as if this behaviour may be fragile in the case of non-clean exits / power-offs. I’ve just pushed a patch to next to change to a named-mutex-based solution on Windows (POSIX is unchanged), which can’t ever get stuck with stale data, since there is no file at all. [1]
the problem with the read-only navigation cache on Windows is simple, and has been $FG HOME that is making the home directory read-only.
[2] This issue is due to a stale fgfs.pid file in $FG HOME on certain MS Windows systems which makes $FG_HOME partly read-only, blocking TerraSync from downloading and disallowing the saving of the new, version specific navigation cache SQL database after an upgrade (hence FG cannot start). This long standing bug has been permanently fixed in the latest 2017.1.2 release.[3] This issue is mainly due to a stale fgfs.pid file in $FG HOME on certain MS Windows systems which makes $FG_HOME partly read-only, blocking TerraSync from downloading. This has been permanently fixed in the latest 2017.1.2 release. [4] the stale fgfs.pid file for making a second FG instance read-only. This is now well known to the FG developers. It has absolutely nothing to do with the navigation cache SQL database, but this error message threw the developers off-track for the 1-2 years the bug has existed. Deleting any navdata_*.cache files has no effect. This has been permanently fixed in FG 2017.1.2, as the PID file is no longer used. [5] For the archives, the two relevant forum threads are: https://forum.flightgear.org/viewtopic.php?t=31746 https://forum.flightgear.org/viewtopic.php?t=31720 Note that forum user commsbiff partly confirmed theombie fgfs.pid file being the issue and SkinnierSteve fully confirmed it. A few more tests on fresh $FG_HOME's with navigation cache errors after an upgrade should confirm this without doubt.[6]
References
References
|