Scheduler Support

[clarkeash]

I previously asked about adding cron support #657 which is not very reliable on mac and Apple discourage the use of it.

From what I have been reading it looks like launchd could work quite well, just wanted to check if you'd be open to this before I put the work in.

Thanks :)

[mattstauffer]

I like the idea but I'm definitely nervous about this really significantly expanding the scope of what Valet tries to do. I can't decide whether this is fine, or too much, whether it should maybe be an extension, or should be its own thing, or what. Not ignoring this, just not 100% sure what to do with it.

[drbyte]

I like the idea too, as I've also had frustrations with the reliability issues, and just avoid it.

If the implementation into Valet is too stretching, there are a couple options:

• At least document the steps one could take to do it reliably themselves.
• Make a valet extension that does it by just dropping it in (or even better, just doing a git checkout in the extensions dir, as that's already supported), and then people who want it can enable it for themselves.

[mattstauffer]

I guess the biggest question about whether it fits is A) how much code and technical complexity are we introducing, B) how much customer support is being added onto @drbyte's already hugely full and entirely volunteer plate lol, and C) of course does this make sense to be included.

I think C is: It could make sense but it could be argued it doesn't.
And A and C probably would be answered best by seeing an implementation.

[drbyte]

Agreed. If it's a simple implementation, then there's a good argument to include it. It'd be good if there can be some indication of which macOS versions will support it without any/many gotchas.
If it'll "just work", then sweet! 👍

[clarkeash]

Hey, I’m on holiday at the moment so can’t do much, but my understanding is that launchd already comes on Mac and all we should need to do is create a xml file per site, and call some commands.

I think the best way to see the effort involved will be to just give it a go, which I can do in a couple of weeks.

[okaufmann]

What about just using an alias running in a Terminal window? I use the following bash function:

scheduler() {
	while :
	do
		php artisan schedule:run
		echo "Sleeping 60 seconds..."
		sleep 60
	done
}

[drbyte]

@okaufmann Yes, that's the sort of thing I do when I need it running locally for dev purposes. It's definitely fast and easy to do it that way. And perfectly project-specific, as it needs to be.

[drbyte]

The trouble with Valet trying to provide something for this (launchd, cron, whatever) is that the scheduler is project-specific, which is not really Valet's role.

• artisan needs to know and run with the right working directory
• not "all" projects need the scheduler running
• what to do when a scheduler instance fails?
• or needs reloading?
• when to start? on boot? or on login? or only when working on the project?
• massive log accumulation if the scheduler triggers errors while unattended, due to a bug or unfinished section of code
• etc

I'm still interested in a working doc that can be used as a quick reference. Perhaps the alias/function mentioned by @okaufmann above may be enough to add to the core Laravel docs, as it's perfectly relevant to Laravel and not specific to Valet.

[clarkeash]

I agree that it is project specific, but we could add something to each driver file that defines how the scheduler is configured, and if we don't add it then that driver doesn't support the scheduler.

We could have commands such as:

• schedule:start
• schedule:stop
• schedule:status

So that it is only enabled per project if its wanted and it can be restarted should it need it.
I am not sure how we deal with the log accumulation.

I think it would a good addition to valet but I do understand the hesitation to add this.

Also are there any docs on valet extensions as I didn't know they existed?

[drbyte]

@clarkeash ,
Extensions are simply additional application Commands to the Valet Application, which uses mnapoli/silly to create a simpler interface around symfony/console.

Here are some issue comments where I've given examples of extensions:
#883 (comment)
#798 (comment)
#659 (comment)

[drbyte]

@clarkeash
Any thoughts about pros/cons of using supervisord http://supervisord.org ?

Possible steps could include:

• Install using brew install supervisor
• The default config at /usr/local/etc/supervisord.ini is fine, and it points to auto-loading any configs from /usr/local/etc/supervisor.d/*.ini so that makes things simple for individual jobs.
• mkdir -p /usr/local/etc/supervisor.d/ to make sure that auto-load dir exists

And then perhaps something like this basic config (akin to what @okaufmann posted above in #804 (comment)) would suit?
/usr/local/etc/supervisor.d/site_name.ini

[program:artisan-schedule]
; Run the Laravel Artisan scheduler every minute
command=/bin/bash -c "while true; do (php /Users/MYUSERNAME/PATH_TO_LARAVEL_PROJECT/artisan schedule:run --verbose --no-interaction &); sleep 60; done"
; user=MYUSERNAME
autostart=true
autorestart=true
numprocs=1
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

[clarkeash]

@drbyte I don't know. Supervisor is a good tool but I feel like this is misusing it as its for keeping processes alive, it's not a scheduler.

If we compare it to launchd (https://www.launchd.info), I think we can achieve the same results with either tool however, launchd is designed for recurring jobs and is already on every mac and doesn't need to be installed like supervisor does.

Are you aware of any advantages of using supervisor or disadvantages of launchd that I am not aware of?

I am not against supervisor, i'm just trying to make sure we go with the right tool

[drbyte]

Totally fair point. And I agree with your description of each tools' normal intended purpose. With Valet, since it's close-to-the-metal launchd is probably most appropriate (where with docker supervisor would be more relevant).

Both tools require some sort of "script" to create their respective configs, so that part of the exercise is still relevant, although the outcome slightly different depending on the tool.

Either way, the generated configs need to be:

• uniquely named
• able to be started/stopped with ease
• able to be monitored (supervisor may be easier there)
• self-terminating if the directory/project is deleted (supervisor may be easier there)
• not fill up system logs, nor waste CPU time, if failures are happening

I worry that all of this adds a lot of stuff to Valet that's really outside of its scope and control. But still interested in exploring whether it can be accommodated with simplicity.
As discussed, best to build it as a set of custom commands in an Extension ... just in case it becomes obvious to treat it as a separate package. Plus it's easier to test if a couple files can just be dropped in ;)

[drbyte]

While on the surface it says it's especially beneficial for testing operation of scheduled tasks over time, this may be a suitable scheduler alternative for those willing to have long-running processes active and not wanting supervisor or launchd:
https://freek.dev/1689-a-package-to-run-the-laravel-scheduler-without-relying-on-cron

[clarkeash]

Yea, okay.