Bugzilla – Bug 2009
Prefs file lost - reverts to defaults
Last modified: 2011-03-16 04:19:49 UTC
I think it happens if you kill the server when its writing, or maybe when about to write the prefs. On startup, look at d_prefs. I get a lot of writing out messages in the startup: 2005-08-24 00:11:53.6635 Adding PLUGIN.alarmname.F to setup hash 2005-08-24 00:11:53.6636 Adding PLUGIN.alarmtime.F to setup hash 2005-08-24 00:11:53.6638 Adding PLUGIN.alarmvolume.F to setup hash 2005-08-24 00:11:53.6705 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:53.8921 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:54.1148 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:54.3368 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:54.6088 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:54.8331 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:55.0552 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:55.2800 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:55.5471 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:55.7694 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:55.9924 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:56.2134 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:56.4636 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:56.6860 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:56.9094 Writing out prefs in /etc/slimserver.conf 2005-08-24 00:11:57.1308 Writing out prefs in /etc/slimserver.conf if I kill the server too close to the time of those, my prefs file goes to zero size. start in up again, I'm with default prefs. This is similar to what was reported a while back (can't recall which user). I can't make it happen on demand, but I can better than 50% of times I try.
Robert, any thoughts as to why this might happen? This is with the new YAML prefs in 6.2, latest svn (4040+) but it has happened before this. I only recently noticed it reliably and along with the prefs debug.
Do you have a lot of clients connecting? And is your prefsWriteDelay set to 0? If the answer to both of those is yes, then what you are seeing is the prefs getting written after each client initializes. As for it ending up with a 0 length file, what may be happening is that it is getting interrupted in between the opening of the file and the writing to the file. One thing to try would be to move the $writePending = 0; statement in the writePrefs() sub to the end of the sub. That might work in that the cleanup() function would then go ahead and do a writePrefs at the end, since $writePending will still be set if writePrefs() is interrupted.
I have my delay set to 0, yes. I have only 5 clients, so wasn't linking the 16 writes to that. I'll try your suggestion and see if I can cut down the losses. thanks
SoftSqueeze and SB2 will generate three writes per client, SBG will do two, and the rest one. SS isa SB2 isa SBG isa SB isa player isa client initClientPrefs (which does a scheduled write) is called from the init of SB2, SBG, and client (with different prefs to check). With prefsWriteDelay > 0, only one write would have been generated. The scheduled write could be taken out of initClientPrefs and added to the Client::init() to reduce this to one write per client regardless of type.
Whoops, missed one, Player::init() also calls Prefs::initClientPrefs(), so bump up the number of writes by one for all of those.
thanks. so, good argument for having a prefs delay then :)
well, with the suggested change, I can't seem to make it fail deliberately. With prefs delay on 0 or no. I've committed this (change 4059), but I'll leave this open for a while longer just to be sure.
no incidents in a week. seems safe.
had this happen again. I have no idea how, since clearly I was only aware of it after it was far too late.
The last fix put in for this should have taken it down to a window of one line of perl for the previous problem to be the cause. I guess we need something more robust to recover since it seems this small window may not be rare enough, or if there is another as yet unknown cause.
Is this still an issue?
it happens very rarely, but enough to make me keep backups. with today's crashes, the prefs were getting lost too. server crashed and prefs file is blank. with the service set to autorestart, the defaults go in. a dangling filehandle somwhere when the serve stops seems to be the problem. any way to copy and read instead?
I doubt if the reading is the problem. Write to temp, delete, rename would be the safer way to go.
I assume that the File::Slurp atomic writes fix this.