Bug 885530 - Need init scripts for swift services
Need init scripts for swift services
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-swift (Show other bugs)
2.0 (Folsom)
Unspecified Unspecified
unspecified Severity unspecified
: snapshot2
: 2.1
Assigned To: Alan Pevec
Jaroslav Henner
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-09 20:27 EST by Derek Higgins
Modified: 2016-04-26 09:25 EDT (History)
3 users (show)

See Also:
Fixed In Version: openstack-swift-1.7.4-6.el6ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-14 13:23:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Candidate fix 2 (31.36 KB, patch)
2013-01-09 23:10 EST, Pete Zaitcev
no flags Details | Diff
adjust swift_action (2.55 KB, patch)
2013-01-16 19:36 EST, Alan Pevec
zaitcev: review+
Details | Diff
Fixup for the expirer (2.40 KB, patch)
2013-01-19 00:48 EST, Pete Zaitcev
apevec: review+
Details | Diff

  None (edit)
Description Derek Higgins 2012-12-09 20:27:44 EST
Swift should have init scripts for 

openstack-swift-account-auditor
openstack-swift-account-reaper
openstack-swift-account-replicator
openstack-swift-container-auditor
openstack-swift-container-replicator
openstack-swift-container-updater
openstack-swift-object-auditor
openstack-swift-object-expirer
openstack-swift-object-replicator
openstack-swift-object-updater
Comment 3 Pete Zaitcev 2013-01-08 14:39:57 EST
See bug 807170 for systemd fix.
Comment 4 Pete Zaitcev 2013-01-09 23:10:21 EST
Created attachment 676016 [details]
Candidate fix 2
Comment 7 Jaroslav Henner 2013-01-16 01:46:36 EST
Pete, please make sure to specify the `Fixed In Version` field when setting to ON_QA so I know which rpm to test against.
Comment 8 Alan Pevec 2013-01-16 07:09:24 EST
NVR added but we'll have to reopen this one for bug 895116
Comment 9 Alan Pevec 2013-01-16 07:15:33 EST
*** Bug 895116 has been marked as a duplicate of this bug. ***
Comment 11 Alan Pevec 2013-01-16 19:36:09 EST
Created attachment 679944 [details]
adjust swift_action

Minimal adjustment to "Candidate fix 2"
Comment 12 Jaroslav Henner 2013-01-18 05:34:18 EST
I installed from brew and didn't run the tests yet, but I can see some problems with the swift-proxy and object-expirer anyway: 

[root@folsom-rhel6 ~]# for svc in /etc/init.d/openstack-swift-*; do $svc start; sleep 1; done
Starting swift-account-server:                             [  OK  ]
Starting swift-account-auditor:                            [  OK  ]
Starting swift-account-reaper:                             [  OK  ]
Starting swift-account-replicator:                         [  OK  ]
Starting swift-container-server:                           [  OK  ]
Starting swift-container-auditor:                          [  OK  ]
Starting swift-container-replicator:                       [  OK  ]
Starting swift-container-updater:                          [  OK  ]
Starting swift-object-server:                              [  OK  ]
Starting swift-object-auditor:                             [  OK  ]
Starting swift-object-expirer:                             [  OK  ]
Starting swift-object-replicator:                          [  OK  ]
Starting swift-object-updater:                             [  OK  ]
Starting swift-proxy-:                                     [  OK  ]

[root@folsom-rhel6 ~]# for svc in /etc/init.d/openstack-swift-*; do $svc status; done
account-server (pid  6453) is running...
account-auditor (pid  6466) is running...
account-reaper (pid  6477) is running...
account-replicator (pid  6488) is running...
container-server (pid  6499) is running...
container-auditor (pid  6512) is running...
container-replicator (pid  6523) is running...
container-updater (pid  6534) is running...
object-server (pid  6545) is running...
object-auditor (pid  6559) is running...
object-expirer dead but pid file exists
object-replicator (pid  6578) is running...
object-updater (pid  6589) is running...
proxy- dead but pid file exists

I managed to make the object-expirer working by adding 
[object-expirer]
to /etc/swift/object-server.conf


I also saw following in the /var/log/swift-startup.log
/bin/bash: /usr/bin/swift-proxy-: No such file or directory
Comment 13 Alan Pevec 2013-01-18 06:43:05 EST
(In reply to comment #12)
> I managed to make the object-expirer working by adding 
> [object-expirer]
> to /etc/swift/object-server.conf

Not sure about that one, upstream sample https://github.com/openstack/swift/blob/master/etc/object-expirer.conf-sample
has different pipeline, so  reusing object-server.conf is a bug.
Comment 14 Pete Zaitcev 2013-01-19 00:02:13 EST
Sorry, I forgot that expirer does not actually run on the object storage
nodes, the name is misleading.

The /usr/bin/swift-object-expirer binary is included into openstack-swift
package, which I think is correct (could be alternatively placed into
openstack-swift-proxy for convenience).

However, the man pages are in -object subpackage in the same mistake
that I made with init/upstart scripts, only harmless.

We should either drop openstack-swift-object-expirer.{init|upstart}
altogether, or relocate them to openstack-swift-proxy.
Comment 15 Pete Zaitcev 2013-01-19 00:48:17 EST
Created attachment 682936 [details]
Fixup for the expirer
Comment 16 Alan Pevec 2013-01-21 05:45:53 EST
(In reply to comment #12)
> Starting swift-proxy-:                                     [  OK  ]
> proxy- dead but pid file exists
> I also saw following in the /var/log/swift-startup.log
> /bin/bash: /usr/bin/swift-proxy-: No such file or directory

Follow up to patch in comment 11:
--- a/openstack-swift-proxy.init
+++ b/openstack-swift-proxy.init
 name="proxy"
+subserv="server"
Comment 18 Jaroslav Henner 2013-02-12 16:00:23 EST
Everything seems to start OK. Modified and sorted ps aux shows that every server is started twice. Is it OK?

/usr/bin/python /usr/bin/swift-account-auditor /etc/swift/account-server.conf
/usr/bin/python /usr/bin/swift-account-reaper /etc/swift/account-server.conf
/usr/bin/python /usr/bin/swift-account-replicator /etc/swift/account-server.conf
/usr/bin/python /usr/bin/swift-account-server /etc/swift/account-server.conf    1
/usr/bin/python /usr/bin/swift-account-server /etc/swift/account-server.conf    1
/usr/bin/python /usr/bin/swift-container-auditor /etc/swift/container-server.conf
/usr/bin/python /usr/bin/swift-container-replicator /etc/swift/container-server.conf
/usr/bin/python /usr/bin/swift-container-server /etc/swift/container-server.conf    2
/usr/bin/python /usr/bin/swift-container-server /etc/swift/container-server.conf    2
/usr/bin/python /usr/bin/swift-container-updater /etc/swift/container-server.conf
/usr/bin/python /usr/bin/swift-object-auditor /etc/swift/object-server.conf    3
/usr/bin/python /usr/bin/swift-object-auditor /etc/swift/object-server.conf    3
/usr/bin/python /usr/bin/swift-object-replicator /etc/swift/object-server.conf
/usr/bin/python /usr/bin/swift-object-server /etc/swift/object-server.conf    4
/usr/bin/python /usr/bin/swift-object-server /etc/swift/object-server.conf    4
/usr/bin/python /usr/bin/swift-object-updater /etc/swift/object-server.conf

pstree follows
     ├─swift-account-a(swift)
     ├─2*[swift-account-r(swift)]
     ├─swift-account-s(swift)───swift-account-s
     ├─swift-container(swift)───swift-container
     ├─3*[swift-container(swift)]
     ├─swift-object-au(swift)───swift-object-au
     ├─swift-object-re(swift)───20*[{swift-object-r}]
     ├─swift-object-se(swift)───swift-object-se
     ├─swift-object-up(swift)
Comment 19 Pete Zaitcev 2013-02-13 00:39:57 EST
This looks a little random indeed. The default workers for object-server,
container-server, account-server is 1. However, all stock configs that
our RPMs install have workers = 2. I don't know why we chose 2, and not
3 or 8. Probably copied from the Multinode doc.
Comment 20 Pete Zaitcev 2013-02-13 00:52:16 EST
I just looked at the object-auditor and it has a weird hardwired fork
inside ObjectAuditor.run_forever. I think we can say it's ok to have 2,
although I'm not getting to what end it's done this way.
Comment 21 Jaroslav Henner 2013-02-13 03:47:35 EST
(In reply to comment #20)
> I just looked at the object-auditor and it has a weird hardwired fork
> inside ObjectAuditor.run_forever. I think we can say it's ok to have 2,
> although I'm not getting to what end it's done this way.

I didn't read the code, but maybe it is an example of double-forking?

# Fork a second child and exit immediately to prevent zombies.  This
# causes the second child process to be orphaned, making the init
# process responsible for its cleanup.  And, since the first child is
# a session leader without a controlling terminal, it's possible for
# it to acquire one by opening a terminal in the future (System V-
# based systems).  This second fork guarantees that the child is no
# longer a session leader, preventing the daemon from ever acquiring
# a controlling terminal.
http://stackoverflow.com/a/881434

But I guess in that case, both parents should live fast and die young. ;)
Comment 22 Alan Pevec 2013-02-13 04:50:40 EST
(In reply to comment #19)
> However, all stock configs that our RPMs install have workers = 2.
> I don't know why we chose 2, and not 3 or 8.
> Probably copied from the Multinode doc.

Redirecting needinfo to Derek, he added config files to our RPMs:
http://pkgs.fedoraproject.org/cgit/openstack-swift.git/commit/?id=61f8545c153a01169a586873ad7056cbb5c5de5d
Comment 23 Derek Higgins 2013-02-13 09:48:21 EST
The initial values set in the config files were based on sample configs I was looking at at the time from upstream, I have no objection to changing workers to a more sensible default value.
Comment 25 errata-xmlrpc 2013-02-14 13:23:10 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-0260.html
Comment 26 Pete Zaitcev 2013-02-20 13:51:12 EST
The fix was incomplete, see bug 913195.

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