Troubleshooting

Shared Memory Errors
A number of people have reported that they aren't seeing banners, even though they have set up sections and creatives (and assigned campaigns/creatives to the sections!). When they look at the "Hourly Assignments" admin page, they get an error like this:

Warning: shm_attach() failed for key 0x4f415300: memorysize too small in /home/ads/www/oasis/mgmt/admin.php on line 402 

Error clearing shared memory segment OAS0

This indicates that the shared memory segment holding the hourly assignments was not created properly by the hourly_maint.php script.

You can verify this by typing "ipcs" at the command prompt. You will see a list of shared memory segments, their sizes, owners, permissions, and their keys. If none has a key of "0x4f415300" then you know something has gone wrong.

Either you never ran hourly_maint.php (not likely, since install.php tries to do it for you), or something went wrong when you did.

It is important to note that the first time hourly_maint.php is run, it needs to get the start option:

hourly_maint.php start

Another thing that you must ensure is that the maintenance scripts are always run by the Web user (the user as which your Web server runs). If any of the shared memory segments are created by another user (especially root), you'll never get off the ground.

Use ipcs to check the ownership of your shared memory segments. If any are owned by the wrong user, use ipcrm to remove all of OASIS' shared memory segments (and the semaphore as well). You can identify them easily, since all have keys that start with "0x4f41". Once you've cleared them out, run hourly_maint.php start. Now run ipcs again. You should have nine shared memory segments, all owned by the right user.

register_argv_argc set incorrectly in php.ini
If your php.ini has

register_argv_argc = Off; 

Errors running hourly_maint.php
The most common problem with hourly_maint.php is that it is run for the first time without the start argument. Be especially careful when running it with su

su nobody -c /path/to/hourly_maint.php start

will not work. The system will pass "start" as an argument to su, not to hourly_maint.php. Instead, do this:

su nobody -c '/path/to/hourly_maint.php start'

Of course, use the appropriate username and path for your system!

Errors Reloading in OASIS Enterprise
If you have problems reloading your slave servers, check the following:

• MySQL running on all slaves
• Adequate disk space on master and slaves
• post_max_size large enough to accomodate the XML produced and sent to slaves (/tmp/OASIS-SL2*.xml)
• memory_limit large enough to accomodate the XML produced; figure at least a factor of 4 over the filesizes to parse the XML and hold an XML DOM in memory
• Clock sync between master and slave; for security purposes, the digital signatures generated by the master are valid for only a short period of time; if the clocks get out of sync, the slave will reject reload requests from the master.
• Look at the files /tmp/OASIS* on the master. Here's a brief rundown of what should be in each:
  • OASIS-SL1-hostname - creative traffic statistics from hostname
  • OASIS-SL1-hostname.done - a "flag" file to indicate that master_reload1.php is done
  • OASIS-SL2-hostname - overflow creative traffic statistics from hostname
  • OASIS-SL2-hostname.done - a "flag" file to indicate that master_reload2.php is done
  • OASIS-SL2-hostname - overflow creative traffic statistics from
  • OASIS-SL3-hostname.done - a "flag" file to indicate that master_reload3.php is done
  • OASIS-assignments - simple text file with all creative-to-section assignments; used to build XML reload message
  • OASIS-creative_content - XML for the creative content; inserted into XML reload message
  • OASIS-delivery_controls - simple text file with delivery controls; used to build XML reload message
  • OASIS-imp_caps - simple text file with impression caps; used to build XML reload message

  If you don't see all of the appropriate host-specific files, something may have gone wrong in the client-server communications. Check the master's OASIS admin log, and check the slave's Apache logs for errors.

• Look at the files /tmp/OASIS* on the slave. Here's a brief rundown of what should be in each:
  • OASIS-MS1 - list of all running creatives (along with a timestamp and a digital signature)
  • OASIS-MS2 - XML for the complete reload of the server
  • OASIS-MS3 - timestamp and digital signature

  If you don't see all of these files, something has gone wrong in the client-server communications. Check the slave's Apache logs for errors.

Banners working for IMG tags, but not for embedded or IFRAME/ILAYERs
At install time, if you forget a trailing slash (or otherwise mis-define the URL) when you define oasis_url in your oasis.cfg, oasisi-i.php and oasisi-e.php will generate bad URLs for oasisi.php and oasisc.php.

To fix it, manually edit oasisi-i.php and oasisi-e.php to correct the bad URLs.

Cookie Problems
If OASIS runs on a machine that has no hostname, the cookie that is sent to browsers will incorrectly specify its domain and will not be returned by browsers. Thus, users may not click through to the right URL if you're using IMG tagging (they might click through correctly based on their IP addresses, but this is not reliable for hosts that share an IP address, like those behind a NAT device).

This must be fixed in three places: oasisi-e.php, oasisi-i.php, and oasisi.php. Change

setcookie("OASISID", $id, time() + 157680000, "/", ".yourdomain.com");

setcookie("OASISID", $id, time() + 157680000, "/", "");

MySQL Problems
Some users have reported problems with persistent MySQL connections exhausting the number of available connections. If you have this option enabled and are running out of available connections, you may want to try disabling it.