We have a on-prem jira install, with inbound mail using IMAP connected to an Exchange mail infrastructure, and we use JEMH as the mail handler.
So last night was the Daylight saving time switchover in the US. We turned clocks back an hour.
At a little after 1:00AM I got a call from one of our users, who noticed that a mail that was sent to our jira mailbox didnt create an issue in jira. I checked the mailbox, the mail was in there. I ran all the usual tests from jira, it was able to connect to the mail server fine, etc. But it would not pick up the mail that was in there. No errors in the logs, and there was nothing unusual about the mail that would haven been an issue. It had been working fine earlier in the day.
We have a Jira Service Desk instance on the same server, so I tested a mail to there as well and it was picked up.
I restarted Jira, no change. I eventually rebooted the server, but I happened to notice that around the time of the reboot, the time rolled back the hour, (from 2:00 back to 1:00 AM.)
After the reboot of the server, the mails were picked up fine.
Now I know that the reboot of the server could have fixed some oddball underlying condition, but i can't help wondering if there is something about falling back an hour that would have caused jira to stop reading from the imap mailbox, or processing mail.
Anyone else notice oddities around mail handling on daylight savings time?
I wonder why you are changing the server time when the clocks change and not allowing Jira to adjust to the local settings of your users? In the past I have had lots of servers get very confused when they are set to change to accomodate daylight saving time. Especially with regard to SLAs where an open ticket over such a change can suddenly lose/gain an hour of time.
I'm using ntp to keep time on the servers. It automatically makes the adjustment so that the local time on the server appears correct. (or maybe its just the built in time library routines that account for the change using the timezone data) Its not like I was resetting the time on all the machines in our environment by hand. And the internal "localtime" on the servers, which is based on seconds since the unix epoch, didn't change.
Do your servers not report the correct time zone adjusted time?
Not surprisingly I did not expect you to be changing them by hand. I was trying to understand the scenario where you needed to have the server working on the current local time rather than a time such as UTC which does not change.
As I said I have had experience in the past with all sorts of problems with having servers changing time to accomodate daylight saving time and so was interested to hear if you had any similar experience. With Jira Service Desk it well and truly messed up the durations of open tickets across the change. Something which is still not solved to my knowledge.
So in summary I was just interested to hear your perspective on the decision to allow the server to change the time to reflect daylight saving and whether this had caused/solved any issues for you.
If Jira passes an email to JEMH, then it will be processed (or at least it will check if it needs to be processed). If JEMH Auditing is enabled, you can see if any emails were passed to JEMH during the problematic time period. If you do not see any email items listed for that period - Jira did not pass emails to JEMH.
Thanks Mike. Didnt really think it was JEMH, but thought it was worth mentioning. I think its more that Jira didnt pull the mail from the inbox.
Not something I can easily test, and if it wasn't for the 1 automated process that generated the email during that 1 hour window I doubt I would have noticed.
Maybe I'll test again next year :)
Background When you hear the words ‘Release notes’, almost always you think of an unsolicited email from a software vendor. But I am here to tell you that from our data, sending release notes via E...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events