octane: Runtime Exception: Unable to write to process ID file. (Swoole + Docker)

  • Octane Version: 0.1.0
  • Laravel Version: 8.36.0
  • PHP Version: 8.0.3
  • Database Driver & Version: PostgreSQL (libpq) Version => 13.2

Description:

Running a docker container, running laravel octane as root, shouldn’t have permission issues.

  RuntimeException 

  Unable to write to process ID file.

  at vendor/laravel/octane/src/Swoole/ServerStateFile.php:62
     58▕      */
     59▕     public function writeState(array $newState): void
     60▕     {
     61▕         if (! is_writable($this->path) && ! is_writable(dirname($this->path))) {
  ➜  62▕             throw new RuntimeException('Unable to write to process ID file.');
     63▕         }
     64▕ 
     65▕         file_put_contents($this->path, json_encode(
     66▕             array_merge($this->read(), ['state' => $newState]),

      +27 vendor frames 
  28  artisan:37
      Illuminate\Foundation\Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))

Steps To Reproduce:

  • Try to run octane in a docker container. (ENTRYPOINT ['php', 'artisan', 'octane:start'])

Dockerfile to reproduce

FROM php:latest
RUN apt-get update && apt-get upgrade -y && apt-get install git -y
COPY ./ /app/
WORKDIR /app

# Install Extensions (Swoole)
ADD https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/
RUN chmod +x /usr/local/bin/install-php-extensions && sync
RUN install-php-extensions swoole

# Install Source Code Dependencies
ADD https://getcomposer.org/composer-stable.phar /usr/local/bin/composer
RUN chmod +x /usr/local/bin/composer
RUN composer install

# Open Ports
EXPOSE 8000

# Entrypoint
ENTRYPOINT ["php", "artisan", "octane:start", "--host=0.0.0.0"]

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 19 (1 by maintainers)

Commits related to this issue

Most upvoted comments

I can only provide feedback on using within Laravel Sail (which works correctly). Can’t help debug custom Docker setups.

Well, in that case:

That is extremely faulty reasoning, and the problem with this philosophy is while sail uses docker-compose, if you’re trying to scale up to something much larger such as Kubernetes, your marketed solution doesn’t work because a use-case such as this one needs to be in the form of a singular docker image rather than a docker-compose stack to run in a cluster. As someone who has been writing code in Laravel since 5.1, I’m extremely disappointed by this.

For anyone else who is trying to get Laravel Octane into a Kubernetes cluster to make their project scale and may encounter this issue in the future: The problem seems rooted in the first execution. Simply popping into a shell and running octane:start twice caused the process to start running. Find some way to run your command twice to get it working successfully.

eg:

RUN php artisan octane:start --host=0.0.0.0 2>&1 /dev/null || echo "Initial run failed as expected."
CMD ["php", "artisan", "octane:start", "--host=0.0.0.0", "--port=8000"]

Video demonstration of solution in action: https://www.youtube.com/watch?v=MwbfxS2i1Xo. (You will also see me create an application key as I cannot run octane without one, when I am initially providing it as an environment variable)

I hope maintainers are more optimistic rather than dismissive in the future when people report issues, because rather than what you might think at first glance it supposedly being a docker issue, the problem might actually be something else involving an edge case you might not consider, like a botched sys_get_temp_dir call in PHP to test your application in a workflow where other dependencies/requirements might be pre-satisfied, rather than something from a clean state.

Insert obligatory “it works on my machine” sticker /s

I managed to solve this. For me, it was a missing /app/storage/logs location. After creating the location in my Dockerfile with RUN mkdir -p /app/storage/logs Octane starts up first time.

@AlexGodbehere that’s indeed the solution here - there’s simply no reason at all to require the existence of a logs directory. Docker applications log to stdout/stderr as per best practices. This is nothing but a bug based on a naive assumption by the Laravel team.

@AlexGodbehere testing all morning on my M1 MacBook using Minikube. The command I got to work still follows the principles of the above, but a little more merged/repititve.
It did spit out “No arguments expected for octane:start, got /dev/null.” however.

CMD php artisan octane:start 2>&1 /dev/null || php artisan octane:start --host=0.0.0.0 --port=8000

I’m still convinced the proper action for this issue should be to test that the library can actually write to $this->path rather than trusting is_writable, but I don’t have much faith that this issue will be fixed for quite some time until someone opens a new issue with more information referencing this issue.

'state_file' => storage_path('logs/octane-server-state.json') add above line in config/octane.php , its working for me

Guys after digging further in the vendor files, I did check the value of $this->path in my case /var/www/{MYLARAVELPROJECT}/storage/logs and i realized that the directory logs was not writable for “others” drwxrwxr**-x just change others to have w (write permissions) drwxrwxrw**x

Issue solved !!!

I’m encountering the same issue but the second restart doesn’t help.

I’m trying to run Octane on a k8s cluster and receiving the Unable to write to process ID file. at /app/vendor/laravel/octane/src/Swoole/ServerStateFile.php error message as above. The aforementioned directory has the correct permissions and simply removing the checks in ServerStateFile.php sees Octane start up without fault.

I need to do some more digging on this but it looks like @Elycin’s theory of is_writable only checking the user and not groups could be a good place to start.