Supervisor: Tidak dapat menentukan pemilik atau izin file log

Rupanya masalahnya adalah bahwa dalam mode AUTO, file log dibuat dengan mkstemp, yang secara default memiliki izin yang sangat ketat. Jika Anda menentukan file log stdout/stderr secara eksplisit, file log dibuat dengan izin yang diharapkan.

Saya memang menentukan file stdout/stderr secara eksplisit, mereka masih menggunakan pengguna root daripada yang ditentukan dalam konfigurasi program.

Sama di sini, dan umask selalu x77 jadi file log dibuat oleh root dengan 600 dan tidak dapat dibaca oleh orang lain, ini masalah bagi saya

Saya punya di supervisord.conf :

[supervisord]
logfile=/var/log/supervisord/supervisord.log
user=supervisor
umask=022

dan di conf.d/foo.conf :

stdout_logfile=/var/log/supervisord/%(program_name)s-stdout.log
stderr_logfile=/var/log/supervisord/%(program_name)s-stderr.log

Direktori /var/log/supervisord ada dan dimiliki oleh supervisor . Ini menghasilkan 3 file log:

-rw-r--r-- 1 supervisor supervisor   0 2013-02-20 19:26 foo-stderr.log
-rw-r--r-- 1 supervisor supervisor  82 2013-02-20 19:29 foo-stdout.log
-rw-r--r-- 1 supervisor supervisor 649 2013-02-20 19:29 supervisord.log

Bukan untuk saya, saya mencoba ini di bagian [supervisord] dan di setiap file conf.d/* untuk setiap proses yang diluncurkan, tanpa hasil, supervisord terus membuat file log dengan 600 perms. Tampaknya berfungsi untuk file log utama supervisord.log, yang tampaknya menghormati param umask saya

Saya memiliki masalah serupa. Saya telah menetapkan umask 000 di SV dan tingkat proses, namun semua file log dibuat dengan topeng 022.
(Saya tidak menggunakan mode AUTO)
(Saya juga punya masalah untuk file log supervisor)

Terkait: #312, meminta opsi untuk menyetel pemilik log.

Ada resolusi untuk ini?

oh pengawas

Hanya pengguna lain yang mencari hal yang persis sama!

Menyetel user=<user> pada program supervisord bekerja untuk saya... Semua log diberikan kepada pengguna itu oleh supervisor.

+1 tolong - ini masalah yang cukup besar

Kami juga berjuang dengan ini. Solusi yang kami temukan melibatkan pra-pembuatan semua file log sebagai bagian dari proses penerapan kami sebelum supervisord dimulai ulang. Pada dasarnya kita menjalankan perintah grep | awk | xargs (touch ; chown; chmod) terhadap konfigurasi supervisor. Ini berfungsi dengan baik selama log tidak berputar, yang jarang dilakukan.

Solusi yang lebih baik akan dihargai. ;)

+1
Seperti yang disebutkan @gkertai , kami juga harus melakukan banyak penyediaan dan pengecekan ulang dalam proses penerapan kami untuk dapat menggunakan supervisor (seperti membuat file log sebelumnya dengan izin yang benar), dan itu benar-benar terasa merepotkan. Itu termasuk harus memastikan bahwa direktori file log utama ada ( https://github.com/Supervisor/supervisor/issues/120 ), hanya agar supervisord bahkan akan mulai menjalankan apa pun, atau tidak menghapus banyak proses dengan itu. Saya sangat menyukai ide Supervisor, dan saya tidak suka memikirkan harus memelihara skrip Pemula atau initd, tetapi menggunakan Supervisor di lingkungan produksi sejauh ini belum terbukti dapat diandalkan seperti yang kami inginkan. Penanganan file log yang lebih bersih akan sangat membantu, dan sangat dihargai, _terutama_ pembuatan direktori file log utama (saya dapat memahami tidak membuat direktori log program, tetapi saya dengan sepenuh hati merasa bahwa direktori log utama untuk supervisord itu sendiri seharusnya menjadi miliknya tanggung jawab). Setidaknya saya merasa harus kembali ke lokasi log default yang diharapkan selalu dapat diakses (misalnya /tmp/supervisord.log ) sehingga pesan peringatan tentang tidak adanya direktori log yang diinginkan dapat diakses dengan mudah

Bagi saya, solusi terbaik adalah mengubah umask dalam proses induk:

#!/usr/bin/env bash

umask 0000
supervisord -c supervisord.conf

Proses anak akan mewarisi umask dari proses induk, akibatnya semua file yang akan dibuat akan memiliki izin yang baik:

Anda juga dapat mengatur umask menggunakan opsi umask= di bagian [supervisord ] dari file konfigurasi.

@sidnei haruskah ada chmod setelah mkstemp di sini ?

masalah serupa di sini, gila ini belum ditangani

[program: tes1]
pengguna = pengguna1
stdout_logfile = user1.log

memulai aplikasi dengan benar sebagai user1 tetapi membuat user1.log sebagai root
alih-alih pengguna1, ini lebih seperti bug daripada perangkat tambahan

Dan +1 dari saya.
Sepertinya itu bug, karena saya tidak berharap jika Anda menentukan pengguna di program:x bagian file log akan dibuat dari root.

oh kesenangan memberi +1 pada masalah berusia 3 tahun yang belum terselesaikan.

:menangis:

+1

Ya silahkan! +1

+1 - telah terjadi rotasi log dan berbagai layanan berubah dengan kesalahan izin pada pegangan file log .. dan tentu saja file log baru yang mengkilap dimiliki oleh root. Kejutan yang buruk!

+1

+1

Sangat menyedihkan melihat begitu banyak orang beralih ke solusi yang kikuk. nginx menangani ini dengan sangat baik.
+1

:'(

:+1:

+1

+1. Saya tidak berpikir siapa pun akan pernah memperbaikinya.

@coleplx terus +1ing. Jika itu tidak bisa diperbaiki, setidaknya kita akan membuat komunitas yang bagus di sini ^_^

+1

+1

Hai kawan,
anda dapat menjalankan perintah Anda sebagai berikut:

command= bash -c "your_command first_param second_param 2> error_file.txt > stdout.txt"

dan HAPUS tag ini:

redirect_stderr
stderr_logfile
stdout_logfile

@BahmaniAlireza : yakin kita bisa. tapi kemudian kita akan kehilangan fitur barang ini... :(
stderr_logfile_maxbytes
stderr_logfile_backups
stderr_capture_maxbytes

+1

+1

+1

Kapan ini akan diperbaiki????

Kapan ini akan diperbaiki????

ketika itu cukup mengganggu seseorang sehingga mereka tidak mengatasinya secara eksternal dan
mereka menyerahkan PR ... :)

+1

+1

Saya menemukan bahwa menggunakan setgid tampaknya menjadi metode yang layak untuk mendapatkan beberapa fungsi yang ingin kita lihat dari parameter umask (non-fungsional) di supervisor. Dalam kasus saya, saya membutuhkan log dari program yang dikelola oleh supervisor agar dapat dilihat oleh agregator log, jadi saya menggunakan setgid untuk mewujudkannya: seperti ini:
chmod u=rwx,go=rx,a+s /var/log/myapplogs/

Kemudian di konfigurasi supervisor, saya hanya perlu mengatur file log, pengguna, pidfile, stdout_logfile, stdout_events_enabled (true), stderr_logfile, stderr_events_enabled (true), dll.

Contoh penyiapan: https://Gist.github.com/jpsandiego/a7927d14fc23efc0eae049d1466656b0

Untuk semua orang yang meninggalkan komentar terpisah untuk +1, jempol, dll.: FUCK OFF.

Serius, bagian masalah adalah alat pengembang, dan semua yang Anda lakukan adalah mengganggu pengembang (dan kita semua) dengan mengirim spam kepada kita semua dengan pesan tidak berguna Anda. Saya benar-benar tidak mengerti mengapa perlu mengajari Anda tentang fakta dasar etiket ini. Jika Anda tidak memiliki sesuatu yang berguna untuk ditambahkan, cukup acungkan jempol pada masalah tersebut dan lanjutkan.

(Maaf untuk semua orang atas spam ini, tetapi masalah ini telah di luar kendali.)

"Untuk semua orang yang meninggalkan komentar terpisah untuk +1, jempol, dll"
...
"Jika Anda tidak memiliki sesuatu yang berguna untuk ditambahkan, cukup acungkan jempol pada masalah ini dan lanjutkan."

Hanya untuk MATI kembali - reaksi (yang merupakan acungan jempol yang Anda maksud) ditambahkan pada bulan Maret 2016. https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and -komentar

Itu hampir EMPAT TAHUN setelah masalah ini dimulai. Sebelum saat itu (dan saya akan perhatikan bahwa saya sebenarnya belum melihat fitur itu ditambahkan) cara yang tepat dan satu-satunya untuk mengacungkan masalah adalah komentar.

Jika Anda tidak suka orang melakukan upvoting, TUTUP MASALAH. Ini terbuka, jadi mungkin tim pengembangan memiliki minat dalam hal ini - dan kami para pengguna yang menyatakan minatnya masih peduli juga.

Jika Anda mewakili tim pengembangan, dan merasa itu bukan sesuatu yang akan pernah diselesaikan, maka nyatakan dan tutup. Jika tidak, berhenti berlangganan. :)

Jadi, PERGI.

Memang.

Ryan APAAN OFF

Pada 10/01/17 17:18, david raistrick menulis:
>

"Untuk semua orang yang meninggalkan komentar terpisah untuk +1, jempol, dll"
...
"Jika Anda tidak memiliki sesuatu yang berguna untuk ditambahkan, cukup acungkan jempol pada masalah ini dan
berjalan terus."

Hanya untuk FUCK OFF kembali - reaksi (yang diacungi jempol Anda
mengacu pada) ditambahkan pada bulan Maret 2016.
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

Itu hampir EMPAT TAHUN setelah masalah ini dimulai. Sebelum itu
beberapa saat (dan saya akan perhatikan bahwa saya sebenarnya tidak memperhatikan
fitur telah ditambahkan) cara yang tepat dan satu-satunya untuk mengacungkan masalah
adalah sebuah komentar.

Jika Anda tidak suka orang melakukan upvoting, TUTUP MASALAH. Ini terbuka, jadi
mungkin tim pengembangan memiliki minat dalam hal ini - dan kami
pengguna yang menyatakan minatnya masih peduli juga.

Jika Anda mewakili tim pengembangan, dan merasa itu bukan
sesuatu yang akan pernah diselesaikan, menyatakan itu dan menutupnya.

Jadi, PERGI.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-271686060 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAzKDJ3bty9ezBMMR8ObCeV_8hIazqPTks5rQ-edgaJpZM4AA4dF .

+1

+1

+1

+1

Pada 12/01/17 06:31, Eugen Ivanov menulis:
>

+1

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Supervisor/supervisor/issues/123#issuecomment-272115994 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAzKDKMUhFVHCN1C03WXOSUsuRSmv48Tks5rRfMMgaJpZM4AA4dF .

Hai semuanya, pertama-tama saya tidak setuju menjadi agresif ketika berbicara di forum, untuk alasan apa pun, karena kita semua pantas dihormati dan jelas bahwa tidak ada seorang pun di sini yang bermaksud jahat tetapi menunjukkan bahwa masalah ini memengaruhi banyak orang. Namun, @keen99 memiliki poin yang valid, saya telah berlangganan masalah ini beberapa waktu lalu dan setiap kali saya mendapat pemberitahuan, saya bertanya-tanya "wow, apakah kita memiliki berita yang valid tentang itu?" tapi kemudian saya membukanya dan menemukan +1 .

Dengan menekan berlangganan dan memberikan jempol pada komentar pertama dari masalah ini, menurut saya adalah cara yang lebih produktif untuk menunjukkan minat, karena itu jauh lebih visual untuk berapa banyak orang yang memiliki masalah yang sama.

Yang mengatakan, melakukan +1 s tidak akan membuat pengelola proyek berjalan lebih cepat dengan masalah ini karena kami sudah memiliki banyak +1s dan ini tidak diperbaiki (jelas mereka tidak harus melakukannya , siapa pun yang sangat terpengaruh bebas untuk membuka permintaan tarik seperti OSS apa pun). Tapi menurut saya ini mengganggu banyak pelanggan tanpa alasan yang jelas dan tidak ada manfaat yang diambil.

Saya menekan ini dan mungkin tidak tahu apa yang saya lakukan, tetapi setgid dan pengaturan umask di [supervisord] dan di skrip init tidak berhasil. Saya mungkin akan menggunakan nilai syslog ajaib untuk pengaturan file log:
stdout_logfile=syslog stderr_logfile=syslog
Dan bertengkar hal-hal dari sana. Ini bukan pertama (dan saya ragu yang terakhir) kali saya secara pribadi memecahkan masalah izin untuk agregasi log hanya dengan menggunakan syslog. Berfungsi dengan baik!

+1

Kami menggunakan supervisor pada mesin kami untuk memantau dan mengontrol proses. Kami ingin meningkatkan keamanan instance kami dan memperhatikan bahwa tidak mungkin mengubah izin file log dengan mudah. Berikut adalah masalah lain yang relevan:

https://github.com/Supervisor/supervisor/issues/114
https://github.com/Supervisor/supervisor/issues/107

Apakah seseorang mengerjakan ini atau masalah terkait?

Bagaimana dengan memiliki bidang konfigurasi global terpisah yang disebut stdout_log_user dan stdout_log_permissions (juga untuk stderr_* ) yang memungkinkan pengguna menentukan siapa yang memiliki log (misalnya, hanya root ) dan dengan izin apa (misalnya, 0o600 )?

Anda dapat memiliki bidang ini di bagian program juga untuk menimpa yang global jika perlu.

Jika tidak ada yang menangani masalah ini, tim kami di Parquery AG akan dengan senang hati membantu dan mengajukan permintaan penarikan. Tolong beri tahu saya apa langkah selanjutnya.

@mristin Saya sarankan mengirimkan PR dan menggunakan garpu Anda sendiri sampai digabungkan di sini .. yang mungkin memakan waktu karena tampaknya proyek ini menderita karena kurangnya kontributor aktif (tidak menunjuk, saya tidak punya waktu untuk terjun dan berkontribusi, sayangnya!).

@lukeburden , terima kasih, kami akan melakukannya.

Bisakah beberapa pengguna yang tertarik dengan fitur tersebut dengan cepat mengonfirmasi bahwa proposal kami cocok untuk mereka?

@mristin yang akan melakukan trik dalam kasus saya. Saya akan menggunakan pengaturan tingkat program untuk memastikan ketika rotasi log terjadi pada proses seledri saya bahwa file log baru dimiliki oleh pengguna yang tepat celery dan bahwa izinnya sesuai. Saat ini, supervisor membuat file log baru sebagai root, dan kemudian proses seledri tidak dapat menulis ke file log baru.

Satu-satunya pemikiran tambahan saya adalah mungkin ide yang baik untuk memiliki pengaturan untuk memungkinkan spesifikasi grup juga? Ini mungkin penting untuk konfigurasi beberapa orang.

@mristin yang akan melakukan trik untuk saya juga.

Saya juga dapat membantu Anda mengujinya jika Anda membutuhkan saya.

Saya tahu ini sudah tua, tetapi saya kesulitan membuat supervisor TIDAK memutar log, dan tampaknya, di beberapa titik nama konfigurasi untuk pengaturan yang mematikannya berubah dari "logfile_maxbytes" menjadi "stdout_logfile_maxbytes".

Apa yang saya temukan untuk mengatasi perubahan izin file log kembali ke root adalah bahwa mematikan rotasi log supervisor dan menggunakan logrotate berhasil. Namun, jika file tumbuh cukup cepat, logrotate akan mati karena ukuran file.

Mungkin ini membantu seseorang.

Halo semua,

Saya menemukan jawaban ini pada topik ini: http://supervisor-users.10397.x6.nabble.com/Supervisor-users-Changing-owner-of-log-files-td4945286.html

Dengan membuat file log dengan pengguna yang diinginkan (seperti orang yang memiliki proses anak supervisor), kepemilikan disimpan selama proses supervisor.

Semoga membantu!

Salam hangat dan tetap aman!

@keen99 +1