Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not restarting when deploying with Envoyer #6

Open
adamthehutt opened this issue Jul 28, 2022 · 6 comments
Open

Not restarting when deploying with Envoyer #6

adamthehutt opened this issue Jul 28, 2022 · 6 comments

Comments

@adamthehutt
Copy link

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?

@aarondfrancis
Copy link
Owner

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.

@adamthehutt
Copy link
Author

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

@adamthehutt
Copy link
Author

@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
Copy link
Author

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

@aarondfrancis
Copy link
Owner

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.

@adamthehutt
Copy link
Author

adamthehutt commented Jul 29, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants