Bug 657512
Summary: | jabberd - init script issues | |||
---|---|---|---|---|
Product: | Red Hat Satellite 5 | Reporter: | Jan Pazdziora (Red Hat) <jpazdziora> | |
Component: | Server | Assignee: | Jan Pazdziora (Red Hat) <jpazdziora> | |
Status: | CLOSED ERRATA | QA Contact: | Jan HutaĆ <jhutar> | |
Severity: | medium | Docs Contact: | ||
Priority: | high | |||
Version: | 540 | CC: | cperry, jhutar | |
Target Milestone: | --- | Keywords: | Regression | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | jabberd-2.2.8-10.el5sat | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 660357 (view as bug list) | Environment: | ||
Last Closed: | 2010-12-16 14:38:32 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: | ||||
Bug Depends On: | 662611 | |||
Bug Blocks: | 646488 |
Description
Jan Pazdziora (Red Hat)
2010-11-26 10:19:41 UTC
Martin Poole then commented: for 1) should we automatically adjust the config file (c2s.xml being the normally affected beast) or make it suitably huge by default. <max_fds>1024</max_fds> since without modification the daemon will be limited to max_fds rather than ulimit.nofile for 2) note the location has now changed and appears to be /var/lib/jabberd/db (In reply to comment #0) > 2) Details, in startup section we use to do: > > #Remove the database files, if they exist. > if [ -e /var/lib/jabberd ] > then > for i in /var/lib/jabberd/* > do > #Don't try to remove /var/lib/jabberd/* > if [ -e $i ] > then > rm -f $i > fi > done > fi Cliff, why can't we simply do rm -rf /var/lib/jabberd/* here? I somehow fail to see what the intended logic of the code was. Jan - looking: Sat 5.3 - jabberd-2.0s10-3.52.el5sat : -------------------------------------- [root@rlx-1-10 jabberd]# pwd /var/lib/jabberd [root@rlx-1-10 jabberd]# ls authreg.db __db.001 __db.002 __db.003 __db.004 __db.005 log.0000000001 sm.db [root@rlx-1-10 jabberd]# I can confirm that those above files will be re-created on restart as clients connect. It is transient data in that it does not need to be preserved. Sat 5.4 - jabberd-2.2.8-8.el5sat: --------------------------------- [root@rlx-1-18 jabberd]# pwd /var/lib/jabberd [root@rlx-1-18 jabberd]# find . . ./log ./db ./db/__db.001 ./db/__db.004 ./db/__db.002 ./db/authreg.db ./db/__db.005 ./db/sm.db ./db/log.0000000001 ./db/__db.003 ./pid ./pid/s2s.pid ./pid/router.pid ./pid/c2s.pid ./pid/sm.pid [root@rlx-1-18 jabberd]# Looking on Sat 5.4 - the script would rm -rf /var/lib/jabberd/db/* here, leaving the .pid files alone. Though, if the daemon is already shut down, removing the pid files if they still exist is good cleanup to do, before starting back up. As for the specific question on why the loop to go through all files. I cannot remember. No doubt the developer at the time hit an issue and prefered not to use 'rm -rf'. I do not know why it was choosen to be implemented this way. Cliff (In reply to comment #3) > Looking on Sat 5.4 - the script would rm -rf /var/lib/jabberd/db/* here, > leaving the .pid files alone. > > Though, if the daemon is already shut down, removing the pid files if they > still exist is good cleanup to do, before starting back up. Pid files get removed by the script already, before starting the individual programs: for prog in ${progs}; do if [ $( pidof -s ${prog} ) ]; then echo "process [${prog}] already running" continue fi echo -n "Starting ${prog}: " rm -f /var/lock/subsys/${prog} rm -f ${pidPath}/${prog}.pid Addressed in the thirdparty repo, ced047d23d06089e0be8111222e91b2bc424c09b, f575bdfd27e508b1adaa58a1a44e8e939af6d5a0, and 3164cd44232cd83a934b308bea3b14ccbe288477. Built as jabberd-2.2.8-9.el5sat. Fixed the fix in Satellite thirdparty, e6c16053c4f7ea9c135ed2517cc1432d6634236c, to work correctly upon upgrades. Moving ON_QA. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0989.html |