gunicorn: o proprietário do diretório logfile está sendo reinicializado na reinicialização?

Question

Eu tenho uma gota hospedada no Digital Ocean runing Ubuntu 14.04.

Eu tenho um diretório de log gunicorn que fiz para armazenar meus arquivos de log e ele só funciona se o proprietário for o usuário que está executando o processo de gunicorn.

Eu faço ...

chown user gunicorn

mas isso só dura até a reinicialização e, em seguida, a propriedade volta para a raiz e o grupo é adm. Estou executando um processo de django e não sei o que fazer. Como posso fazer minha mudança para um novo proprietário permanente ou também adicionar o usuário ao grupo adm?

O caminho do diretório

é ...

/var/log/gunicorn

ls -la o diretório gunicorn ...

drwxr-x---  2 root   adm        4096 Jan 30 20:08 .
drwxrwxr-x 12 root   syslog     4096 Jan 31 03:06 ..
-rw-r--r--  1 django django    73747 Jan 31 02:34 access.log
-rw-r--r--  1 django django 97698592 Jan 31 03:05 error.log

montar saída ..

/dev/vda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)

ls -la / var / log | grep gunicorn ...

drwxr-x---  2 root      adm           4096 Jan 30 20:08 gunicorn

/etc/init/gunicorn.conf ...

description "Gunicorn daemon for Django project"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [!12345]

# If the process quits unexpectadly trigger a respawn
respawn

setuid django
setgid django
chdir /home/django

exec venv/bin/gunicorn \
    --name=langalang \
    --pythonpath=langalang \
    --bind=0.0.0.0:9000 \
    --config /etc/gunicorn.d/gunicorn.py \
    langalang.wsgi:application

/etc/gunicorn.d/cunicorn.py ...

"""gunicorn WSGI server configuration."""
from multiprocessing import cpu_count
from os import environ


def max_workers():
    return cpu_count() * 2 + 1

max_requests = 1000
worker_class = 'gevent'
workers = max_workers()
errorlog = '/var/log/gunicorn/error.log'
accesslog = '/var/log/gunicorn/access.log'

    

Answer 1

Acontece que havia um script em /etc/init.d/gunicorn que estava criando e dando permissões ao diretório toda vez que gunicorn era iniciado. Acabei de alterar as permissões nesse arquivo e tudo funciona bem. Isso foi realmente difícil de encontrar