Bug 1542391

Summary: calling service reload after starting firewalld stop NM daemon
Product: Red Hat Enterprise Linux 7 Reporter: Vladimir Benes <vbenes>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Frantisek Sumsal <fsumsal>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.5CC: atragler, bbreard, bgalvani, fgiudici, fsumsal, lrintel, rkhan, sukulkar, systemd-maint-list, thaller
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-219-55.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1576081 (view as bug list) Environment:
Last Closed: 2018-04-10 11:25:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1576081    
Attachments:
Description Flags
logs
none
journal for NetworkManager restarting
none
systemctl show NetworkManager.service output none

Description Vladimir Benes 2018-02-06 09:22:13 UTC
Description of problem:
NM service goes down after calling systemctl reload NetworkManager after I unmasked firewalld and started it. This is very odd.

 

Version-Release number of selected component (if applicable):
1.10.2-10

How reproducible:
always

Steps to Reproduce:
systemctl unmask firewalld
systemctl start firewalld
systemctl reload NetworkManager

Actual results:
no NM service running

Expected results:
NM should be running and conf reloaded

Additional info:

Comment 2 Vladimir Benes 2018-02-06 09:22:55 UTC
Created attachment 1391916 [details]
logs

Comment 3 Vladimir Benes 2018-02-06 09:31:40 UTC
without unmasking it doesn't happen.

Comment 4 Thomas Haller 2018-02-06 11:54:53 UTC
Created attachment 1392041 [details]
journal for NetworkManager restarting

I replaced NetworkManager.service's ExecStart with:

  ExecStart=/usr/bin/strace -s 2048 -ttt -x -f -D /sbin/NetworkManager --no-daemon

Attached is the journal. We see:


Feb 06 06:38:57 gsm-r5s2-01.wlan.rhts.eng.bos.redhat.com systemd[1]: Reloading.

Feb 06 06:39:08 gsm-r5s2-01.wlan.rhts.eng.bos.redhat.com NetworkManager[2874]: <info>  [1517917148.9204] audit: op="reload" arg="0" pid=2995 uid=0 result="success"

Feb 06 06:39:08 gsm-r5s2-01.wlan.rhts.eng.bos.redhat.com strace[2874]: [pid  2878] 1517917148.963770 restart_syscall(<... resuming interrupted poll ...> <unfinished ...>
Feb 06 06:39:08 gsm-r5s2-01.wlan.rhts.eng.bos.redhat.com strace[2874]: [pid  2880] 1517917148.963792 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
Feb 06 06:39:08 gsm-r5s2-01.wlan.rhts.eng.bos.redhat.com strace[2874]: [pid  2874] 1517917148.963801 <... poll resumed> ) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
Feb 06 06:39:08 gsm-r5s2-01.wlan.rhts.eng.bos.redhat.com strace[2874]: [pid  2880] 1517917148.963813 --- SIGCONT {si_signo=SIGCONT, si_code=SI_USER, si_pid=1, si_uid=0} ---
Feb 06 06:39:08 gsm-r5s2-01.wlan.rhts.eng.bos.redhat.com NetworkManager[2874]: <info>  [1517917148.9641] caught SIGTERM, shutting down normally.




Apparently, systemd is not only executing ExecReload

ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.Reload uint32:0

but also sending SIGTERM, which causes NetworkManager to exit.

Comment 5 Thomas Haller 2018-02-06 12:09:43 UTC
Created attachment 1392044 [details]
systemctl show NetworkManager.service output

Also, the output of `systemctl show NetworkManager`

Note:

ExecReload={ path=/usr/bin/dbus-send ; argv[]=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.Reload uint32:0 ; ignore_errors=no ; start_time=[Tue 2018-02-06 06:39:08 EST] ; stop_time=[Tue 2018-02-06 06:39:08 EST] ; pid=2995 ; code=exited ; status=0 }

which matches the time from the previous log, when SIGTERM was received.

Comment 6 Thomas Haller 2018-02-06 12:10:52 UTC
Reassigning to systemd, to understand why SIGTERM was sent.

Comment 8 Lukáš Nykrýn 2018-02-07 14:10:23 UTC
fix merged to staging branch -> https://github.com/lnykryn/systemd-rhel/pull/194 -> post

Comment 13 errata-xmlrpc 2018-04-10 11:25:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0711