Call to undefined function: iworx_check_restart()?

I have approximately 125 emails from my Cron Daemon starting at 4:22 AM. All of them say this:

PHP Fatal error: Call to undefined function: iworx_check_restart() in /home/interworx/cron/iworx.php on line 84
They are coming in every 5 minutes, and I can’t think of any other cause besides an automatic update. Is anyone else experiencing this?

I have them, too (starting at 4:30 EST) … but coming from:

Cron <iworx@web1> cd /home/interworx/cron ; ./iworx.pex --fively

and saying:

Allowed memory size of 134217728 bytes exhausted (tried to allocate 0 bytes)

Unfortunately, the services aren’t responding on the box now, either. I can SSH in and reboot – but it’s not fixing the lack of httpd, nor the cron messages.

Help?

JB

More info …

I also get this:

[root@web1 init.d]# ./httpd start
Flushing IPC Semaphores                                    [  OK  ]
Starting httpd: Syntax error on line 1 of /etc/httpd/conf.d/some.domain.com.conf:
/etc/httpd/conf.d/some.domain.conf:1: <VirtualHost> was not closed.
                                                           [FAILED]

When trying to stop/start the httpd service.

Thoughts?

JB

More for ya …

The above some.domain.com.conf file in question has:

DocumentRoot /home/interworx/var/overage

Instead of their normal path. I assume (and wouldn’t be surprised that) this is the path to the “you’re over your bandwidth” default location (as they often go over their allocated amount) – but it’s never created this issue before.

JB

JayBaen,

Make sure the some.domain.conf file has a
</VirtualHost>

at the end of it, if you haven’t already.

Also it’d be best if you open a support ticket so we can get access to the server and reproduce the problem, so we can track down the source.

Thanks,

Paul

Make sure the some.domain.conf file has a
</VirtualHost>

That did the trick (you’re a god as always) …

Now, the question is - Why was it missing? I’m guessing the VirtualHost file when going to an overage state was created by IWorx.

Possible (new) bug?

JB

Edit as a side note, this stopped all the “-fively” cron job failures as well.

JayBaen,

This was indeed a new bug in 1.9.2, if you run yum update it’ll pull down the fix (auto update will apply it also).

Jimp - your problem is different from JayBaen, and I can’t reproduce that one here. You may want to open a support ticket if it isn’t resolved so we can check it out.

Paul

Thx Paul.

In fact, I had pulled down a YUM update (before writing in), thinking you may have caught the issue and the box did update –

but

It didn’t fix the </VirtualHost> already in question. I had to fix that one manually. I’m sure any future ones probably won’t be an issue.

JB

That’s correct, it should prevent this problem from happening again but you do need to manually add the
</VirtualHost> line to the end of any conf file that’s missing it.

Paul

I just tried a yum update, but it did not find anything that needs updating.

I tried logging into NodeWorx / SiteWorx and both say “Permission Denied.” Most of the permissions do not look right to me, but here they are:

ls -l /home

drwx–x--x 14 iworx iworx 4096 Mar 28 08:59 interworx

ls -l /home/interworx

total 84
drwxr-x— 4 iworx iworx 4096 Mar 28 04:20 bin
-rw------- 1 iworx iworx 245 Oct 18 2003 CREDITS
drwxr-x— 2 iworx iworx 4096 Mar 28 04:20 cron
drwx------ 7 iworx iworx 4096 Mar 12 01:57 etc
-rw------- 1 iworx iworx 6344 Feb 18 2004 EULA
drwx------ 2 iworx iworx 4096 Mar 12 01:52 html
drwx------ 10 iworx iworx 4096 Mar 12 01:53 include
drwx------ 2 iworx iworx 4096 Mar 12 01:52 ioncube
-rw------- 1 iworx iworx 10425 Mar 16 20:19 iworx.ini
drwx------ 4 iworx iworx 4096 Mar 12 01:52 lang
drwx–x--x 18 iworx iworx 4096 Mar 12 01:52 lib
-rw------- 1 iworx iworx 1825 Nov 6 2003 LICENSE
drwx------ 5 iworx iworx 4096 Mar 26 14:32 nodeworx
drwx------ 4 iworx iworx 4096 Mar 26 14:32 siteworx
drwx------ 2 iworx iworx 4096 Mar 12 01:52 sql
drwx–x--x 9 iworx iworx 4096 Mar 12 01:52 var
I know I didn’t mess with these permissions, but they also don’t look like someone used a chmod -R on them… :confused:

It is sounding like no one else is having this problem. Should I open a support ticket now?

I just got this error emailed to me. Its like the 3rd one, I think I deleted the others, but I only get one every once in a while, not slammed like others.

SUBJECT: Cron <iworx@server1> cd /home/interworx/cron ; ./iworx.pex --fively

/bin/bash: line 1: cd: /home/interworx/cron: Permission denied
/bin/bash: line 1: ./iworx.pex: No such file or directory

EDIT
I also got one right after that with the “–fifteenly” with the same error.

My guess is this was b/c of the small InterWorx update, especially b/c the time of these errors was during my “–daily” cron.

Jimp: Yes, go ahead and open a support ticket.

Justin: Yes, the occasional permission denied error triggered during the --daily cron is nothing to worry about.

Paul,

Is this permission error a new part of InterWorx with the latest upgrades? Or is this just a random non-eventful occurance?

I was going to ask if there was a way to shut down the --5’ly and --15’ly cron jobs while the --daily was running since the daily is very CPU intensive and was thinking that having the 5’ly and 15’ly overlapping the daily was the cause of my Apache not starting itself back up on the --daily httpd restart (I think my ticket is still in the system about that).

Also, this thread is about “iworx_check_restart()”. Is this a new function in the /cron/iworx.php file? And it is run every 5 mins?

Thanks,

I discovered another one of these today that crept up after some changes to a Siteworx account. I think this was the process I followed that created the error:

  1. Siteworx account originally created in 1.8.x - no changes to options since creation.
  2. It lived through the upgrades of 1.9.x and 2.0.x
  3. Now, as a 2.0.x account, I enabled both CGI and Scriptworx for the account at the same time, and saved the changes.

After this point, the “fively” messages began pouring in, and httpd wouldn’t restart correctly (same as earlier issue in this thread).

I found the missing </VirutalHost> in that *.conf, inserted it and it solved the issue.

Just wanted to make sure if it’s a bug in upgrading any older Siteworx account within the 2.0 framework, you all know about it.

JB

I know this has been a random bug for almost as long as I can remember. The last I’d heard they didn’t know for sure what caused it (other than the obvious). I was told to ignore it unless it became cronic. Any update on that?