Link Robins Metronome (No proc_open no problem)

Karl

Keeps Flarum's scheduled tasks running on shared hosting where PHP's proc_open function is disabled.

The problem

Many shared hosts disable proc_open, and Flarum's scheduler depends on it: every scheduled task is launched as a separate process. On those hosts php flarum schedule:run looks fine. It exits cleanly, and the admin dashboard even reports the scheduler as active. But no task ever actually runs. The only trace is a line buried in the log for every task, every minute:

The Process class relies on proc_open, which is not available on your PHP installation.

So extensions that clean up, sync, or aggregate on a schedule quietly do nothing, and it looks like their bug.

What it does

Adds a schedule:run-inline command that walks the exact same schedule as schedule:run, but runs each due task inside the one PHP process your cron job already starts. Nothing needs proc_open at all.

Due-time, environment and maintenance-mode checks work as before.
withoutOverlapping() locks are honored, and are compatible both ways with locks taken by the stock runner.
onOneServer() is honored.
Before/after hooks, success/failure hooks and sendOutputTo() / appendOutputTo() output capture all work.
Closure-based tasks run through Flarum's own machinery untouched.
Failures are reported to the Flarum log, and the admin dashboard's scheduler status is updated the same way the stock runner updates it.

Two things cannot be identical without proc_open, and the command is upfront about both instead of skipping work silently: a task that asks for runInBackground() runs in the foreground instead (with a warning, and it still runs), and a task scheduled as a raw shell command via exec() cannot run at all, so it is reported as a failed task rather than ignored.

If your hosting does have proc_open, keep using the stock schedule:run. This is for the hosts where that is not an option.

Requirements

Flarum 2.0.0+
PHP 8.3+

There is no build for Flarum 1.8.

Installation

composer require linkrobins/metronome

Then enable the extension in admin → Extensions, and point your cron job (or your host's "cron jobs" panel) at the new command once per minute:

* * * * * php /path/to/flarum/flarum schedule:run-inline

That is the whole setup. There are no settings.

License

MIT.

IanM

I’m reading this and wondering, why is this a new extension, rather than an issue raised against the framework?

IMO this is such a foundational thing, that someone installing Flarum on such a host would expect it to “just work”, rather than to go hunting for an extension to fix it?

luceos

IanM I’m reading this and wondering, why is this a new extension, rather than an issue raised against the framework?

It's a new extension because for people less versed on the technical side of things, it's not always clear whether something is caused by Flarum, or an upstream dependency like Laravel or Symfony. Heck, I can imagine this borders on the "it's a given". To those people who tried their hand at agentic development, and have become rather familiar with it, it's easier to just send the respective instructions to such an agent and propose a solution. Quick win, quick fix, quick happy.

I for one don't see any harm in these, in fact in the early beta's we had a lot of micro extensions that simply seemed superfluous. They were still much appreciated and their functionality was later integrated into core.

What I think would be helpful for someone like Karl, is to hear affirmation that resolving this issue was a good judgment call, and that the given functionality can be ported into core. After all, we're all here to make the product better, one way or another. In fact him providing the extension can even be considering as a investigation task to see whether it's even possible to do scheduling without proc_open.

As for the technical implementation, I'm very curious whether withoutOverlapping and the non-async nature without proc_open will lead to missed triggers and thus scheduled tasks not being executed.

IanM

luceos It's nothing to do with technical understanding. More about core should already take care of this. Yes, I'm not a fan of the implementation here, but hey, ho

Karl

@IanM @luceos I figured that there’s only a handful of shared hosted Flarum users here that are faced with this issue. I also know Flarum wants to keep things lightweight and didn’t think that this would be be considered for core honestly.
If you want, I can discard this extension and make it a PR if requested by Flarum Core. I would also like feedback if any as well.

luceos

IanM I see, the answer is this.

Scheduled tasks run every minute, but each of those minutes any number of tasks could potentially be fired. Laravel uses proc_open to asynchronously fire these tasks and wait for them to finish before marking the initial process as succeeded. As a consequence of this implementation all tasks are fired (pretty much) at the given minute.

In the case of this extension, where a pipeline is created to process each task synchronously after each other, the execution time of the task is delayed.
The Laravel method is known to be not accurate, but the margins are small.

I don't think core can take care of this honestly, and this extension is pretty much a last resort solution. Most shared hosting providers should have no issue with allowing proc_open if given the reason.

Karl I figured that there’s only a handful of shared hosted Flarum users here

I think a lot of people run into this actually. Because almost all shared hosting environments will have proc_open blocked by default, similar to the path traversal problem going outside of the docroot in #39748.

DLBB

Thanks a lot for looking into this, @Karl — appreciate the quick turnaround!

Quick heads up on my end: my proc_open issue is on a live 1.x site, and since Metronome needs Flarum 2.0+, I'm not able to test it right now without upgrading production, which I'd rather not rush. I do have an upgrade to 2.x planned, so I'll circle back and give it a proper test once that's done.

For reference, here's a snippet of the log from my end — fires every minute on the scheduler tick:

[2026-08-30 21:21:01] flarum.ERROR: Symfony\Component\Process\Exception\LogicException: The Process class relies on proc_open, which is not available on your PHP installation. in vendor/symfony/process/Process.php:147
...
#3 vendor/illuminate/console/Scheduling/ScheduleRunCommand.php(143): Illuminate\Console\Scheduling\Event->run()
...

Thanks again for taking this seriously and running with it!

EDIT: Attached is the full day's log for your reference.

flarum-2026-08-30.txt

[2026-08-30 02:49:10] flarum.ERROR: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'database.settings' doesn't exist in /home/user/domains/example.com/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:82
Stack trace:
#0 /home/user/domains/example.com/public_html/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php(82): PDO->prepare()
#1 /home/user/domains/example.com/public_html/vendor/illuminate/database/Connection.php(368): Doctrine\DBAL\Driver\PDOConnection->prepare()
#2 /home/user/domains/example.com/public_html/vendor/illuminate/database/Connection.php(705): Illuminate\Database\Connection->{closure:Illuminate\Database\Connection::select():359}()

Download file

Error previewing file. It may have been deleted, or the provided file ID is invalid.

Karl

DLBB I can do a back port to solve your issue. And then wait for a green light on the PR from @IanM so it’s included to core in 2.x.

Karl

luceos no missed triggers. The stock runner is sequential too. It waits on each foreground task before starting the next, and collects due events once at invocation start the same way it does. Cross-minute coverage comes from cron itself firing every minute, and the overlap locks are the same cache locks core takes, so a stock runner and mine coordinate fine side by side (tested that combination live).

Two real differences, both bounded and neither silent: runInBackground() tasks run in the foreground with a warning, so a long one stretches the invocation. And sub-minute repeatable tasks (everyFifteenSeconds and friends) fire once per minute instead of looping until the end of the minute. Just added that second one to the readme.

ernestdefoe

@Karl @IanM @luceos if this could be something added to core it would probably be better there but if it's not something that can be added easily or something that truly doesn't belong in core for the "few" people that may use it then there's nothing wrong with it being a 3rd party extension. As @luceos mentioned above and I remember those days of micro extensions that served a purpose until something was added to core that served the same function. Similar to my seamless refresh extension it's a micro extension that serves a purpose.

rafaucau

I’d also like to suggest trying a custom php.ini as a possible workaround.
For example:

php -c /path/to/php.ini flarum schedule:run

This might be enough to re-enable proc_open on some hosting setups, although it will not help if the provider enforces the restriction independently of the selected PHP configuration.

Karl

rafaucau yes that is the best option, but some shared hosts disable certain items to “harden” their security.

DLBB

rafaucau Can confirm the custom php.ini approach works.

I copied my host's disable_functions list into a custom php.ini, took out proc_open (and ended up needing to remove proc_close too, since Symfony's Console component calls both together — with only proc_open re-enabled it threw a fatal error), then had the cron job load it via -c:

 -c /home/user/domains/example.com/custom-php.ini flarum schedule:run >> /dev/null 2>&1

After that, the scheduler started running tasks normally and the proc_open errors stopped showing up in the log. Worth trying first if your host lets you pass a custom -c path for CLI — mine does, and it turns out the restriction wasn't going any deeper than the default php.ini.

Still can't test Metronome itself until I upgrade to 2.x, but glad to have a working interim fix either way. Thanks all for digging into this.

Have a pleasant evening, everyone!

Karl

v1.1.0 is out.

Metronome now notices when the old scheduler is still running next to it. The install instructions say to replace your scheduler cron line with schedule:run-inline, but it is easy to add the new line and forget to remove the old one, and a forum running both executes every scheduled task twice per minute. withoutOverlapping()will not save you there: it only stops runs that overlap in time, not two quick runs in a row.

So Metronome now warns, in its output and in the Flarum log, whenever a stock schedule:run has also run in the last few minutes, and keeps warning until the leftover line is removed. A one-off manual schedule:run triggers the same notice once and the message says it is safe to ignore.

Also documented since the last release: tasks scheduled at sub-minute rates fire once per cron invocation rather than repeating within the minute. Nothing in the ecosystem schedules sub-minute today, but if yours does, know it will tick at cron's pace.

linkrobins/metronomev1.1.0

Karl

DLBB I was under the impression that you've already tried it lol.

DLBB

Karl Ha, no worries — that was the custom php.ini workaround from earlier. I'm still on 1.x, so trying out Metronome properly is still on my to-do list once I move to 2.x.

Good call adding the double-scheduler check, by the way — an easy thing to miss during migration otherwise.

Appreciate you sticking with this and continuing to polish it. Worth keeping it maintained regardless — with how often shared hosts disable proc_open, someone's going to need this sooner or later, even beyond this thread.

I'll circle back with results once I've had a proper go at testing it.

Forogramero

Karl

Dear:

Thank you for creating Metronome, such a useful and important extension for the Flarum community. I would say it is a very important piece of the Flarum ecosystem, especially for small and medium-sized community forums.

I hadn't realized just how important it was until users started reporting that they weren't receiving their system notifications. I spent half a day trying to find the problem, together with ChatGPT, which couldn't solve it, until I searched this forum and found the solution thanks to the term “proc-open.”

It turned out that Hostinger does not allow proc-open, and I had no idea. I had assumed that simply enabling the Pusher extension would be enough. Big mistake.

I didn't fully realize this until I installed the Extension Manager, another very useful tool, which informed me—or rather, confirmed it, since ChatGPT and I had already detected the issue.

But detecting the problem was only half the battle. And well, all my problems, as well as those of my hundreds of users, were solved at once thanks to the Metronome extension.

I simply had to increase the memory limit to 512 MB and add “-inline” to my cron job, and that was it. Problem solved, thanks to this great extension.

If I had paid attention to Metronome from the beginning, I think I could have saved myself a lot of headaches.

Thank you, Karl, for making life a little easier for internet users.