[stickfigure]

so I told them how to X

No, you didn't.

What you probably meant is "run it from cron, or create an OS service that starts from init.d/systemd/whatever". Which answers the question, but isn't very impressive from a technology stack.

[CiPHPerCoder]

No, what I meant is: Run this command. It can run for as long as you want it to. That's a long-running process, by definition.

If they wanted something more specific, they should ask for what they really want.

[Piskvorrr]

Except that "PHP is meant to die", i.e. doesn't perform well as a long-running process, you'll keep running into bugs and warts. Software Gunslinger has explained that well: https://software-gunslinger.tumblr.com/post/47131406821/php-...

[penagwin]

I kinda meant both. I feel silly not knowing that it's only "php ./script.php".

I also meant long-running processes, which it sounds like is still problematic. To be fair, it doesn't sound like PHP was ever designed to be used for long-running processes, to which I guess "Fair enough", but that might make things like a job worker queue more complicated if you want to write the workers in PHP (it sounds like you'll need a dispatcher in a different language because that would be a long-running process).

[r34]

This article is from 2013 and is not relevant anymore. Dozens of concepts useful even for writing desktop apps with PHP (I don't claim that it is the best choice) were presented in book "PHP Beyond the Web".

[Piskvorrr]

Not saying it's not possible: from where I am in 2020, long-lived PHP 7.4 processes still exhibit the described symptoms (memory leaks, even segfaults). In other words, tools for the job.

[CiPHPerCoder]

Memory leaks don't surprise me. Segfaults do.

Have you reported them upstream? That implies a memory safety or garbage collection bug.

[Piskvorrr]

Yup, GC bugs, mostly; some fixed, some are hard to repro...