• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Issue /usr/local/psa/handlers/spool full of old emails

Frostbolt

Basic Pleskian
I noticed our harddisc was almost full today, and upon investigating I found /usr/local/psa/handlers/spool full of old emails, literally hundreds of thousands.

I found this topic: /usr/local/psa/handlers/spool full of e-mails

It states the issue was resolved in Plesk 12.0 but I'm running Plesk v17.8.11 and the emails aren't getting deleted for us.

Edit: I see I've posted this question in the wrong forum, sorry! Can anyone move it please?
 
Last edited:
Are you seeing any other errors on the server, anything in the /var/log/messages (CentOS) a.k.a. /var/log/syslog (Debian and derivatives)?

There might be an error somewhere in the mail path that causes these files to linger instead of being removed.
 
Yeah, I'm seeing a lot of:

Nov 12 05:04:58 _ xinetd[1298]: START: ftp pid=32586 from=::ffff:1.56.233.97
Nov 12 05:04:59 _ xinetd[1298]: EXIT: ftp status=0 pid=32586 duration=1(sec)
Nov 12 05:04:59 _ xinetd[1298]: START: ftp pid=32590 from=::ffff:1.56.233.97
Nov 12 05:05:02 _ xinetd[1298]: EXIT: ftp status=0 pid=32590 duration=3(sec)

and

Nov 12 05:05:02 _ kernel: show_signal_msg: 80 callbacks suppressed
Nov 12 05:05:02 _ kernel: dk_sign[32638]: segfault at 8 ip 00000000004028d3 sp 00007fff83988200 error 4 in dk_sign[400000+e000]
Nov 12 05:05:02 _ kernel: dk_sign[32647]: segfault at 8 ip 00000000004028d3 sp 00007fff40c7d510 error 4 in dk_sign[400000+e000]
Nov 12 05:05:02 _ kernel: dk_sign[32656]: segfault at 8 ip 00000000004028d3 sp 00007fff7ed42540 error 4 in dk_sign[400000+e000]
Nov 12 05:05:02 _ kernel: dk_sign[32665]: segfault at 8 ip 00000000004028d3 sp 00007fff01d18fb0 error 4 in dk_sign[400000+e000]
 
The xinetd entries are normal, or, better said, they might mean that someone is brute forcing the FTP, but they aren't connected to this issue. The segmentation faults are directly connected, though.

They basically mean that DKIM is crashing and leaving those messages behind. The issue is likely different than the one I've linked above (PPPM-10547), so I'd advise you to fill in a separate bug report.
 
Back
Top