Laravel & Supervisor Tips

When using Supervisor to run your Laravel queue workers in the background, you may run into the issue of your application crashing due to being unable to write to the log files. That is because when a log file is created by the queue worker that is executed by Supervisor, it is created by the root user. When your application tries to write to the same log file, it crashes because the user that attempts to write the log entry does not have permissions to do so.

There are multiple solutions to this and I will go through two of them.

This is aimed at CentOS web servers. It may work on other Linux distributions as well.

  • Run the queue worker with supervisor as a different user
  • Create different log files for different users

Run the queue worker with supervisor as a different user

When configuring Supervisor to run your Laravel queue worker, you can specify a user to run the process as.

$ nano /etc/supervisord.conf


See the Supervisor Configuration section in the Laravel documentation for more information.

This works but there is a catch.

The log files are created as the user you specify in supervisor’s configuration. Your application will no longer crash because it is able to write to the log files but a new issue arises. If all your configuration is stored in the .env file, it will not be available for your Laravel application to use. Laravel will still however use the cached configuration until it is cleared, then fall back to the configuration stored in your Laravel application’s config directory.

If you do not make use of the .env file, your Laravel application will work normally.

This is what I know. The child process that gets executed by supervisor to execute and run your queue worker does not run in a fully configured shell environment. It is unable to read your Laravel application’s .env file.

You can find a better solution below.

Create different log files for different users

Run the Laravel application’s queue worker with Supervisor as the root user.

Change your application’s logging config file to create daily log files based on the user that executes the script.

$ nano config/logging.php

return [
  'channels' => [
    'daily' => [
      'path' => storage_path('logs/laravel-'.php_sapi_name().'.log'),

Here is an example of the log files it creates.

-rw-r--r-- 1 root root  43K Jun 26 19:00 laravel-cli-2019-06-26.log
-rw-r--r-- 1 user userĀ  43K Jun 26 19:00 laravel-cgi-fcgi-2019-06-26.log

It does not matter who created the log files. All users will have their own log files thus averting the log file writing permissions issue outlined above.

Learning Game Development

I started learning game development a few weeks ago, starting with 2D game development.

Galaxy Shooter based on a tutorial to learn game development concepts.
It uses standard 2D game controls, arrows or a, w, d, s for movement. Space or mouse click for shooting.
Use Google Chrome if you want to try it out.

There are quite a lot of similarities between game programming and hardware programming. Both have loops that executes infinitely until you stop the game or program.

If you want to get started with game development, download and install unity3D via the Unity Hub. It’s much easier managing different unity versions and packages. If you are new to game programming I would recommend learning 2D game development concepts first. It will make 3D game development easier.

A game development course that I found useful.

At the moment I am focusing on blended character animations using user input values. User input values generally range from -1 to 1.

An interesting thing I learned while learning game development. The speed of gravity is 9.81 meters per second. You would utilise that value in order to let your character fall after jumping or walking off a surfaces.

I am looking forward to posting more about what I learn in this space.

Getting started with hardware programming

If you want to get started with hardware programming, I would suggest starting with Arduino. It was the easiest starting point for me. Arduino comes in many shapes and flavours for various kinds of projects. Think about robotics, home automations, GPS tracking units etc.

You essentially program the boards in C/CPP via a USB interface. If you want to get started with C programming I would highly recommend the book called “Let us C” by Yashavant Kanetkar. The Arduino starter kit for developers is a great starting point as it teaches you what you need to know to build great stuff. You get to build 15 small projects.

The first “real world” project I created was a gate controller. You scan an RFID tag, the tag id is sent to an online API, the API request authorisation for the tag id and sends a response back. Based on the response that is received from the API, the connected gate is opened. It is quite fun playing with small projects like this.

Workflow that works for me

I am a big fan of automating workflow processes to increase productivity. Making every second count in my profession is important not only for my personal and professional growth but for the organisation I am working for as well. 

I use GitLab as my code repository service provider of choice. GitLab has an excellent CI/CD (Continues Integration/Continues Delivery) pipeline that you can utilise to test your code quality and build processes before it goes to production. There are various use cases for it. There is also a robust issue tracker that you can utilise to keep track of work.

GitLab is created by developers for developers. 

I work in my local development environment on my MacBook Pro using Apache, PHP and MySQL. Angular and Ionic spins up its own servers for development. The terminal is one of the best tools a developer can have to get things done quicker.

I only work in GitLab branches. 99% of the time, the master branch contains the most stable code that passes code quality and build tests. When work is completed and the branch passes code quality and build testing, it gets  merged it into master. 

On the staging server, the code gets pull from the master branch. This is where user experience is tested. If any issues arise, a new branch is created, the code gets fixed and is tested before it gets merged into master. Code that does not pass on the staging server never gets pulled into production. It will stay in circulation until it is production ready.

Finally, if all is well and the code works on the staging server, it gets pulled into the production server for our clients to consume.

This is a simple but effective workflow process that I am fond of using.