ERROR: WDExc (PLESK 8.6)

[petters]

WdExc error

Watchdog error is common Plesk panal. Sometime I also face the same server error.

 

[PEER1_Luis]

Has anyone found a fix for the subject listing "December 31st, 1969" in the watchdog emails after applying this fix?

You can duplicate the issue by running:
/usr/local/psa/libexec/modules/watchdog/cp/send-reports weekly

I have an opened a ticket for one of our customers, so I will let you all know if Parallels support provides the fix to us.

 

[BernhardE]

This error does not belong to that fix I think. I had the same issue before applying the fix. PSA 9.5.3, Debian Lenny.

 

[ThomasR]

I confirm issue is still open:

° Replaced both patch files on our Plesk 8.6 server and pack-sysstats executed manually (cfr http://forum.parallels.com/showpost.php?p=434532&postcount=57).
° Red error message in image on Statistics page in Watchdog Module has disappeared, but no image is shown instead.
° Weekly mail report still "Watchdog weekly report Jan 1, 1970 - Jan 1, 1970 on XXXXXXXXX" (on Plesk 9.5 servers this message is "Watchdog weekly report Jan 2, 111 - Jan 8, 111 on XXXXXXX").

Should we really all open a support ticket for this worldwide bug? Is it really to difficult for Parallels to fix this small issue in 10 (!) days?

 

[Paul Maine]

Partial Fix

We seem to be getting new statistics on Plesk 8.6, but like other posters, have invalid dates in the Watchdog report message:

"Watchdog weekly report Dec 31, 1969 - Dec 31, 1969 on [canonical name]"

ThomasR: Check your file ownership & permissions. Here's the recipe we used:

mv stats-graph.php /usr/local/psa/admin/htdocs/modules/watchdog/
mv pack-sysstats.sh /usr/local/psa/libexec/modules/watchdog/cp/
cd /usr/local/psa/libexec/modules/watchdog/cp/
mv pack-sysstats pack-sysstats.old
mv pack-sysstats.sh pack-sysstats
chown rootsaadm pack-sysstats
chmod ug+x pack-sysstats
./pack-sysstats year
./pack-sysstats month
./pack-sysstats week
./pack-sysstats day

 

[ThomasR]

ThomasR: Check your file ownership & permissions.

Hi Paul,

Our file permissions should be right:

# ls -al /usr/local/psa/admin/htdocs/modules/watchdog/
total 104
drwxr-xr-x 3 root root 4096 Jan 6 08:36 .
drwxr-xr-x 4 root root 4096 Mar 13 2009 ..
-rw-r--r-- 1 root root 782 Sep 12 2008 disk-edit.php
-rw-r--r-- 1 root root 1130 Sep 12 2008 disks.php
-rw-r--r-- 1 root root 274 Sep 12 2008 index.php
drwxr-xr-x 3 root root 4096 Mar 13 2009 locales
-rw-r--r-- 1 root root 7400 Sep 12 2008 preferences.php
-rw-r--r-- 1 root root 9799 Sep 12 2008 secur-scan.php
-rw-r--r-- 1 root root 817 Sep 12 2008 service-edit.php
-rw-r--r-- 1 root root 1061 Sep 12 2008 services.php
-rw-r--r-- 1 root root 23785 Jan 5 15:43 stats-graph.php
-rw-r--r-- 1 root root 23576 Sep 12 2008 stats-graph.php.old
-rw-r--r-- 1 root root 1850 Sep 12 2008 stats.php
# ls -al /usr/local/psa/libexec/modules/watchdog/cp/
total 44
drwxr-xr-- 2 root psaadm 4096 Jan 5 16:57 .
drwxr-xr-- 6 root psaadm 4096 Mar 13 2009 ..
-rwxr-xr-- 1 root psaadm 408 Sep 12 2008 clean-events
-rwxr-xr-- 1 root psaadm 601 Sep 12 2008 clean-reports
-rwxr-xr-- 1 root psaadm 442 Sep 12 2008 clean-sysstats
-rwxr-xr-- 1 root psaadm 2769 Jan 5 15:43 pack-sysstats
-rwxr-xr-- 1 root psaadm 2697 Sep 12 2008 pack-sysstats.old
-rwxr-xr-- 1 root psaadm 543 Sep 12 2008 secur-check
-rwxr-xr-- 1 root psaadm 10951 Sep 12 2008 send-report
# cd /usr/local/psa/libexec/modules/watchdog/cp/
# ./pack-sysstats year
# ./pack-sysstats month
# ./pack-sysstats week
# ./pack-sysstats day

With the new stats-graph.php a broken image is shown (cfr attachments). With the old stats-graph.php the 24h image is ok, but weekly, monthly and yearly reports do show an image with the red error text (cfr attachments).

 

[Paul Maine]

Clear stats table?

ThomasD: Your file ownership & permissions look correct from here. Perhaps this bug created invalid data in your stats?

It's a safe bet this bug is due to two-digit years being used in their internal code. A programmer probably delayed the symptoms using a 100-year sliding window hack rather than solving the issue completely. So here we are, again, 10 years later.

stats-graph.php appears to dynamically build images using data from the psa.module_watchdog_sys_stat MySQL table. If I were you, I'd take a look at some of the data to ensure it has valid dates in the time field. Worst case scenario, try backing up the data using an export of the table, then empty/truncate the table to start fresh.

I'm just shotgun debugging here. I don't work for SWSoft / Parallels. Their code is obfuscated via encryption and doesn't run under debugging tools like strace. This MIGHT be acceptable if:

- They only protected their proprietary code,
- They responded in a timely manner to defect reports, and
- They provided solutions that fully addressed defects.

None of the above criteria seems to fit Parallel's behavior. They are violating licenses of open source packages like Apache, qmail, postfix, monit, rrdtool, and many others by distributing altered versions of the software without making source code available. As you pointed out, we're now 10 days into a major bug with only a partial solution.

 

[ThomasR]

stats-graph.php appears to dynamically build images using data from the psa.module_watchdog_sys_stat MySQL table. If I were you, I'd take a look at some of the data to ensure it has valid dates in the time field. Worst case scenario, try backing up the data using an export of the table, then empty/truncate the table to start fresh.

Hi Paul,

Thanks for you suggestion. All dates and data in these tables seem to be ok. I have emptied the module_watchdog_sys_stat and module_watchdog_service_event tables but it doesn't change anything on the graph images (checked for both old and new version of stats-graph.php). Meaning that after all we better open a new support ticket for it?

 

[Paul Maine]

Last Ditch Effort

ThomasR: Double-check your crontab (if you commented out pack-sysstats earlier) and try restarting the psa daemon like so:

/etc/init.d/psa restart

The graphs are working on our end (Plesk 8.6 on Ubuntu 8.04LTS). Perhaps you're dealing with some funky filesystem / apache caching issue?

 

[ThomasR]

ThomasR: Double-check your crontab (if you commented out pack-sysstats earlier) and try restarting the psa daemon like so:

/etc/init.d/psa restart

Hi Paul,

Thanks for suggestions, but the cronjobs weren't changed and restarting psa didn't fix it. However, I once again downloaded the patched files (http://forum.parallels.com/showpost.php?p=434456&postcount=42) and found out Parallels changed them in the meanwhile (check file sizes):

# original file with bug:
-rw-r--r-- 1 root root 23576 Sep 12 2008 stats-graph.php
# patched file which didn't fix the problem:
-rw-r--r-- 1 root root 23785 Jan 5 15:43 stats-graph.php
# latest patched file which fix the problem:
-rw-r--r-- 1 root root 23787 Jan 12 08:50 stats-graph.php

Overwriting the patched file with it latest version (23787 bytes) did the trick. Watchdog is now up and running on all our containers. Thanks to all for helping!

 

[MerkasiS]

Weekly mail report still "Watchdog weekly report Jan 1, 1970 - Jan 1, 1970 on XXXXXXXXX" (on Plesk 9.5 servers this message is "Watchdog weekly report Jan 2, 111 - Jan 8, 111 on XXXXXXX").

And it doesnt log any event:

"Security scans number: 0.

No events registered for the period."

 

[105547111]

I just updated Plesk yesterday and now a new watchdog email bug! Will this fix still work after the panel update?

Here is the new error:

/usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats: line 1: ?php: No such file or directory
/usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats: line 2: syntax error near unexpected token `"The file {$_SERVER['SCRIPT_FILENAME']} is part of Plesk 9 distribution. It cannot be run outside of Plesk 9 environment.\n"'
/usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats: line 2: ` ***die("The file {$_SERVER['SCRIPT_FILENAME']} is part of Plesk 9 distribution. It cannot be run outside of Plesk 9 environment.\n");'

Hello Everyone. Thank you for reporting and sorry for the inconvenience.

Please try attached fixes for Plesk 8.6, 9.x, 9.5.x and 10.x.

Please don't forget to backup original files before replacement.

1. unzip archive corresponding your Plesk version
2. replace pack-sysstats located in "/usr/local/psa/libexec/modules/watchdog/cp/".
3. replace stats-graph.php located in "/usr/local/psa/admin/htdocs/modules/watchdog/".

NOTE: This is latest updated fix

------------

 

[SubZer0]

Also fixed by applying patch

I just updated Plesk yesterday and now a new watchdog email bug! Will this fix still work after the panel update?

Here is the new error:

/usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats: line 1: ?php: No such file or directory
/usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats: line 2: syntax error near unexpected token `"The file {$_SERVER['SCRIPT_FILENAME']} is part of Plesk 9 distribution. It cannot be run outside of Plesk 9 environment.\n"'
/usr/local/psa/libexec/modules/watchdog/cp/pack-sysstats: line 2: ` ***die("The file {$_SERVER['SCRIPT_FILENAME']} is part of Plesk 9 distribution. It cannot be run outside of Plesk 9 environment.\n");'

I had the same problem. It's also solved by applying these instructions

 

[ZakW]

Me & Roland Leurs - we have Plesk 8.4.0...what can we do? Is it safe to try the 8.6 fix on a live server?

Also looking for a fix for 8.4.0. Any help would be appreciated!

 

[ChK]

i get this error again, since the last "microupdate", Plesk 9.5.4

and sorry, but.. i'm a little bit nerved! so much manual and automatic updates and ever comes the same "known!" error...


--- ERROR

ERROR: WDExc
Error occurred while processing database query: 'MySQL query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'group by service_id, type, round(unix_timestamp(time) / 200, 0) having count(val' at line 3'

0: wdlib.php:1088
wd__db_query(string 'select service_id, type, unix_timestamp(min(time)) as min_time, unix_timestamp(max(time)) as max_time, avg(value) as avg
from module_watchdog_sys_stat where
group by service_id, type, round(unix_timestamp(time) / 200, 0) having count(value) > 1 limit 10000;')
1: pack-sysstats:63
pack_statistics(integer '200', boolean false, boolean false)
2: pack-sysstats:44


---------- Last Update 2010-04-13 :

Parallels Products Installer 3.6.0 (built on 2010-04-13 11:27 svn rev. 290858) started at (timezone CET) Fri Jan 14 20:53:29 2011 Command line arguments: /usr/local/psa/admin/bin/autoinstaller -

[...]

Installing patches...
File downloading PSA_9.5.4/microupdates/MU1/common/pack-sysstats: 41%..95%..100% was finished.
File downloading PSA_9.5.4/microupdates/MU1/common/send-report: 10%..23%..36%..49%..63%..76%..89%..100% was finished.
File downloading PSA_9.5.4/microupdates/MU1/common/stats-graph.php: was skipped because of md5 checksum match.

 

[ThomasR]

Last week we updated all our servers with the provided patch. After all this works for the graphs in the Watchdog module itself, but now it comes out that the weekly reports still continue to falter:

For a Plesk 8.6 server:

Watchdog is running since Jan 17, 2011 01:00 AM.
Watchdog is monitoring services:
Plesk Web Server
Web Server (Apache)
SMTP Server (QMail)
IMAP/POP3 Server (Courier-IMAP)
DNS Server (BIND)
MySQL
Watchdog is not monitoring disks.

Security scans number: 0.

No events registered for the period.

For a Plesk 9.5.4 server:

Watchdog is running since Jan 17, 2011 01:00 AM.
Watchdog is monitoring services:
Plesk Web Server
Web Server (Apache)
SMTP Server(Postfix)
IMAP/POP3 Server (Courier-IMAP)
DNS Server (BIND)
Tomcat
MySQL
Watchdog is monitoring:
[normal] /dev/vzfs (mount point /)


Security scans number: 0.

No events registered for the period.

Parallels, please do take your responsibility and test, debug and fix this annoying problem. I can open a support ticket for it, but as this is clearly a worldwide bug I refuse to do this.

 

[MerkasiS]

Last week we updated all our servers with the provided patch. After all this works for the graphs in the Watchdog module itself, but now it comes out that the weekly reports still continue to falter:

For a Plesk 8.6 server:


For a Plesk 9.5.4 server:


Parallels, please do take you responsibility and test, debug and fix this annoying problem. I can open a support ticket for it, but as this is clearly a worldwide bug I refuse to do this.

Same Here.

 

[HostMySite.comH]

Last week we updated all our servers with the provided patch. After all this works for the graphs in the Watchdog module itself, but now it comes out that the weekly reports still continue to falter:

For a Plesk 8.6 server:


For a Plesk 9.5.4 server:


Parallels, please do take your responsibility and test, debug and fix this annoying problem. I can open a support ticket for it, but as this is clearly a worldwide bug I refuse to do this.

Same issue here as well.

 

[TakahikoO]

Watchdog report subjects

Last week we updated all our servers with the provided patch. After all this works for the graphs in the Watchdog module itself, but now it comes out that the weekly reports still continue to falter:

For a Plesk 8.6:
Watchdog weekly report Jan 1, 1970 - Jan 1, 1970 on XXXXXXXX

For a Plesk 9.5:
Watchdog weekly report Jan 9, 111 - Jan 15, 111 on XXXXXXXX


Same issue here!!

 

[ThomasR]

24 days later, still no solution for the latest versions of Plesk 8 and Plesk 9. Parallels, is this what you mean with "improving response and resolution times" in practice?

Customer Support was mentioned as an area where Parallels needs to improve. As many of you know, we are changing our Customer Support processes to improve response and resolution times, and we also introduced a better quality control process. In addition to these changes, we are implementing a closer cooperation between our Engineering and Customer Support to be able to reduce the number of incidents in the first place.