Bug 714830

Summary: No equivalent of --initscript parameter to /usr/sbin/alternatives when using systemd instead of an /etc/init.d script
Product: [Fedora] Fedora Reporter: Sam Varshavchik <mrsam>
Component: chkconfigAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: jskarvad, k.georgiou, notting, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 723679 (view as bug list) Environment:
Last Closed: 2011-07-20 19:33:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test patch
none
better patch none

Description Sam Varshavchik 2011-06-20 22:44:33 UTC
Description of problem:

The --initscript option to /usr/sbin/alternatives does not work with systemd

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

1.3.52-1.fc15

How reproducible:

Always

Steps to Reproduce:
1. Take two or more existing packages. Each package install its own /etc/init.d/{servicename}. Each package installs a corresponding alternatives symlink using the --initscript option to alternatives.
2. Using the alternatives command to switch between the alternative services also ends up with the alternatives taking care of running chkconfig on and chkconfig off.
3. Now, update all packages from /etc/init.d/{service} to /lib/systemd/system/{servicename}.service
4. Note that there is no equivalent --initscript option for systemd, for the alternatives command, so leave the same alternatives --install in place.
5. Proceed to install the rpms. Either upgrades of the pre-systemd versions, or new installs.
  
Actual results:

Example:

# /usr/sbin/alternatives --install /usr/sbin/sendmail mta \
     /usr/lib/courier/bin/sendmail 91 \
     --slave /usr/bin/mailq mta-mailq /usr/lib/courier/bin/mailq \
     --slave /usr/bin/rmail mta-rmail /usr/lib/courier/bin/rmail \
     --slave /usr/bin/newaliases mta-newaliases \
          /usr/lib/courier/sbin/makealiases \
     --initscript courier
error reading information on service courier: No such file or directory

Expected results:

Activating the alternatives link to a package should result in a systemctl enable {service}.name, and, perhaps, systemctl disable {service}.name, for the corresponding service, for a package that uses systemd.

Deactivating the alternatives link to a package, should result in a systemctl stop {service}.name and systemctl disable {service}.name for the corresponding service.

Additional info:

Dropping the --initscript parameter, of course, works, but then controlling the alternatives-managed link has no effect on the supporting service daemon, which must then be managed manually. This is a loss of functionality from initscripts.

Comment 1 Bill Nottingham 2011-06-28 21:00:27 UTC
I started looking at this today.

The big issue is that the --initscript argument today works in terms of 'chkconfig --add' and 'chkconfig --del', where it removes/adds all the start/stop links entirely. There's not a direct analog here, so it's not a trivial fix - might require some changes to its semantics.

Comment 3 Sam Varshavchik 2011-07-15 21:16:18 UTC
The test patch appears to be a CNN article...

Comment 4 Bill Nottingham 2011-07-15 21:23:04 UTC
That's a neat trick. Will fix.

Comment 5 Bill Nottingham 2011-07-15 21:23:40 UTC
Created attachment 513448 [details]
test patch

Comment 7 Sam Varshavchik 2011-07-15 23:49:07 UTC
Does not work. A watchpoint shows isSystemd that gets initialized by the patch subsequently gets clobbered by line 595:

	/* Insert new set into the set of alternatives */
	for (i = 0 ; i < set.numAlts ; i++) {
		if (!strcmp(set.alts[i].master.target, newAlt.master.target)) {
====>			set.alts[i] = newAlt;
			break;
		}

Comment 8 Bill Nottingham 2011-07-19 20:59:01 UTC
What is it doing for you if you pass --verbose? It seems to be working for me.

Comment 9 Bill Nottingham 2011-07-19 20:59:27 UTC
Oh, never mind. --set works, the initial install doesn't.

Comment 10 Bill Nottingham 2011-07-19 21:18:20 UTC
Created attachment 513882 [details]
better patch

Here's a better patch that works for me, and will be in the next rawhide build; it just leaves the determination of whether to call systemctl to when it actually performs the action.

Comment 11 Sam Varshavchik 2011-07-20 02:05:09 UTC
Gave the new patch a spin.

Seems to work, except for one thing. --remove does not run "systemctl disable". The alternatives symlink gets removed, but the systemd service does not get disabled.

For me, --install runs "systemctl enable", but --remove does not run "systemctl disable". This seems to be inconsistent.

Comment 12 Bill Nottingham 2011-07-20 18:22:45 UTC
That's not a regression, though.

If I recall, the idea is that that is done in the package's scripts on uninstallation.

Comment 13 Sam Varshavchik 2011-07-20 19:26:30 UTC
But, presumably, so would be on installation too.

Since chkconfig does not support systemd at all, I don't see what's here to regress. But this is an opportunity to make things more consistent.

It seems more consistent to me that if chkconfig enables the service on install, it should also disable it on uninstall. Or, do not enable or disable on install and uninstall at all; make it the package's responsibility, to enable and disable its service, in addition to installing and uninstalling an alternatives links; and chkconfig only invokes systemctl when switching to a new alternative.

Comment 14 Bill Nottingham 2011-07-20 19:33:23 UTC
I've cloned this bug for that issue (bug 723679); setting this one as CLOSED->RAWHIDE.