Bug 719283

Summary: Provide native systemd unit file
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: tomcat6Assignee: David Knox <dknox>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: alee, dknox, dwalluck, jclere, robinlee.sysu, sochotni, SpikeFedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tomcat6-6.0.32-8.fc15 Doc Type: Bug Fix
Doc Text:
This release is the first using a systemd unit file. SystemV files are packaged separately. During this transition users may experience this error: "error reading information on service tomcat6: No such file or directory" The error occurs because there is no tomcat service to delete. It has been tested, is harmless, and can be ignored.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-19 00:35:08 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 713562    
Attachments:
Description Flags
Native systemd service file tomcat6
none
Patch to fix /usr/sbin/tomcat6
none
Script to start tomcat6 intended to be called by a unit file
none
Complete systemd unit file that uses tomcat6-sysd
none
Script to start tomcat6 intended to be called by a unit file
none
debuggd systemv unit file for tomcat6
none
Initialization script called by tomcat6.service none

Description Jóhann B. Guðmundsson 2011-07-06 06:46:30 EDT
Description of problem:

https://fedoraproject.org/wiki/Features/SysVtoSystemd


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jóhann B. Guðmundsson 2011-07-06 06:48:30 EDT
Created attachment 511472 [details]
Native systemd service file tomcat6
Comment 2 Jóhann B. Guðmundsson 2011-07-06 06:52:09 EDT
Created attachment 511473 [details]
Patch to fix /usr/sbin/tomcat6

Why are the lines 10 --> 17 commented out?
Comment 3 Ade Lee 2011-08-31 16:14:23 EDT
As it stands, the patch to /usr/sbin/tomcat6 will not work - but I can understand why Johann needed to uncomment those lines.

Currently, the system 5 init script does the following:

# Get the tomcat config (use this for environment specific settings)
TOMCAT_CFG="/etc/tomcat6/tomcat6.conf"
if [ -r "$TOMCAT_CFG" ]; then
    . $TOMCAT_CFG
fi

# Get instance specific config file
if [ -r "/etc/sysconfig/${NAME}" ]; then
    . /etc/sysconfig/${NAME}
fi

That is - it gets the generic environment settings, followed by any instance specific settings.  It then exports these setting to the environment and calls /usr/sbin/tomcat6.

Uncommenting those lines in /usr/sbin/tomcat6 has the effect of overwriting any instance specific config.  

But if you plan to not use the system V init file and have systemd start tomcat using the /usr/sbin/tomcat6, then the environment file must be read in /usr/sbin/tomcat6.  Maybe the answer then, is to read the config files in a similar manner to the way that it is done in the system V init script -- ie. general and then instance specific.

I do not see the relevance of the /etc/sysconfig/tomcat6 file though -- are those supposed to be commented out by the user?
Comment 4 David Knox 2011-08-31 17:35:14 EDT
Hi Ade,
There have been related confusion & questions.

The lines that source tomcat6.conf in the wrapper (sbin/tomcat6) should be commented. (see also 734886 and 575341). Someone needing an additional tomcat6 service should copy and rename the initscript, e.g., tomcat6-2. When the new tomcat6-2 service is started it will look for sysconfig/tomcat6-2. This is useful when, say, one instance is running under the security manager and another is not. 

The wrapper (sbin/tomcat6) inherits the config as set in the initscript. It was never intended to stand alone; which is part of the confusion. The wrapper should always be called by an initializing script.

hope this helps.
Comment 5 Ade Lee 2011-09-01 13:40:18 EDT
Knoxy, 

That makes complete sense.  You will notice though that Johann uses the /usr/sbin/tomcat6 file as the starting point in his systemd native init file.  This will not work as the tomcat environment needs to be parsed.

Johann had mentioned that simply pointing to the system V init script was not correct.  So, do you plan to create an initializing script that will read the relevant config files, do anything else needed - and that will call /usr/sbin/tomcat6 ?  A script that will be referenced in the tomcat6.service file?

The reason I ask is because I need to systemd-ize dogtag, and I would like to take advantage of whatever infrastructure you choose to create - so that I can take advantage of any bug fixes/ updates in tomcat6 going forward.

Incidentally, I have gotten dogtag working by calling /usr/sbin/tomcat6 in the pki-cad.service file - and specifying an environment file with all the variables that would have been defined by reading tomcat6.conf and /etc/sysconfig/tomcat6
Comment 6 David Knox 2011-09-01 17:10:52 EDT
Hi Ade, Hope these answers help. Feel free to ask additional questions. 

>> So, do you plan to create an initializing script that will read the
relevant config files, do anything else needed - and that will call
/usr/sbin/tomcat6 ?  A script that will be referenced in the tomcat6.service
file?

This is exactly what the init.d script does already. There is no plan to create a third script at the moment and this is the first request. I need to understand more with respect to the need and requirements, and if the requirements can be accommodated already. If I understand correctly at the moment, the current scripts don't seem to be completely off base with your requirements.

>>I have gotten dogtag working by calling /usr/sbin/tomcat6 in the
pki-cad.service file - and specifying an environment file with all the
variables that would have been defined by reading tomcat6.conf and
/etc/sysconfig/tomcat6

That is one wasy to do it. However, you won't be able to take advantage of changes to tomcat6.conf in the distro. BTW, the sysconfig/tomcat6 file is a template. You can (and should) rename yours to, say, pki-cad-tomcat6 and use it for instance specific environment values. Then call sbin/tomcat6 with the environment correctly set like the initd script does. 

>>  ...and I would like to take advantage of whatever infrastructure you choose to create - so that I can take advantage of any bug fixes/ updates in tomcat6 going forward.

The requirement is important and very reasonable. I think I can easily accommodate if you are willing to make a small change. First, giving respect to bug fixes/updates: tomcat6.conf and sbin/tomcat6 are the files which you have the most interest. The two completely compose the working infrastructure (the initd script just sets the environment and calls sbin/tomcat6 so I don't regard it as 'working' infrastructure). 

Any fixes or changes to the runtime environment values will be done in tomcat6.conf versus the sysconfig/tomcat6. Changes to the way tomcat is started will be in the sbin/tomcat6 script versus the initd script. You will get the updates to these files in the distro requiring no changes to your scripts. But first, your script needs to use these two files. The sbin/tomcat6 script you already include. So just reading tomcat6.conf and your instance specific sysconfig remains. Very little will be done to the initd tomcat6 script except perhaps more work on LSB compliance concerning error traps.

It is important that your script source tomcat6.conf before sourcing the instance specific environment script, and it is important to rename the sysconfig/tomcat6 script so you don't have the pesky problem of repeatedly renaming rpm.save or having it overwritten completely.

cheers!
Comment 7 Jóhann B. Guðmundsson 2011-09-02 13:10:44 EDT
You cant call the legacy sysv init script since you will effectively then violate the packaging guidelines "If present, the SysV initscript(s) must go into an optional subpackage, so as not to confuse sysadmins. The guidelines for SysV initscripts can be found here:"

http://fedoraproject.org/wiki/Packaging:Systemd
Comment 8 Ade Lee 2011-09-02 14:45:09 EDT
knoxy, 

I misspoke when I said that we source /etc/sysconfig/tomcat6.  We actually copy and rename this file for the particular instance -->  so for an instance named pki-ca - we source /etc/sysconfig/pki-ca.  So we are doing the right thing there.

Under our current system V environment, we have an initscript that ends up calling /etc/rc.d/init.d/tomcat6 (the tomcat6 system V initscript).  This script will source the relevant config files (tomcat6.conf and the instance specific config /etc/systconfig/pki-ca for example) and call /usr/sbin/tomcat6.

For simplicity, we'd like to continue to call /etc/rc.d/init.d/tomcat6 or an equivalent script in a systemd environment.  But in light of what Johann mentions in comment 7 - its not clear that this init script will still be present once tomcat6 is systemd-ized, or if it will be renamed/ modified.

So, the question is : how do you plan to modify tomcat6 when you migrate from system V to systemd?

Ade
Comment 9 David Knox 2011-09-02 14:58:38 EDT
Ade,
To answer your question directly: I don't know. I have to read those specifications to tell the difference between the two. I'm not a system v or systemd expert. I've got other bugs to deal with but this one is in the top 3. 

cheers!
Comment 10 David Knox 2011-09-08 15:49:25 EDT
Created attachment 522190 [details]
Script to start tomcat6 intended to be called by a unit file
Comment 11 David Knox 2011-09-08 16:03:53 EDT
Created attachment 522196 [details]
Complete systemd unit file that uses tomcat6-sysd
Comment 12 David Knox 2011-09-08 17:33:15 EDT
Created attachment 522210 [details]
Script to start tomcat6 intended to be called by a unit file
Comment 13 David Knox 2011-09-12 17:48:06 EDT
Created attachment 522807 [details]
debuggd systemv unit file for tomcat6
Comment 14 David Knox 2011-09-12 17:49:01 EDT
Created attachment 522808 [details]
Initialization script called by tomcat6.service
Comment 15 Fedora Update System 2011-09-21 19:46:55 EDT
tomcat6-6.0.32-16.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/tomcat6-6.0.32-16.fc16
Comment 16 David Knox 2011-09-21 20:16:23 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
This release is the first using a systemd unit file. SystemV files are packaged separately. 

During this transition users may experience this error: "error reading information on service tomcat6: No such file or directory" The error occurs because there is no tomcat service to delete. It has been tested, is harmless, and can be ignored.
Comment 17 Fedora Update System 2011-09-24 16:48:22 EDT
Package tomcat6-6.0.32-16.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tomcat6-6.0.32-16.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/tomcat6-6.0.32-16.fc16
then log in and leave karma (feedback).
Comment 18 Fedora Update System 2011-09-27 18:24:48 EDT
tomcat6-6.0.32-8.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/tomcat6-6.0.32-8.fc15
Comment 19 Fedora Update System 2011-09-27 18:25:55 EDT
tomcat6-6.0.32-17.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/tomcat6-6.0.32-17.fc16
Comment 20 Fedora Update System 2011-10-19 00:35:08 EDT
tomcat6-6.0.32-17.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2011-10-20 05:57:18 EDT
tomcat6-6.0.32-8.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.