You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Yifan (Eric) Jiang" <e....@auckland.ac.nz> on 2007/05/21 05:56:02 UTC
mod_jk problem
Hi all,
Not quite sure if this list is the best place to send this question. But
I can't find anywhere else to send it to...
I am trying to install Shibboleth (http://shibboleth.internet2.edu/)
Identity Provider with Cosign protection on a RedHat Linux production
server.
Well, Shibboleth Identity Provider is a Java Application and is using
Tomcat as a Java container. Therefore for the user conveniences, I have
to load a mod_jk module into Apache in order to build a connection
between Apache and Tomcat.
I am using Apahce2.0.46, mod_jk 1.2.22 and Tomcat 5.5.23. After the
Shibboleth Identity Provider installation, everything is running
perfectly fine until the log rotation has been triggered by the cron job
at mid-night.
The cron job has the following configuration:
59 23 * * * /usr/local/etc/rotate.log --move
--after=/usr/local/etc/rotate.log-after.std /var/log
59 23 * * * /usr/local/etc/rotate.log --move
--after=/usr/local/etc/rotate.log-apache /var/log/httpd
So after the log rotation, Apache appears to have some problems to
restart. It returns a HTTP 500 error to users, and the ssl_error_log
file has logged a "Premature end of script headers: cosign.cgi" error.
Therefore it requires the administrator to restart the Apache manually.
Before I thought it was caused by Shibboleth and Cosign, so I just
disable the Cosign module for Apache. However, the error still happens
on the next day after the log rotation. Then I realised it may be cause
by the mod_jk, so I disable the mod_jk module and the Apache is back to
normal, even after the log rotation.
I have not idea what exactly caused this problem, and the log for
mod_jk, Apache doesn't give me much help. So does anyone know this
issue?
Any information in regards of this would be much appreciated.
Thanks
Eric
RE: mod_jk problem
Posted by "Yifan (Eric) Jiang" <e....@auckland.ac.nz>.
Hi Rainer,
Yeah, I've look at the link that you sent to me in the last post.
But again, it is in a production server; I don't really have the
authority to make this change. According to your email, I've realized it
is a very bad idea to this kind of log rotating, so I will suggest the
system administrator to make some changes. But thanks again for all your
helps. However we maybe end up to buying another server to host it.
Thank you very much.
Sincerely
Eric
-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
Sent: Tuesday, 22 May 2007 9:48 a.m.
To: Tomcat Users List
Subject: Re: mod_jk problem
You really should totally drop the idea of rotating an open logfile from
the outside. The file descriptor is open in the writing process and it
will proceed to use the file descriptor, which will point to the rotated
file and after compression will be deleted. Really a very bad idea.
Usually if you need to rotate a log file from the outside, you need to
take down the process during the rotation. If a process implements a
signal or restart procedure, you can also send a signal or restart
command after rotatting and before further manipulation on the file.
Why aren't you simply using apache httpd rotatelogs, as suggested in my
last post?
http://httpd.apache.org/docs/2.0/programs/rotatelogs.html
Regards,
Rainer
Yifan (Eric) Jiang wrote:
> Hi Rainer,
>
> Thanks for all your helps. I know that is a very outdated version of
> httpd,
> But since it is in a production server, and the server for the
> authentication of the whole university, so it is unlikely, or it is
> impossible for me to do any big change on it. And it is weird, because
> it is running completely fine in the test server which is the
> replication for the production server.
>
> So we are trying to reproduce the same error/bug that occurred in the
> production server, but unfortunately we still can't reproduce it. Any
> idea why?
>
>
> Thanks
>
> Regards
>
> Eric
>
> -----Original Message-----
> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> Sent: Monday, 21 May 2007 7:26 p.m.
> To: Tomcat Users List
> Subject: Re: mod_jk problem
>
> Rotating an open log file from outside the using processes is a very
bad
>
> idea. The processes in most cases will simply try to use the old log
> file further on (and will run into trouble, after you compressed them
> etc.).
>
> Rotating log files for apache can be easily done using the bundles
> rotatelogs (see the Apache httpd documentation).
>
> mod_jk is able to use rotatelogs with JkLogFile as well, and the
syntax
> is the same as for the other Apache httpd log files
> ("|/pathtorotatelogs/rotatelogs /pathtologfile/logfile OPTIONS").
>
> Since I'm interested in the root of your problem nevertheless, if you
> can reproduce it, try to get a pstack (solaris) or gstack[?] (linux)
of
> your running httpd processes, once the problem occurs. In case threads
> are hanging, this will tel us, where they are.
>
> By the way: your httpd is a pretty outdated version. The 2.0 branch is
> at 2.0.59 and there is 2.2.x around for 1.5 years now. (I'm not saying
> such an update will solve your problem, but the other two components
are
>
> pretty up to date, so updating your apache would make a good fit).
>
> Regards,
>
> Rainer
>
> Yifan (Eric) Jiang wrote:
>> Hi all,
>>
>>
>>
>> Not quite sure if this list is the best place to send this question.
> But
>> I can't find anywhere else to send it to...
>>
>>
>>
>> I am trying to install Shibboleth (http://shibboleth.internet2.edu/)
>> Identity Provider with Cosign protection on a RedHat Linux production
>> server.
>>
>> Well, Shibboleth Identity Provider is a Java Application and is using
>> Tomcat as a Java container. Therefore for the user conveniences, I
> have
>> to load a mod_jk module into Apache in order to build a connection
>> between Apache and Tomcat.
>>
>>
>>
>> I am using Apahce2.0.46, mod_jk 1.2.22 and Tomcat 5.5.23. After the
>> Shibboleth Identity Provider installation, everything is running
>> perfectly fine until the log rotation has been triggered by the cron
> job
>> at mid-night.
>>
>>
>>
>> The cron job has the following configuration:
>>
>> 59 23 * * * /usr/local/etc/rotate.log
> --move
>> --after=/usr/local/etc/rotate.log-after.std /var/log
>>
>> 59 23 * * * /usr/local/etc/rotate.log
> --move
>> --after=/usr/local/etc/rotate.log-apache /var/log/httpd
>>
>>
>>
>> So after the log rotation, Apache appears to have some problems to
>> restart. It returns a HTTP 500 error to users, and the ssl_error_log
>> file has logged a "Premature end of script headers: cosign.cgi"
error.
>> Therefore it requires the administrator to restart the Apache
> manually.
>>
>>
>> Before I thought it was caused by Shibboleth and Cosign, so I just
>> disable the Cosign module for Apache. However, the error still
happens
>> on the next day after the log rotation. Then I realised it may be
> cause
>> by the mod_jk, so I disable the mod_jk module and the Apache is back
> to
>> normal, even after the log rotation.
>>
>>
>>
>> I have not idea what exactly caused this problem, and the log for
>> mod_jk, Apache doesn't give me much help. So does anyone know this
>> issue?
>>
>>
>>
>> Any information in regards of this would be much appreciated.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Eric
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk problem
Posted by Rainer Jung <ra...@kippdata.de>.
You really should totally drop the idea of rotating an open logfile from
the outside. The file descriptor is open in the writing process and it
will proceed to use the file descriptor, which will point to the rotated
file and after compression will be deleted. Really a very bad idea.
Usually if you need to rotate a log file from the outside, you need to
take down the process during the rotation. If a process implements a
signal or restart procedure, you can also send a signal or restart
command after rotatting and before further manipulation on the file.
Why aren't you simply using apache httpd rotatelogs, as suggested in my
last post?
http://httpd.apache.org/docs/2.0/programs/rotatelogs.html
Regards,
Rainer
Yifan (Eric) Jiang wrote:
> Hi Rainer,
>
> Thanks for all your helps. I know that is a very outdated version of
> httpd,
> But since it is in a production server, and the server for the
> authentication of the whole university, so it is unlikely, or it is
> impossible for me to do any big change on it. And it is weird, because
> it is running completely fine in the test server which is the
> replication for the production server.
>
> So we are trying to reproduce the same error/bug that occurred in the
> production server, but unfortunately we still can't reproduce it. Any
> idea why?
>
>
> Thanks
>
> Regards
>
> Eric
>
> -----Original Message-----
> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> Sent: Monday, 21 May 2007 7:26 p.m.
> To: Tomcat Users List
> Subject: Re: mod_jk problem
>
> Rotating an open log file from outside the using processes is a very bad
>
> idea. The processes in most cases will simply try to use the old log
> file further on (and will run into trouble, after you compressed them
> etc.).
>
> Rotating log files for apache can be easily done using the bundles
> rotatelogs (see the Apache httpd documentation).
>
> mod_jk is able to use rotatelogs with JkLogFile as well, and the syntax
> is the same as for the other Apache httpd log files
> ("|/pathtorotatelogs/rotatelogs /pathtologfile/logfile OPTIONS").
>
> Since I'm interested in the root of your problem nevertheless, if you
> can reproduce it, try to get a pstack (solaris) or gstack[?] (linux) of
> your running httpd processes, once the problem occurs. In case threads
> are hanging, this will tel us, where they are.
>
> By the way: your httpd is a pretty outdated version. The 2.0 branch is
> at 2.0.59 and there is 2.2.x around for 1.5 years now. (I'm not saying
> such an update will solve your problem, but the other two components are
>
> pretty up to date, so updating your apache would make a good fit).
>
> Regards,
>
> Rainer
>
> Yifan (Eric) Jiang wrote:
>> Hi all,
>>
>>
>>
>> Not quite sure if this list is the best place to send this question.
> But
>> I can't find anywhere else to send it to...
>>
>>
>>
>> I am trying to install Shibboleth (http://shibboleth.internet2.edu/)
>> Identity Provider with Cosign protection on a RedHat Linux production
>> server.
>>
>> Well, Shibboleth Identity Provider is a Java Application and is using
>> Tomcat as a Java container. Therefore for the user conveniences, I
> have
>> to load a mod_jk module into Apache in order to build a connection
>> between Apache and Tomcat.
>>
>>
>>
>> I am using Apahce2.0.46, mod_jk 1.2.22 and Tomcat 5.5.23. After the
>> Shibboleth Identity Provider installation, everything is running
>> perfectly fine until the log rotation has been triggered by the cron
> job
>> at mid-night.
>>
>>
>>
>> The cron job has the following configuration:
>>
>> 59 23 * * * /usr/local/etc/rotate.log
> --move
>> --after=/usr/local/etc/rotate.log-after.std /var/log
>>
>> 59 23 * * * /usr/local/etc/rotate.log
> --move
>> --after=/usr/local/etc/rotate.log-apache /var/log/httpd
>>
>>
>>
>> So after the log rotation, Apache appears to have some problems to
>> restart. It returns a HTTP 500 error to users, and the ssl_error_log
>> file has logged a "Premature end of script headers: cosign.cgi" error.
>> Therefore it requires the administrator to restart the Apache
> manually.
>>
>>
>> Before I thought it was caused by Shibboleth and Cosign, so I just
>> disable the Cosign module for Apache. However, the error still happens
>> on the next day after the log rotation. Then I realised it may be
> cause
>> by the mod_jk, so I disable the mod_jk module and the Apache is back
> to
>> normal, even after the log rotation.
>>
>>
>>
>> I have not idea what exactly caused this problem, and the log for
>> mod_jk, Apache doesn't give me much help. So does anyone know this
>> issue?
>>
>>
>>
>> Any information in regards of this would be much appreciated.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Eric
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: mod_jk problem
Posted by "Yifan (Eric) Jiang" <e....@auckland.ac.nz>.
Hi Rainer,
Thanks for all your helps. I know that is a very outdated version of
httpd,
But since it is in a production server, and the server for the
authentication of the whole university, so it is unlikely, or it is
impossible for me to do any big change on it. And it is weird, because
it is running completely fine in the test server which is the
replication for the production server.
So we are trying to reproduce the same error/bug that occurred in the
production server, but unfortunately we still can't reproduce it. Any
idea why?
Thanks
Regards
Eric
-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
Sent: Monday, 21 May 2007 7:26 p.m.
To: Tomcat Users List
Subject: Re: mod_jk problem
Rotating an open log file from outside the using processes is a very bad
idea. The processes in most cases will simply try to use the old log
file further on (and will run into trouble, after you compressed them
etc.).
Rotating log files for apache can be easily done using the bundles
rotatelogs (see the Apache httpd documentation).
mod_jk is able to use rotatelogs with JkLogFile as well, and the syntax
is the same as for the other Apache httpd log files
("|/pathtorotatelogs/rotatelogs /pathtologfile/logfile OPTIONS").
Since I'm interested in the root of your problem nevertheless, if you
can reproduce it, try to get a pstack (solaris) or gstack[?] (linux) of
your running httpd processes, once the problem occurs. In case threads
are hanging, this will tel us, where they are.
By the way: your httpd is a pretty outdated version. The 2.0 branch is
at 2.0.59 and there is 2.2.x around for 1.5 years now. (I'm not saying
such an update will solve your problem, but the other two components are
pretty up to date, so updating your apache would make a good fit).
Regards,
Rainer
Yifan (Eric) Jiang wrote:
> Hi all,
>
>
>
> Not quite sure if this list is the best place to send this question.
But
> I can't find anywhere else to send it to...
>
>
>
> I am trying to install Shibboleth (http://shibboleth.internet2.edu/)
> Identity Provider with Cosign protection on a RedHat Linux production
> server.
>
> Well, Shibboleth Identity Provider is a Java Application and is using
> Tomcat as a Java container. Therefore for the user conveniences, I
have
> to load a mod_jk module into Apache in order to build a connection
> between Apache and Tomcat.
>
>
>
> I am using Apahce2.0.46, mod_jk 1.2.22 and Tomcat 5.5.23. After the
> Shibboleth Identity Provider installation, everything is running
> perfectly fine until the log rotation has been triggered by the cron
job
> at mid-night.
>
>
>
> The cron job has the following configuration:
>
> 59 23 * * * /usr/local/etc/rotate.log
--move
> --after=/usr/local/etc/rotate.log-after.std /var/log
>
> 59 23 * * * /usr/local/etc/rotate.log
--move
> --after=/usr/local/etc/rotate.log-apache /var/log/httpd
>
>
>
> So after the log rotation, Apache appears to have some problems to
> restart. It returns a HTTP 500 error to users, and the ssl_error_log
> file has logged a "Premature end of script headers: cosign.cgi" error.
> Therefore it requires the administrator to restart the Apache
manually.
>
>
>
> Before I thought it was caused by Shibboleth and Cosign, so I just
> disable the Cosign module for Apache. However, the error still happens
> on the next day after the log rotation. Then I realised it may be
cause
> by the mod_jk, so I disable the mod_jk module and the Apache is back
to
> normal, even after the log rotation.
>
>
>
> I have not idea what exactly caused this problem, and the log for
> mod_jk, Apache doesn't give me much help. So does anyone know this
> issue?
>
>
>
> Any information in regards of this would be much appreciated.
>
>
>
> Thanks
>
>
>
> Eric
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk problem
Posted by Rainer Jung <ra...@kippdata.de>.
Rotating an open log file from outside the using processes is a very bad
idea. The processes in most cases will simply try to use the old log
file further on (and will run into trouble, after you compressed them etc.).
Rotating log files for apache can be easily done using the bundles
rotatelogs (see the Apache httpd documentation).
mod_jk is able to use rotatelogs with JkLogFile as well, and the syntax
is the same as for the other Apache httpd log files
("|/pathtorotatelogs/rotatelogs /pathtologfile/logfile OPTIONS").
Since I'm interested in the root of your problem nevertheless, if you
can reproduce it, try to get a pstack (solaris) or gstack[?] (linux) of
your running httpd processes, once the problem occurs. In case threads
are hanging, this will tel us, where they are.
By the way: your httpd is a pretty outdated version. The 2.0 branch is
at 2.0.59 and there is 2.2.x around for 1.5 years now. (I'm not saying
such an update will solve your problem, but the other two components are
pretty up to date, so updating your apache would make a good fit).
Regards,
Rainer
Yifan (Eric) Jiang wrote:
> Hi all,
>
>
>
> Not quite sure if this list is the best place to send this question. But
> I can't find anywhere else to send it to...
>
>
>
> I am trying to install Shibboleth (http://shibboleth.internet2.edu/)
> Identity Provider with Cosign protection on a RedHat Linux production
> server.
>
> Well, Shibboleth Identity Provider is a Java Application and is using
> Tomcat as a Java container. Therefore for the user conveniences, I have
> to load a mod_jk module into Apache in order to build a connection
> between Apache and Tomcat.
>
>
>
> I am using Apahce2.0.46, mod_jk 1.2.22 and Tomcat 5.5.23. After the
> Shibboleth Identity Provider installation, everything is running
> perfectly fine until the log rotation has been triggered by the cron job
> at mid-night.
>
>
>
> The cron job has the following configuration:
>
> 59 23 * * * /usr/local/etc/rotate.log --move
> --after=/usr/local/etc/rotate.log-after.std /var/log
>
> 59 23 * * * /usr/local/etc/rotate.log --move
> --after=/usr/local/etc/rotate.log-apache /var/log/httpd
>
>
>
> So after the log rotation, Apache appears to have some problems to
> restart. It returns a HTTP 500 error to users, and the ssl_error_log
> file has logged a "Premature end of script headers: cosign.cgi" error.
> Therefore it requires the administrator to restart the Apache manually.
>
>
>
> Before I thought it was caused by Shibboleth and Cosign, so I just
> disable the Cosign module for Apache. However, the error still happens
> on the next day after the log rotation. Then I realised it may be cause
> by the mod_jk, so I disable the mod_jk module and the Apache is back to
> normal, even after the log rotation.
>
>
>
> I have not idea what exactly caused this problem, and the log for
> mod_jk, Apache doesn't give me much help. So does anyone know this
> issue?
>
>
>
> Any information in regards of this would be much appreciated.
>
>
>
> Thanks
>
>
>
> Eric
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org