я просто решил уточнить: это лыжи не едут или я того.

ну не ясно что такое "почти самое последнее" но твои доказательства выглядят убедительно

если быть точнее

master из bootstrap-salt.sh версии 3003
minion 3003+ds-1 and 3003.2+ds-1 по фиг

а можете просветить по service.systemctl_reload? Как его использовать в стейтах, когда создаем какой-нибудь юнит?
https://docs.saltproject.io/en/latest/ref/modules/all/salt.modules.systemd_service.html#salt.modules.systemd_service.systemctl_reload
в таком виде никогда шаг systemd-reload  не запускается

set_gracefulshutdown.service:
  file.managed:
    - name: /etc/systemd/system/set_gracefulshutdown.service
    - source: salt://check_shutdown/files/set_gracefulshutdown.service

service.systemctl_reload:
  module.run:
    - name: service.systemctl_reload
{# это можно указывать, а можно и нет, т.к. шаг service.systemctl_reload в любых вариантах не запускается
    - onchanges:
      - file: set_gracefulshutdown.service
#}

а в таком виде норм:

set_gracefulshutdown.service:
  file.managed:
    - name: /etc/systemd/system/set_gracefulshutdown.service
    - source: salt://check_shutdown/files/set_gracefulshutdown.service
  module.run:
    - service.systemctl_reload: []
    - onchanges:
      - file: set_gracefulshutdown.service    

https://www.gitmemory.com/issue/saltstack/salt/60787/904541331- вот здесь нашел, что надо указывать некое service.systemctl_reload: []

хотя дока и найденные ссылки в инете (https://yetiops.net/posts/saltstack-introduction/, https://www.lutro.me/posts/managing-systemd-units-with-salt) говорят, что первый способ должен быть правилен.
При запуске в дебаге для первого варианта, всегда пишется такое:

[INFO    ] Running state [service.systemctl_reload] at time 07:21:12.235092
[INFO    ] Executing state module.run for [service.systemctl_reload]
[INFO    ] No changes made for []
[INFO    ] Completed state [service.systemctl_reload] at time 07:21:12.236469 (duration_in_ms=1.377)

Я лично стараюсь вообще не заморачиваться с ручной настройкой systemd сервисов, а юзаю спец подготовленную для этого https://github.com/saltstack-formulas/systemd-formula формулу.

Но по факту есть до сих пор работающих пара легаси сценариев в которых всё делается в ручную.

Ты можешь в формуле подсмотреть ответы на свои вопрос

в указанной формуле всего лишь так :( - https://github.com/saltstack-formulas/systemd-formula/blob/master/systemd/reload.sls

reload_systemd_configuration:
  cmd.wait:
    - name: systemctl daemon-reload
    - runas: root

тоже самое что и в модуле. вопрос почему модуль не работает

я тут с запуском раннеров столкнулся. похожая вещь там. но суть в том, чтобы правильно вызвать раннер/модуль. дело в том, что вызов раннера/модуля из sls описания происходит специальным способом (возможно lazy чё то там - точно не помню - можно увидеть в трейcбеке).

так вот есть два вида параметров позиционные args и не позиционные kwarg. позиционные передаются раннеру (наверное и модулю) как лист, при чём если вызов идёт через salt-call, то лист собирается из salt-call param1 param2 и передаётся непосредственно в питон код листом из строки с пробелами. kwargs собирается в dict из параметров следующих внутри вызова модуля(описания sls).

но суть не меняется. второй вариант работает потому, видимо что методу встроенному в солт передается пустой лист. даже не смотря на то, что def systemctl_reload() ни чего не надо, подсистема солта так устроена.

я так себе это представляю на данный момент.

почему-то вы используете не официальный issue tracker
https://github.com/saltstack/salt/issues/60787
и не офф доки
https://docs.saltproject.io/en/latest/ref/states/all/salt.states.module.html
а ссылаетесь на старые статьи

в общем если коротко - изменился формат записи для module.run и если в настройках мастера включена опция use_superseded: [module.run], но используется старый формат записи - то стейт всегда будет как бы успешно выполняться без малейшего эффекта.

я использую такую конструкцию, не красиво зато работает в любых комбинациях - разные версии солта, включенный или выключенный use_superseded: [module.run]

{{ sls }}_reload_systemd:
 module.wait:
 # Workaround for deprecated `module.run` syntax, subject to change in Salt 3005
 {%- if 'module.run' in salt['config.get']('use_superseded', [])
     or grains['saltversioninfo'] >= [3005] %}
   - service.systemctl_reload: []
 {%- else %}
   - name: service.systemctl_reload
 {%- endif %}
   - watch:
     - file: {{ sls }}_systemd_drop-in

да, на всякий случай, обращаю внимание - у меня используется module.wait + watch

Должен ли работать failover при одном мастере и следующих параметрах на миньоне ?

master_type: failover
master_alive_interval: 30
master_failback: True
master_failback_interval: 30

Мастер у меня один. По умолчанию резолвиться из salt. Я хотел добиться от миньона чтобы тот переподключался к мастеру как только тот становился он-лайн. Но получается так что попытка подключения работает всего один раз. Например делаю мастер не доступным. Перезапускаю миьона - он не видит мастер и сыплет об этом в лог. Делаю мастера доступным миьно его обнаруживает, подключается к нему и прогоняет то, что там получит в полной мере. Делаю мастер вновь не доступным (iptables -A OUTPUT -m comment --comment 'drop' -d 192.168.1.1 -j DROP) миньону пофиг. Он продолжает ни чего не делать. Т.е. в первом случае попытки переподключения к мастеру бесконечны. Во втором его уже ни чего не интересует. Можно ли реализовать мой кейс при условии что у меня всего один мастер и как со всем этим связаны опции retry_dns,  retry_dns_count.

не знаю почему вопрос мне адресован :)

у меня так миньоны настроены, переподключаются нормально
master_tries: -1
ping_interval: 2

у меня ситуации следующие - перезапуск мастера (в т.ч. остановка и потом запуск через некоторое, небольшое, время). перезагрузка хоста с мастером

https://docs.saltproject.io/en/latest/ref/configuration/minion.html#master-tries
master_tries: 1 - значение по умолчанию, так что все закономерно у вас

благодарю!

ух ты. благодарю. вопрос был адресован лично - случайно. извиняюсь

подскажи, а какие именно проблемы решает параметр ping_interval: 2 ?

ухты какая крутая штука. спасибо)

миньон отваливается от мастера и ничего об этом не знает, с этим параметром он точно подключится снова

эти параметры я настроил много лет назад, каких-то особых подробностей уже не помню