[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> 
> Noooooooooooooooooooooooooooooooooooooooooooooooooooooooo!
> 
> 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


Reply to: