[php-maint] Bug#711291: Bug#711291: php5 cron file can run multiple times in parallel

[Ondřej Surý]

On Thu, Jun 6, 2013 at 11:38 AM, Alexander E. Patrakov
<patrakov at gmail.com>wrote:

> 2013/6/6 Ondřej Surý <ondrej at debian.org>:
> > Control: fixed -1 php5/5.5.0~alpha1-1
> > Control: tags -1 wheezy
> >
> > Hi Alexander,
> >
> > you might want to pull cron job:
> >
> http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/php5-common.php5.cron.d;h=8865fddb4c451f38f0d6f1ae722a3082c2eb5f81;hb=refs/heads/debian-experimental
> >
> > and sessionclean script:
> >
> http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/sessionclean;h=a5f5360d015a4e74199f8c71152ab96f0bd4bb33;hb=refs/heads/debian-experimental
> >
> > I have already improved the session clean script, but it didn't make it
> into
> > wheezy, because of lack of testers with too many session files.
> >
> > Unfortunatelly we cannot avoid looking at the files, because of #626640.
>
> I see. The new script does avoid a per-session-file process call, and
> that should be much better than the current situation. However, I (as
> a person who reviews your code) disagree that the bug has been fixed
> completely, because it is still possible that two instances of
> sessionclean run in parallel from cron and thus uselessly raise the
> load average. Please use a lock file (e.g. with flock -w 0
> /run/lock/php5.lck prepended to the original sessionclean invocation)
> to avoid that issue. As a bonus, this will generate a cron mail
> (without raising LA) if the script does run over its own tail.
>

While this might save some cycles if you are cleaning a result of an
onetime action, the locking will in fact make the load worse if it is
result of an ongoing sessions generation.

If you postpone the cron job run by half an hour, the number of sessions
will grow by that half an hour.

Let me model that...

Let's say:
- the number of sessions you can clean in an half an hour is 1.000.000.
- the bad guy generates 5.000.000 session files as one shot thing.
- the normal number of generated sessions per hour is 100.000.

The lock file will cause the files to be cleaned in 3 hours (2.5 hours for
the 5 mio + next run for generated 250.000 normal session file which will
be generated meanwhile).

But if it's not onetime thing, let's say:
- the number of sessions you can clean in an half an hour is 1.000.000.
- the number of sessions of generated per hour is 2.100.000

The lock file will cause the sessions to never clear because:
- first run (ETA +0 min) will run for 1+ hour (making two subsequent ETA
+30 min and +60 min runs to be stopped)
- the number of sessions which will be generated meanwhile is more than
3.150.000
- the next script (ETA +90 min) will have to clean 3 mio+ session files
making it run for ~1.6 hours stopping three subsequent runs
- repeat and rinse until you run out of inodes

So I actually thinks it's better to suffer from temporary load spikes (with
the new script – the old one is crazy, but it took me a while to figure out
how to fix it) than to be DoSed by sessions files not cleaning fast enough.

O.
-- 
Ondřej Surý <ondrej at sury.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20130606/8a20ac95/attachment.html>