Red Hat Bugzilla – Bug 1478335
rhel-dmesg service always enabled even after systemctl disable rhel-dmesg.service
Last modified: 2017-08-23 11:10:16 EDT
Description of problem:
rhel-dmesg service always enabled even after systemctl disable
[root@kc0005 basic.target.wants]# systemctl status rhel-dmesg.service
* rhel-dmesg.service - Dump dmesg to /var/log/dmesg
Loaded: loaded (/usr/lib/systemd/system/rhel-dmesg.service; disabled; vendor preset: disabled) <== disabled status
Active: active (exited) since Thu 2017-08-03 10:33:01 JST; 1 day 9h ago
Process: 1034 ExecStart=/usr/lib/systemd/rhel-dmesg (code=exited, status=0/SUCCESS)
Main PID: 1034 (code=exited, status=0/SUCCESS)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. systemctl disable rhel-dmesg.service
2. Reboot the system
rhel-dmesg.service always started. And generate dmesg log under /var/log.
One can enable/disable rhel-dmesg.service using systemctl.
My understanding is that this symptom happen because
the initscripts RPM install symlink when the RPM install files.
But it is not the way how to "enable" the unit by default with systemd.
Preset files may be used to encode policy which units shall be enabled
by default and which ones shall be disabled.
I think the initscript packager should make use of this method.
Remove symlink under /usr/lib/systemd/system/basic.target.wants
And systemctl enable rhel-dmesg, then the system writes dmesg in /var/log.
And systemctl disable rhel-dmesg, then the system stop output dmesg in /var/log.
One customer asked HPE that why rhel-dmesg output the logs even it
has "disabled" status.
The I troubleshoot and found the reason.
I know that current method (provide the symlink by initscript RPM)
does the job.
But I think it doesn't follow the rule under systemd.
That's why the customer could not stop the service.
I'm closing this as a duplicate. If needed, please follow up in the former BZ.
*** This bug has been marked as a duplicate of bug 1395391 ***