[fpc-pascal] Re: Configuration file handling

[Mark Morgan Lloyd]

Reinier Olislagers wrote:
> On 16-2-2013 9:09, Sven Barth wrote:
>> On 15.02.2013 23:54, Mark Morgan Lloyd wrote:
>>> If multiple, related, programs running on unix (Linux, Solaris etc.)
>>> refer to the same configuration file accessed via a TIniFile, is there
>>> any recommended "good practice" to ensure that they don't try to update
>>> it simultaneously?
>>>
>>> In the case that I'm thinking of, I don't anticipate e.g. multiple
>>> logins trying to write setup information at the same time. The more
>>> risky case is if there are e.g. multiple daemons or apps trying to save
>>> state when a UPS signals imminent shutdown.
>>>
>> This might be for Windows, but I think this applies here as well:
>> http://blogs.msdn.com/b/oldnewthing/archive/2004/11/22/267890.aspx
> 
> Security problems with world-writable files? Yes, that problem applies
> to *nix as well but Mark has given no indication his config files are
> world-writable. (Even if the logins Mark speaks of run under different
> user accounts, there's such a thing as groups on *nix, too :) )

[Checks link] I agree. The specific case I'm thinking of is where a 
number of related daemons running (after any low-numbered sockets have 
been grabbed) as the same user. Since they will be referring to the same 
database servers and probably to common tables it makes sense to use a 
common configuration file, this also makes it much easier since somebody 
setting up a new collaborating system can be sent a template for the 
single .ini required.

I think I'm leaning towards an arrangement where important stuff 
(database names etc.) is written to the common .ini as soon as it is 
entered into whichever program is dominant, but less-important stuff 
(window sizes etc.) which might be updated at termination is kept in its 
own file. There's still a risk that multiple instances of the same 
program could interfere with each other, but the worst case result will 
be messed up screen layout and it will always be fixable by deleting the 
relevant .ini.

> UPS shutdown: no experience with that - I'd expect the process to just
> get a regular kill signal; perhaps the OS/UPS driver provides dbus (or
> other messaging layer) notifications.
> 
> If the data is not that important, wouldn't a naive approach like a loop
> that
> - repeats say max 3x,
> - tries to save the data,
> - catching exceptions coming from TIniFile, then waiting a random small
> amount of time
> - giving up after those 3x
> help?
> 
> Obviously, this problem would be alleviated if you run under multiple
> different accounts (normal applications) and properly save settings
> somewhere in the user's ~ directory rather than a systemwide path (which
> the FPC getconfig... forgot exactly supports).

The notable thing about UPS shutdowns is that in at least some cases a 
system first signals term then after five seconds signals kill. I think 
that initial term is going to be problematic where shared data is 
involved, since multiple programs can receive it simultaneously.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]