Jobs never run

[agentphoenix]

I was really excited to see this come across Twitter today and started playing with it this afternoon. Unfortunately though, it doesn't look like it works at this point.

I created a simple Artisan task to add a message to the log file. I manually set up a cronjob to run every minute that called the specific command and it did as expected. Updated the job to run through Dispatcher and nothing ever happens. I can run the job manually, but no matter what I change (setting it to run every minute, setting it on a schedule, running the scheduled:run command manually, etc.), the job never runs.

Let me know what you need from me to help debug what might be going on. Thanks for the package!

[bkuhl]

Can you provide me the output of scheduled:summary?

[agentphoenix]

[bkuhl]

@agentphoenix, thanks for taking the time to shoot me a screenshot of what you see in the output. Based on the output it looks like you're using $scheduler->everyMinutes(1);. This actually kind of an invalid cron syntax. You see, * already runs the command every minute and */2 does every 2 minutes. Simply returning $scheduler without adjusting the scheduler at all will by default run the command every minute.

I'll have to put some thought into how to handle ->everyMinutes(1). In the meantime, if you want it to run every minute, just return $scheduler;.

[agentphoenix]

It doesn't actually matter if I just return $scheduler or if I set a daily schedule, the jobs never run. I even tried manually running php artisan scheduled:run and they don't run, but if I manually run the command I created, everything works fine.

I'm just at a loss for how to get this to work without manually setting the cron jobs like before.

[bkuhl]

Can you provide me the entry you have in your crontab? The 1>> /dev/null 2>& portion is catching errors and command output and essentially throwing them away. Try removing that and see if you end up with any cron output.

[agentphoenix]

Yeah, I figured that out, so I pulled it out early on so that it would throw errors. No errors are being thrown now though, it just never runs.

My crontab is (path to artisan truncated):

* * * * * /Applications/MAMP/bin/php/php5.4.19/bin/php [...]/artisan scheduled:run

[bkuhl]

Can you show me the schedule() method you're currently using? Can you also show me how you're logging? Have you verified that the logging directory is writable?

[agentphoenix]

public function schedule(Schedulable $scheduler)
{
    return $scheduler;
}
public function fire()
{
    \File::append(public_path()."/test.txt", "test command ran\n");
    \Log::info('Test command ran.');
}

I know that the logging works right because when I run the command manually, it creates a line in the log and appends to the test text file.

[bkuhl]

I created a fresh laravel project with nothing except a single command using the same schedule()/fire() as you have shown here. My command successfully runs and writes to the log files. I don't believe it's an issue with this package.

[agentphoenix]

Alright. I'll keep digging and see if I can find what might be causing the issue. Thanks!

[bkuhl]

Sorry I couldn't be of more help... when you find the solution, please update this issue.

[bkuhl]

I've just pushed version 1.0.1 which contains a few minor fixes, one of which is the cron driver fix for ->everyMinutes(1) so it will now compute to *.instead of */1.

[agentphoenix]

I've made a little headway with this.

The first issue is that I think there's a step missing from the installation instructions. Once I realized there was a config file in the vendor directory, I ran a config:publish to put that into my app/config/packages directory. Once I did that, manually calling php artisan scheduled:run did as I expected and ran my job. Every time I run it manually, it works, but letting the cron do it doesn't actually execute my command. It's strange to be sure.

I put some debugging code in and here's what's happening as it steps through the process. Any insight you might be able to offer would be awesome!

[2014-03-08 02:08:00] production.DEBUG: scheduled:run started [] []
[2014-03-08 02:08:00] production.DEBUG: php [...]/artisan tv:test & > /dev/null 2>&1 [] []
[2014-03-08 02:08:00] production.DEBUG: scheduled:run ended [] []

It's clearly building the command properly, but when it runs that command through scheduled:run, nothing happens. I'm gonna sleep on it and see if I can come up with any ideas, but if anything jumps out at you, let me know!

[bkuhl]

Comment out this line from the package in the vendor directory and see if you get any output there.
https://github.com/Indatus/dispatcher/blob/master/src/Indatus/Dispatcher/Services/CommandService.php#L71

[agentphoenix]

Success!

Commenting out that line didn't reveal anything, but I dug deeper into the exec command because that where it seemed to be having the issues. With a little debugging, I figured out that the command was throwing Laravel's error about mcrypt not being enabled. That made no sense to me at first until I realized that exec ignores the fact that I update my PATH with the MAMP version of PHP instead of the system version.

In order to get it to work locally, I had to create a symbolic link from the MAMP version of PHP to the system version. Once I did that, everything started working. I'm hoping this won't be an issue when it comes time to deploy this to a shared host, but now that I know what's happening, I'll know what to look for.

Thanks for all your help. This is going to be an invaluable tool for many of my projects!

[bkuhl]

Excellent, I'm glad you got it working!

[bkuhl]

I've added a note about mcrypt to the FAQ in hopes of preventing a big hassle for someone else in the future.

[agentphoenix]

It's just strange that exec uses a totally different version of PHP in that instance. The symbolic thing was key to fixing it. Hopefully if anyone runs across this issue, they'll see my comments above.

Thanks again for all your help with this. Been running some jobs through Dispatchers the last couple of days and it works like a charm!

[bkuhl]

Thanks, glad to hear it was worth building :)

On my mac, using the symbolic link method broke when the OS updated. So I added alias php="/usr/local/Cellar/php54/5.4.23/bin/php to my .bash_profile which fixes it for me. This will only work for the user that I add the .bash_profile to of course, but for a dev box that's usually sufficient.

[agentphoenix]

Interesting. I'll have to keep an eye out for that when the next software update comes out.

Before adding the symbolic link, I'd added PHP to my path through my ZSH profile, but exec didn't run through ZSH, so maybe if I add PHP to the path of the bash profile, I could get around the issue with the symbolic link.

[marlocorridor]

@agentphoenix, could you show me how did you use the exec(). I just need to see the debug error from mcrypt too.

@bkuhl Do you know how he might done that?

Thanks in advance.

[bkuhl]

Using php artisan scheduled:run --debug will show the command that is being used to run commands.