No, you shouldn’t. The cases I’ve seen on my Omnia since 3.11 were all caused by this (easy enough to check log for the error message at the point the PID changes). But this particular problem should always be just a split-second service disruption, i.e. nothing too noticeable.
hmm - I have multiple PIDs and no entry in logs
root@omnia:/mnt/var/kresd/tty# ls -la
total 0
drwxr-x--- 1 root root 100 Dec 16 14:34 .
drwxr-xr-x 1 root root 56 Aug 7 11:47 ..
srwxr-xr-x 1 root root 0 Nov 16 00:09 12243
srwxr-xr-x 1 root root 0 Nov 17 16:31 13491
srwxr-xr-x 1 root root 0 Dec 16 14:34 14546
srwxr-xr-x 1 root root 0 Nov 21 03:38 24266
srwxr-xr-x 1 root root 0 Nov 27 00:08 24334
srwxr-xr-x 1 root root 0 Nov 1 04:40 30642
srwxr-xr-x 1 root root 0 Dec 12 23:59 3525
srwxr-xr-x 1 root root 0 Sep 22 14:43 4058
srwxr-xr-x 1 root root 0 Sep 20 20:31 4236
srwxr-xr-x 1 root root 0 Oct 24 22:45 4806
srwxr-xr-x 1 root root 0 Nov 26 00:06 4922
I’m keeping all the logs on SSD disk so example of log from 27 Nov as the PID was created shortly after midnight:
2018-11-27T00:00:02+01:00 2018-11-27T00:00:02+01:00 omnia user info nikola[]: (v42) recognized WAN interfaces: eth1, lo
2018-11-27T00:00:29+01:00 2018-11-27T00:00:29+01:00 omnia user info nikola[]: (v42) Establishing connection took 10.317584 seconds
2018-11-27T00:00:29+01:00 2018-11-27T00:00:29+01:00 omnia user info nikola[]: (v42) Logrotate took 0.005695 seconds
2018-11-27T00:00:29+01:00 2018-11-27T00:00:29+01:00 omnia user info nikola[]: (v42) Syslog parsing took 0.000087 seconds
2018-11-27T00:00:30+01:00 2018-11-27T00:00:30+01:00 omnia user info nikola[]: (v42) Session init took 0.896588 seconds
2018-11-27T00:00:30+01:00 2018-11-27T00:00:30+01:00 omnia user info nikola[]: (v42) Records parsed: 0
2018-11-27T00:00:30+01:00 2018-11-27T00:00:30+01:00 omnia user info nikola[]: (v42) Records after filtering: 0
2018-11-27T00:00:30+01:00 2018-11-27T00:00:30+01:00 omnia user info nikola[]: (v42) Records filtering took 0.001431 seconds
2018-11-27T00:00:31+01:00 2018-11-27T00:00:31+01:00 omnia user info nikola[]: (v42) {u'msg': u'Server was notified that client has no data to send.'}
2018-11-27T00:00:31+01:00 2018-11-27T00:00:31+01:00 omnia user info nikola[]: (v42) Sending records took 0.413394 seconds
2018-11-27T00:15:01+01:00 2018-11-27T00:15:01+01:00 omnia user info nikola[]: (v42) recognized WAN interfaces: eth1, lo
2018-11-27T00:15:02+01:00 2018-11-27T00:15:02+01:00 omnia user info nikola[]: (v42) Establishing connection took 0.787665 seconds
2018-11-27T00:15:02+01:00 2018-11-27T00:15:02+01:00 omnia user info nikola[]: (v42) Logrotate took 0.006323 seconds
2018-11-27T00:15:02+01:00 2018-11-27T00:15:02+01:00 omnia user info nikola[]: (v42) Syslog parsing took 0.000070 seconds
2018-11-27T00:15:03+01:00 2018-11-27T00:15:03+01:00 omnia user info nikola[]: (v42) Session init took 1.018696 seconds
As reported above I also gave up on DNS over TLS (slow Luci).
Still, in my case, I’m experiencing that the resolving of websites clutters up after about 24 hours. A restart of the resolver does the trick.
Is there a downgrade path to 3.10.8 (after a 3.11 medkit)? I searched for previous medkits but did not find them.
It seems to be solved by update to 3.11.1 
@Jack_Konings I have copy of medkit with 3.10.8 version if you want but I think you should use latest version instead.
Just pm me and I can post it somewhere or maybe via torrent.
Thanks for your offer.
The link n8v8r gave (https://repo.turris.cz/archive/omnia/) holds all released medkits.
I assume the “Errno 32” and “Errno104” are related to wrong DoT-implementation (cloudflare) introduced with 3.11: the error does not appear anymore, when I stop using DNS over TLS (cloudflare).
I moved to 3.11.1 and will report there if the error occurs again.
if you had configured DoT manually before 3.11, you need to remove that setup before trying to use the 3.11 method. See https://doc.turris.cz/doc/en/public/dns_knot_misc
I already stated to have that done. (see above…)
It seems I found the reason for repeated entries Errno 32 and Errno104: I had by mystake entered invalid static dhcp-clients (one doublette and another one with wrong IP). After cleanup the errormessage don’t appear anymore.
Hopefully my DNS dropouts are gone, too!
I’m afraid the DNS problems are unlikely to be related (except for resolving the DHCP-determined names).
Ok, understood.
But how should I troubleshoot that? I have at least an indicator (1 day without dropouts when disabling DoT) why it happens, but don’t know how to proceed further on that.
As a partial coincidence, I made a workaround that effectively lowers priority of the GUI-generated forwarding rule, so that your additional rules shouldn’t get “shadowed” by them anymore.