Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: Re: Re: file handling question

by smackdab (Pilgrim)
on Dec 17, 2003 at 07:24 UTC ( #315233=note: print w/ replies, xml ) Need Help??

in reply to Re: Re: file handling question
in thread file handling question


I think that confirms that my choice for IO::AtomicFile is a good one ;-)

The second part, which I can see was a little confusing, is as follows: (I am on win32, but want to be portable)

I have a server process and it often needs to read config files for instructions. I expect the file to always be readable, but one time it wasn't (I think I was in the debugger and maybe viewing the file also, no locking that I am aware of...). Instead of just throwing out the job, I figured I could retry opening the file a few times, maybe sleeping .1 sec in between? Is this just overkill? Curious, if you are manually editing a crontab file in vi and cron runs, what happens? (I don't have unix or cron...just use windows and we don't expect users to edit config files behind our backs ;-)

thanks for any defensive programming ideas !

Comment on Re: Re: Re: file handling question
Re: Re: Re: Re: file handling question
by graff (Chancellor) on Dec 17, 2003 at 17:59 UTC
    Curious, if you are manually editing a crontab file in vi and cron runs, what happens?

    cron is always running -- it's a daemon. When it starts (at boot-up), it looks for crontab files in a specific directory, reads all the ones that are present, and sets "alarm" signals for when the various jobs are supposed to run. The files are organized by user; root always has a crontab file, and it's up to the sysadmin to decide whether other users can have their own crontabs as well.

    There's a specific unix command called "crontab" that you run to view or edit the crontab file; if you say "crontab -e" to edit it, your default editor is invoked on a copy of your existing crontab file (or on a new file, if you never used cron before), and when you exit the editor, the "crontab" utility takes over again -- it replaces the original file with the edited copy, and sends a signal to the cron daemon that will cause cron to re-initialize based on the updated file. If you added a command to your crontab file that is supposed to run at noon every day, and you close the editor 30 seconds after noon, the command won't run till tomorrow.

    Most problems are avoided by keeping crontab files separated by user. Of course, on unix, a single user can be running a number of command-line shells at once, and could try to edit the same crontab file from two separate shells (this is quite possible, e.g. when two or more people, working in different locations, can log in as root); but "crontab -e" uses flock, and will not allow concurrent edits of the file.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://315233]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (5)
As of 2014-10-02 17:25 GMT
Find Nodes?
    Voting Booth?

    What is your favourite meta-syntactic variable name?

    Results (67 votes), past polls