Could not open input file: <project root>/crunz

[pridit]

Crunz version:
v1.11.0-beta.1

PHP version:
7.2.5

Operating system type and version:
Ubuntu 18.04.1

Description
Since upgrading to this beta release, calling crunz schedule:run results in Could not open input file: <project root>/crunz

Intermittently, it may also throw No task found! Please check your source path. as well without any configuration change, but I have not been able to reliably reproduce this one.

Both of these are not an issue for releases prior to this version.

How to reproduce
Upgrade to v1.11.0-beta.1 or later and attempt to call schedule:run.

[kinoute]

Regarding the "No task found" error, I encountered the same when trying to use the 1.11.0 beta few weeks ago after the empty email log fix was added. It only happened on my production server (Ubuntu 16.04.5, PHP 7.2.13). I had to rollback. I couldn't reproduce the bug locally so I didn't report it, thinking it was a problem on my side.

I couldn't investigate more on my production server, I needed my tasks to run again really quickly sorry.

[PabloKowalczyk]

@pridit i need some details to reproduce, please provide paths relative to <project root>:

1. Location of config (crunz.yml) file
2. Value of source parameter in config file
3. Location of tasks directory
4. Location of vendors directory
5. Location of crunz

@kinoute Could you try to investigate this bug locally?

I think that this bug is caused by changes in #146, all paths are relative to cwd, not crunz bin file.

[kinoute]

The thing is, I can't reproduce it locally on My Mac. With an empty project, respecting the same project's tree and even importing my crunz.yml file, it works (with the beta or the rc1 version).

IIRC, I even tried on my server with an empty project and it was working as well, that's why I didn't report it, thinking my project was the problem.

[kinoute]

Since @pridit said he wasn't able to reproduce the bug everytime, I made a loop to see if I could catch it:

We can see that with the loop, I get the "No task error" every time. But running directly the script, It works. Could it be a problem about how schedule:run is called, by who and where?

When I use part of the cronjob entry to simulate the cronjob that should run every minute, I get the same error as well:

[PabloKowalczyk]

Could it be a problem about how schedule:run is called, by who and where?

I think the key here is where, after #146 all paths resolution is relative to cwd (current working directory). Could you paste what is the cwd in for loop?

About the second screenshot, try to do * * * * * cd /Volumes/Storage/kinoute/Sites/crunz-error && vendor/bin/crunz schedulre:run, if this works it means this bug is definitely related to paths resolution and PR #146.

[kinoute]

* * * * * cd /Volumes/Storage/kinoute/Sites/crunz-error && vendor/bin/crunz schedule:run works.

Also:

[PabloKowalczyk]

We have answer, thanks @kinoute.

[PabloKowalczyk]

@pridit @kinoute colud you test that version https://github.com/PabloKowalczyk/crunz/tree/fix-missing-tasks-source? Remember about adding -vvv switch, should tell you more and could be useful in further debug/fixing.

[kinoute]

Is it helpful?

[PabloKowalczyk]

It is :) Forgot about tasks in legacy paths.

[PabloKowalczyk]

@kinoute could test again after update, please?

[kinoute]

No change :(

[PabloKowalczyk]

Interesting, where are your tasks? In /Volumes/Storage/kinoute/Sites/crunz-error/tasks?

[kinoute]

There are in app/tasks.

My project's tree is like this:

crunz.yml

[PabloKowalczyk]

So, i must also fallback config.yml resolution, thanks @kinoute!

[PabloKowalczyk]

Another update pushed, could you test it @kinoute? Maybe @pridit also have some time to test patch mentioned earlier?
In my tests it fallbacks as expected, if you confirm it also works for you it will be first step to stable v1.11.

[kinoute]

[PabloKowalczyk]

Already pushed fixes, could retest please?

[kinoute]

No more "no task found" error, but the task fails:

[PabloKowalczyk]

Did that task work in v1.10?

[kinoute]

the task is only echo 'test'; 😃

[PabloKowalczyk]

Your screenshot tells cd app/game/test; php test.php :)

[kinoute]

It's because I use the in() functionality. Here is the task:

require_once dirname(__DIR__) . '/../vendor/autoload.php';

use Crunz\Schedule;

$schedule = new Schedule();

$schedule->run('php test.php')
         ->everyMinute()
         ->in('app/game/test')
         ->description('Test');

return $schedule;

[PabloKowalczyk]

Done some testing with similar task:

<?php

use Crunz\Schedule;

$scheduler = new Schedule();

$scheduler
    ->run('pwd')
    ->in('vendor/symfony')
    ->description('PWD')
    ->everyMinute();

return $scheduler;

v1.7.3, v1.10.1 and v1.11-rc.1 completed with success, but only because pwd is global binary. cding always was cwd-relative and this behavior not changed in v1.11. Could you test some older versions to make sure v1.11 not break something?

[kinoute]

Same problem with v1.10.1. Do you want me to upload my test repo?

[PabloKowalczyk]

No, it is not necessary. Bug seems solved to me, WDYT?

[kinoute]

Really? I have still the problem here, even with your last commits on fix-missing-tasks-source.

Running vendor/bin/crunz schedule:run -vvv within the repo : works
Simulating the cron job call with /path/to/project/vendor/bin/crunz... makes the task fail.

https://gist.github.com/kinoute/2f1eec3c4908f17b63001aa29bc38795

[PabloKowalczyk]

Running vendor/bin/crunz schedule:run -vvv within the repo : works
Simulating the cron job call with /path/to/project/vendor/bin/crunz... makes the task fail.

Isn't it the same behavior as on v1.10.1, v1.7.3 or any other version? I have tested it and it fails on any earlier version, not only newest v1.11. The ->in() call was always related to cwd. If you think that ->in() should work it is other case which we can discuss in other issue, but it is not caused by changes in v1.11.

[kinoute]

Okay sure, I will maybe create another issue to it. But I thought we were fixing path related problems at once, that's why. Since you took over the development of this library, I run in production tasks with all of them using in() and a cronjob with call to /path/to/project/vendor etc. Never had any issue before but yeah, I can't tell exactly when it began.

[PabloKowalczyk]

What version you use in production? Maybe I'm wrong and ->in() is broken only in v1.11 or maybe commands you use in production are globally and do not need changing cwd, so even if cd fail they can end successfully? Could you paste one of these commands?

[kinoute]

I posted my test repo here: https://github.com/kinoute/crunz-error (used locally on PHP 7.3 by the way, using your latest fixes on your personal GitHub repo). That's the one who works from within the repo, but the task fails when getting called by the cronjob call /path/to/project etc.

To sum up my use of crunz, I've been using the same kind of tasks (all of them using in()) since you fixed the CPU usage in v1.5.1. I started to have description/error missing in email errors afterwards (#161) in v1.10.1 and you fixed the bug not into the same version, but in the next one, v1.11.0-beta.2.

Therefore, I updated my version in production, but then I got the problem described here, "No task found". I immediately downgraded at that time because I couldn't reproduce the bug locally. Since this issue has been discussed here, I updated again to v1.11.0-rc.1 in production. I still have the same issue about tasks not being found, but I use a workaround to avoid this error (I basically changed the cronjob call to "cd /path/to/project && vendor...").

I also have a problem where some scripts generate an empty error every time from crunz as discussed in the other issue, but it seems related to a PHP 7.3.0 bug and I'm waiting 7.3.1 or 7.3.2 to see how it goes. For the moment, I disabled email_errors.

[PabloKowalczyk]

Tested your repository against v1.5.1, calling vendor/bin/crunz schedulre:run from project root was successful, but call from / ends with error sh: 1: cd: can't cd to app/game/test - the same error as you have on my branch.
On your production ->in() calls probably fails, but your commands are global so they ends without errors.

[kinoute]

Thanks for the answer. Now I know why my production tasks were working when the local ones weren't. I think the initial error of this issue has been fixed in your own repo so I have no more to add.

I will update when PHP 7.3.2 is released since, according to one of the developers, it will fix my annoying other bug.

[PabloKowalczyk]

I think the initial error of this issue has been fixed

Glad to hear.
End-to-end needs some polishing but patch is almost ready, i would like to merge it in the next week.

[PabloKowalczyk]

PR #181 merged into v1.11.x, thanks @pridit and @kinoute.