Issue Messages from a Plesk component appearing on root ssh console

[TimReeves]

Server operating system version

Debian 12

Plesk version and microupdate number

18.0.66 #1

I've just installed a high-end VPS rented from Strato (Germany), using their "Debian 12 + Plesk" image. It's the latest Plesk 18.0.66.
The image had two problems of note:

1. BIND was not selected as a Plesk component, and I didn't add it manually - never needed it before. Turns out, without BIND this combination of OS and Plesk has huge problems with the internet adapter - can't get the IPv6 address, can't repair it, can't migrate (IPv6 not working), can't instatntiate the templates dealing with webservers - really massive problems. Installed BIND (as a last resort) - everything then fine.
2. Brotli Support in Nginx was not activated, although it should be by default. That's easily rectified - and needed to be as my Configs use brotli_types.

Why I'm writing is that whenever I'm logged in to an SSH root session, sometimes messages like the following are written to my console:

2025 Jan 8 10:09:47 mail 127.0.0.1 [57885] /var/spool/drweb/spool/drweb.tmp.ikIhSU - archive MAIL
2025 Jan 8 10:09:47 mail 127.0.0.1 [57885] >/var/spool/drweb/spool/drweb.tmp.ikIhSU/1.part - Ok
2025 Jan 8 10:09:47 mail 127.0.0.1 [57885] >/var/spool/drweb/spool/drweb.tmp.ikIhSU/2.reexport - Ok
2025 Jan 8 10:09:47 mail 127.0.0.1 [57885] /var/spool/drweb/spool/drweb.tmp.ikIhSU - Ok

Never had that before, either. How on earth does that happen, and how can I fix it, it's annoying.

Thanks, Tim

 

[TimReeves]

After writing I found the thread DRWeb logging to root console and I edited /etc/drweb/drweb32.ini to OutputMode = Quiet and erstarted DrWeb. This has not solved the problem )-:

 

[trialotto]

@TimReeves

I think that you should have a look at /etc/drweb/drweb32.ini and make sure that OutputMode = Quiet

Also have a look at this : DRWeb logging to console

If it is not OutputMode settings, then there might be some other culprits.

Also, the recommendation to reinstall Plesk Antivirus might be a good starting point.

In fact, it might resolve some issues and even the drweb-logging-to-console issue .... but it certainly will narrow down the potential causes of the matter at hand.

Kind regards.....

 

[TimReeves]

Hi trialotto,
nice to hear from you again after yome years!
See above - I did just try what you suggested, but to no avail.
I've now looked at drweb_handler.conf which contains this section:

###################
# Logging section #
###################
[Logging]
# Logging detalization ( Quiet, Errors, Alerts, Info, Verbose, Debug )
Level = Info

# Facility used for logging to syslog ( Daemon, Mail, Local0..7 )
SyslogFacility = Mail

# Priority used for logging to syslog ( Debug, Info, Notice, Alert )
SyslogPriority = Info

I suspect Level = Quiet might solve things; but I don't understand what "SyslogFacility = Mail" actually means - surely not that some mail program should write into syslog? A guru explanation would be very welcome before I alter something in that area that I don't understand!

Cheers, Tim

BTW At Plesk 18.0.66 I would have hoped that we don't have such problems )-:

 

[TimReeves]

I just checked the same file at a Debian 11 server with Plesk (just updated to) 18.0.66, the logging section in drweb_handler.conf is identical, the file is unchanged since Apr 18 2023 (but no problem there).

 

[trialotto]

I just checked the same file at a Debian 11 server with Plesk (just updated to) 18.0.66, the logging section in drweb_handler.conf is identical, the file is unchanged since Apr 18 2023 (but no problem there).

@TimReeves,

The config settings in drweb_handler.conf are or should be barely relevant.

The config settings in drweb32.ini should be relevant.

Can you check that you have in drweb32.ini the following entries

1 - LogFileName = syslog
2 - SyslogFacility = Daemon

and please note that SyslogFacility should have a double entry.

Also, can you check that you have syslog service running?

By the way, a remarkable note, I have checked on an Ubuntu 20.04 server ....... and OutputMode is simply set to Terminal .... without issues. Odd? Yes! It should not be the case that some config setting is simply ignored - what is the point of that config variable then?

 

[TimReeves]

I think I've found the root problem:

Where is some os logs in Debian 12

It seems that some of the system log files (/var/log/syslog, /var/log/auth.log, /var/log/kern.log, ...) have been removed in the latest version of Debian, Debian Bookworm. What should be done to ac...

serverfault.com

"In Debian 12, the traditional syslog system has been replaced with systemd-journald. This means that the old log files like syslog, messages, auth.log are no longer used. Instead, all system logs are now stored in a centralized journal, which is accessible using the journalctl command."
I'll be looking at this after a nap (I'm 70). This could have major repercussions for my server safety, of which fail2ban reading such (old) logs is a major part.

 

[TimReeves]

1 - LogFileName = syslog
2 - SyslogFacility = Daemon

OK, there are two sections in /etc/drweb, [Daemon] and [Updater], and both have exactly those entries. On a server with Debian 11 there is also "OutputMode = Terminal", but I never saw any console output, so I agree that it seems that the option does nothing.

In the meantime, I've had a good look at the system - it's a high-end VPS hosted by Strato in Germany, on which I installed their image "Debian 12 + Plesk". But the state of the software in general was poor: no housekeeping was happening since the packages anacron and logrotate were both not installed. Worse, I could hardly configure Plesk - there were obstruse problems like not being able to instantiate templates for Apache and Nginx, and not being able to reread the IP addresses, saying that there was no network card. Those problems went away when I installed the BIND package in Plesk Updater. That fazed me a bit - I've never needed BIND before, why now? Does that have to do with Debian 12 - or some goofed-up software config by Strato?

Anyway, perhaps someone thought they don't need anacron and logrotate as now "all is done with journald". Except without the traditional logs, fail2ban could not work, so I then checked them out: And yes, those used by (Plesk) Fail2Ban are there. But rsyslog is not. Instead, Strato has opted for syslog-ng. Perhaps this might cause the console logging problem? I checked its config but don't see anything suspicious. What I did confirm is that the messages from drweb which are shown on the console are also written to syslog.

So next, I wanted to deinstall syslog-ng and install rsyslog, to see if that might help. But:

The following packages were automatically installed and are no longer required:
drweb-bases drweb-common drweb-daemon drweb-libs drweb-libs32 drweb-updater libc6-i386
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
fail2ban plesk-fail2ban-configurator plesk-mail-pc-driver psa-drweb-configurator psa-spamassassin syslog-ng-core

Obviously, I refused to continue; and my problem is still unsolved. I see three possible candidates:

1. drwebd (since most other programms, but not all, log normally to syslog, without duplication to console)
2. syslog-ng - perhaps it does something a bit differently to rsyslog
3. journald - do I understand it right that all syslog-style messages from binary programs now run over journald?
   Can anyone tell me how syslog-ng / rsyslog get their messages when the system is based on journald?

Can anyone tell me how to successfully switch from syslog-ng to rsyslog?

Thanks for any help,
Tim

 

[JVG]

Hi,

you might take a look at this thread: Issue - fatal: Timeout before authentication for [IP-ADDRESS] port 44745

It wasn't specifically about drweb messages but other related OS report messages being shown in the prompt of servers with Debian 12.

 

[TimReeves]

@JVG Many many thanks for this tip!
I'm seldom logged on to a console (my automated scripts tell me if anything needs doing, and an external Zabbix monitoring).
So I chose the hammer method:
1. Comment out the line in syslog-ng.conf: log { source(s_src); filter(f_crit); destination(d_console); };
2. systemctl restart syslog-ng.service
Now, blessed peace on the console!
Tim