Certainly yes. On our moodle cluster, all the webservers try and run the cronjobs, and the first one to get the "lock" gets to run it. This ensures a pretty fair distribution of load, as all servers are on NTP, so the least loaded one has the most chance to be early to the lock.
Initially, I had messed up the commandline args for dotlockfile, and more than one server was running cron.php -- we immediately got reports of users getting duplicate forum posts mailouts about 50% of the time. I didn't read the Moodle code, as it was my locking that was buggy, but I think there's a race condition with a pretty wide window.
Now, I don't think it's particularly problematic, and I think it'd be extremely hard to prevent race conditions across all the modules. cron.php could help prevent this problem by incorporating a locking mechanism. There are some tricky points over stale locks if cron.php dies -- I still think it's better to do it from a shell wrapper to cron.php.
In the end, I think whoever is running a cluster should know how to manage their cronjobs to avoid duplication/overlaps.
General developer forum
The last time cron.php was run...
This discussion has been locked because a year has elapsed since the last post. Please start a new discussion topic.