Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Michal Sekletar]

On Thu, Mar 10, 2016 at 10:11 PM, Orion Poplawski  wrote:

> Can't the stop of iptables be dropped because the service is already stopped
> (or more likely not even present)?

Isn't this the case already? I simplified your scenario, i.e. A
conflicts B and C is part of both A and B. If I first start B and C
and then issue stop for B, then follow-up restart of A doesn't produce
an error. I observed the problem only after trying to restart A when B
and C were running.

Michal
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Andrei Borzenkov]

12.03.2016 13:41, Marcos Mello пишет:
> Orion Poplawski  cora.nwra.com> writes:
> 
>>
>> Andrei Borzenkov  gmail.com> writes:
>>> 11.03.2016 00:11, Orion Poplawski пишет:
 Uoti Urpala  pp1.inet.fi> writes:
> On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
>> It appears that this is a trigger for this issue.  Removing the
>> conflicts=iptables.service removes it.  This seems like a bug to me
>> though -
>> why is iptables being brought in if the PartOf= is a one-way dep?
>
> I guess it's because it's because firewalld.service has
> "Conflicts=iptables.service", and thus (re)starting firewalld.service
> stops iptables.service; fail2ban.service has PartOf to both, thus both
> the restart and stop are propagated, and conflict.

 Can't the stop of iptables be dropped because the service is already
> stopped
 (or more likely not even present)?
>>>
>>> One possible implementation is to have firewall.target and make all
>>> other services (firewalld, iptables and fail2ban) PartOf this target.
>>> You would then start/stop firewall.target instead of individual services.
>>
>> I tried this, but I get the same problem:
>>
>> # systemctl restart firewall.target
>> Failed to restart firewall.target: Transaction contains conflicting jobs
>> 'restart' and 'stop' for iptables.service. Probably contradicting
>> requirement dependencies configured.
>>
>> Also, this doesn't solve the issue of restarting fail2ban if firewalld is
>> restarted via "systemctl restart fail2ban" (which someone will do I'm sure),
>> unless there is some other dependency that needs to be setup between the
>> various units that I don't understand.  Not very familiar with configuring
>> targets.
> 
> 
> # /usr/lib/systemd/system/firewall.target
> [Unit]
> Description=Firewall
> StopWhenUnneeded=yes
> 
> [Install]
> WantedBy=basic.target
> 
> 
> # /usr/lib/systemd/system/firewalld.service
> [Unit]
> Description=firewalld - dynamic firewall daemon
> Before=network.target
> Before=libvirtd.service
> Before=NetworkManager.service
> After=dbus.service
> After=polkit.service
> Conflicts=iptables.service ip6tables.service ebtables.service ipset.service
> PartOf=firewall.target
> 
> [Service]
> EnvironmentFile=-/etc/sysconfig/firewalld
> ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS
> ExecReload=/bin/kill -HUP $MAINPID
> # supress to log debug and error output also to /var/log/messages
> StandardOutput=null
> StandardError=null
> Type=dbus
> BusName=org.fedoraproject.FirewallD1
> 
> [Install]
> WantedBy=firewall.target
> Alias=dbus-org.fedoraproject.FirewallD1.service
> 
> 
> # /usr/lib/systemd/system/fail2ban.service
> [Unit]
> Description=Fail2Ban Service
> Documentation=man:fail2ban(1)
> After=network.target iptables.service firewalld.service firewalld.service
> PartOf=firewall.target
> 
> [Service]
> Type=forking
> ExecStart=/usr/bin/fail2ban-client -x start
> ExecStop=/usr/bin/fail2ban-client stop
> ExecReload=/usr/bin/fail2ban-client reload
> PIDFile=/var/run/fail2ban/fail2ban.pid
> Restart=always
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> Then enable firewall.target and make all firewall services be
> WantedBy=firewall.target instead of basic.target.
> 
> However it is troublesome, because users will not restart firewall.target.
> They will restart firewalld.service, or iptables.service, or whatever.
> 

You can set RefuseManualStart, RefuseManualStop on each individual
service and educate users ...

> Each firewall package could drop a snippet adding a reverse PartOf=
> dependency in firewall.target:
> 
> # /usr/lib/systemd/system/firewall.target.d/firewalld.conf
> [Unit]
> PartOf=firewalld.service
> 
> This works, as firewalld.service restart will trigger firewall.target
> restart and finally fail2ban.service restart. But do not you think it is too
> much?
> 
> Cannot the restart job for the conflict units be dropped? IMO this is a
> valid use case and would make things a lot easier for packagers.


The problem apparently comes from the fact that systemd adds STOP jobs
for each conflicting unit which propagates this STOP to all units it
ConsistsOf. As conflicting unit is presumed to be already stopped at
this point, this can be considered as redundant. But I am not sure how
easy it is to avoid it. Unit state is checked when job is dispatched,
nto when job is enqueued ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Andrei Borzenkov]

12.03.2016 08:18, Orion Poplawski пишет:
> Andrei Borzenkov  gmail.com> writes:
>> 11.03.2016 00:11, Orion Poplawski пишет:
>>> Uoti Urpala  pp1.inet.fi> writes:
 On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
> It appears that this is a trigger for this issue.  Removing the
> conflicts=iptables.service removes it.  This seems like a bug to me
> though -
> why is iptables being brought in if the PartOf= is a one-way dep?

 I guess it's because it's because firewalld.service has
 "Conflicts=iptables.service", and thus (re)starting firewalld.service
 stops iptables.service; fail2ban.service has PartOf to both, thus both
 the restart and stop are propagated, and conflict.
>>>
>>> Can't the stop of iptables be dropped because the service is already stopped
>>> (or more likely not even present)?
>>
>> One possible implementation is to have firewall.target and make all
>> other services (firewalld, iptables and fail2ban) PartOf this target.
>> You would then start/stop firewall.target instead of individual services.
> 
> I tried this, but I get the same problem:
> 
> # systemctl restart firewall.target
> Failed to restart firewall.target: Transaction contains conflicting jobs
> 'restart' and 'stop' for iptables.service. Probably contradicting
> requirement dependencies configured.
> 

No, you tried something different.

You need firewall.target, which then includes *either* firewalld.service
*or* iptables.service. You never have them both enabled at the same
time. I.e.

firewalld.service:

PartOf=firewall.target
Conflicts=iptables.service

iptables.service:

PartOf=firewall.target
Conflicts=firewalld.service

fail2ban.service:

PartOf=firewall.target

And you probably want to have

[Install]
WantedBy=firewall.target

in all of them. Then you enable either firewalld or iptables together
with fail2ban.

This works.

> Also, this doesn't solve the issue of restarting fail2ban if firewalld is
> restarted via "systemctl restart fail2ban" (which someone will do I'm sure),
> unless there is some other dependency that needs to be setup between the
> various units that I don't understand.  Not very familiar with configuring
> targets.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Marcos Mello]

Orion Poplawski  cora.nwra.com> writes:

> 
> Andrei Borzenkov  gmail.com> writes:
> > 11.03.2016 00:11, Orion Poplawski пишет:
> > > Uoti Urpala  pp1.inet.fi> writes:
> > >> On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
> > >>> It appears that this is a trigger for this issue.  Removing the
> > >>> conflicts=iptables.service removes it.  This seems like a bug to me
> > >>> though -
> > >>> why is iptables being brought in if the PartOf= is a one-way dep?
> > >>
> > >> I guess it's because it's because firewalld.service has
> > >> "Conflicts=iptables.service", and thus (re)starting firewalld.service
> > >> stops iptables.service; fail2ban.service has PartOf to both, thus both
> > >> the restart and stop are propagated, and conflict.
> > > 
> > > Can't the stop of iptables be dropped because the service is already
stopped
> > > (or more likely not even present)?
> > 
> > One possible implementation is to have firewall.target and make all
> > other services (firewalld, iptables and fail2ban) PartOf this target.
> > You would then start/stop firewall.target instead of individual services.
> 
> I tried this, but I get the same problem:
> 
> # systemctl restart firewall.target
> Failed to restart firewall.target: Transaction contains conflicting jobs
> 'restart' and 'stop' for iptables.service. Probably contradicting
> requirement dependencies configured.
> 
> Also, this doesn't solve the issue of restarting fail2ban if firewalld is
> restarted via "systemctl restart fail2ban" (which someone will do I'm sure),
> unless there is some other dependency that needs to be setup between the
> various units that I don't understand.  Not very familiar with configuring
> targets.


# /usr/lib/systemd/system/firewall.target
[Unit]
Description=Firewall
StopWhenUnneeded=yes

[Install]
WantedBy=basic.target


# /usr/lib/systemd/system/firewalld.service
[Unit]
Description=firewalld - dynamic firewall daemon
Before=network.target
Before=libvirtd.service
Before=NetworkManager.service
After=dbus.service
After=polkit.service
Conflicts=iptables.service ip6tables.service ebtables.service ipset.service
PartOf=firewall.target

[Service]
EnvironmentFile=-/etc/sysconfig/firewalld
ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS
ExecReload=/bin/kill -HUP $MAINPID
# supress to log debug and error output also to /var/log/messages
StandardOutput=null
StandardError=null
Type=dbus
BusName=org.fedoraproject.FirewallD1

[Install]
WantedBy=firewall.target
Alias=dbus-org.fedoraproject.FirewallD1.service


# /usr/lib/systemd/system/fail2ban.service
[Unit]
Description=Fail2Ban Service
Documentation=man:fail2ban(1)
After=network.target iptables.service firewalld.service firewalld.service
PartOf=firewall.target

[Service]
Type=forking
ExecStart=/usr/bin/fail2ban-client -x start
ExecStop=/usr/bin/fail2ban-client stop
ExecReload=/usr/bin/fail2ban-client reload
PIDFile=/var/run/fail2ban/fail2ban.pid
Restart=always

[Install]
WantedBy=multi-user.target


Then enable firewall.target and make all firewall services be
WantedBy=firewall.target instead of basic.target.

However it is troublesome, because users will not restart firewall.target.
They will restart firewalld.service, or iptables.service, or whatever.

Each firewall package could drop a snippet adding a reverse PartOf=
dependency in firewall.target:

# /usr/lib/systemd/system/firewall.target.d/firewalld.conf
[Unit]
PartOf=firewalld.service

This works, as firewalld.service restart will trigger firewall.target
restart and finally fail2ban.service restart. But do not you think it is too
much?

Cannot the restart job for the conflict units be dropped? IMO this is a
valid use case and would make things a lot easier for packagers.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Orion Poplawski]

Andrei Borzenkov  gmail.com> writes:
> 11.03.2016 00:11, Orion Poplawski пишет:
> > Uoti Urpala  pp1.inet.fi> writes:
> >> On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
> >>> It appears that this is a trigger for this issue.  Removing the
> >>> conflicts=iptables.service removes it.  This seems like a bug to me
> >>> though -
> >>> why is iptables being brought in if the PartOf= is a one-way dep?
> >>
> >> I guess it's because it's because firewalld.service has
> >> "Conflicts=iptables.service", and thus (re)starting firewalld.service
> >> stops iptables.service; fail2ban.service has PartOf to both, thus both
> >> the restart and stop are propagated, and conflict.
> > 
> > Can't the stop of iptables be dropped because the service is already stopped
> > (or more likely not even present)?
> 
> One possible implementation is to have firewall.target and make all
> other services (firewalld, iptables and fail2ban) PartOf this target.
> You would then start/stop firewall.target instead of individual services.

I tried this, but I get the same problem:

# systemctl restart firewall.target
Failed to restart firewall.target: Transaction contains conflicting jobs
'restart' and 'stop' for iptables.service. Probably contradicting
requirement dependencies configured.

Also, this doesn't solve the issue of restarting fail2ban if firewalld is
restarted via "systemctl restart fail2ban" (which someone will do I'm sure),
unless there is some other dependency that needs to be setup between the
various units that I don't understand.  Not very familiar with configuring
targets.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Colin Guthrie]

Andrei Borzenkov wrote on 11/03/16 03:36:
> 11.03.2016 00:11, Orion Poplawski пишет:
>> Uoti Urpala  pp1.inet.fi> writes:
>>
>>>
>>> On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
 Orion Poplawski  cora.nwra.com> writes:
>  
> # systemctl restart firewalld
> Failed to restart firewalld.service: Transaction contains
> conflicting jobs
> 'restart' and 'stop' for fail2ban.service. Probably contradicting
> requirement dependencies configured.
>>>
 It appears that this is a trigger for this issue.  Removing the
 conflicts=iptables.service removes it.  This seems like a bug to me
 though -
 why is iptables being brought in if the PartOf= is a one-way dep?
>>>
>>> I guess it's because it's because firewalld.service has
>>> "Conflicts=iptables.service", and thus (re)starting firewalld.service
>>> stops iptables.service; fail2ban.service has PartOf to both, thus both
>>> the restart and stop are propagated, and conflict.
>>
>> Can't the stop of iptables be dropped because the service is already stopped
>> (or more likely not even present)?
>>
>>> Claiming a PartOf relationship to both of two conflicting services is
>>> the problem here. I doubt such a use case was what PartOf was designed
>>> to support.
>>
>>
>> The problem is that fail2ban can work with either iptables.service or
>> fail2ban.service, and we don't know which one the use wants to use.  And we
>> need fail2ban to be restarted if either firewalld or iptables is restarted.
>> If there is some other supported way of achieving this, that would be
>> welcome.  Otherwise this strikes be as something that should be able to be
>> handled as is.
> 
> 
> One possible implementation is to have firewall.target and make all
> otehr services (firewalld, iptables and fail2ban) PartOf this target.
> You would then start/stop firewall.target instead of individual services.

That's certainly more the kind of configuration PartOf= was originally
developed to support. I wasn't even aware you could use it with .service
units, thought it was only for .targets if I'm honest.

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Andrei Borzenkov]

11.03.2016 00:11, Orion Poplawski пишет:
> Uoti Urpala  pp1.inet.fi> writes:
> 
>>
>> On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
>>> Orion Poplawski  cora.nwra.com> writes:
  
 # systemctl restart firewalld
 Failed to restart firewalld.service: Transaction contains
 conflicting jobs
 'restart' and 'stop' for fail2ban.service. Probably contradicting
 requirement dependencies configured.
>>
>>> It appears that this is a trigger for this issue.  Removing the
>>> conflicts=iptables.service removes it.  This seems like a bug to me
>>> though -
>>> why is iptables being brought in if the PartOf= is a one-way dep?
>>
>> I guess it's because it's because firewalld.service has
>> "Conflicts=iptables.service", and thus (re)starting firewalld.service
>> stops iptables.service; fail2ban.service has PartOf to both, thus both
>> the restart and stop are propagated, and conflict.
> 
> Can't the stop of iptables be dropped because the service is already stopped
> (or more likely not even present)?
> 
>> Claiming a PartOf relationship to both of two conflicting services is
>> the problem here. I doubt such a use case was what PartOf was designed
>> to support.
> 
> 
> The problem is that fail2ban can work with either iptables.service or
> fail2ban.service, and we don't know which one the use wants to use.  And we
> need fail2ban to be restarted if either firewalld or iptables is restarted.
> If there is some other supported way of achieving this, that would be
> welcome.  Otherwise this strikes be as something that should be able to be
> handled as is.


One possible implementation is to have firewall.target and make all
otehr services (firewalld, iptables and fail2ban) PartOf this target.
You would then start/stop firewall.target instead of individual services.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Uoti Urpala]

On Thu, 2016-03-10 at 17:51 +, Orion Poplawski wrote:
> Orion Poplawski  cora.nwra.com> writes:
> > 
> > # systemctl restart firewalld
> > Failed to restart firewalld.service: Transaction contains
> > conflicting jobs
> > 'restart' and 'stop' for fail2ban.service. Probably contradicting
> > requirement dependencies configured.

> It appears that this is a trigger for this issue.  Removing the
> conflicts=iptables.service removes it.  This seems like a bug to me
> though -
> why is iptables being brought in if the PartOf= is a one-way dep?

I guess it's because it's because firewalld.service has
"Conflicts=iptables.service", and thus (re)starting firewalld.service
stops iptables.service; fail2ban.service has PartOf to both, thus both
the restart and stop are propagated, and conflict.

Claiming a PartOf relationship to both of two conflicting services is
the problem here. I doubt such a use case was what PartOf was designed
to support.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Transaction contains conflicting jobs 'restart' and 'stop'

[Orion Poplawski]

Orion Poplawski  cora.nwra.com> writes:
> 
> Can someone please explain this to me?
> 
> # systemctl restart firewalld
> Failed to restart firewalld.service: Transaction contains conflicting jobs
> 'restart' and 'stop' for fail2ban.service. Probably contradicting
> requirement dependencies configured.
>
> # cat /usr/lib/systemd/system/fail2ban.service
> [Unit]
> PartOf=iptables.service firewalld.service
> 
> # cat /usr/lib/systemd/system/firewalld.service
> [Unit]
> Conflicts=iptables.service ip6tables.service ebtables.service

It appears that this is a trigger for this issue.  Removing the
conflicts=iptables.service removes it.  This seems like a bug to me though -
why is iptables being brought in if the PartOf= is a one-way dep?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel