Re: tomcat9 preview
Le 12/08/2018 à 02:13, Emmanuel Bourg a écrit :
> * The catalina.out log file is no more. It duplicates the content
> of the catalina*.log files already generated by Tomcat since the
> version 5.5, and with the systemd integration the latest logs are
> available in /var/log/syslog and through 'journalctl -t tomcat9'
> anyway.
Erratum:
* The log messages are not sent to /var/log/syslog by default, but only
to the systemd journal.
* The catalina*.log files don't capture the standard output/error unlike
catalina.out. On Windows the standard output/error actually goes to
tomcat-std{out,err}.-MM-DD.log files. So there is still a good
reason to keep catalina.out (the systemd journal is fine, but I feel
better with a copy as a plain old file).
Emmanuel Bourg
Re: tomcat9 preview
Hi Thorsten,
Thanks a lot for the feedback.
On 12/08/2018 03:45, Thorsten Glaser wrote:
> This will likely also fix #814446 by simply not writing
> to the configuration file any more.
I'm not sure it will help with #814446. When we modify again the
/etc/default/tomcat9 file in a future update it's likely to conflict
with the user changes and trigger the same conflict resolution dialog.
>> * The catalina.out log file is no more. It duplicates the content
>
> N!
>
> This is *extremely* not good, because having one reliable name
> for the latest log without having to fudge around with calls to
> date(1) was *the* selling factor for easy integration of Tomcat
> on Debian with shell scripts, as opposed by Tomcat on CentOS,
> for example.
>
> I *urge* you to take this back.
I should have mentioned that it's easy for the administrator to add it
back, it's just a matter of dropping a 3 lines file in /etc/rsyslog.d/.
Here is the one I've used for tomcat8 [1]:
:programname, startswith, "tomcat8" {
/var/log/tomcat8/catalina.out
stop
}
May I ask what kind of processing you do on catalina.out?
> These are user logs, they do not belong into syslog. The
> separate catalina.out file was the correct way to do this,
> consider e.g. the various Apache logs.
On my servers my web applications all have their dedicated log files,
and the catalina logs contains only server events (like configuration
info at startup, issues with the connectors, occasional webapp unloading
issues, etc). This doesn't really look out of place in the syslog.
But if an application uses the standard servlet logger (with the
getServletConfig().getServletContext().log() method) that's a different
story, because these messages go straight to the catalina log and should
probably not land in the syslog.
My main motivation for redirecting the Tomcat output to the syslog was
to have an immediate feedback on a startup error when typing 'systemctl
status tomcat9'. But maybe there is a way to retain that without
redirecting to the syslog.
>> * The logs are now rotated directly by Tomcat instead of a cron job.
>> The cron job is still used to compress the logs though.
>
> Will this fix the problem with log files that haven’t been
> written to for an entire day?
I don't know, what was this issue? The catalina.out file didn't update
while the catalina*.log did?
>> * The sysv init script has been removed and the service is now
>> exclusively started with systemd. systemd brings so many
>
> Objection! Strong objection!
>
> I *will* file an RC bug if it won’t work without systemd!
I doubt this qualifies for a release critical bug, but maybe we can work
out another solution. What about moving the sysv stuff to a dedicated
packages (tomcat9-sysv) maintained by someone who needs it? I'm even
volunteering for preparing the initial upload. After a full release
cycle we could reevaluate on the basis of the relative popcon numbers if
it's worth merging it back into the main tomcat package.
>> * Tomcat is now automatically restarted if the JVM crashes
>> (another systemd feature).
>
> Double objection: this existed pre-systemd, for those who
> wanted it, but it is not desirable in many cases.
How do you do this without systemd? Could you elaborate why you think
this isn't a good default behavior? mariadb has auto restart enabled too
and I find this rather useful.
Emmanuel Bourg
[1]
https://salsa.debian.org/java-team/tomcat8/blob/master/debian/rsyslog/tomcat8.conf
Re: tomcat9 preview
Am 12.08.2018 um 19:52 schrieb Thorsten Glaser: > On Sun, 12 Aug 2018, Markus Koschany wrote: > >> May I suggest that we turn this objection into more positive energy. > > Sure (given enough time; but as I need the Java stuff for $dayjob > I can justify doing some of the work “on the clock”). > > I’m somewhat of an expert in shell scripting, and I use a lot of > systemd-less systems. [...] Well, that's great! If you are really interested in making it work, you could port the existing init script for Tomcat 8 to Tomcat 9. You don't need to reinvent the wheel. Just test and report back if it works and submit it as a merge request to the tomcat9 package. And then everyone is happy ♥. Cheers, Markus signature.asc Description: OpenPGP digital signature
Re: tomcat9 preview
On Sun, 12 Aug 2018, Markus Koschany wrote: > May I suggest that we turn this objection into more positive energy. Sure (given enough time; but as I need the Java stuff for $dayjob I can justify doing some of the work “on the clock”). I’m somewhat of an expert in shell scripting, and I use a lot of systemd-less systems. > packages still use sysv-init on their systems. We could keep all > sysv-init related scripts and stuff but only if someone steps up who > wants to test them in a real-life environment. Otherwise it is just more I probably cannot test *all* of them, or at least not without good instructions on what to test and how, but I can try and help. > usually easier for smaller server/daemon packages but Tomcat is rather > complex and we had reports about security vulnerabilities in our > sysv-init scripts before, that could have been avoided if we had used > systemd before. Indeed. I had to write a sysvinit script for Wildfly once, and the current Tomcat script pales in comparison to that. Perhaps I can look at how Tomcat is started and redo the init script. [ restart ] > canonical way to override systemd settings is to write a user specific > service file and install it into /etc/systemd/system which will then > override Debian's settings. The restart option is a good default. Those > who are not happy with it, can always override it. Hm. Not convinced, but… bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco 2018!** 12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031** Digital Business, Marketing und Innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) * **Visit us at dmexco 2018!** 12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031** Digital business, marketing and innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) *
Re: tomcat9 preview
Am 12.08.2018 um 03:45 schrieb Thorsten Glaser: >> * The sysv init script has been removed and the service is now >> exclusively started with systemd. systemd brings so many > > Objection! Strong objection! > > I *will* file an RC bug if it won’t work without systemd! May I suggest that we turn this objection into more positive energy. Currently in Debian we have a default init system called systemd and I doubt that anyone of those who regularly upload and maintain Java packages still use sysv-init on their systems. We could keep all sysv-init related scripts and stuff but only if someone steps up who wants to test them in a real-life environment. Otherwise it is just more maintenance burden if we want to support two init systems. This is usually easier for smaller server/daemon packages but Tomcat is rather complex and we had reports about security vulnerabilities in our sysv-init scripts before, that could have been avoided if we had used systemd before. No objections against supporting two init systems but only if someone maintains it, who is not Emmanuel Bourg. > >> * Tomcat is now automatically restarted if the JVM crashes >> (another systemd feature). > > Double objection: this existed pre-systemd, for those who > wanted it, but it is not desirable in many cases. > > Please make this optional even for systemd users, so an > admin who wants this can enable it, but do not default to > it and especially do not force it on admins. The restart feature of systemd is very useful. Emmanuel chose "on-abort" which is triggered only by unclean signals. I would even use "on-failure" which catches even more abnormal situations. Anyway the canonical way to override systemd settings is to write a user specific service file and install it into /etc/systemd/system which will then override Debian's settings. The restart option is a good default. Those who are not happy with it, can always override it. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: tomcat9 preview
Hi Emmanuel, > with the tomcat8 package. In the latest update of tomcat8 (8.5.32-2) > I've added a systemd service file, and with tomcat9 I've tried > leveraging more systemd features. The current work in progress is as long as it will still work under sysvinit, fine. > * The system user running Tomcat is now fixed and no longer > configurable. I did this for several reasons: Good. > * The debconf integration has been removed. With the user/group Very good. > dialog. Moreover it's affected by a debconf bug that has bitten > many of us (see #658554). This will likely also fix #814446 by simply not writing to the configuration file any more. > * The catalina.out log file is no more. It duplicates the content N! This is *extremely* not good, because having one reliable name for the latest log without having to fudge around with calls to date(1) was *the* selling factor for easy integration of Tomcat on Debian with shell scripts, as opposed by Tomcat on CentOS, for example. I *urge* you to take this back. > version 5.5, and with the systemd integration the latest logs are > available in /var/log/syslog These are user logs, they do not belong into syslog. The separate catalina.out file was the correct way to do this, consider e.g. the various Apache logs. > and through 'journalctl -t tomcat9' anyway. Not with sysvinit… (and having an init system-specific way to access logs is not going to fly well, independent on what init system it is). > * The logs are now rotated directly by Tomcat instead of a cron job. > The cron job is still used to compress the logs though. Will this fix the problem with log files that haven’t been written to for an entire day? > * The sysv init script has been removed and the service is now > exclusively started with systemd. systemd brings so many Objection! Strong objection! I *will* file an RC bug if it won’t work without systemd! > * Tomcat is now automatically restarted if the JVM crashes > (another systemd feature). Double objection: this existed pre-systemd, for those who wanted it, but it is not desirable in many cases. Please make this optional even for systemd users, so an admin who wants this can enable it, but do not default to it and especially do not force it on admins. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * **Besuchen Sie uns auf der dmexco 2018!** 12**. **& 13. September 2018, Koelnmesse / **Halle 7,** **Stand A-031** Digital Business, Marketing und Innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) * **Visit us at dmexco 2018!** 12th & 13th September, 2018, Koelnmesse / **Hall 7,** **Booth A-031** Digital business, marketing and innovation [www.tarent.de/dmexco](http://www.tarent.de/dmexco) *
tomcat9 preview
Hi all, I've started working on the tomcat9 packaging. Since this is a new package I've investigated disruptive changes that we couldn't afford with the tomcat8 package. In the latest update of tomcat8 (8.5.32-2) I've added a systemd service file, and with tomcat9 I've tried leveraging more systemd features. The current work in progress is available on Salsa [1], here is a quick summary of the changes: * The system user running Tomcat is now fixed and no longer configurable. I did this for several reasons: - Updating the owner of the webapp directories when upgrading from tomcat to tomcat is inconvenient. - The system user is rarely configurable is other packages. Apache, MySQL/MariaDB, Exim, Postgres, OpenLDAP... all have a non configurable user. - systemd dosen't seem to support environment variables in the User/Group directives on the service files. * The debconf integration has been removed. With the user/group becoming non configurable, there is only the JAVA_OPTS variable left configurable with debconf. JAVA_OPTS often contains parameters for fine tuning the JVM (memory settings, garbage collector, crash reporting and other advanced VM options), that's a quite complex item to configure for a simple debconf dialog. Moreover it's affected by a debconf bug that has bitten many of us (see #658554). * The Servlet API package has been removed (as discussed) * The catalina.out log file is no more. It duplicates the content of the catalina*.log files already generated by Tomcat since the version 5.5, and with the systemd integration the latest logs are available in /var/log/syslog and through 'journalctl -t tomcat9' anyway. * The logs are now rotated directly by Tomcat instead of a cron job. The cron job is still used to compress the logs though. * The sysv init script has been removed and the service is now exclusively started with systemd. systemd brings so many benefits in terms of simplicity and security that I think it's worth going with it exclusively. Our tomcat8 package has been affected by several vulnerabilities in its init script that could have been avoided with systemd. - In terms of simplicity, with systemd the authbind package is no longer necessary to bind to privileged ports, and the startup script is now ridiculously short and readable [2]. - Security wise, Tomcat is sandboxed and unable to write on the system besides its work directories. It also has a private tmp directory which prevents a whole class of vulnerabilities. I've tried to further isolate Tomcat from the system by using the chroot features (with the RootDirectory directive) but I haven't figured out how to use it properly. * Tomcat is now automatically restarted if the JVM crashes (another systemd feature). * The common, shared and server directories in CATALINA_BASE are no longer added to the classpath. This is in line with the upstream releases since the version 5.5. Please give it a try and post your feedback, I plan to upload tomcat9 next month when I'm back from vacation. Emmanuel Bourg [1] https://salsa.debian.org/ebourg/tomcat9 [2] https://salsa.debian.org/ebourg/tomcat9/blob/master/debian/libexec/tomcat-start.sh
