Bug 491137

Unfortunately, I can't reproduce this.

Also, definition of sqimap_login() is in functions/imap_general.php

redirect.php contains:
require_once(SM_PATH . 'functions/imap.php');
which contains:
require_once(SM_PATH . 'functions/imap_general.php');

so sqimap_login should be definitely defined.

Please add description, how you reproduce this.

Also please add output of 
rpm -V squirrelmail

and content of log messages (after getting this error) in /var/log/httpd/error_log (or ssl_error_log if you are using https://... ) would be useful

Thanks

I looked into it more and it seems you have to restart httpd server after you upgrade squirrelmail.

I am using https:// and I guess the failure depends on what file was getting cashed by the server, because I upgraded another server and got this error:

PHP Fatal error:  Cannot redeclare sqimap_search() (previously declared in /usr/share/squirrelmail/functions/imap_search.php:23) in /usr/share/squirrelmail/functions/imap_search.php on line 124

But after I restarted the server the problem went away. Should some post-install scripts take care of this?

I presume this error is not produced during the yum update process, but it's still reproducible some time after yum update completes.

I don't know if it's good idea to restart the server or if there is another way how to solve it... let's ask httpd maintainer.

Joe, do you have any idea if there is a nice way how to solve it?

How is squirrel getting itself into a state where it is half-broken after an update?

(In reply to comment #4)
> How is squirrel getting itself into a state where it is half-broken after an
> update?  

I don't understand your question. I don't think squirrelmail itself is broken. AFAIK it's broken only until httpd restart. The function in this bug report should be defined - it's included with no preceding if statements.

This is probably caused by some function that has been moved from one file to another file.

Because the function should be defined and because it works after httpd restart I think old file is maybe cached by httpd?

Can you explain why squirrel is broken after the upgrade but before the restart?   Why does performing a restart fix anything?

httpd does not cache PHP scripts

(In reply to comment #6)
> Can you explain why squirrel is broken after the upgrade but before the
> restart?   Why does performing a restart fix anything?
> 
> httpd does not cache PHP scripts  

No, I don't know... afaik squirrelmail doesn't contain anything related to php scripts caching (I even doesn't know if there exists anything like that on the php's client=script side). 

Because squirrelmail doesn't change it's definition of any function and it works after httpd restart I think squirrelmail is not broken. I'll try to do some tests...

ok, I can see there exists some php caching stuff.

I assume you are using php-pecl-apc or something similar, right?

If you are using cache for php scripts, I'm not sure we can do too much here. Restarting httpd every time squirrelmail is updated even if caching is not used (or hardcode check for php-pecl-apc existence) doesn't look like good idea to me. 

What's your opinion about httpd restarting, Joe? or if you have any other idea...

jorton: ping

do you think it's good/bad idea to restart httpd after squirrelmail update?

I don't think it should be necessary to restart httpd.

Vadym Chepkov, were you using any of the PHP caching packages when you encountered this bug?

Yes, php-pecl-apc

Thanks.  Michal, did the mtime of the files in question change between the two updates?  If so, I would say that this is a php-pecl-apc bug (and should be reassigned to that package) - the cache has gone stale and not been refreshed as required.

(In reply to comment #12)
> Thanks.  Michal, did the mtime of the files in question change between the two
> updates?  If so, I would say that this is a php-pecl-apc bug (and should be
> reassigned to that package) - the cache has gone stale and not been refreshed
> as required.  

I can't check it because I don't know the exact version-release he used before update, but we don't preserve time stamps, so when file is patched, it gets time of patching. Also upstream sources have different time for modified files. So when updating time should be different.

reassigning as per comment #12 and #13

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.