Good day, 

I've seen this behavior as well, I have disabled the firewall, and ensured that the service wouldn't restart, and yet there are a number of times during the day(s) that the firewalld.service is running again. Honestly, it's frustrating as SMT clients won't update properly, if they cannot contact/connect with the SMT 2.0 server, I also never saw this behavior with SMT 1.0, and would like to find some type of remediation. I don't if there would be anything in the SLES15-Sp4 forums, I've never actually logged into that service, but happy to try if that becomes needed. Much like you mentioned, in my internal arrangement, I rarely if ever bother with friewalls, certainly for outside connections I would do so, but again internally it seems to be another layer that isn't really needed. 

That being said I've only been running SMT 2.0 to match/mimic my customer arrangement, and might just return to SLES12-SP5 and SMT 1.0 if I cannot figure out the firewall.d.service issue. 

Again I've tried to disable, manually start up, but it seems that it's changing on it's own volition. 

Thank you, 

-DS 

Those 3 commands should help :

# systemctl stop firewalld

# systemctl disable firewalld

# systemctl mask firewalld

3d one is the best one ;-)

Those 3 commands should help :

# systemctl stop firewalld

# systemctl disable firewalld

# systemctl mask firewalld

3d one is the best one ;-)

ahh,   a mask!

a good trick to remember

let's hope they don't start pulling away our masks in our masquerade/dance of getting our systems to work.

Good day, 

I used this command as well (for now) systemctl mask firewalld and we'll see how things do moving forward. I can usually tell if the firewall service has turned back on because unable to SSH to the server in question. I guess as you had mentioned as well might not be a bad idea to start digging into this and seeing what it would take to keep the firewall up in the future.