One of the tasks which a Debian / Linux system does, is log-rotations at regular intervals. Some log-rotations take place daily, others weekly, and others monthly.
When log files are rotated, the services that generate them must usually be restarted, although there are a very few daemons which can simply be commanded to reopen their log file. This needs to be done, because even when the name of the log file has been changed (by the log-rotation), the file handle which its process has, still points to the same file. So most generally, the service is also restarted, so that it can open a new log-file, with the name of the old log-file, which was rotated to having a new file-name.
I have two services installed, to which this is relevant today. One of them is my “OpenVPN Server”, and the other is my “Teredo Client”. The Teredo Client was already configured by package maintainers, not to do any log-rotations. But my OpenVPN Server does a log-rotation on a monthly basis.
One of the facts about how my system reacts is in practice, that when my OpenVPN Server does a restart, it also incapacitates my Teredo Client. I am not sure why this happens, but it is completely consistent behavior. It has something to do with how my dual-stack kernel manages its IPv6 addresses.
So today, being July 1, saw a log-rotation to my OpenVPN Server, which also took out my Teredo Client, at the time the monthly log-rotations are supposed to take place, in a 100% predictable manner. I needed to restart the Teredo Client, in order to get my IPv6 address back, by about 14h15 this afternoon. From about 6h00 until 14h15 today, this site had no working IPv6 address.
I apologize for any inconvenience.