I have a fresh install of supervisord inside a development vagrant machine. I have rabbitmq setup and receiving messages from my Symfony2 producers. I am attempting to use supervisord to maintain X consumers which are Symfony2 console commands.
The following config works like a dream. My consumers are created and maintained fine.
# /etc/supervisord.conf
# ...
[supervisord]
logfile=/var/log/supervisor/supervisord.log
user=root
[program:rabbitmq-consume-email]
command=/usr/bin/php /another/path/app/console rabbitmq:consumer -w email
numprocs=2
process_name=%(program_name)s-%(process_num)s
But changing it up to the following, does not seem to create any producers, including checking for current consumers on the queues I am consuming from.
# /etc/supervisord.conf
# ...
[supervisord]
logfile=/var/log/supervisor/supervisord.log
user=root
[include]
files = /abs/path/to/more/confs/*.conf
With ...
# /abs/path/to/more/confs/rabbitmq-email.conf
# ...
[program:rabbitmq-consume-email]
command=/usr/bin/php /another/path/app/console rabbitmq:consumer -w email
numprocs=2
process_name=%(program_name)s-%(process_num)s
As you can see from the following, the configuration files all share the same permissions. But even making the included config files 777 (purely out of frustration) I have no progress.
vagrant#box ~ ls -l /etc/supervisord.conf
-rw-r--r-- 1 root root 391 Dec 3 14:51 /etc/supervisord.conf
vagrant#box ~ ls -l /abs/path/to/more/confs/
-rw-r--r-- 1 root root 197 Dec 3 15:41 rabbitmq-email.conf
-rw-r--r-- 1 root root 193 Dec 3 15:42 rabbitmq-sms.conf
The log file shows the normal start info (at debug level) and no errors concerning including any files (before and after permission changes.
2015-12-03 16:00:02,225 CRIT Set uid to user 0
2015-12-03 16:00:02,234 DEBG supervisord forked; parent exiting
2015-12-03 16:00:02,235 INFO daemonizing the process
2015-12-03 16:00:02,235 INFO supervisord started with pid 28061
Any suggestions greatly appreciated.
Related
We are getting the error "permission denied" when trying to write to a file that is owned by a service user and a shared group. In particular that is www-data:www-data and the user trying to write to it is in the group www-data.
There is no acl on none of the parent folders and the permissions to the file and folders are correct.
Here some details:
$ sudo -u deploy id -Gn
www-data
$ ls -lah /tmp
drwxrwxrwt 17 root root 4.0K Jul 11 11:22 .
drwxr-xr-x 23 root root 4.0K Jul 8 10:08 ..
...
-rw-rw-r-- 1 www-data www-data 0 Jul 11 10:50 test
...
$ echo 'hello world' | sudo -u deploy tee -a /tmp/test
tee: /tmp/test: Permission denied
hello world
we tried that on different folders and made sure there is no acl on any of the folders or parents or files...
Unfortunately that is not described in the link stark posted in the comment. And also not in any other page I found until I found an answer here on stackoverflow that clarified it.
2018 two new filesystem configurations got added to sysctl that should prevent regular files and fifos from beeing opened with the O_CREAT flag (as append mode is doing) in directories with the sticky bit set unless the user is the owner of the file. This commit added the settings: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5
To change that behaviour you have to set fs.protected_regular to 0:
sudo sysctl fs.protected_regular=0
Or to persist the change add fs.protected_regular=0 to your sysctl.conf.
side node: since O_CREAT is not deleting or renaming the file I'm wondered why it is connected to the sticky bit. It really is possible to create a file in directories with the stick bit set.
Every time after newsyslog rotates the log file, syslog stops logging into the file. Until a syslogd restart is done.
(myserver:wheel)# logger -p local1.info -t myprocess "hello thiru"; ll myfile.log; cat myfile.log
-rw-r--r-- 1 root wheel 0B Nov 10 11:26 myfile.log
(myserver:wheel)# /etc/rc.d/syslogd restart
Stopping syslogd.
Starting syslogd.
(myserver:wheel)# logger -p local1.info -t myprocess "hello thiru"; ll myfile.log; cat myfile.log
-rw-r--r-- 1 root wheel 44B Nov 10 12:04 myfile.log
Nov 10 12:04:31 myserver myprocess: hello thiru
(myserver:wheel)#
On Linux (which uses logrotate), we can solve this by doing syslog/rsyslog restart in the postrotate section of the logroate conf.
Is there something similar to postrotate in newsyslog?
Edit:
Syslog and newsyslog conf files:
(TPC-E11-36:wheel)# cat /etc/newsyslog.d/newsyslog-myprocess.conf
/var/log/myfile.log 644 20 10000 * Z
(TPC-E11-36:wheel)# cat /etc/syslog.d/syslog-myprocess.conf
!myprocess
local1.info /var/log/myfile.log
(TPC-E11-36:wheel)#
Add the path of the pidfile into the /etc/newsyslog.conf and if required a signal for example 1 that stands for SIGHUP, more info about newsyslog here: https://www.freebsd.org/doc/handbook/configtuning-syslog.html
The format/example is this:
# logfilename [owner:group] mode count size when flags [/pid_file] [sig_num]
/var/log/your-app.log root:wheel 600 7 * #T00 GBJC /var/run/your-app.pid 1
Also see this answer: https://serverfault.com/a/701563/94862
There is actually something similar to postrotate in newsyslog, it's the R flag in the configuration file in combination with path_to_pid_cmd_file (that's what it's called in the FreeBSD manual entry of newslog.conf(5)). With this flag set, the path provided will not be interpreted as a path to a PID file, but as a path to a script (for example a shell script) which will be executed after the log rotation is finished.
You can even pass arguments to the script, but for this you'll have to use the IFS-variable (separated by a space, the argument would be interpreted as a signal and likely throw an error).
# logfilename [owner:group] mode count size when flags [/cmd_file]
/var/log/myfile.log root:wheel 644 20 10000 * ZR /path/to/my/script${IFS}myargument
when I run
sudo service logstash start
it doesn't write anything to /var/log/logstash/logstash.log
Not really that good at unix, is there anything I am missing to make it write to the log?
I've installed logstash the yum way, as detailed in the logstash website
ls -l logstash
-rw-r--r-- 1 logstash logstash 80949 Aug 11 09:16 gc.log
-rw-r--r-- 1 root root 0 Aug 11 09:15 logstash.err
-rw-r--r-- 1 root root 0 Aug 11 06:17 logstash.log
-rw-r--r-- 1 root root 60 Aug 11 09:15 logstash.stdout
Logstash can't write log info because the owner of the log file is root currently.
You should change owner of the log file with the command below
chown logstash:logstash logstash.log
I assume that the reason is you started logstash as root user in contrast with logstash service is started as logstash
(See the contents of this file /etc/init.d/logstash)
It seems logstash is writing log into gc.log. you can change the file instead.
Have you change the /etc/init.d/logstash file before?
in the file, you can find name field.
if the value of the name is logstash, the log file name will be logstash.log
if you want to change the log file name, modify /etc/init.d/logstash and change the value of the name to "logstash" (I assume that your current value is "gc")
name=logstash
pidfile="/var/run/$name.pid"
LS_USER=logstash
LS_GROUP=logstash
LS_HOME=/var/lib/logstash
LS_HEAP_SIZE="1g"
LS_LOG_DIR=/var/log/logstash
LS_LOG_FILE="${LS_LOG_DIR}/$name.log"
LS_CONF_DIR=/etc/logstash/conf.d
LS_OPEN_FILES=16384
What can I do to make this script run daily?
If I manually run the script, it works. I can see that it did what it's supposed to do. (backup files) However, it will not run as a cron.daily script. I've let it go for days without touching it -- and it never runs.
The actual script is here /var/www/myapp/backup.sh
There is a symlink to it here /etc/cron.daily/myapp_backup.sh -> /var/www/myapp/backup.sh
The cron log at /var/log/cron shows anacron running this script:
Aug 19 03:09:01 ip-123-456-78-90 anacron[31537]: Job `cron.daily' started
Aug 19 03:09:01 ip-123-456-78-90 run-parts(/etc/cron.daily)[31545]: starting myapp_backup.sh
Aug 19 03:09:01 ip-123-456-78-90 run-parts(/etc/cron.daily)[31559]: finished myapp_backup.sh
Yet there is no evidence that the script actually did anything.
Here is the security info on these files:
ls -la /var/cron.daily
<snip>
lrwxrwxrwx 1 root root 25 Aug 12 21:18 myapp_backup.sh -> /var/www/myapp/backup.sh
</snip>
ls -la /var/www/myapp
<snip>
drwxr-xr-x 2 root root 4096 Aug 13 13:55 .
drwxr-xr-x 10 root root 4096 Jul 12 01:00 ..
-rwxr-xr-x 1 root root 407 Aug 12 23:37 backup.sh
-rw-r--r-- 1 root root 33 Aug 12 21:13 list.txt
</snip>
The file called list.txt is used by backup.sh.
The script just runs tar to create an archive.
From the cron manpage of a debian/ubuntu system:
the files under these directories have to be pass some sanity checks including the following: be executable, be owned by root, not be writable by group or other and, if symlinks, point to files owned by root. Additionally, the file names must conform to the filename requirements of run-parts: they must be entirely made up of letters, digits and can only contain the special signs underscores ('_') and hyphens ('-'). Any file that does not conform to these requirements will not be executed by run-parts. For example, any file containing dots will be ignored.
So:
file need to be owned by root
if symlink, the source file need to be owned by root
if symlink, the link name should NOT contain dots
I had a similar situation with cron.hourly and awstats processing.
I THINK it is related to SELinux and anacron not having the same powers/permissions as cron.
The ACTUAL solution defeated me (so far).
MY WORKAROUND SOLUTION: Run the job via root's cron entries (crontab -e ) and simply schedule it hourly.
I have the following problem, I run a script on multiple servers that writes files on a single server.
Files are written with these rights:
-rw-r--r-- 1 someuser someuser 139 Apr 2 12:40 filename.jpg
What I would like to do would be to be able to delete this file via a php script that runs with www-data rights.
Is there a way to configure something so www-data is allowed to remove the above file?
The php script run wiht user (euid): www-data and group (egid): www-data.
One solution may be the following:
-rw-rw-r-- 1 someuser www-data 139 Apr 2 12:40 filename.jpg
In this situation, the php script could delete the file without problems.