минимальный конфиг - в папку /etc/supervisor/conf.d/ добавляем конфиги для нужных очередей... можно в принципе все в одном файле зафигачить, я обычно отдельные файлы на каждого демона создаю
А вообще у супервайзера очень неплохая документация http://supervisor.readthedocs.io/en/latest/configuration.html#program-x-section-values

[program:mainQueue]
process_name = %(program_name)s
command=/usr/bin/php /srv/http/shop/console/yii queue/listen
stdout_logfile=/var/log/queue.log
autostart=true
autorestart=true
user=www-data
stopsignal=KILL
numprocs=3
stdout_logfile_maxbytes=20MB
stdout_logfile_backups=50
stdout_capture_maxbytes=1MB

[program:staffQueue]
command=/usr/bin/php /srv/http/shop/console/yii staff-queue/listen
stdout_logfile=/var/log/staffQueue.log
autostart=true
autorestart=true
user=www-data
stopsignal=KILL
numprocs=1
stdout_logfile_maxbytes=20MB
stdout_logfile_backups=50
stdout_capture_maxbytes=1MB

А конфиг самого systemd по умолчанию - все работает

[Unit]
Description=Supervisor process control system for UNIX
Documentation=http://supervisord.org
After=network.target

[Service]
ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf
ExecStop=/usr/bin/supervisorctl $OPTIONS shutdown
ExecReload=/usr/bin/supervisorctl -c /etc/supervisor/supervisord.conf $OPTIONS reload
KillMode=process
Restart=on-failure
RestartSec=50s

[Install]
WantedBy=multi-user.target

Если не запустилось - что выводит sudo systemctl status supervisord.service ?

Начал разбираться с тем как запускать демонов и наткнулся на кучу разных менеджеров upstart,supervisor,SysVInit, systemd.Решил использовать systemd т.к. он встроен уже в систему, чтобы запускать yii queue/listen. Создал для него конфиг файл /etc/systemd/system/yii-queue.service:

Description=yii-queue
After=mysql.service apache2.service redis.service

[Service]
PIDFile=/var/run/yii-queue/yii-queue.pid
ExecStart=/usr/sbin/yii-queue-listen
ExecStop=kill -9 yii-queue
Type=forking
Restart=always
User=root
Group=root

[Install]
WantedBy=multi-user.target

В /usr/sbin/yii-queue-listen:

#!/bin/bash
nohup /home/ivan/web/bot-vk/yii queue/listen > /dev/null 2>&1 &

В итоге когда пытаюсь запустить systemctl start yii-queue:

Job for yii-queue.service failed because a timeout was exceeded. See "systemctl status yii-queue.service" and "journalctl -xe" for details.

В journalctl -xe:

Май 14 11:45:59 ivan-mint systemd[1]: Starting yii-queue...
-- Subject: Начинается запуск юнита yii-queue.service
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Начат процесс запуска юнита yii-queue.service.
Май 14 11:45:59 ivan-mint systemd[1]: yii-queue.service: PID file /var/run/yii-queue/yii-queue.pid not readable (yet?) after start: No such file or directory

Пытался нагуглить эту ошибку, ничего в итоге не нашел. Не хочется разбрасывать демоны на разные системы, чтобы помнить потом апач вот там а yii вот тут.

так вы не супервизор а напрямую systemd пробуете...
Попробуйте Type = simple
в ExecStart - прямую команду без nohup
ExecStop= kill -9 $(cat /var/run/yii-queue/yii-queue.pid) (килл киллит по номеру, номер пишется в пидфайле)
или pkill -9 -F /var/run/yii-queue/yii-queue.pid

и для запуска sudo systemsctl daemon-reload

Большое спасибо всё заработало, только на сервере почемуто потребовало полный путь в поле Exec для команды стоп. Конечный конфиг для systemd вдруг кому пригодится:

[Unit]
Description=yii-queue
After=mysql.service apache2.service redis.service

[Service]
PIDFile=/var/run/yii-queue/yii-queue.pid
ExecStart=/home/ivan/web/bot-vk/yii queue/listen > /dev/null 2>&1 &
ExecStop=/usr/bin/pkill -9 -F /var/run/yii-queue/yii-queue.pid
Type=simple
Restart=always
User=root
Group=root

[Install]
WantedBy=multi-user.target

ой только зачем же под рутом!!!!
И на самом деле у супервизора всё-таки есть несколько преимуществ - во-первых есть возможность управлять и смотреть логи через веб-интерфейс, или через апи (поставить релоад воркеров при деплое). воркеры можно группировать чтоб задавать комманду на группу, во-вторых встроенный eventlistener - можно доп. уведомления повешать при отвале, или например сделать перезапуск если идет утечка и процесс стал слишком много памяти кушать, и в докере ему норм живется

То есть желательно специального пользователя сделать типа yii-user с правами только на папку с проектом.
Спасибо за информацию по поводу супервизоров. Их что-то много оказалось разных, и выбор пал на тот что не надо устанавливать. Пока это мой единственный демон и systemd думаю хватит. Всё лучше чем каждую минуту кроном запускать команду через flock)

под линем в принципе под рутом сидеть не принято, как минимум нужно обычного юзера, а повышение привелегий с помощью sudo но это уже совсем в оффтопик выходит... информации и ресурсов на эту тему в сети много.

Полезные выкладки, обязательно добавлю в документацию, большое спасибо.

На правах рекомендации, я бы добавил опцию verbose. Тогда в STDOUT и STDERR будет падать весь вывод воркера, а супервизор запишет это в логи.

command=/usr/bin/php /.../yii queue/listen --verbose

Или через конфиг:

'queue' => [
    //...
    'commandOptions' => [
        'verbose' => true,
    ],
],

чтобы команды queue/listen и queue/run по умолчанию работали в подробном режиме.

Впрочем, это не сильно актуально если логи ведутся штатными средствами фреймворка, например через LogBehavior. Тогда ту же информацию можно писать в логи приложения.

Еще у supervisor есть numprocs. Важная опция. Она задает кол-во процессов, которые будут запущены. А кол-во запущенных воркеров - то, чем можно балансировать скорость обработки всей очереди. Сколько воркеров - столько и заданий может обрабатываться параллельно. Не знаю, есть такое у systemd или нет.

Утечек быть не должно. По умолчанию основной процесс queue/listen занимается только опросом очереди, а для обработки сообщений запускает дочерний queue/exec, который живет пока не выполнит свое задание. Соответственно все ресурсы дочернего процесса освобождаются.

Это поведение можно изменить опцией isolate:

yii queue/listen --isolate=0

Тогда задания будут обрабатываться в основном процессе. Хоть это и быстрее, но могут быть утечки. Также, нужно учитывать артефакты типа #8 и #12.