date format error can crash server

  • bhammondCVL

    (@bhammondcvl)


    9 years, 8 months ago

    If a user enters (mistakenly or not) a date in the Begin field that does not conform to the YYYY-MM-DD standard, the date defaults to 1970-01-01. This can cause numerous errors as the plugin struggles to load events.

    This error can be entered without throwing an immediate error. In our case, once entered the dates caused a series of errors that eventually crashed the server. Details are below, if you are interested.

    We use the My Calendar plugin on more than 20 sites, and have for nearly a year, without any serious incidents. But regardless, even if events like this are rare, it would seem easy to avoid them altogether by adding some better validation to the date fields, so that mis-formatted dates are not accepted, or do not default to 1970-01-01.

    When one of our servers crashed recently, we narrowed the problem down to the Linux function “gettimeofday,” which was being executed hundreds of thousands of times per minute. Some other processes or scripts – most likely PHP – were obviously calling this function in an infinite loop.

    Some odd settings in our php.ini exacerbated the problem, and Apache was soon hogging CPU and killing processes to free up swap space. By examining the Apache error log files we were able to determine that the problem existed in a WordPress site using the My Calendar plugin, which had accumulated an error log more the 30GB large, mostly containing errors from my-calendar-output.php.

    We deleted the error log and then dumped the tables associated with the calendar data. There were several calendar events (and associated recurrences) where the start dates were in the years 1970 to 197x. We deleted the events with dates beginning in the 1970s, and all normal functionality returned.

    https://wordpress.org/plugins/my-calendar/

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Joe Dolson

    (@joedolson)

    9 years, 8 months ago

    That sounds very confusing. If My Calendar had a bunch of events with start dates in the 1970s that would not actually make any difference; it’s perfectly capable of scheduling events 40 years ago.

    The situation that can be tricky and cause performance issues is a combination of two factors: an event with an end date different from the start date that is recurring, where the recurrence interval is less than the difference between the two dates. E.g., an event that starts January 1st, 2016 and runs through February 1st, 2016 and repeats weekly. That event will end up overlapping each other and can cause problems. If the start date was in 1970, this could cause significant problems; but it isn’t because of the start date, it’s the combination of dates and an overlapping recurrence.

    Is it possible that this was the case?

    Thread Starter bhammondCVL

    (@bhammondcvl)

    9 years, 8 months ago

    I think that is possible, if I understand you correctly. The problem is not the number of reoccurrences, but a conflict between the reoccurrence interval and the end date. So, following your example of a weekly event beginning Jan 1, the plugin generates reoccurrences for 1/1, 1/8, 1/15, 1/22, 1/29, 1/5, etc… But the end date of 1 Feb is before the last reoccurrence, hence the conflict. Is that right?

    I know that both the My Calendar events that caused our server problems had weekly reoccurrences. In the dumped tables event_recur is W1, and event_repeats is 0; event_end is set to 11/7/16 and 11/21/16, respectively.

    Plugin Author Joe Dolson

    (@joedolson)

    9 years, 8 months ago

    Then yes, that was the problem. My Calendar does raise a warning when that kind of a combination is created, but doesn’t actually modify the values you’ve saved. Unfortunately, the warning is not sufficiently obvious; I’ll work on making those warnings more aggressive, since this really can be a major problem.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘date format error can crash server’ is closed to new replies.