http://www.perlmonks.org?node_id=999647

DustyM has asked for the wisdom of the Perl Monks concerning the following question:

Apologies. I've been managing a perl based ecommerce site for many years. It was an out the box and..while I haven't learnt perl, I have a good understanding of how it works. It's been a rock as regards reliability until 5 weeks ago. The site crashed out. couldn't find the config ascii files. I switched to my back up site on the same server. 3 days later that crashed. Same problem. My hosts say they don't help with coding errors. It's not a coding error. I can restore the site. Same files. I just delete and reset the location files and config. It works for a few days then crashes. I think the problem is the time stamps. When I update a group file the timestamp time is two minutes behind the update time. I've asked the server provider to look at the time on the server and make sure it's correct. Am I barking up the wrong tree or could it be that there are two different clocks (so to speak) at the server end? and if there were and they were out of sync would this explain why, at my end, it randomly stops being able to find the files?

Replies are listed 'Best First'.
Re: Timestamps query
by MidLifeXis (Monsignor) on Oct 18, 2012 at 12:53 UTC

    In addition to a possibility of the config files being stored in a temporary directory (unable to substantiate it without code), there is also the possibility that some code path in your code allows the configuration files to be removed by some invocation of your code.

    I would do the following things (for starters):

    • Check for any security advisories on your software, and apply fixes for those issues. This is extremely important for any public-facing server, not just web servers.
    • check your configuration files and settings to ensure that you are not storing them in an area that gets periodically cleaned.
    • Check to see that there are no external cleanup (or other) processes that can delete these files (see at, cron, windows scheduled tasks, and so on). I once saw a situation where important files on a shared filesystem were removed by a find process on another machine, because of a '-follow' flag and a symlink in a /tmp directory.

    Additionally, you may want to get familiar with your code and learn how to (or contract with someone to) do a code audit on your system. There are monks around who make themselves available for consulting of this type.

    --MidLifeXis

Re: Timestamps query
by Anonymous Monk on Oct 18, 2012 at 02:08 UTC

    Am I barking up the wrong tree or could it be that there are two different clocks (so to speak) at the server end?

    Very unlikely, but not inconceivable ( virtual machines , rogue time server, broken time daemons ... )

    and if there were and they were out of sync would this explain why, at my end, it randomly stops being able to find the files?

    No. If it is too old, it will still be there. Chances are you have a coding error -- or doing something bizzare like keeping the config file in a temp directory which gets emptied every 2-3 days.

Re: Timestamps query
by Anonymous Monk on Oct 20, 2012 at 04:31 UTC

    Thank you both.
    I should have mentioned that it's a pretty old site and has been working for nearly 10 years.
    Config not in a temp directory.
    Possibility of a new vulnerability? I guess but it's no longer supported.
    No files get deleted. They are where they always have been.

    It has a setup interface accessed by deleting the location.pl file.
    To restart I merely delete the timestamps and recreate the location.pl.
    It's not the location file that's the problem as it times out while looking in the correct folder for a file that is there and does have the correct permissions.

    Timestamps are the only files that get renewed.
    To be honest, the entire site is being retired in a couple of weeks but it bugs me if I don't have logical explanations for things.

    I was sure it was at the server end (ref two different sites having the same problem) but a new vulnerability is a real possibility. Thank You Both!!!