Cron job runs every 30 secs?

Hi. I google it and it seems cron cannot starts a script every N secs. The best you can do is just every min.

The problem is I need the php program to send member email confirmation which contains a confirm link. Run every min may still make the member wait. So I like to make it to run every 20 or 30 secs.

I don't want to put the code to send email on my sign up page as that's no good.

But I don't want to put a sleep 30 sec on my php script and going on loop. If it failed in the middle then it may wait abit to start.

What can be done to achieve my goal and what's the best way?

Making a php script to run as a daemon process? Is that possible and okay?

Appreciated if anyone can help.

Thanks.

Why?


It's possible, but PHP isn't really designed to be used that way.

Why not send the confirmation immediately?

Email can take several minutes to propagate anyway, even if you do send it immediately (especially if your ISP bounces it to an external scanning service).

But if you really want say 10 seconds, then try (in bash)

That will slow down the sign up process. What if it takes a bit long to send email or it just hangs? Then the sign up page will load a long time then eventually not show anything.

Also if you just store the mail task into the database and if for any reason it fails you can restart it again easily. But do it through the sign up page then what happens it fails?

I just think that's bad design on the system? I don't think most site do it like that?

Thanks but this response not that helpful. After reading this I feel going no where. I hope people can think of what if someone response their question this way what do they think? I rather people not response.

When you fail to provide sufficient information in your first post it is necessary for me to ask you to provide more before I can help you. If you don't want to provide enough information for me to help you then I won't.

Most sites do send the confirmation E-Mail immediately from the signup page. Unless your SMTP server is overloaded you shouldn't have many problems with the outbound E-Mail delaying the loading of the page. SMTP servers have queues of their own for outbound messages; thus recipient's mail server should not impact the loading of the page.

You say you don't want to follow the commonly accepted way of sending confirmation E-Mails, so the question "why" is actually very important. The answer tells me what solutions will work for you and which solutions will not work for you. If I don't know why you don't want to send the E-Mail directly from the confirmation page then the alternative solutions I provide might not work for you for the same reason that sending it directly from the confirmation page doesn't work for you. I'm not going to waste my time writing up information on an alternative solution that you can't use.

Anyway, since you did answer my question, I can see that you don't really need batch processing capabilities for the E-Mails, you are just worried about the sending process hanging up the page; and that's an acceptable reason.

You don't need to use a CRON job to execute code asynchronously in PHP. You can use the exec function or the popen function to spawn a new PHP process in the background (there should be examples of this on the manual pages in the user comments for those functions). The new process can execute independently of the webpage process, and will not prevent the page from loading.

So my recommendation for you is that you record the confirmation E-Mail to the database with a unique ID, then spawn a new PHP process in the background to actually send the E-Mail. Your webpage process can pass the E-Mails unique ID to the background process and the background process can handle the sending of that E-Mail immediately. You can record the sent/unsent status of the E-Mail in the database as well, so that you can detect failures. If you want to retry sending failures you can do so with a longer-running CRON job (like 5 or 15 minutes).

This method has the benefit of sending the E-Mail out sooner, not requiring extra server (CRON) configuration and (assuming you have fewer than 1 signup per 30 seconds) is more efficient than running a CRON job every 30 seconds.

Hi. Alright. Thank you for everyone's help and opinion.

Hi. I google about how to execute shell command without waiting for result. Then the best I found is this. The php shell_exec does wait for output and return it. But adding the following will not wait. That's what they say. I haven't try it yet.

"> /dev/null 2>/dev/null &"

shell_exec('php measurePerformance.php 47 844 email@yahoo.com > /dev/null 2>/dev/null &');

I don't know much on shell command. I just know if I add "> /dev/null" then it will do mailto=root if only errors occur.

They only mentioned this will also gets rid of the stdio and stderr. If get rid of stderr then I won't get any email when there's error.

So which part is actually to tell not to wait for result? Hope anyone may know? Thank you.

>/dev/null redirects stdout to /dev/null (discards it)
2>/dev/null redirects stderr to /dev/null (discards it)

Without these statements PHP will wait for the process to close stdout/stderr before shell_exec returns.

& executes the process in the background, causing the shell to return immediately, and allowing PHP to continue without waiting for the process to finish.

So all three parts are necessary to allow the process to execute without PHP waiting for it to finish.

shell_exec will not E-Mail root if an error occurs under any circumstances. That is a feature of CRON only.

I see. Thank you for your help.

Try "Celery". You can use a PHP binding to queue tasks to it and allow your sign-up page to continue loading.

If you search for "Celery" alone, you may not see the right results.

Search for "php celery" for a PHP binding of it. It's a lot better than your current solution, and celery is used on many production servers for the very task of queuing tasks.