Question

I run the SmartSession plugin and I'm overwhelmed by the number of cgisess files it creates. Every time a page is accessed, it creates 2 cgisess files. I've been monitoring the number of files along side changes in the twiki/data/log200410.txt file to see this.

I suspect there is something redundant that is causing the session creating code to be called twice every time a page is accessed by a not-authenticated user.

Also, as I watch these cgisess files pile up, it appears that as I browse this site after logging in, then it creates still more session files.

So, can you tell me

1. Why so many cgisess files? Is it intended to be this way?

2. Is there a way to turn off the session creation thing for TWikiGuest. Only create the session thing for people who push the login button.

-- PaulJohnson - 29 Oct 2004

Environment

-- PaulJohnson - 29 Oct 2004

Answer

Why has this been closed unanswered? The definition is "Not fully answered and no longer relevant." To what extent is this not relevant?

I agree that is "Not fully answered" but it is still a good question.

-- MartinCleaver - 04 Dec 2004

The chance that someone will reply after more then one month is small. I close old questions to reduce the clutter in the support home page.

Yes, you and anyone else can help answer questions in a timely manner

-- PeterThoeny - 05 Dec 2004

Have you automated or is closing unanswered a manual process?

-- MartinCleaver - 05 Dec 2004

I know this is rather after the fact, but I ran up against this exact issue recently. I documented it while I was troubleshooting, and here is what I tried.

On January 6, 2007, I noticed that the twiki was running extremely slow. With the "top" command, I saw that dozens of instances of perl and httpd processes were being run at the same time. Also, /tmp/ was being filled up with countless numbers of files with the name cgisess_****

Apparently, these files are created with the perl CGI:SESSION library each time a user or guest is using the twiki. An example of one is:

$D = {"_SESSION_ETIME" => undef,"_SESSION_ID" => "5fa88df3682e8796965f5c4ca7580b8e","_SESSION_ATIME" => "1168191042","_SESSION_EXPIRE_LIST" => {},"_SESSION_REMOTE_ADDR" => "128.12.181.69","_SESSION_CTIME" => "1168191036"};

This shows the IP address of the user under the _SESSION_REMOTE_ADDR user. For the thousands (there were so many that the rm command couldn't handle deleting all of them) of cgisess* files, the IPs appeared completely random.

When I looked at /var/log/httpd/access_log, I saw that a TwikiUser named WillStakeDan was continuously executing a command, or at least someone was using his account to execute them. The command that was being executed was /twiki/bin/viewfile/Main/WillStakeDan?rev=1;filename="Some Dirty Porn Site.html", where the Dirty Porn Site varied from ebony.html to bigdicks.html. Also, /var/log/httpd/error_log showed that hundreds of computers were trying to execute php scripts on my machine that didn't exist and that the viewfile command was so overloaded that it caused errors for users trying to access the twiki with decent intention. The error_log showed that the script was saving the pornsites as attachments in ../twiki/pub/Main for two users: PeterKoft and WillStakeDan. I removed those files and users.

I disabled execution of /twiki/bin/viewfile temporarily and that stopped the Perl scripts from slowing the twiki down, but still tons of httpd processes were being run. This is not a great solution because users can no longer view attachments. I have read through the documentation about access control to attachments and it seems that even if you restrict viewing of attachments solely to registered users, you can still run up against people who register and infiltrate the sytem. If anyone knows of a way to deal with this issue, I'm all ears.

Also, I added a cron job to remove the cgisess* files from /tmp/ periodically. I executed the command

sudo crontab -e

to generate the file and added the line

* /30 * * * * rm /tmp/cgisess

that tells cron to delete the files every half-hour on the half-hour.

the cron is just not root level solution to this problem, did you have any better idea??

-- Jiang Nan - 2013-04-28

Jiang, see TWikiInstallationGuide

-- Peter Thoeny - 2013-04-28

Also, if you are on a public TWiki site I recommend installing the BlackListPlugin.

-- Peter Thoeny - 2013-04-28