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 
or you might see this error when running hourly_maint.php:

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 four 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; 
the maintenance scripts will be unable to get their arguments, which will lead to incorrect behavior.

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!

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");
to
setcookie("OASISID", $id, time() + 157680000, "/", "");