Announcement

**firefoo** · 16-May-2007, 10:24 AM

We are having EXACTLY the same problem, and the Actinic support people I spoke to have not been very helpful so far. I took the initiative and moved all of our Actinic sites from a Windows server (i was thinking maybe it was a server config issue..) to a Linux server. It all looked good for a day or two, then guess what was on the boss'es screen yesterday when he called me over to look at a website problem

I've done some digging around the perl scripts, and have been able to track down the problem to Session.pm.

What I noticed happening under Windows was when a session is locked, an extra file is created with the same name, but with ".LCK" appended after the .session part of the filename. When this LCK file exists, it prevents other actinic scripts from opening your session file from 120 (the default) seconds since the .LCK file was created. There is a function called SessionLock:

ESTROY() in Session.pm which is supposed to be run when the running Actinic perl script terminates, and that was supposed to call SessionLock::Unlock() which removes the .LCK file so that the next hit on a an Actinic perl script can open your session.

Under Linux, I see the same thing that you do, a session file being created in the acatalog directory with 0200 permissions, I didn't check for LCK files yesterday when the problem occured as I was busy with other stuff at the time.

Have you found a solution at all?

(Oh, random thought, you might want to remove a bit of your session filename as it gives away your client computer's IP address in the filename, eg, if your IP address is 123.123.123.123 then your session file name would begin with 123Z123Z123Z123......)

**firefoo** · 16-May-2007, 10:49 AM

Oh yes, one more thing.

Previous posts on this forum have talked about invalid directory permissions on the acatalog and cgi-bin directories (should be 777 and 755 respectivly).

To help with my own diagnosis I wrote a quick script in perl that attempts to perform the same session locking routine and properly evaluate the response from the SessionLock package in Session.pm. See the attached script.

It can show you why the SessionLock failed, and it returns a different error message if directory permissions are incorrect.

Attached Files

testsession.txt (4.2 KB, 399 views)

**DiscoverNet** · 16-May-2007, 04:58 PM

firefoo, thanks for the script. I ran it (then modified it to check every session file) and didn't have any errors. Part of the problem with my situation is that it is so random!

No solutions yet. Any other help??

**Bruce** · 16-May-2007, 06:52 PM

I would suggest getting in touch with support the next time it happens so that a member of the team can take a look at it for you.

Kind regards,

**firefoo** · 17-May-2007, 12:03 PM

Hi Bruce,

Can you or someone else at Actinic confirm what permissions the .session files are supposed to be created with when everything is working Ok?

If i remember correctly there is something in the Network Settings ("cart permissions"??) in Actinic that allows you to set the permissions on files being created (?). Does that apply to session files?

Like DiscoverNet mentioned, 0200 does seem like a strange setting, however I can understand you might not want the session file to be able to be shown if someone were to guess the filename and plug it into their browser address bar. A .htaccess restriction seems like a more appropriate way of preventing session files being accessed directly?

DiscoverNet: Yes, we have the problem only intermittently as well, it is not all the time. I have not been able to identify any sort of pattern as to when it happens or what triggers it off again. The only (very vague) possibility I have came up with so far is when using two different PC's to access the site from inside a network performing NAT, however, I kind of disproved that the other day by testing what happens when browing the site concurrently in IE and Firefox, and the problem did not re-occur then so I think that is a red-herring.

Thanks.

**Bruce** · 17-May-2007, 12:34 PM

Firefoo,

Can you or someone else at Actinic confirm what permissions the .session files are supposed to be created with when everything is working Ok?

Session files are created with only write permissions so 0200 is just fine for them.

If i remember correctly there is something in the Network Settings ("cart permissions"??) in Actinic that allows you to set the permissions on files being created (?). Does that apply to session files?

No this does not apply for the session file, these are the cart lock/unlock permissions you set.

All I can suggest is to raise a ticket with support the next time this happens and provide us with a Dr.Watson report and the results of ActDiagnose so that we can take a look at it to see what is happening.

Kind regards,

**Buzby** · 17-May-2007, 04:35 PM

I had this problem and had to set the permissions to 777 in cart options. My host also had to change something at their end as well to do with who can access the file.

All sorted now, although Support said it was not an Actinic problem and offered no help. Will I renew this year?

**Marci** · 24-May-2007, 02:16 PM

It seems very strange to me that Actinic is creating these session files as apache:apache

It is... our server creates them (session files) as the account user (see code below)... not as the apache user. What happens if you SSH into your server as root and CHOWN all the session files over to "jimb"?

This sounds stupidly similar to problems we had with both Actinic v3 and v4 years ago, where actinic would also create all session files as the apache-user rather than the account-user.

Hmmmm... anything in the server setup that forces CGI scripts to run as apache, and denying them from running as account owner? (SUEXECy kinda thang...)

Code:

-rw-r--r--    1 1005     ocuk         6887 May 23 12:47 01_r8_c4.jpg
-rw-r--r--    1 1005     ocuk         9749 May 21 15:37 111.jpg
-rw-r--r--    1 1005     ocuk        13972 May 21 15:37 11206_1.jpg
-rw-r--r--    1 1005     ocuk         9915 May 21 15:37 11601_1.jpg
-rw-r--r--    1 1005     ocuk         2924 May 21 15:37 120MOTRAY.jpg
-rw-r--r--    1 1005     ocuk        30157 May 21 15:37 1330.jpg
--w-------    1 1005     ocuk          927 May 24 11:54 141Z81Z141Z3A1180006799B96786.session
-rw-------    1 1005     ocuk            0 May 24 11:52 141Z81Z141Z3A1180006799B96786.session.OPN

**Toby B** · 29-May-2007, 11:43 AM

Hi Ben,

Did you resolve this?

If not do you use Paypal by any chance?

**DiscoverNet** · 05-Jun-2007, 05:00 PM

I haven't resolved this issue yet.

It is... our server creates them (session files) as the account user (see code below)... not as the apache user. What happens if you SSH into your server as root and CHOWN all the session files over to "jimb"?

I've tried this, but because Actinic creates new ones as Apache it isn't a permanent fix by any means.

Did you resolve this?

If not do you use Paypal by any chance?

No, we do not use PayPal.

**Toby B** · 06-Jun-2007, 08:14 AM

This error is a known bug and it started to occure when we made a fix to a PayPal and Nochex problem.

Can you please try this:

Edit ActinicConstants.pm and search for PAYPAL.

You should see...

$::PAYMENT_PAYPAL = 900;
$::PAYMENT_NOCHEX = 52;

comment these lines out by preceding the lines with '#' so it reads...

# $::PAYMENT_PAYPAL = 900;
# $::PAYMENT_NOCHEX = 52;

Save and exit
Update the site.

Does the problem still occur? If it does try:

Edit Session.pm
Search for 'sub GetSessionFileName' you will see...

sub GetSessionFileName
{
my $Self = shift;
my $sID = shift;
my $sPath = $Self->GetSessionFileFolder();
return ($sPath . $sID . '.session');
}

Insert after this ...

sub DESTROY
{
my $Self = shift;
$Self->{_LOCKER}->Unlock()
}

Save and exit
Update the site

**Buzby** · 02-Jul-2007, 06:49 PM

Toby,

I too am having this problem, however with OMD files being produced.

Is this a connected problem as discussed above?

I do use Paypal and am running version 8.5.0

Can I safely do what you have suggested above even though the problem is slightly different?

Many thanks

Jason

**Suemoo** · 03-Jul-2007, 07:06 PM

Hi there

I'm having this same problem. Is this fix safe to use if we do accept PayPal payments?

Thanks

Sue

**Bruce** · 03-Jul-2007, 07:14 PM

Hi,

It is safe to do the fix. Paypal have made some changes on their end and if you are not receiving order emails etc then please comment to http://community.actinic.com/showthread.php?t=31085.

Kind regards,

Announcement

v8 Error: "...session can not be locked during Sesssion init"

v8 Error: "...session can not be locked during Sesssion init"

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment