Persistent flag in memory

Good day,

May I ask you, gurus, whether it is possible to set a flag in PHP that
persists for the duration of the server being switched on?

If the server would be power cycled, the flag would be off. Similarly if
the web server would be restarted the flag would be off also.

I do realize that such a thing would be possible to be done in MySQL by
using a table with flags in memory: CREATE TABLE IF NOT EXISTS timer
(flag int) ENGINE =3D MEMORY;

But is this also possible in PHP?

Thanks for any help,

Teus Benschop


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

Op 2/11/10 4:37 AM, Teus Benschop schreef:
> Good day,
>
> May I ask you, gurus, whether it is possible to set a flag in PHP that
> persists for the duration of the server being switched on?
>
> If the server would be power cycled, the flag would be off. Similarly if
> the web server would be restarted the flag would be off also.
>
> I do realize that such a thing would be possible to be done in MySQL by
> using a table with flags in memory: CREATE TABLE IF NOT EXISTS timer
> (flag int) ENGINE = MEMORY;
>
> But is this also possible in PHP?

take a look at memcache, or APC in terms of memory storage, although it might be possible
to have the web server setup a $_ENV value (I do this myself sometimes with the
mod_rewrite extension of apache).

as such php is a 'share nothing' architecture - so essentially there is no concept of
server level global/persisent vars. if your coming from .NET or Java et al this may be a
little shocking but it is by design, it requires a somewhat different approach (possibly)
to application design.

>
> Thanks for any help,
>
> Teus Benschop
>
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

On Thu, Feb 11, 2010 at 06:37:39AM +0200, Teus Benschop wrote:

> Good day,
>
> May I ask you, gurus, whether it is possible to set a flag in PHP that
> persists for the duration of the server being switched on?
>
> If the server would be power cycled, the flag would be off. Similarly if
> the web server would be restarted the flag would be off also.
>
> I do realize that such a thing would be possible to be done in MySQL by
> using a table with flags in memory: CREATE TABLE IF NOT EXISTS timer
> (flag int) ENGINE = MEMORY;
>
> But is this also possible in PHP?
>
> Thanks for any help,

The only way I can imagine to do this is to dump some values into a file
in the web root of your site. This would be something like the interval
since the server/webserver was started. You'd issue shell commands to
find this value, and then compare it to what's in the file. If the
file contains a larger interval than what you've just found by running
the shell commands, you know the server/webserver's been restarted, and
how long since that's happened. That is, if the file contains a longer
interval, it's "stale". You'd then replace its contents. Otherwise,
you'd leave it alone.

To actually *get* the interval(s) you're looking for would be quite a
trick. On a Linux/BSD server, you'd have to use a combination of shell
commands, possibly including uptime, ps and top. The uptime command will
give you the up time for the computer, but is only good at a resolution
of about a minute. I'm not sure how to get reliable up times out of
'ps'; the command has about a thousand options. For computer uptime,
search for the 'init' process (usually process ID 1). For the webserver,
search for apache, apache2, or whatever webserver is running.
Unfortunately, this is complicated by the fact that apache typically
runs several processes, and process IDs aren't a reliable way to
determine which one started first, since process IDs recycle.

If you have cron available to you, you can do a crontab entry which
starts with the string '@reboot'. This could dump a date/time into your
file. But it won't help with apache.

Yes, I know you asked for a yes/no flag. If you must have this, then
have your cron command simply dump 'no' into your file. As for apache, I
suspect you're stuck with calculating intervals to determine the flag,
as described above.

Maybe someone else has a better idea.

Paul

--
Paul M. Foster

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

Thank you for the hints given. I'll look into the various options given.
The main reason for the need for a persistent flag in memory is that
several installations where the PHP code would be deployed do not have
access to crontab, so I am simulating crontab's functionality by letting
a PHP script run forever. Page visits would start that script, but once
the first visitor has started the script, next visitors would only start
it if the script had died. Here is where the persistent flag is needed.
Normally the script will never die unless at server reboot, or perhaps
if some timeout limit has been exceeded. If I would touch a file in the
filesystem as a flag, this would persist even after server reboot, so
that means that my simulated crontab would never restart, since it looks
like it runs. Teus.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

Op 2/11/10 5:42 AM, Teus Benschop schreef:
> Thank you for the hints given. I'll look into the various options given.
> The main reason for the need for a persistent flag in memory is that
> several installations where the PHP code would be deployed do not have
> access to crontab, so I am simulating crontab's functionality by letting
> a PHP script run forever. Page visits would start that script, but once
> the first visitor has started the script, next visitors would only start
> it if the script had died. Here is where the persistent flag is needed.
> Normally the script will never die unless at server reboot, or perhaps
> if some timeout limit has been exceeded. If I would touch a file in the
> filesystem as a flag, this would persist even after server reboot, so
> that means that my simulated crontab would never restart, since it looks
> like it runs. Teus.

whatever it is that your trying to do, it sounds like one of two things:

1. you have hosting that is unsuitable for your needs
2. you are tackling the problem incorrectly

at any rate, as far I'm concerned, you should never have a long running
php process via a web server. (obviously this is the point that someone
posts a brilliant use case to prove me wrong ;-)

could you detail what is is you're actuallt trying to do, chances are people
have:

a. got a better alternative
b. already invented the particular wheel you're trying to build
c. you really do need shell (or even just control panel) access to run a cron job

>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

On Thu, 2010-02-11 at 05:53 +0000, Jochem Maas wrote:
> whatever it is that your trying to do, it sounds like one of two things:
>=20
> 1. you have hosting that is unsuitable for your needs
> 2. you are tackling the problem incorrectly
>=20
> at any rate, as far I'm concerned, you should never have a long running
> php process via a web server. (obviously this is the point that someone
> posts a brilliant use case to prove me wrong ;-)
>=20
> could you detail what is is you're actuallt trying to do, chances are peo=
ple
> have:
>=20
> a. got a better alternative
> b. already invented the particular wheel you're trying to build
> c. you really do need shell (or even just control panel) access to run a =
cron job
>=20

What I am trying to achieve is to have a php script run once a minute
and do a few tasks. There are some constraints:
- Users usually install the php application on their local machines, be
it Linux, Windows, or Macintosh.
- The application is defined as needing zero-configuration, i.e. it runs
out of the box.

Teus.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

Op 2/11/10 6:34 AM, Teus Benschop schreef:
> On Thu, 2010-02-11 at 05:53 +0000, Jochem Maas wrote:
>> whatever it is that your trying to do, it sounds like one of two things:
>>
>> 1. you have hosting that is unsuitable for your needs
>> 2. you are tackling the problem incorrectly
>>
>> at any rate, as far I'm concerned, you should never have a long running
>> php process via a web server. (obviously this is the point that someone
>> posts a brilliant use case to prove me wrong ;-)
>>
>> could you detail what is is you're actuallt trying to do, chances are people
>> have:
>>
>> a. got a better alternative
>> b. already invented the particular wheel you're trying to build
>> c. you really do need shell (or even just control panel) access to run a cron job
>>
>
> What I am trying to achieve is to have a php script run once a minute
> and do a few tasks. There are some constraints:
> - Users usually install the php application on their local machines, be
> it Linux, Windows, or Macintosh.
> - The application is defined as needing zero-configuration, i.e. it runs
> out of the box.

much too vague. no mention of a webserver ... zero-config and needing to install
are somewhat mutually exclusive.

I still have the feeling you're using the wrong tool for the job somehow,
I may be wrong or drunk or both ;)

>
> Teus.
>
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

On Thu, 2010-02-11 at 06:46 +0000, Jochem Maas wrote:
> Op 2/11/10 6:34 AM, Teus Benschop schreef:
> > On Thu, 2010-02-11 at 05:53 +0000, Jochem Maas wrote:
> >> whatever it is that your trying to do, it sounds like one of two thing=
s:
> >>
> >> 1. you have hosting that is unsuitable for your needs
> >> 2. you are tackling the problem incorrectly
> >>
> >> at any rate, as far I'm concerned, you should never have a long runnin=
g
> >> php process via a web server. (obviously this is the point that someon=
e
> >> posts a brilliant use case to prove me wrong ;-)
> >>
> >> could you detail what is is you're actuallt trying to do, chances are =
people
> >> have:
> >>
> >> a. got a better alternative
> >> b. already invented the particular wheel you're trying to build
> >> c. you really do need shell (or even just control panel) access to run=
a cron job
> >>
> >=20
> > What I am trying to achieve is to have a php script run once a minute
> > and do a few tasks. There are some constraints:
> > - Users usually install the php application on their local machines, be
> > it Linux, Windows, or Macintosh.
> > - The application is defined as needing zero-configuration, i.e. it run=
s
> > out of the box.
>=20
> much too vague. no mention of a webserver ... zero-config and needing to =
install
> are somewhat mutually exclusive.
>=20
> I still have the feeling you're using the wrong tool for the job somehow,
> I may be wrong or drunk or both ;)

Well, on the web server, this usually would be Apache, though one user
indicated he would use some light httpd instead. Then, of course, yes,
installation is not zero-config, but what I mean is that after
installation no further configuration steps would be needed, e.g. if the
user unpacks a tarball in the web root, it should run straightaway, or
if he does 'apt-get install ', no further configuration would
be needed. I thought therefore that using visitors page requests was a
clever way of initiating starting a php script. At the moment I've got
the following code:

$crontable =3D Database_Cron::getInstance ();
if ($crontable->getFlag ()) die;
$crontable->setFlag ();
ignore_user_abort(true);
set_time_limit(0);
while(1)
{
$log =3D Database_Logs::getInstance();
$log->log ("Minutely maintenance routine started");
.. do some maintenance ...
$log->log ("Minutely maintenance routine finished");
sleep(60);
}

This uses the mechanism of a sql table in memory, which seems fine for
the moment, since it is volatile and would disappear if the user
restarts his laptop (or if the Amazon cloud reboots ;) - thus next time
the user visits any page, this script would be restarted and do the
maintenance till the user shuts down, and so on. I still have to look
into the other mechanisms of creating a volatile flag.

I think therefore, with my limited experience of PHP, that the above
does well, though improvements are welcome.

About scripts running forever, I don't see a problem here since most of
the time it sleeps anyway, and when I look in my Ubuntu 9.10 laptop,
doing "ps ax" gives 194 live processes already, so what does the one
single extra sleeping process matter?

Teus.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

Op 2/11/10 7:25 AM, Teus Benschop schreef:
> On Thu, 2010-02-11 at 06:46 +0000, Jochem Maas wrote:
>> Op 2/11/10 6:34 AM, Teus Benschop schreef:
>>> On Thu, 2010-02-11 at 05:53 +0000, Jochem Maas wrote:
>>>> whatever it is that your trying to do, it sounds like one of two things:
>>>>
>>>> 1. you have hosting that is unsuitable for your needs
>>>> 2. you are tackling the problem incorrectly
>>>>
>>>> at any rate, as far I'm concerned, you should never have a long running
>>>> php process via a web server. (obviously this is the point that someone
>>>> posts a brilliant use case to prove me wrong ;-)
>>>>
>>>> could you detail what is is you're actuallt trying to do, chances are people
>>>> have:
>>>>
>>>> a. got a better alternative
>>>> b. already invented the particular wheel you're trying to build
>>>> c. you really do need shell (or even just control panel) access to run a cron job
>>>>
>>>
>>> What I am trying to achieve is to have a php script run once a minute
>>> and do a few tasks. There are some constraints:
>>> - Users usually install the php application on their local machines, be
>>> it Linux, Windows, or Macintosh.
>>> - The application is defined as needing zero-configuration, i.e. it runs
>>> out of the box.
>>
>> much too vague. no mention of a webserver ... zero-config and needing to install
>> are somewhat mutually exclusive.
>>
>> I still have the feeling you're using the wrong tool for the job somehow,
>> I may be wrong or drunk or both ;)
>
> Well, on the web server, this usually would be Apache, though one user
> indicated he would use some light httpd instead. Then, of course, yes,
> installation is not zero-config, but what I mean is that after
> installation no further configuration steps would be needed, e.g. if the
> user unpacks a tarball in the web root, it should run straightaway, or
> if he does 'apt-get install ', no further configuration would
> be needed. I thought therefore that using visitors page requests was a
> clever way of initiating starting a php script. At the moment I've got
> the following code:

if you're doing all this already in order to facilitate a multi-platform
install ... why not go the extra yard and have the install process setup
a cronjob (or scheduled task, launchd entry, etc, depending on platform)?

> $crontable = Database_Cron::getInstance ();
> if ($crontable->getFlag ()) die;
> $crontable->setFlag ();
> ignore_user_abort(true);
> set_time_limit(0);
> while(1)
> {
> $log = Database_Logs::getInstance();
> $log->log ("Minutely maintenance routine started");
> .. do some maintenance ...
> $log->log ("Minutely maintenance routine finished");
> sleep(60);
> }

of itself this seems like reasonable code, people argue about
the finer details but you seem to be writing clean and tidy stuff.

as such I still don't think this kind of thing belongs in a webserver
process.

I have recently been using daemontools (*nix/bsd compatible daemon management
tools ... also used to manage qmail processes) to actually keep a
long running / perpetual script running ... it's a very robust bit of
kit which takes care of running just one instance of whatever
and restarting it if it happens to die ... very nice, very simple, not
available on Windows (AFAIK) ... and helps to keep this kind
of management logic out of the actual php app.

> This uses the mechanism of a sql table in memory, which seems fine for
> the moment, since it is volatile and would disappear if the user
> restarts his laptop (or if the Amazon cloud reboots ;) - thus next time
> the user visits any page, this script would be restarted and do the
> maintenance till the user shuts down, and so on. I still have to look
> into the other mechanisms of creating a volatile flag.
>
> I think therefore, with my limited experience of PHP, that the above
> does well, though improvements are welcome.

I'd think your php is an issue - little bit I've seen suggests you
code diligently, it's merely the vehicle your using to have the script run
perpetually that irks me.

> About scripts running forever, I don't see a problem here since most of
> the time it sleeps anyway, and when I look in my Ubuntu 9.10 laptop,
> doing "ps ax" gives 194 live processes already, so what does the one
> single extra sleeping process matter?

in practice not much on a personal machine - nonetheless it's wasteful
and technically a webserver is unneeded and creates another layer of
complexity and overhead. it does seem rather brittle in terms of how you
have it set up though.

realise that your Ubuntu laptop is *probably* alot more stable, robust when
running a never-ending Apache child [worker] process with mod_php loaded and
executing ... I'd be quite confident that it would be stable and such on my
Mac as well ... but a Windows machine, I wouldn't trust that to do it ...
and keep running reliably (not from the script or the user POV)

it's possible that it's the best you can do given the pratical circumstances
of the users/maintainers of the installations ... but I hazard to say
you 'wrapper' for you perpetual/reaccuring script *might* be a sub-optimal
setup ... then again it's rather hard to say without known exactly what you
want done every minute, why it needs to be done on the user's machine and
what the connection with a cloud.

mostly I just curious.

you might also look into HipHop-for-PHP or another PHP code compiler
in order to compile your script to executable machine code which you can
then distribute to users of the software in an install package which
can then setup the relevant cron-type job to run said binary.

>
> Teus.
>
>
>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

On Thu, 2010-02-11 at 08:26 +0000, Jochem Maas wrote:
> if you're doing all this already in order to facilitate a multi-platform
> install ... why not go the extra yard and have the install process setup
> a cronjob (or scheduled task, launchd entry, etc, depending on platform)?

The reason is that the php application will not only be installed
locally, but also properly on a server. And some users could have
servers that do not offer access to the cron daemon. Which means it
might be covered by the installer on windows, and other platforms, but
there would still be no crontab equivalent on the server that runs on
the internet. Hence an platform-independent solution is still needed.
Once that platform-independent solution is there, it could as well be
deployed everywhere. But this seems to be going off-topic.

> I have recently been using daemontools (*nix/bsd compatible daemon manage=
ment
> tools ... also used to manage qmail processes) to actually keep a
> long running / perpetual script running ... it's a very robust bit of

If little or no configuration would be required that would help, and if
it were available on commodity servers like Bravehost that would be a
plus too.


> it's merely the vehicle your using to have the script run
> perpetually that irks me.

Well, on the type of vehicle used to get a job done, my feeling is that
PHP is very flexible and should / can adapt to the user's need, so why
not use the tools provided?

>=20
> in practice not much on a personal machine - nonetheless it's wasteful
> and technically a webserver is unneeded and creates another layer of
> complexity and overhead. it does seem rather brittle in terms of how you
> have it set up though.

Basically it is written as a web application, which installs locally as
well. Therefore to reduce programming efforts, and to make it easier to
be cross-platform, the LAMP server was chosen. Programmer's efforts are
expensive, therefore choosing these robust tools as Apache, MySQL and
PHP / Perl / Python was done for that reason.

>=20
> it's possible that it's the best you can do given the pratical circumstan=
ces
> of the users/maintainers of the installations ... but I hazard to say
> you 'wrapper' for you perpetual/reaccuring script *might* be a sub-optima=
l
> setup ... then again it's rather hard to say without known exactly what y=
ou
> want done every minute, why it needs to be done on the user's machine and
> what the connection with a cloud.

The "cloud" comes in when somebody installs the app in such an
environment (if that is at all possible, I haven't looked into that).
The tasks to be done every minute is to check incoming email and process
is since users can operate the system through email as well must like a
message board where users can post by email. Then there's the processing
of the outgoing email queue since all "email" sent to a user is first
going to be put online, then transferred to email if the connection is
on. Then there would be regular tasks as sending out diffs to the users
since this is an online collaboration environment for translators, so
other members can see who changed what in the translation. (This all is
still to be made, but these are the plans). PHP is very flexible so
should be able to do all of this. But I am afraid to go off-topic again.

Teus.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

On Thu, Feb 11, 2010 at 8:47 AM, Teus Benschop wro=
te:
> On Thu, 2010-02-11 at 08:26 +0000, Jochem Maas wrote:
>> if you're doing all this already in order to facilitate a multi-platform
>> install ... why not go the extra yard and have the install process setup
>> a cronjob (or scheduled task, launchd entry, etc, depending on platform)=
?
>
> The reason is that the php application will not only be installed
> locally, but also properly on a server. And some users could have
> servers that do not offer access to the cron daemon. Which means it
> might be covered by the installer on windows, and other platforms, but
> there would still be no crontab equivalent on the server that runs on
> the internet. Hence an platform-independent solution is still needed.
> Once that platform-independent solution is there, it could as well be
> deployed everywhere. But this seems to be going off-topic.
>
>> I have recently been using daemontools (*nix/bsd compatible daemon manag=
ement
>> tools ... also used to manage qmail processes) to actually keep a
>> long running / perpetual script running ... it's a very robust bit of
>
> If little or no configuration would be required that would help, and if
> it were available on commodity servers like Bravehost that would be a
> plus too.
>
>
>> it's merely the vehicle your using to have the script run
>> perpetually that irks me.
>
> Well, on the type of vehicle used to get a job done, my feeling is that
> PHP is very flexible and should / can adapt to the user's need, so why
> not use the tools provided?
>
>>
>> in practice not much on a personal machine - nonetheless it's wasteful
>> and technically a webserver is unneeded and creates another layer of
>> complexity and overhead. it does seem rather brittle in terms of how you
>> have it set up though.
>
> Basically it is written as a web application, which installs locally as
> well. Therefore to reduce programming efforts, and to make it easier to
> be cross-platform, the LAMP server was chosen. Programmer's efforts are
> expensive, therefore choosing these robust tools as Apache, MySQL and
> PHP / Perl / Python was done for that reason.
>
>>
>> it's possible that it's the best you can do given the pratical circumsta=
nces
>> of the users/maintainers of the installations ... but I hazard to say
>> you 'wrapper' for you perpetual/reaccuring script *might* be a sub-optim=
al
>> setup ... then again it's rather hard to say without known exactly what =
you
>> want done every minute, why it needs to be done on the user's machine an=
d
>> what the connection with a cloud.
>
> The "cloud" comes in when somebody installs =A0the app in such an
> environment (if that is at all possible, I haven't looked into that).
> The tasks to be done every minute is to check incoming email and process
> is since users can operate the system through email as well must like a
> message board where users can post by email. Then there's the processing
> of the outgoing email queue since all "email" sent to a user is first
> going to be put online, then transferred to email if the connection is
> on. Then there would be regular tasks as sending out diffs to the users
> since this is an online collaboration environment for translators, so
> other members can see who changed what in the translation. (This all is
> still to be made, but these are the plans). PHP is very flexible so
> should be able to do all of this. But I am afraid to go off-topic again.
>
> Teus.
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Could the app be converted to an Adobe AIR app or use PHPdock (
http://www.nusphere.com/products/phpdock.htm ) to run local? There are
a number of security issues that surround installing a webserver and a
database locally on a users machine that may become issues.

--=20

Bastien

Cat, the other other white meat

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

> On Thu, 2010-02-11 at 09:27 -0500, Bastien Koert wrote:
> Could the app be converted to an Adobe AIR app or use PHPdock (
> http://www.nusphere.com/products/phpdock.htm ) to run local? There are
> a number of security issues that surround installing a webserver and a
> database locally on a users machine that may become issues.

It probably could be converted into a local application using these
technologies, interesting technologies, by the way. The snag that will
be hit though is that the application is licensed under the GPL v 3.
Both tools you mention are closed source, I believe, and in addition I
am not sure whether these work for Windows only, leaving Mac and Unix
out. Will contributors to the applications be willing to buy the
technologies? The security issues that you mention should be taken
seriously. Teus.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Persistent flag in memory

Op 2/11/10 3:48 PM, Teus Benschop schreef:
>> On Thu, 2010-02-11 at 09:27 -0500, Bastien Koert wrote:
>> Could the app be converted to an Adobe AIR app or use PHPdock (
>> http://www.nusphere.com/products/phpdock.htm ) to run local? There are
>> a number of security issues that surround installing a webserver and a
>> database locally on a users machine that may become issues.
>
> It probably could be converted into a local application using these
> technologies, interesting technologies, by the way. The snag that will
> be hit though is that the application is licensed under the GPL v 3.
> Both tools you mention are closed source, I believe, and in addition I
> am not sure whether these work for Windows only, leaving Mac and Unix
> out. Will contributors to the applications be willing to buy the
> technologies? The security issues that you mention should be taken
> seriously. Teus.

Adobe AIR is a free platform - incl. a free SDK, it runs on Win, Mac and Linux.
AFAICT there is no restriction for developing GPL code that runs on the Air
platform ... obviously you'll not be using PHP inside Air - javascript and/or
actionscript would be the language in which the app logic is written.

>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php