Bug 699835 - service command is not fully backwards compatible with 389-ds-base
Summary: service command is not fully backwards compatible with 389-ds-base
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-26 17:53 UTC by Rich Megginson
Modified: 2012-08-07 20:26 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-07 20:26:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch (507 bytes, patch)
2011-04-26 19:11 UTC, Bill Nottingham
no flags Details | Diff
systemctl status dirsrv.service (384 bytes, text/plain)
2011-04-26 20:05 UTC, Rich Megginson
no flags Details

Description Rich Megginson 2011-04-26 17:53:10 UTC
The 389-ds-base package uses a service named "dirsrv".  There can be more than one dirsrv daemon (389 uses the term "directory server instances" or "instances") running on the system.  The single dirsrv initscript is used to operate on all instances or on individual instances.

service dirsrv start

will operate on all instances.

service dirsrv start foo

will operate only on the instance named "foo".

Comment 1 Rich Megginson 2011-04-26 18:33:15 UTC
With 389

service dirsrv CMD

works.  That is, it does CMD to all instances.

service dirsrv CMD inst

does not work.  It does CMD to all instances.

Comment 2 Lennart Poettering 2011-04-26 19:02:17 UTC
Uh, that's not SysV what you have been doing there. That's brokenness, sorry. I have no plans supporting that, sorry.

Comment 3 Rich Megginson 2011-04-26 19:06:51 UTC
(In reply to comment #2)
> Uh, that's not SysV what you have been doing there. That's brokenness, sorry. I
> have no plans supporting that, sorry.

# man service

service(8)                                                          service(8)

NAME
       service - run a System V init script

SYNOPSIS
       service SCRIPT COMMAND [OPTIONS]
...
"service  passes  COMMAND  and  OPTIONS it to the init script unmodified."

I would say service is broken if it cannot pass "inst" to the init script unmodified.

Comment 4 Bill Nottingham 2011-04-26 19:11:06 UTC
Created attachment 495017 [details]
patch

Does this fix it for you?

(It's a hack, but it's probably the simplest solution.)

Comment 5 Dmitri Pal 2011-04-26 19:21:16 UTC
I am not sure that will work for cases where there are no arguments. I mean fix is not complete but by shell skills might be a bit rusty...

Comment 6 Dmitri Pal 2011-04-26 19:31:00 UTC
(In reply to comment #4)
> Created attachment 495017 [details]
> patch
> 
> Does this fix it for you?
> 
> (It's a hack, but it's probably the simplest solution.)

Why every single component should fix this?

Comment 7 Bill Nottingham 2011-04-26 19:32:18 UTC
(In reply to comment #5)
> I am not sure that will work for cases where there are no arguments. I mean fix
> is not complete but by shell skills might be a bit rusty...

If there are no arguments, you shouldn't have a problem.

(In reply to comment #6)
> > Does this fix it for you?
> > 
> > (It's a hack, but it's probably the simplest solution.)
> 
> Why every single component should fix this?

They shouldn't. This isn't a patch for every single component.

Comment 8 Dmitri Pal 2011-04-26 19:38:58 UTC
> > 
> > Why every single component should fix this?
> 
> They shouldn't. This isn't a patch for every single component.

Every single component that relies on this functionality. For me it means all the components that I am in charge.

Comment 9 Rich Megginson 2011-04-26 19:42:10 UTC
I don't understand.  This patch applies to /etc/rc.d/init.d/function which will affect every script that uses /etc/rc.d/init.d/function ?  Which is probably most if not all sysv initscript?

Anyway, even with the patch, the following does not work:
I have two instances dirsrv-foo and dirsrv-bar

service dirsrv start

ps -ef|grep slapd shows foo and bar

service dirsrv stop foo

ps -ef|grep slapd shows bar

service dirsrv stop bar

ps -ef|grep slapd shows nothing

service dirsrv start

does not start foo or bar - ps -ef shows nothing

Comment 10 Bill Nottingham 2011-04-26 19:43:50 UTC
(In reply to comment #9)
> Anyway, even with the patch, the following does not work:
> I have two instances dirsrv-foo and dirsrv-bar
> 
> service dirsrv start
> 
> ps -ef|grep slapd shows foo and bar
> 
> service dirsrv stop foo
> 
> ps -ef|grep slapd shows bar
> 
> service dirsrv stop bar
> 
> ps -ef|grep slapd shows nothing

If you insert 'service dirsrv stop' here, does it work?

> service dirsrv start
> 
> does not start foo or bar - ps -ef shows nothing

Comment 11 Rich Megginson 2011-04-26 19:49:36 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > Anyway, even with the patch, the following does not work:
> > I have two instances dirsrv-foo and dirsrv-bar
> > 
> > service dirsrv start
> > 
> > ps -ef|grep slapd shows foo and bar
> > 
> > service dirsrv stop foo
> > 
> > ps -ef|grep slapd shows bar
> > 
> > service dirsrv stop bar
> > 
> > ps -ef|grep slapd shows nothing
> 
> If you insert 'service dirsrv stop' here, does it work?
>

Yes.
 
> > service dirsrv start
> > 
> > does not start foo or bar - ps -ef shows nothing

Comment 12 Bill Nottingham 2011-04-26 19:51:30 UTC
At the point where I suggested running 'service dirsrv stop', what's the output of:

systemctl status dirsrv.service

?

Comment 13 Rich Megginson 2011-04-26 20:05:11 UTC
Created attachment 495026 [details]
systemctl status dirsrv.service

Comment 14 Rich Megginson 2011-04-26 20:17:58 UTC
I think the solution for 389 is to just add
SYSTEMCTL_SKIP_REDIRECT=1 ; export SYSTEMCTL_SKIP_REDIRECT
at the beginning of the regular sysv init script.

Comment 15 Rich Megginson 2011-04-28 14:52:43 UTC
done - 389-ds-base and 389-admin in F15 have disabled the use of systemd.

To ssh://pkgs.fedoraproject.org/389-ds-base.git
   4bc713c..a73b935  f15 -> f15/master
commit a73b9353fc172352d8b9509f2ae81d6b30c60d72
Author: Rich Megginson <rmeggins>
Date:   Wed Apr 27 18:51:15 2011 -0600

    Disable the use of systemd for the initscripts

To ssh://rmeggins.org/389-admin
   1a24529..7a7ffcd  f15 -> f15/master
commit 1a24529c1173dea8086729105e42f107cf4466aa
Author: Rich Megginson <rmeggins>
Date:   Wed Apr 27 18:58:44 2011 -0600

    Disable the use of systemd for the initscripts

Comment 16 Fedora Update System 2011-04-28 15:02:49 UTC
389-ds-base-1.2.8.2-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-ds-base-1.2.8.2-2.fc15

Comment 17 Fedora Update System 2011-04-28 15:03:26 UTC
389-admin-1.1.16-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-admin-1.1.16-2.fc15

Comment 18 Fedora Update System 2011-04-28 19:00:55 UTC
Package 389-admin-1.1.16-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing 389-admin-1.1.16-2.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/389-admin-1.1.16-2.fc15
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2011-06-21 22:05:40 UTC
389-admin-1.1.18-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-admin-1.1.18-1.fc15

Comment 20 Fedora Update System 2011-06-28 16:13:56 UTC
389-admin-1.1.19-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-admin-1.1.19-1.fc15

Comment 21 Fedora Update System 2011-07-01 01:41:40 UTC
389-admin-1.1.19-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-admin-1.1.19-2.fc15

Comment 22 Fedora Update System 2011-07-05 20:56:39 UTC
389-admin-1.1.20-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-admin-1.1.20-2.fc15

Comment 23 Fedora Update System 2011-08-02 21:42:39 UTC
389-admin-1.1.21-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-admin-1.1.21-1.fc15

Comment 24 Fedora Update System 2011-08-11 16:05:29 UTC
389-admin-1.1.22-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/389-admin-1.1.22-1.fc15

Comment 25 Fedora Admin XMLRPC Client 2011-10-20 16:30:10 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 26 Fedora End Of Life 2012-08-07 20:26:51 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.