laravel-pseudo-daemon
laravel-pseudo-daemon copied to clipboard
Not restarting when deploying with Envoyer
First off, thanks for a great package! Really easy to use and useful.
I'm using Forge and Envoyer, but for some reason my pseudo-daemons are not restarting after deployments. I've looked through the code and it certainly seems like it should be stopping. We use the standard /home/forge/[domain]/current convention.
I've just tested with multiple deployments but the same daemon has been running for ~30 minutes even though I deployed 4 minutes ago. The process itself only takes about 10-15 seconds to run.
Is this something you've seen before? Any idea where to look?
Well that's certainly not ideal! Maybe you can log $this->restartWhenChanged()
on every loop and then do a deploy so you can see what exactly Pseudo Daemon is watching, vs what we think it's watching? Maybe increase your sleep time to 30 or 45s so it doesn't spam your logs too much.
Thanks @aarondfrancis I'll give that a try and let you know what I figure out.
@aarondfrancis One tricky thing is that after I deploy, since the daemon doesn't restart, I need to kill it somehow. But if I just kill the process Laravel's scheduler never restarts it because the mutex lock is still in place. Is there a better way to handle this?
@aarondfrancis Hmm, this is weird. When it logs $this->restartWhenChanged() it's logging an empty response. But when I use tinker on the server and manually create an instance of the command then run $command->restartWhenChanged() it correctly returns the path to the current release (and even logs it correctly).
So for some reason when the process is run by the scheduler it's getting an empty response but when it's run manually it gets the correct path. Maybe the scheduler is running the command from a different working directory? I'll explore that possibility.
Ooo now you're onto something! Maybe add a closure command to your scheduler to see if you can dump it from there?
But if I just kill the process Laravel's scheduler never restarts it because the mutex lock is still in place. Is there a better way to handle this?
Ugh, yes, this sucks. I don't have a good workaround for that right now.
I got it working with:
public function currentForgeEnvoyerRelease()
{
if ($realPath = realpath(base_path() . '/../../current')) {
return $realPath;
}
}
I'm pretty sure this accomplishes the same thing as your version, without relying on the current working directory. If it's run from a non-forge/envoyer setting then realpath() returns false.
Any interest in a pull request?