• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

Resolved ERROR: Dr.Web Updater: failed to download files ! return code 105

@trialotto can you please confirm what are the exact errors you encounter when running the /etc/cron.daily/drweb-update and /opt/drweb/update.pl? I am unable to replicate the behavior on a test environment.
@Sebahat.hadzhi

It is probably difficult or even impossible to replicate a specific symptom.

In essence, there are multiple "symptoms" which are very likely to be caused by ONE root cause of the problem.

In addition, the "symptoms" are not consistent over time - in a test environment, I can get different errors per day.

In summary, in order to create STR (steps-to-reproduce), it is best to

1 - assume that there is an issue with DrWeb updates, with the issue TRIGGERED by the (daily) cronjob (read: taking into account that manual updates work),

2 - change the following lines in /etc/cron.daily/drweb-update

"${update_scr}" >$outfile 2>&1
rc=$?

to

"${update_scr}" >$outfile 2>&1
cp $outfile /[testdir]/drweb/
rc=$?

and leave it for a couple of days.

3 - compare the contents of the (copy) of the outfile (which is in format "drweb-update.XXXXXX") with the actual error notification send by mail.


Please note that all of the above will ONLY be a first step to create STR - it is an analysis of the random results from running the (daily) cronjob.

In case that one finds output in the (copy of the) outfile, then one STILL has to run /opt/drweb/update.pl manually and compare results.

In most cases, a non-empty outfile will provide totally different results from a manual run of /opt/drweb/update.pl ..... and therein lies the issue : any (daily) cronjob that executes update.pl should have exactly the same (and consistent) results.


I hope the above helps a bit ..... I cannot provide more feedback yet.


Kind regards.....


PS Plesk still has to investigate why the update.pl script, if run from a new task created in Scheduled Task Manager, does NOT yield issues, whilst the same script, if run from /etc/cron.daily, is actually creating issues that are rather random and odd.
 
Thank you for the update. The initially reported error with 105 error code was reviewed by our engineers and it was determined it is due to connectivity issue with Dr.Web's update servers. Regarding the last reported errors with code 109, the root cause is also usually due to connectivity issues. Could everyone who experiences the 109 errors try applying the following workaround and let us know if the issue still persists afterward?
 
I tried the mentioned workaround yesterday. I added

Code:
81.176.67.172 update.geo.drweb.com

to the hosts file and increased the timeout value to 360. This morning I received this message again:

/etc/cron.daily/drweb-update:
ERROR: Dr.Web Updater: failed to download files !
run-parts: /etc/cron.daily/drweb-update exited with return code 105

When I run

/opt/drweb/update.pl

manually on the system, everything updates fine without any error or warning.
 
I receive the error too since 03.06.2025 on a daily base:

/etc/cron.daily/drweb-update:
ERROR: Dr.Web Updater: failed to download files !
run-parts: /etc/cron.daily/drweb-update exited with return code 105

Manually executing /etc/cron.dailty/drweb-update does work without errors.

1751619161958.png
 
@chris-design , it is still believed the errors result from connectivity issue on Dr.Web's update servers. Can you please try replacing the IP address in the hosts file with another one from the same article?
 
@Sebahat.hadzhi I think the connectivity issue would also be visible in the manual updating process. But this runs through everything very fast. The entire update process just needs a couple of seconds. So I think this is not a connectivity issue.
 
Thank you for the update. I consulted with our team again and the other suggestion than connectivity issue is incorrect license. Hence, please execute the following command and let us know what the output is:

systemctl status drwebd
 
Thank you for the update. I consulted with our team again and the other suggestion than connectivity issue is incorrect license. Hence, please execute the following command and let us know what the output is:
@Sebahat.hadzhi

Output of systemctl status drwebd will not result in abnormalities - at least, it should not be the case.

It is clearly a bug of some kind that is not related to connectivity issues and/or license issues - after all, manual updates should not work if that was the case.

Again, I believe that it simply is something related to the cronjob (or the time at which it is run).

Kind regards....
 
Thank you for the update. The status should return if there are any issues detected with the license. According to internal discussion with our team about this case, it could be correlated to an issue with invalid license. It might be a bug, but since it is not possible to replicate it and it is intermittent, there isn't enough evidence to classify it as such.
 
I am experiencing daily (nightly) messages that DrWeb didn't update, too. And they are on several severs. No license issues here.
 
Thank you for the update. The status should return if there are any issues detected with the license. According to internal discussion with our team about this case, it could be correlated to an issue with invalid license. It might be a bug, but since it is not possible to replicate it and it is intermittent, there isn't enough evidence to classify it as such.
@Sebahat.hadzhi

It is not a license issue, unless Plesk did issue problematic licenses themselves.

The simple proof that it is not a license issue is already present in 2 ways : (a) you cannot replicate it and (b) all manual updates work fine.

Again, it should be wise to focus on the cronjob - it only goes wrong with updates triggered by cronjobs.

Also, to exclude the most strange explanation for these error notifications, please try to verify with DrWeb when they reboot servers - any cronjob triggering an update during intervals in which DrWeb servers are reset / rebooted, that cronjob will also cause issues.

In addition, please do the same verification for the licensing server ..... there is another explanation for the error notifications.

Anyway, a solution should be found for all those DrWeb related error notifications.

Kind regards....
 
Hello everyone,

I've been having the same problem as described by others since June 3.

When investigating cron jobs in Ubuntu/Debian servers, I have seen the same time configuration for the daily cron job several times.
What if the problem is really on the drweb-update server side, since thousands of servers run this cron job script in the exact same time period? Maybe this is causing the problem because the server is being overloaded.

I will test this by changing the time configuration of my daily cron job. I'll check tomorrow to see if the problem still exists, or in a week if it hasn't arisen again.

Best regards!
 
This makes totally sense!

Since the solution mentioned from @Sebahat.hadzhi also recommends to use a different IP address for update.geo.drweb.com, this shouldn't be solved manually from administrators.

The server under

81.176.67.172 update.geo.drweb.com

should balance load to the mentioned alternatives IPs for Dr.Web update servers:

195.133.219.93
213.59.3.178
195.133.219.91
85.10.234.30
195.161.158.50

@Sebahat.hadzhi could this be a possible solution for the issue?
 
@chris-design , essentially this allows you to switch (define) another Dr.Web update server. If the issue is on their end as suspected, changing the destination server should sort it out. If the 81.176.67.172 entry does not produce good results, you may use one of the alternative IPs.
 
If the issue is on their end as suspected, changing the destination server should sort it out.
Randomizing the update time should sort it out too. Mass changing to another server will only perform what essentially looks like a DDoS on that other server.
If Plesk wants to keep using a fixed update time, Plesk should take care of proxy-caching the files on their own servers.
 
Randomizing the update time should sort it out too. Mass changing to another server will only perform what essentially looks like a DDoS on that other server.
If Plesk wants to keep using a fixed update time, Plesk should take care of proxy-caching the files on their own servers.
That sounds like a good idea, too!

@Sebahat.hadzhi could you deliver this via a Plesk update?
 
Back
Top