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:
Created attachment 511472 [details] Native systemd service file tomcat6
Created attachment 511473 [details] Patch to fix /usr/sbin/tomcat6 Why are the lines 10 --> 17 commented out?
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?
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.
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
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!
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
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
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!
Created attachment 522190 [details] Script to start tomcat6 intended to be called by a unit file
Created attachment 522196 [details] Complete systemd unit file that uses tomcat6-sysd
Created attachment 522210 [details] Script to start tomcat6 intended to be called by a unit file
Created attachment 522807 [details] debuggd systemv unit file for tomcat6
Created attachment 522808 [details] Initialization script called by tomcat6.service
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
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.
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).
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
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
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.
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.