Resolved API call failed: HTTP Error 500: Internal Server Error

[selcukedirne]

sharing a video maybe it helps or gives an idea for solution

Imunify QuickPatch - reliability and vulnerability evaluation - Plesk Obsidian 18.0.26

 

[cheda]

sharing a video maybe it helps or gives an idea for solution

Imunify QuickPatch - reliability and vulnerability evaluation - Plesk Obsidian 18.0.26

The (hourly) cron notification is fixed if u reinstall the plugin, u won't receive any notifications anymore. Follow the steps described in my previous post.

I have the same message on the screen as yours. Personally, i am satisfied that the problem of getting hourly e-mail notifications is at least solved for now.

The problem i guess is that the API Imunify update server page can't be reached (at this moment). I hope there will be in an update/fix soon. But there is nothing left u can do anymore on your side. We can only sit and wait patiently for a fix (hopefully very soon).

 

[selcukedirne]

The (hourly) cron notification is fixed if u reinstall the plugin, u won't receive any notifications anymore. Follow the steps described in my previous post.

I have the same message on the screen as yours. Personally, i am satisfied that the problem of getting hourly e-mail notifications is at least solved for now.

The problem i guess is that the API Imunify update server page can't be reached (at this moment). I hope there will be in an update/fix soon. But there is nothing left u can do anymore on your side. We can only sit and wait patiently for a fix (hopefully very soon).

ok then wait & see what happens next, thanks for your effort

 

[Ayki]

I am having the same problem. Did anyone try the advice in the following article?

Plesk Administrator receives emails with the following message: dgri-report: docker socket present but not accessible

Applicable to: Plesk Onyx for Linux Symptoms Numerous email notifications sent to Plesk administrator mailbox: dgri-report@example> /usr/bin/dgri-report collect on_unchanged_config=nop with...

support.plesk.com

 

[panamaserver.com]

Removing the Imunify QuickPatch extension worked for me.
I will reinstall again and share results.

 

[josede]

Removing the Imunify QuickPatch extension and reinstalling. WORKS.

 

[selcukedirne]

yes, removing & reinstalling works well! but not solution for extension error, still gives reload(ish) action & stuck on its own page anyway at least not giving cron job or schedule task error for now

 

[josede]

yes, removing & reinstalling works well! but not solution for extension error, still gives reload(ish) action & stuck on its own page anyway at least not giving cron job or schedule task error for now

Yes it stucks

 

[sachac]

And 1 more affected by this... don’t have docker installed.

Update 1: just has you all I uninstalled Imunify QuickPatch... let’s wait 22:50 if I receive the mail..
Update2: great, no more mails. Waiting on the dev now to have it fixed.

 

[Martin Dias]

Plesk Administrator hourly recieves email messages: dgri-report API call failed: HTTP Error 500: Internal Server Error follow this article to get updates on this issue (it is still under investigation by CloudLinux)

 

[MicheleB]

The issue has been resolved.

 

[trialotto]

The issue has been resolved.

@MicheleB (and @others),

Problem might have returned - so keep a good look at your syslog entries.

I have had this problem on one server, on the 22th of May 2020.

The endresult? A completely wasted Plesk instance........ which instance shuts down randomly ...... and even though all services are working, they do not work properly : websites are at the default (Plesk) page, Plesk Panel is not accessible and so on.

It might be more complex than only a problem related to dgri.

Kind regards......

 

[karam]

@MicheleB (and @others),

Problem might have returned - so keep a good look at your syslog entries.

I have had this problem on one server, on the 22th of May 2020.

The endresult? A completely wasted Plesk instance........ which instance shuts down randomly ...... and even though all services are working, they do not work properly : websites are at the default (Plesk) page, Plesk Panel is not accessible and so on.

It might be more complex than only a problem related to dgri.

Kind regards......

Yup, my plesk instance was wasted too back then,
I'll prepare to waste the new one too, thanks for notifying.
Too many inconsistencies lately with updates..

 

[trialotto]

Yup, my plesk instance was wasted too back then,
I'll prepare to waste the new one too, thanks for notifying.
Too many inconsistencies lately with updates..

@karam,

There is something odd going on with the firewall......... an important question to you : did you have Plesk Firewall extension installed?

I would like to hear that, because it seems to be the case that some script or task is affecting iptables in such a way that it is not in line with Plesk Firewall rulesets.

Please give me some (elaborate!) feedback, so we can try to tackle this issue.

Kind regards.......

 

[karam]

@trialotto Yes, I had it installed, and I have it now too.
Am ready to provide any information if needed.

 

[karam]

@trialotto When the server got wasted, it blocked all ports, I remember this yes.
Which happened after an update. while having the dgri problem.. it is a mess.
PS: the server was very clean

 

[trialotto]

Plesk Administrator hourly recieves email messages: dgri-report API call failed: HTTP Error 500: Internal Server Error follow this article to get updates on this issue (it is still under investigation by CloudLinux)

@Arashi

Problem seems to have returned with a vengeance.

I receive new messages with the text :

API call failed: <urlopen error timed out>
error: failed to collect system info

The problem here is an issue that is very likely related to the firewall, given the facts that

- Plesk Panel becomes inaccessible after a random time period, with sw-cp-server and sw-engine still working and listening on the appropriate ports, (and)
- several services (like postfix/smtp) stop working properly after a random time period, with mail connections timing out, (and)
- several services still working (like systemd-timesyncd) and connecting properly, (and)
- apt-get update command not resolving for specific repo's, like atomicorp, cloudlinux etc, (and)
- SSH access is possible from one (remote) machine and not possible from another (remote) whitelisted machine, (and)
- Plesk Firewall rulesets (as stored in firewall-active.sh) do not correspond with iptables entries,

and this is only a small summary of symptoms.

In addition, systemd is behaving rather randomly and the root cause of that is not known to me.

The two issues (firewall + systemd) are probably related, but it is not known to which extent and in what way.

I hope that you can have a look at this, because this odd behaviour occurs independent of the presence of dgri (i.e. Imunify QuickPatch).

Kind regards.........

 

[trialotto]

@trialotto When the server got wasted, it blocked all ports, I remember this yes.
Which happened after an update. while having the dgri problem.. it is a mess.
PS: the server was very clean

I suppose the update from Obsidian 18.0.26 to 18.0.27?

It is a bit odd, because the issues are not really related to the update - a new fresh Obsidian 18.0.27 installation does not exhibit any problems at all.

It becomes even more strange, since the problems are more or less the same when having dgri installed and when dgri uninstalled.

Another question - did you have Watchdog installed?

Kind regards.......

 

[karam]

I suppose the update from Obsidian 18.0.26 to 18.0.27?

It is a bit odd, because the issues are not really related to the update - a new fresh Obsidian 18.0.27 installation does not exhibit any problems at all.

It becomes even more strange, since the problems are more or less the same when having dgri installed and when dgri uninstalled.

Another question - did you have Watchdog installed?

Kind regards.......

No,not a plesk version update,
But instead, a system packages update.

I don't have watchdog installed.

I think the problem isn't only by dgri, It is really hard for me to investigate now as i have already rebuilt the server,
But I feel it will be down soon, I'll update you, as there are 239 pending packages update, and hell no I will not do that until I take all backups..

 

[trialotto]

@karam

A small tip - it is recommended to allocate a new server and migrate all data to the new server, before doing something on the old (problematic) server.

After all, the site data is or should not be compromised, the Plesk related (server-wide) data probably is.

If you follow this procedure, you will have a fresh Obsidian 18.0.27 instance, which can also function as a backup (of data) and a fail-over (of sites and services).

Please note that you should inspect disk performance on the old (problematic) server, since it is very likely that you will encounter problematic performance - this is another reason for not using regular backup methods : a regular backup process via Plesk will put a heavy burden on your (old) server.

In short, in order to prevent a full breakdown of the old server with complete data loss, I would recommend to migrate data to a new server - as a work-around.

Hope this suggestion helps a bit.

Kind regards........