типа одноразовые

например еще несомненный плюс юнита (любого) - помимо того, что screen-tmux не нужны, если он долго работает - ты гарантированно (почти) получишь его логи в journald

но, конечно, ЗАПУСК всего в них странно засовывать. Ну, например, служебные команды ad-hoc типа fdisk/ps aux и прочее - странно совать в юниты, да, согласен

и, да, юнит может дергать юнит (внезапно)

transient service юниты не одноразовые, а динамически создаваемые. Они все равно для типовых вещей, а не для задач, запускаемых единожды.

кто нибудь в курсе, что не так

[ec2-user@ip-172-31-28-23 ~]$ aws s3 sync s3://dlvrys s3://dlvrs --storage-class DEEP_ARCHIVE
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

 aws help
 aws <command> help
 aws <command> <subcommand> help
aws: error: argument --storage-class: Invalid choice, valid choices are:

STANDARD                                 | REDUCED_REDUNDANCY                      
STANDARD_IA                              | ONEZONE_IA                              
INTELLIGENT_TIERING                      | GLACIER                                
[ec2-user@ip-172-31-28-23 ~]$

Про какой-нибудь scope-юнит еще можно согласиться, если нужна управляемость со стороны systemd.

деплой задача повторяемая, так-то

как обновление системы

Деплой одного и того же кода? :)

разных версий одного кода

Ну тогда пусть логика про версии будет в деплоилке, а в service-е будет только то, что не зависит от версии и не вызывает внутри себя деплоилку.

Я же не против того, чтобы resque запускался systemd-ой :)

от задачи зависит, но скорее соглашусь

Там же написано, storage-class не из поддержимаемых (перечисленных в списке).

> aws: error: argument --storage-class: Invalid choice, valid choices are:
>
> STANDARD                                 | REDUCED_REDUNDANCY                      
> STANDARD_IA                              | ONEZONE_IA                              
> INTELLIGENT_TIERING                      | GLACIER

подскажите, как тогда лучше сделать старт/стоп процессов resque, если resque сейчас запускается вот так

desc "Start Resque workers"
  task :start do
    for_each_workers do |role, workers|
      on roles(role) do
        create_pid_path
        worker_id = 1
        workers.each_pair do |queue, number_of_workers|
          info "Starting #{number_of_workers} worker(s) with QUEUE: #{queue}"
          number_of_workers.times do
            pid = "#{fetch(:resque_pid_path)}/resque_work_#{worker_id}.pid"
            within current_path do
              execute :nohup, %{#{SSHKit.config.command_map[:rake]} RACK_ENV=#{rails_env} RAILS_ENV=#{rails_env} #{fetch(:resque_extra_env)} QUEUE="#{queue}" PIDFILE=#{pid} BACKGROUND=yes #{"VERBOSE=1 " if fetch(:resque_verbose)}INTERVAL=#{fetch(:interval)} #{"environment " if fetch(:resque_environment_task)}resque:work #{output_redirection}}
            end
            worker_id += 1
          end
        end
      end
    end
  end

т.е. pid файлы создаются при старте/рестарте через capistrano resque_work_1.pid resque_work_2.pid resque_work_3.pid и т.д., а если я буду запускать руками команду в systemd

bundle exec rake COUNT=5 QUEUE=sms PIDFILE=tmp/pids/resque.pid BACKGROUND=yes INTERVAL=5 resque:workers

то у меня запускается 5 процессов resque c одним pid файлом в tmp/pids/resque.pid и у меня получается разнобой с pid файлами

forking поставить. вроде так

Ребята, хочу подсветить тут конфу одну в минске