Mail Server Mail Relaxer: Hibernation while running DSM Mail Server and Mail Station

[Basalt]

I didn't upgrade to 4.3 yet.

If you disable Mail Server and -Station with Package Center, does your Syno hibernate properly then?
I guess this "MailScanner" thing (1st and 3rd line) is related to the Spam Filter option? (which I don't use). What if you disable it?

/Erik

 

[MC_Bergsteiger]

Hi Erik,

well; you better don't upgrade to the latest version if you want to stay out of trouble...

I have several other strange things going on since the upgrade, which deal with "modprobe" calls. I discuess them on the English forum:
http://forum.synology.com/enu/viewtopic.php?f=83&t=73277

So, stopping all mail services manually would not be sufficient for hibernation. I am also in contact with Synology support regarding these aspects.

Regarding "Mail Scanner" I already handed in a feature request that these processes should not run at all, when no spam filter option is set, like on my diskstation. (Many other users already complained that mail scanner consumes a lot of memory, although they did not activate it.)

So, I guess we should all wait for the next update(s), before we try to resolve those issues.

Cheers,

Matthias

 

[Karle]

Hi !

I would also be interested in the mail relaxer.

Does anyone use this tool with DSM 4.3?

Regards

Karl

 

[Basalt]

well; you better don't upgrade to the latest version if you want to stay out of trouble...
[...]
So, I guess we should all wait for the next update(s), before we try to resolve those issues.

I already started thinking that I am become paranoid, not upgrading to 4.3, did not see many upgrade problems so far.
You are sure this all started with 4.3 ?


/Erik

 

[MC_Bergsteiger]

Actually, some of the issues (like growing logfiles due to modprobe calls and changed logfile rotation) startet with updating the packages for DSM 4.3 compatibility before installing DSM 4.3 itself:

Information System 2013/08/27 20:01:35 admin Package [Antivirus Essential] has been successfully repaired.
Error System 2013/08/27 18:54:01 SYSTEM Failed to update package [Mail Server].
Information System 2013/08/27 18:53:49 SYSTEM Package [Perl] has been successfully repaired.
Information System 2013/08/27 18:53:25 SYSTEM Package [Perl] has been successfully uninstalled.
Information System 2013/08/27 18:53:07 SYSTEM Windows file service was started.
Information System 2013/08/27 18:52:54 SYSTEM Local UPS was plugged in.
Error System 2013/08/27 18:52:24 SYSTEM Encryption Share [@1] type change to normal, please contact Synology support!
Information System 2013/08/27 18:52:20 SYSTEM System started to boot up.
Information System 2013/08/27 18:46:22 SYSTEM Windows file service was stopped.
Information System 2013/08/27 17:19:49 admin Package [Cloud Station] has been successfully updated.
Information System 2013/08/27 17:18:17 admin Package [Video Station] has been successfully updated.
Information System 2013/08/27 17:16:25 admin Package [Photo Station] has been successfully updated.
Information System 2013/08/27 17:14:54 admin Package [Medienserver] has been successfully updated.
Information System 2013/08/27 17:10:55 admin Package [Mail Server] has been successfully updated.
Information System 2013/08/27 17:09:46 admin Package [Download Station] has been successfully updated.
Information System 2013/08/27 17:09:05 admin Package [DNS Server] has been successfully updated.
Information System 2013/08/27 17:08:01 admin Package [Audio Station] has been successfully updated.
Information System 2013/08/27 16:58:55 admin Package [DHCP Server] has been successfully updated.

Synology support admitted in the meantime that there are some issues with DLLs in audio station which might cause some of my modprobe calls.

Maybe, some problems are CPU-related?
I have an Intel-Atom-based rackstation (RS812+). Probably, the DSM-4.3-code and hardware device drivers for Marvel- or other CPU-based diskstations does not cause the issues I am facing?

Cheers,

Matthias

 

[MC_Bergsteiger]

Things are getting better:

At least, since yesterday's update of Mail Server to version 1.2-0130 there are no "Mail Scanner" processes anymore, if you do not check the "Spam" or "Anti-Virus" options.

 

[MC_Bergsteiger]

For your information:

I found out that those frequent "pidof" calls are caused by the Mail Relaxer script.

Creating the following script as a replacement for "pidof":

#!/bin/sh
for arg in "$*"
do
  echo "/bin/pidof $arg" >>/var/log/pidof.out
  ps|grep $PPID >>/var/log/pidof.out
done
exit 0

...returns, for example, the following output:

/bin/pidof fetchmail
14779 root      3200 S    grep 27143
27143 root      3196 S    /bin/sh /tmp/relax_mailprocd manual_start
/bin/pidof imap
14783 root      3200 S    grep 27143
27143 root      3196 S    /bin/sh /tmp/relax_mailprocd manual_start
/bin/pidof dovecot-auth
14787 root      3200 S    grep 27143
27143 root      3196 S    /bin/sh /tmp/relax_mailprocd manual_start

 

[Basalt]

Indeed Mail Relaxer calls pidof every 3 seconds, sorry I didn't think about that earlier
Until DSM 4.2, pidof was possible during hibernation.
Only alternative I know of is using `ps`, but that appeared to cause hibernation issues with DSM 4.2

After your latest Mail Server update, did you check if your Syno hibernates now?

I assume you have "syno_hibernate_debug_tool" enabled, this could on itself prevent hibernation I am told.
Did you retest with the tool disabled again?

/Erik

 

[MC_Bergsteiger]

Dear Erik,

unfortunately, the Mail Server update does not help with regards to hibernation.

Last night I stopped Mail Server, Mail Station and Mail Relaxer packages manually (as well as Audio Station). I am not sure, if my rackstation went into hibernation between 00:16 AM and 6:12 AM as the debug tool seems to have changed in DSM 4.3, too:

Oct 10 00:16:03 kernel: [233264.058652] [/.htaccess] opened by pid 2492 [u:(/usr/syno/apache/bin/httpd), comm:(httpd)]
Oct 10 06:12:40 kernel: [254651.978585] sd 3:0:0:0:  sda: cmd run - tag ff - 28 00 00 90 3e e8, pid:11041, comm:kworker/2:1
Oct 10 06:12:40 kernel: [254651.987502] sd 2:0:0:0:  sdb: cmd run - tag ff - 28 00 00 90 3e e8, pid:11041, comm:kworker/2:1
Oct 10 06:12:40 kernel: [254652.631051] sd 0:0:0:0:  sdd: cmd run - tag ff - 28 00 00 4b ff 80, pid:8, comm:kworker/1:0
Oct 10 06:12:40 kernel: [254652.613536] [/etc/ld.so.cache] opened by pid 10244 [u:(/sbin/initctl), comm:(initctl)]
Oct 10 06:12:53 kernel: [254665.721531] [/etc/ld.so.cache] opened by pid 10249 [u:(/bin/sh), comm:(dhcpd-script.sh)]

As you can see, I did not get the message that the harddisks woke up from hibernation. But I guess that "sda: cmd run" is exactly that.

If I issue for manual hibernation of harddisk D:

hdparm -y /dev/sdd

... i also get:

Oct 10 07:23:39 kernel: [258909.643123] sd 0:0:0:0:  sdd: cmd run - tag ff - 35 00 00 00 00 00, pid:1094, comm:md0_raid1

... as I expect the harddisk to wake up from hibernation immediately after issueing the command, due to normal operation.

I will investigate the LED status next night, in order to find out about the hibernation status.

Cheers,

Matthias

 

[MC_Bergsteiger]

Update: My assumption was right.
The diskstation goes into hibernation, if I stop all mail services manually.
"...sda: cmd run..." indicates, that it woke up from hibernation, if I set "syno_hibernate_debug_tool --enable 1"

 

[Basalt]

If you set the hibernation to 10 minutes, you don't have to wait the entire night ;-)
For some reason, first time (after startup? after installation?) Mail Relaxer takes much more time (hours?) before it stops the relevant processes. So for that reasons you may have to wait somewhat longer.

Reading back in this topic, I see that you had it working previously.
Some random ideas:

1. Initially something went wrong in your update. Why? Was this fully resolved later on? ("SYSTEM Failed to update package [Mail Server]", "Error System 2013/08/27 18:52:24 SYSTEM Encryption Share [@1] type change to normal, please contact Synology support!")
   
2. Did you reboot your Syno and try again?
3. I know about changes and complaints with the Firewall of DSM 4.3, you could check your current DSM firewall settings.
4. Also, in your router you may have mail related port forward rules that you don't need (e.g. port 25) and could cause a wakeup by an external access attempt.
5. Does your Syno go hibernating when disconnected from the LAN or internet?
6. Do you have smartphones, tablets, laptops, etc that could keep your Syno awake?
7. I have heared about Android that keeps IMAP open all the time, but then Mail Relaxer would not stop the mail services.
8. What mail related processes do you see when your Syno is awake?

Hope this could bring you a little step further...

Erik.

 

[MC_Bergsteiger]

Dear Erik,

thanks for your feedback. First: with DSM 4.2 everything worked fine, including your Mail Relaxer and hibernation during night times. The trouble started with updating some packages and DSM to 4.3.

If you set the hibernation to 10 minutes, you don't have to wait the entire night ;-)

As it seems, my logfile caused a misunderstanding: I did not wait the entire night for hibernation. I woke up at 5 AM for some other reason and realized that I forgot to stop the mail packages, manually, when I went to bed. So I stopped them at about 5 AM. The diskstation went into hibernation about 10 minutes later and woke up again at about 6 AM when I accessed the diskstation again. So it worked "as designed".

Some random ideas:
Initially something went wrong in your update. Why? Was this fully resolved later on? ("SYSTEM Failed to update package [Mail Server]",

After I updated the "Anti Virus" package and "repaired" the "Perl" package everything seemed to be OK. By the way: some other log files inconsistently claim that "Mail Server" was updated properly. Additionaly, in the mean time I updated Mail Server to the next version without problems. So, I hope there is nothing wrong anymore.

"Error System 2013/08/27 18:52:24 SYSTEM Encryption Share [@1] type change to normal, please contact Synology support!")

This is caused by a symbolik link I use for an encrypted external USB hard disk which I use for disaster recovery purposes. Hence, the USB device is not attached to the diskstation, usually. This causes the error message during boot time. I guess, this should not cause any trouble with regards to hibernation.

Did you reboot your Syno and try again?

Yes, I rebooted several times. The updates to 4.3-3776-1 and 4.3-3776-2 forced a reboot. But I also rebooted in order to be sure that all mail process will be stopped and restartet. Once, I rebooted to make sure that less "Mail Scanner" processes will be started.

I know about changes and complaints with the Firewall of DSM 4.3, you could check your current DSM firewall settings.

Everything seems to be fine with my firewall.

Also, in your router you may have mail related port forward rules that you don't need (e.g. port 25) and could cause a wakeup by an external access attempt.

I have limited port forwarding to only those ports absolutely necessary. Additionally, I changed some well-known ports to private ports for external access. As a result, I have very very rare login-attempts form external unknown users, which are blocked by the diskstation after 3 failed login attempts.

Does your Syno go hibernating when disconnected from the LAN or internet?

Well, I could try this again, but I don't think that prevented hibernation is caused by network accesses. The logfile only lists "modprobe" and "pidof" calls during the night when "Audio Station" and mail packages are running. Additionally, there are no clients running during the night.

Do you have smartphones, tablets, laptops, etc that could keep your Syno awake?
I have heared about Android that keeps IMAP open all the time, but then Mail Relaxer would not stop the mail services.

In fact, some months ago I realized that my IPhone is accessing my router via WLAN about once per minute although it is not used during the night. As my diskstation is also providing DHCP services this woke it up frequently. In consequence, I switch off the WLAN interface of my router during the night. So, there should also be no trouble coming from mobile devices anymore.

Additionally, I realized that the frequent "pidof" calls are occuring even if Mail Relaxer already stopped all mail services. In this excert of the logfile you see many "pidof" calls before the mail services are restarted by Mail Relaxer. So, they must have been stopped before.

Oct  7 06:26:57 kernel: [395181.940636] [/etc/ld.so.cache] opened by pid 32372 [u:(pidof), comm:(pidof)]
Oct  7 06:27:00 kernel: [395184.979352] [/etc/ld.so.cache] opened by pid 32376 [u:(pidof), comm:(pidof)]
Oct  7 06:27:03 kernel: [395188.018069] [/etc/ld.so.cache] opened by pid 32380 [u:(pidof), comm:(pidof)]
Oct  7 06:27:06 kernel: [395191.056797] [/etc/ld.so.cache] opened by pid 32384 [u:(pidof), comm:(pidof)]
Oct  7 06:27:09 kernel: [395194.095507] [/etc/ld.so.cache] opened by pid 32388 [u:(pidof), comm:(pidof)]
Oct  7 06:27:12 kernel: [395197.134222] [/etc/ld.so.cache] opened by pid 32392 [u:(pidof), comm:(pidof)]
Oct  7 06:27:15 kernel: [395200.172937] [/etc/ld.so.cache] opened by pid 32396 [u:(pidof), comm:(pidof)]
Oct  7 06:27:18 kernel: [395203.210660] [/etc/ld.so.cache] opened by pid 32400 [u:(pidof), comm:(pidof)]
Oct  7 06:27:21 kernel: [395206.249378] [/etc/ld.so.cache] opened by pid 32404 [u:(pidof), comm:(pidof)]
Oct  7 06:27:24 kernel: [395209.288080] [/etc/ld.so.cache] opened by pid 32408 [u:(pidof), comm:(pidof)]
Oct  7 06:27:27 kernel: [395212.326784] [/etc/ld.so.cache] opened by pid 32412 [u:(pidof), comm:(pidof)]
Oct  7 06:27:30 kernel: [395215.365508] [/etc/ld.so.cache] opened by pid 32416 [u:(pidof), comm:(pidof)]
Oct  7 06:27:33 kernel: [395218.403246] [/etc/ld.so.cache] opened by pid 32420 [u:(pidof), comm:(pidof)]
Oct  7 06:27:36 relax: INFO: Mail clients active, restarting mail processes

What mail related processes do you see when your Syno is awake?

To my understanding the running mail processes seem to be reasonable:

 6225 User1     4260 S    /var/packages/MailStation/target/bin/fetchmail -f /var/packages/MailStation/target/roundcubemail/ext/user1_fetch --pidfile /var/serv
 6230 User2    4260 S    /var/packages/MailStation/target/bin/fetchmail -f /var/packages/MailStation/target/roundcubemail/ext/user2_fetch --pidfile /var/ser
 6301 root     12560 S    /var/packages/MailServer/target/libexec/master
14021 root      8580 S    /var/packages/MailServer/target/sbin/syno_mailloggerd
14024 root      1796 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
14026 root      2160 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
14027 root      1796 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
14028 root      1796 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
14029 root      1796 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
14111 root     12316 S    /var/packages/MailServer/target/sbin/dovecot
14116 root      8588 S    /var/packages/MailServer/target/sbin/syno_mailserverd
15138 root      3196 S    /bin/sh /tmp/relax_mailprocd manual_start

Hope this could bring you a little step further...

Thanks again for your help. I heared that Synology has Update 3 for DSM 4.3 in the pipeline and this is what I am looking forward to, at the moment...

Cheers,


Matthias

 

[Basalt]

Ok, so your software installation and network environment are fine.
By design, Mail Relaxer calls pidof every 3 secs, always. Afaik this does not keep the Syno awake.
EDIT: next 2 lines were incorrect, see post below
In the shown ps output I see some mail processes (syno_mail*d) that are new to me, possibly they prevent hibernation?
I will dig into this after Upgrading to 4.3, maybe in a few weeks time.
/Erik

 

[Basalt]

Sorry, nothing new in your running mail processes after all.
See various ps outputs from my Syno:

Basalt> ps|grep ail
 1635 mailusr  11752 S    imap
 1650 mailusr   4256 S    /var/packages/MailStation/target/bin/fetchmail -f /var/packages/MailStation/target/roundcubemail/ext/mailusr_fetch --pidfile /var/services/homes/mailusr/.Maildir/fetchmail.pid --idfile /var/servic
 1721 root     11896 S    /var/packages/MailServer/target/libexec/master
 1923 mailusr  11688 S    imap
 1950 mailusr  10684 S    imap
 1952 mailusr  10844 S    imap
 1957 mailusr  10696 S    imap
 1959 mailusr  10708 S    imap
 3237 root      2544 S    grep ail
 9992 root      2540 S    /bin/sh /tmp/relax_mailprocd boot_start
10411 root      8452 S    /var/packages/MailServer/target/sbin/syno_mailloggerd
10414 root     73124 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
10416 root     58116 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
10417 root     58116 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
10418 root     46860 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
10419 root     54364 S    /var/packages/MailServer/target/sbin/saslauthd -a pam
10910 root      9992 S    /var/packages/MailServer/target/sbin/dovecot
10914 root      8408 S    /var/packages/MailServer/target/sbin/syno_mailserverd

Basalt> ps|grep dove
 3343 root      2544 S    grep dove
10910 root      9992 S    /var/packages/MailServer/target/sbin/dovecot
10913 root     14136 S    dovecot-auth
10986 dovecot   9924 S    imap-login
10987 dovecot   9924 S    imap-login
10988 dovecot   9924 S    imap-login

Basalt> ps|grep imap
 1635 mailusr  11752 S    imap
 1923 mailusr  11688 S    imap
 1950 mailusr  10684 S    imap
 1952 mailusr  10844 S    imap
 1957 mailusr  10696 S    imap
 1959 mailusr  10708 S    imap
 3377 root      2544 S    grep imap
10986 dovecot   9924 S    imap-login
10987 dovecot   9924 S    imap-login
10988 dovecot   9924 S    imap-login

Additionally:
Getting back on my earlier question:

I assume you have "syno_hibernate_debug_tool" enabled, this could on itself prevent hibernation I am told.
Did you retest with the tool disabled again?

I would recommend switching off the debug tool, reboot your Syno and try again if goes into hibernation.
Be patient, initailly it could take hours before Mail Relaxer stops the mail processes.
If it does finally, you can see it in /var/log/messages.

 

[MC_Bergsteiger]

Hi Erik,

I disabled the "syno_hibernate_debug_tool" and rebooted the system. Mail Relaxer stops the mail services after some time as expected. Unfortunately, the diskstation does not go into hibernation, though.

So, it is not the hibernation tool which prevents hibernation.

Cheers,


Matthias

 

[Basalt]

FWIW: as a first step in migrating to DSM 4.3, I updated all packages to latest version, a.o. Mail Server, now on 1.2-130.
Hibernation still working fine here on my DS412+.

/Erik

EDIT:
Updated from DSM 4.2-3211 to the brand new 4.3-3766-3, no issues during update, and goes nicely into hibernation as before

@Matthias:
Please check if spam or virus scanner is active on your Syno, that could explain why hibernation doesn't work for you (anymore).

 

[MC_Bergsteiger]

Hi Erik,

just to be sure: don't you have those frequent "pidof" calls by Mail Relaxer documented in /var/log/messages when running in hibernation debug mode?

Oct  7 06:26:57 kernel: [395181.940636] [/etc/ld.so.cache] opened by pid 32372 [u:(pidof), comm:(pidof)]
Oct  7 06:27:00 kernel: [395184.979352] [/etc/ld.so.cache] opened by pid 32376 [u:(pidof), comm:(pidof)]
Oct  7 06:27:03 kernel: [395188.018069] [/etc/ld.so.cache] opened by pid 32380 [u:(pidof), comm:(pidof)]
Oct  7 06:27:06 kernel: [395191.056797] [/etc/ld.so.cache] opened by pid 32384 [u:(pidof), comm:(pidof)]
Oct  7 06:27:09 kernel: [395194.095507] [/etc/ld.so.cache] opened by pid 32388 [u:(pidof), comm:(pidof)]
Oct  7 06:27:12 kernel: [395197.134222] [/etc/ld.so.cache] opened by pid 32392 [u:(pidof), comm:(pidof)]
Oct  7 06:27:15 kernel: [395200.172937] [/etc/ld.so.cache] opened by pid 32396 [u:(pidof), comm:(pidof)]

To me it seems that these are the only disk accesses which keep my syno awake.

In the meantime, I un-installed all mail related packages, rebooted and re-installed up from scratch, but still I get the "pidof" calls in the log file and no hibernation at all. No spam or virus scanners are active.

Synology Rackstation 812+
DSM: 4.3-3776-3
Mail Station: 20130529-0061
Mail Server: 1.2-0130

 

[MC_Bergsteiger]

Edit: if I call "pidof imap", "pidof fetchmail" and "pidof dovecot-auth" from the command line, manually, I do not get these accesses of "etc/ld.so.cache" (which does not exist, by the way). So, how can this behaviour be suppressed?

 

[Basalt]

Hi Matthias,

I enabled hibernation debugging and do see the pidof calls as well. My Syno can sleep despite of that (at least, with debugging disabled).
Again, please note that the pidof calls are explicitly made every 3 seconds by the Mail Relaxer tool. It is needed for checking when mail processes can be stopped.

I cannot see something like "ld.so.cache" in my /etc either. It seems to be related with caching of dynamic link libraries.

Only thing I can think of is that on your Syno, another pidof is used than intended. You could try editing the Mail Relaxer daemon script (typically installed in /volume1/@appstore/mail_relaxer/bin) and replace all pidof calls by /bin/pidof.

/Erik

 

[MC_Bergsteiger]

Hi Erik,

thank you for your repsonse. If the "pidof" calls are not the problem, the only thing left in my logfile are the following calls:

Nov  9 02:07:26 kernel: [363898.424715] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 02:17:27 kernel: [364498.396635] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 02:22:27 kernel: [364798.388594] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 02:32:27 kernel: [365398.360527] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 02:37:27 kernel: [365698.352508] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 02:47:27 kernel: [366298.325633] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 02:52:27 kernel: [366598.317691] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 02:57:28 kernel: [366898.309756] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:02:28 kernel: [367198.301818] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:12:28 kernel: [367798.274927] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:17:28 kernel: [368098.266883] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:27:28 kernel: [368698.239819] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:32:28 kernel: [368998.231780] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:37:28 kernel: [369298.223750] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:42:29 kernel: [369598.215725] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:52:29 kernel: [370198.187688] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 03:57:29 kernel: [370498.179655] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 04:07:29 kernel: [371098.152616] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 04:17:29 kernel: [371698.124582] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 04:22:29 kernel: [371998.116559] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 04:32:30 kernel: [372598.088480] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 04:37:30 kernel: [372898.080430] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 04:47:30 kernel: [373498.052359] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 04:57:30 kernel: [374098.024281] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 05:02:30 kernel: [374398.016209] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]
Nov  9 05:12:30 kernel: [374997.989083] [/var/run/dovecot/master.pid] opened by pid 10752 [u:(/var/packages/MailServer/target), comm:(syno_mailserver)]

As the occurences are very frequent, can you resolve the cause for theses accesses to /var/run/dovecot/master.pid and how this can be prevented?

As usual, re-installing and restarting the mail packages and the whole DS did not help, unfortunately.

Cheers,


Matthias