laravel-pseudo-daemon icon indicating copy to clipboard operation
laravel-pseudo-daemon copied to clipboard

Not restarting when deploying with Envoyer

Open adamthehutt opened this issue 2 years ago • 6 comments

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?

adamthehutt avatar Jul 28 '22 22:07 adamthehutt

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.

aarondfrancis avatar Jul 28 '22 22:07 aarondfrancis

Thanks @aarondfrancis I'll give that a try and let you know what I figure out.

adamthehutt avatar Jul 29 '22 18:07 adamthehutt

@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?

adamthehutt avatar Jul 29 '22 18:07 adamthehutt

@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.

adamthehutt avatar Jul 29 '22 19:07 adamthehutt

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.

aarondfrancis avatar Jul 29 '22 19:07 aarondfrancis

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?

adamthehutt avatar Jul 29 '22 21:07 adamthehutt