salt failing to restart iptables on change

[SF Hadoop]

Environment

OS:  CentOS 7

Salt RPMS:

salt-2017.7.1-1.el7.noarch

salt-minion-2017.7.1-1.el7.noarch

I have a basic state that manages iptables as such:

iptables:

  pkg.installed:

    - name: iptables-services

  service.running:

    - enable: True

    - watch:

      - file: /etc/sysconfig/iptables

    - require:

      - pkg: iptables-services

Upon updating the iptables config file (that is being watched), I consistently see failures in the minion log:

[salt.loaded.int.module.cmdmod][ERROR   ][7136] Command '['systemd-run', '--scope', 'systemctl', 'restart', 'iptables.service']' failed with return code: 1

[salt.loaded.int.module.cmdmod][ERROR   ][7136] stderr: Running scope as unit run-7546.scope.

Job for iptables.service failed because the control process exited with error code. See "systemctl status iptables.service" and "journalctl -xe" for details.

[salt.loaded.int.module.cmdmod][ERROR   ][7136] retcode: 1

This results in the new config not getting loaded.  I have to manually restart iptables in order for the changes to get picked up.

I have scoured the threads for something similar but have only found this, which seems like it *could be* related but possibly not.

https://github.com/saltstack/salt/issues/34927

Any help understanding this weirdness is appreciated.

[Viet Hung Nguyen]

What salt actually does in this case is processing conditions (requisites, state config) then run the underlying system command. Here it ran cmd to restart iptables with exactly the cmd you see in the output and failed (return code 1)  so as systemd suggested, you should look at the log and find out why it failed to restart (maybe the iptables config is wrong). All it has to do with the underlying command/software (systemd, iptables service) , not salt. 

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/bb19aa19-2fe7-475f-988e-884a33237f93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[SF Hadoop]

According to the OS it never really runs that command.  Logs on the machine do not report that command every being issued.  Or any other error for that matter.

Prior to the salt run, iptables is running without issue.  Salt runs, the config gets updated, salt emits that error in the log, the daemon remains untouched and is still running without issue.

A manual restart of the iptables services loads the new config without issue so the config is fine.

Salt keeps telling me the command fails and to look at the underlying OS for the issue but the underlying OS is telling me salt never attempted to run the command it says it attempted to run.

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

[Florian Ermisch]

Am 4. Oktober 2017 18:35:05 MESZ schrieb SF Hadoop <sfha...@gmail.com>:
>According to the OS it never really runs that command. Logs on the
>machine
>do not report that command every being issued. Or any other error for
>that
>matter.

Did you put the minion in debug mode
to see all the modules called & stuff?

>
>Prior to the salt run, iptables is running without issue. Salt runs,
>the
>config gets updated, salt emits that error in the log, the daemon
>remains
>untouched and is still running without issue.

Daemon? There's no iptables daemon, there may be a service persisting changes and loading those at start-up.
Unless you're referencing to firewalld which works very differently.

>> [………]

[SF Hadoop]

Did you put the minion in debug mode
to see all the modules called & stuff?

Yes but I did not see anything telling.

Daemon? There's no iptables daemon, there may be a service persisting changes and loading those at start-up.
Unless you're referencing to firewalld which works very differently. 

I meant the service does not get reloaded.