Supervisor not identifying Bash environment variables - laravel

I have an issue when using environment variable defined in .bash_profile. When I run this command :
sudo supervisord -c /etc/supervisord.conf.
It always return :
format string '%(ENV_Jas_name)s' for 'program:laravel-process-user-data-queue.user' contains names ('ENV_Jas_name') which cannot be expanded. .
I am trying to set the user and absolute path of command from the environment variables. Config files :
1. supervisord.conf file:
[unix_http_server]
file=/tmp/supervisor.sock ; the path to the socket file
[supervisord]
enviroment=Jas_root3=%(ENV_nnsms3_root)s,Jas_name=%(ENV_Jas_name$)
logfile=/tmp/supervisord.log ; main log file; default $CWD/supervisord.log
logfile_maxbytes=50MB ; max main logfile bytes b4 rotation; default 50MB
logfile_backups=10 ; # of main logfile backups; 0 means none, default 10
loglevel=info ; log level; default info; others: debug,warn,trace
pidfile=/tmp/supervisord.pid ; supervisord pidfile; default supervisord.pid
nodaemon=false ; start in foreground if true; default false
minfds=1024 ; min. avail startup file descriptors; default 1024
minprocs=200 ; min. avail process descriptors;default 200
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[program:laravel-process-user-data-queue]
process_name=%(program_name)s_%(process_num)02d
command=sudo php %(ENV_Jas_root)s/app/artisan queue:listen --tries=3 --queue=high,default,low
autostart=true
autorestart=true
user=%(ENV_Jas_name)s
numprocs=1
redirect_stderr=true
stderr_logfile=%(ENV_Jas_root)s/app/storage/logs/supervisor/processuserdata.err.log
stdout_logfile=%(ENV_Jas_root)s/app/storage/logs/supervisor/processuserdata.out.log
2. .Bash_profile :
source ~/.profile
export PATH=/Applications/MAMP/bin/php/php7.0.19/bin:$PATH
export PATH="/usr/local/sbin:$PATH"
PATH="/Library/Frameworks/Python.framework/Versions/3.6/bin:${PATH}"
export PATH
export Jas_root="/Users/JasemAl-sadi/Desktop/SMS/Local websites/Jas_main"
export Jas_user="Sony"
I am running in macOS High Sierra with Mamp pro with PHP 7.1 with supervisor 3.3.3
**I saw most of the related issues, but nothing work :( **

Related

Supervisor socket error: Unlinking stale socket /tmp/supervisor.sock

I installed Supervisor on a shared Debian server. When I run:
supervisord -c supervisord.conf
I get this error continuously untill I kill it:Unlinking stale socket /tmp/supervisor.sock
When I run supervisorctl status I get:
unix:///tmp/supervisor.sock no such file
My supervisord.conf file like this (I didn`t change anything):
[unix_http_server]
file=/tmp/supervisor.sock ; (the path to the socket file)
;chmod=0700 ; socket file mode (default 0700)
[supervisord]
logfile=/tmp/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=10 ; (num of main logfile rotation backups;default 10)
loglevel=info ; (log level;default info; others: debug,warn,trace)
pidfile=/tmp/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false ; (start in foreground if true;default false)
minfds=1024 ; (min. avail startup file descriptors;default 1024)
minprocs=200 ; (min. avail process descriptors;default 200)
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; use a unix:// URL for a unix socket
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /path/to/app/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
;user=
numprocs=8
redirect_stderr=true
stdout_logfile= /path/to/app/worker.log
When I cd to /tmp to look for the socket file, the socket looks like this:
supervisor.sock.824804. The six-digit number gets somehow generated randomly by the server after I run the supervisord -c supervisord.confcommand. Do I have to consider this six-digit in the supervisord.config file? And how to I do this, since it gets generated randomly? I have already installed and run Supervisor on a macOS Mojave too and there were no problemes and the socket file just locked like supervisor.sock. Thank for any help and suggestion in advance!
I set nodaemon = true in supervisord.conf and that fixed my problem.
unlink /tmp/supervisor.sock
then I fixed it "Unlinking stale socket /tmp/supervisord.sock".

is there a way to ask supervisor to source vars from a file?

I have a supervisor conf file that need a lot of environment variables::
$ cat /etc/supervisor/conf.d/aaa_staging.conf
[program:aaa_staging]
environment=
API_HOST="https://aaa-api-staging.zettauser.com/api/",
CLOUD_INSTANCE_NAME=media-server-xx-xx-xx-xx,
CLOUD_APPLICATION=media-server,
CLOUD_APP_COMPONENT=none,
CLOUD_ZONE=a,
CLOUD_REGION=b,
CLOUD_PRIVATE_IP=none,
CLOUD_PUBLIC_IP=xx.xx.xx.xx,
CLOUD_PUBLIC_IPV6=xx.xx.xx.xx.xx.xx,
CLOUD_PROVIDER=c
command=/opt/aaa-staging/bin/gunicorn 'aaa.app:app' --workers 4 --bind 0.0.0.0:5046 --timeout 1200
user=user
autostart=true
autorestart=true
redirect_stderr=true
directory=/opt/aaa-staging/lib64/python3.7/site-packages/aaa/
stdout_logfile=/var/log/aaa-staging_app
$
Variables originaly live in a conf file::
$ cat /etc/aaa.conf
API_HOST="https://aaa-api-staging.zettauser.com/api/"
CLOUD_INSTANCE_NAME=media-server-xx-xx-xx-xx
CLOUD_APPLICATION=media-server
CLOUD_APP_COMPONENT=none
CLOUD_ZONE=a
CLOUD_REGION=b
CLOUD_PRIVATE_IP=none
CLOUD_PUBLIC_IP=xx.xx.xx.xx
CLOUD_PUBLIC_IPV6=xx.xx.xx.xx.xx.xx
CLOUD_PROVIDER=c
$
Is there a way to inform supervisor about the fact it has to source
Variables from /etc/aaa.conf ?

laravel horizon elastic beanstalk supervisord having errors

I a have been trying to setup horizon to run inside an elastic beanstalk instance, and it looks like it works.
supervisorctl status
gets me the following output
horizon RUNNING pid 3435, uptime 0:06:31
but the log prints a successful start then loops an error message and the queue is not working
Horizon started successfully.
sh: line 0: exec: : not found
sh: line 0: exec: : not found <------ This prints like an infinite loop
the horizon queue does work if I start it manually from the ssh shell.
here are my configuration files for EBS
001-cron.config
files:
"/etc/cron.d/mycron":
mode: "000644"
owner: root
group: root
content: |
* * * * * root php /var/app/current/artisan schedule:run
002-horizon.config
container_commands:
01-copy_systemd_file:
command: "easy_install supervisor"
02-enable_systemd:
command: "mkdir -p /etc/supervisor/conf.d"
03-copy_horizon_config:
command: "cp .ebextensions/horizon.conf /etc/supervisor/conf.d/horizon.conf"
cwd: "/var/app/ondeck"
04-copy_supervidor_config:
command: "cp .ebextensions/supervisord.conf /etc/supervisord.conf"
cwd: "/var/app/ondeck"
05-touch_log:
command: "mkdir -p /var/log/supervisor/ && touch /var/log/supervisor/supervisord.log"
06-run_supervisor:
command: "/usr/local/bin/supervisord -c /etc/supervisord.conf || true"
07-run_process:
command: "/usr/local/bin/supervisorctl restart horizon:*"
08-get_status:
command: "/usr/local/bin/supervisorctl status"
horizon.conf
[program:horizon]
process_name=%(program_name)s
command=php /var/app/current/artisan horizon
autostart=true
autorestart=true
user=ec2-user
redirect_stderr=true
stdout_logfile=/var/log/horizon.log
supervisord.conf
; supervisor config file
[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)
[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor ; ('AUTO' child log dir, default $TEMP)
; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket
; The [include] section can just contain the "files" setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files *cannot*
; include files themselves.
[include]
files = /etc/supervisor/conf.d/*.conf
; Change according to your configurations
In your horizon.conf file, try specifying the full path to php:
/usr/bin/php
Like so:
[program:horizon]
process_name=%(program_name)s
command=/usr/bin/php /var/app/current/artisan horizon
autostart=true
autorestart=true
user=root
redirect_stderr=true
stdout_logfile=/var/log/horizon.log
Also note that I am using user=root.

Why supervisor is processing one job more than once?

I've been working on a Laravel (5.3) project in which I have to crawl data from multiple websites.
So, for that I set up queue jobs and configured a supervisor for them.
Everything works fine until I configure the supervisor to run only 1 process.
In file
/etc/supervisor/conf.d/laravel-worker.conf
numprocs=1
When I assign the numprocs value to more than 1, it behaves weird that supervisor executes the jobs for 2 times or 3 times.
Followings are my versions:
Ubuntu 14.04.2 LTS
Laravel 5.3
supervisord 3.0b2
Followings are my configurations:
Configurations for following file are
/etc/supervisor/supervisor.conf
; supervisor config file
[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)
[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor ; ('AUTO' child log dir, default $TEMP)
; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket
; The [include] section can just contain the "files" setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files *cannot*
; include files themselves.
[include]
files = /etc/supervisor/conf.d/*.conf
Configurations for following file are
/etc/supervisor/conf.d/laravel-worker.conf
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/myapp/artisan queue:work database --sleep=3 --tries=3
autostart=true
autorestart=true
user=hmabuzar
numprocs=25
redirect_stderr=true
stderr_events_enabled=true
stderr_logfile=/var/www/myapp/storage/logs/worker.error.log
stdout_logfile=/var/www/myapp/storage/logs/worker.log

php-fpm and nginx session problems

I've been having this problem for the past week or so. I've been working on a PHP project that relies HEAVILY on Sessions. For some reason we've been having troubles with the sessions saving the past few days. Any idea why?
Here's the error:
Warning: Unknown: open(/tmp/sess_mmd0ru5pl2h2h9bummcu1uu620, O_RDWR) failed: Permission denied (13) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0
Warning: session_start(): open(/tmp/sess_mmd0ru5pl2h2h9bummcu1uu620, O_RDWR) failed: Permission denied (13)
nginx version:
nginx version: nginx/1.0.11
PHP-FPM config:
;;;;;;;;;;;;;;;;;;;;;
; FPM Configuration ;
;;;;;;;;;;;;;;;;;;;;;
; All relative paths in this configuration file are relative to PHP's install
; prefix.
; Include one or more files. If glob(3) exists, it is used to include a bunch of
; files from a glob(3) pattern. This directive can be used everywhere in the
; file.
include=/etc/php-fpm.d/*.conf
;;;;;;;;;;;;;;;;;;
; Global Options ;
;;;;;;;;;;;;;;;;;;
[global]
; Pid file
; Default Value: none
pid = /var/run/php-fpm/php-fpm.pid
; Error log file
; Default Value: /var/log/php-fpm.log
error_log = /var/log/php-fpm/error.log
; Log level
; Possible Values: alert, error, warning, notice, debug
; Default Value: notice
;log_level = notice
; If this number of child processes exit with SIGSEGV or SIGBUS within the time
; interval set by emergency_restart_interval then FPM will restart. A value
; of '0' means 'Off'.
; Default Value: 0
;emergency_restart_threshold = 0
; Interval of time used by emergency_restart_interval to determine when
; a graceful restart will be initiated. This can be useful to work around
; accidental corruptions in an accelerator's shared memory.
; Available Units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
;emergency_restart_interval = 0
; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
;process_control_timeout = 0
; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging.
; Default Value: yes
;daemonize = yes
;;;;;;;;;;;;;;;;;;;;
; Pool Definitions ;
;;;;;;;;;;;;;;;;;;;;
; See /etc/php-fpm.d/*.conf
nginx.conf:
#######################################################################
#
# This is the main Nginx configuration file.
#
# More information about the configuration options is available on
# * the English wiki - http://wiki.nginx.org/Main
# * the Russian documentation - http://sysoev.ru/nginx/
#
#######################################################################
#----------------------------------------------------------------------
# Main Module - directives that cover basic functionality
#
# http://wiki.nginx.org/NginxHttpMainModule
#
#----------------------------------------------------------------------
user nginx nginx;
worker_processes 5;
error_log /var/log/nginx/error.log;
#error_log /var/log/nginx/error.log notice;
#error_log /var/log/nginx/error.log info;
pid /var/run/nginx.pid;
#----------------------------------------------------------------------
# Events Module
#
# http://wiki.nginx.org/NginxHttpEventsModule
#
#----------------------------------------------------------------------
events {
worker_connections 4096;
}
#----------------------------------------------------------------------
# HTTP Core Module
#
# http://wiki.nginx.org/NginxHttpCoreModule
#
#----------------------------------------------------------------------
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
index index.php index.html index.htm;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
# Load config files from the /etc/nginx/conf.d directory
# The default server is in conf.d/default.conf
include /etc/nginx/conf.d/*.conf;
server {
listen 80;
server_name stats.smilingdevil.com;
error_page 404 /404.php;
root /var/www;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location / {
set $page_to_view "/index.php";
try_files $uri $uri/ #rewrites;
root /var/www/;
index index.php;
}
location #rewrites {
if ($uri ~* ^/([a-z0-9]+)$) {
set $page_to_view "/$1.php";
rewrite ^/([a-z]+)$ /$1.php last;
}
}
location ~ \.php$ {
include /etc/nginx/fastcgi.conf;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
}
}
}
Just change the ownership of /var/lib/php/session/ to nginx from apache instead of giving a world read.
sudo chown -R nginx:nginx /var/lib/php/session/
I found that my php.ini was attempting to save sessions to /var/lib/php/session rather than /tmp
So check your ini file and see where they're being saved to (or set it to somewhere else); then make sure that directory is writeable by the appropriate processes
TL;DR: Add nginx user to apache group
RHEL has decided that /var/lib/php/session is owned by the php package. That package has decided that it will always recreate the /var/lib/php/session directory when installed and will always return the directory to being owned by root with group set to apache with full permissions for each and no permissions for anything else. Therefore, while many suggested solutions here suggest changing the permissions of /var/lib/php/session, that will cause problems in the future.
https://bugzilla.redhat.com/show_bug.cgi?id=1146552
The RHEL suggested way of fixing this issue is to create your own session directory wherever you'd like to store it and set the permissions as necessary. Future php updates won't affect that new location and everything should stay working.
An alternative that has worked quite well for me is to simply add nginx to the apache group.
Chris Rutledge is right,
php some times is saving sesions on /var/lib/php/session/ directory
check your php.ini file or
create the directory with 777 rights
mkdir /var/lib/php/session
chmod -R 777 /var/lib/php/session
this error occured due to the user which run php process may not have permission to write on /tmp directory
to make it writeable by all user use this commend
chmod 777 /tmp
another reason which causes the same issue is read only file system
if /dev/sda1 is mounted on /tmp and due to heavy write your file system may become read only...
to make it rewritable again use this command
mount -t ext3 -o rw,remount /dev/sda1 /tmp
Seems I found something interesting on the Linux. In the chroot php-cgi make same errors when some PHP software try to read/write session. I thought this could be permission issue, but after set 777 and set owner of the webserver to the "/tmp" and set it in the After many hours it found that "urandom" device in the "/dev" needed to work it. Just make sure that it found or copy/make it and change permissions temporary (just for check and then change to safely):
chmod 777 /dev/urandom
Strange to me that it wasn't required in some PHP5.x version but in some PHP7.x need to be there.
I just went through an upgrade of PHP on CentOS. I had to change /etc/php-fpm.d/www.conf and update the php_value[session.save_path] variable and set it to /tmp
php_value[session.save_path] = /tmp
This works fine.
I don't think this will be a security hazard.
You might get this error when you'r using NGINX and the server gives permission to apache instead of nginx.
My fix is:
chown -R nginx:nginx /var/lib/php/
With chown you are changhing the owner of that specific folder and -R means its recursive.

Resources