[pmwiki-users] .flock troubles

[Joachim Durchholz]

Patrick R. Michaud wrote:
> On Thu, Apr 21, 2005 at 10:04:42PM +0200, Joachim Durchholz wrote:
> 
>>I just hit a stale .flock issue again. Just adding another data point to 
>>that nagging problem - hopefully a solution can be found in the end!
> 
> What version of pmwiki?

2.0 beta 28. (Sorry, thought about it but forgot to write it down.)

> Newer versions (since beta30) should
> have *much* better .flock handling, and don't "hang" when a stale
> .flock occurs.

Ah, that's exactly what happened.

I'm not too eager to upgrade though - important new functionality was 
included in these last versions, and since it's unneded, I wanted to let 
it mature a bit.

The single user on that wiki now knows how to delete .flock if necessary :-)

>>Some additional observations:
>>
>>1. The last change was done at 17:20, as checking .lastmod and 
>>Main.AllRecentChanges revealed (that was confirmed by ll -t, which 
>>showed that these were indeed the last files changed). However, as can 
>>be seen above, the .flock file was last created/changed far later.
> 
> That shows the last time a page was saved, but not necessarily
> the last time that someone requested an edit (which also acquires
> an exclusive lock on .flock).

Well, there was no way to request an edit after 17:40 because PmWiki 
didn't serve any pages anymore. (Well, somebody could have typed an edit 
URL into the address bar, or requested it from a bookmark list - but I 
doubt that. The date/time stamp pointed towards my diagnostic attempts, 
which involved trying things like ?action=diag and ?action=phpinfo, 
which were also met with a "hang".)

>>2. Somehow, the .flock file got created with the wrong user. I don't 
>>know how this ever might have happened. I've got even less of a clue why 
>>this should be a problem - any process in group www should be able to 
>>remove or touch that file, since both the file and the wiki.d directory 
>>are in group www and group writable.
> 
> I don't know either.  This commonly happens when a .flock is copied from
> another wiki.d/ directory, either as part of a backup or restore.

Seems likely - though I had thought that .flock is constantly being 
deleted and recreated. (Or at least that's how lock files are usually 
handled - I have no real idea how .flock is handled in PmWiki, and the 
docs are silent on it.)

> It can also happen if the apache administrators mucks temporarily
> with the User/Group settings in Apache, or if an overeager sysadmin 
> thinks it's useful to fix file ownerships with 
> "chown -R someuser ~someuser".

That didn't occur on that machine. I'm the only sysadmin there who would 
think of such things, and I certainly didn't do anything to Apache's or 
the files' permissions in the last weeks :-)

> Regardless, PmWiki felt that the .flock file was sufficiently writable,
> otherwise it would've removed .flock and recreated it rather
> than blocking entirely.  

OK.

>>3. There was a strange file called NOOP in wiki.d/ . That's probably 
>>unrelated, because it is already a week old, but I'm not sure how such a 
>>file might have been created. (It contained a wiki page, but one that 
>>wasn't named NOOP. Actually, NOOP isn't a valid name for a wiki page file.)
> 
> This makes me suspect that some other system process is creating
> files in your wiki.d/ .  You're right that NOOP isn't a valid wiki page
> filename.

Probably an FTP client that tries to be overly smart (or that was overly 
confused - Neil's theory is really the best of the available ones).

If PmWiki doesn't need that name, I'll simply delete the file (which is 
really what I wanted to know). Oh, and I've changed the FTP client, so 
it's likely something on the server itself if the file should reappear.

Thanks for the feedback. Very much appreciated.
Again, I'm not sure when exactly I'll upgrade that particular PmWiki to 
the current version - the site is near public presentation now, and the 
.flock problem is currently more tolerable than the risk of breakage on 
update. (Not that I consider the risk significant - it's just the wrong 
time for an upgrade right now.)

Regards,
Jo