My money is on writedata(). I bet there is a case where the file is zeroed out, then prior to the writing of the new value, it fails leaving an empty file. Then the main code which is written to handle a missing file silently, resets the counter to 1 and goes on with its life. Perhaps an error should be logged if the file is zero length. ie reading the first line returns undef which, for example which means your process either just created an empty file or opened an empty file. Either way your counter data has disappeared.

I do wonder why the main file isn't opened RW then locked LOCK_EX then read, increment value, truncate(), and write, and close (unlocking the file). This method only uses one file, one lock, and only opens the file once. The locking will ensure that all the processes play well together.

Also if you have access to a database which has sequences which don't have to relate to a specific table, one could be set up to do the counting. The interface is heavier but automicity is guaranteed and your counter won't mysteriously reset to zero. This probably only makes sense if you are using the database for other things already on the site.

In PostgreSQL the SQL would go like SELECT nextval('my_sequence'). One would then use DBI presumably and fetch the value which would always be the next one in the series. This works for multiple processes and is quite scalable.