Bug 16549 - systemctl enable/disable goes into infinite loop when both sysvinit and systemd native units exists
Summary: systemctl enable/disable goes into infinite loop when both sysvinit and syste...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-07 02:45 CEST by Frank Griffin
Modified: 2019-02-19 22:41 CET (History)
1 user (show)

See Also:
Source RPM: systemd
CVE:
Status comment:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Frank Griffin 2015-08-07 02:45:56 CEST 
I was trying a fresh install today, and part of my post-install is to disable services I want installed but not activated.

When my script issued a "systemctl disable mythbackend.service" it went into a loop with systemd referring it to sysv-install and sysv-install referring it back to systemd.  This continued until all of the DBUS resources for systemd were tied up and the system had to be rebooted.

Reproducible: 

Steps to Reproduce:
Comment 1 Marja Van Waes 2015-08-07 22:41:00 CEST 
Colin will understand :-)

CC: (none) => marja11
Assignee: bugsquad => mageia

Comment 2 Colin Guthrie 2015-08-08 11:59:59 CEST 
Ahh quite possibly! The newer systemd releases will try and keep sysvinit in sync with systemd units if both are present and I suspect I messed something up there. Should be easy to fix tho'. Will take a look.

Certainly isn't a problem with mythbackend specifically tho' (although it would make sense to kill off the sysvinit script, although keeping it there for testing is handy :D)

Summary: mythbackend seems to belong to both systemd and sysv => systemctl enable/disable goes into infinite loop when both sysvinit and systemd native units exists
Source RPM: mythbackend => systemd

Comment 3 Frank Griffin 2015-11-03 03:22:39 CET 
Ping ?
Comment 4 Frank Griffin 2019-02-19 22:41:03 CET 
Closing as OLD.

Resolution: (none) => OLD
Status: NEW => RESOLVED
Note You need to log in before you can comment on or make changes to this bug.