Bug 491137 - undefined function sqimap_login
undefined function sqimap_login
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: php-pecl-apc (Show other bugs)
10
All Linux
low Severity urgent
: ---
: ---
Assigned To: Remi Collet
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-19 11:15 EDT by Vadym Chepkov
Modified: 2009-12-18 04:04 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 04:04:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vadym Chepkov 2009-03-19 11:15:49 EDT
squirrelmail-1.4.17-4.fc10.noarch is broken

PHP Fatal error:  Call to undefined function sqimap_login() in /usr/share/squirrelmail/src/redirect.php on line 83
Comment 1 Michal Hlavinka 2009-03-20 03:41:09 EDT
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
Comment 2 Vadym Chepkov 2009-03-20 08:45:59 EDT
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?
Comment 3 Michal Hlavinka 2009-03-26 06:41:31 EDT
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?
Comment 4 Joe Orton 2009-04-02 04:06:31 EDT
How is squirrel getting itself into a state where it is half-broken after an update?
Comment 5 Michal Hlavinka 2009-04-02 04:30:09 EDT
(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?
Comment 6 Joe Orton 2009-04-02 04:46:43 EDT
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
Comment 7 Michal Hlavinka 2009-04-09 08:19:52 EDT
(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...
Comment 8 Michal Hlavinka 2009-04-30 04:38:38 EDT
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...
Comment 9 Michal Hlavinka 2009-07-01 04:38:34 EDT
jorton: ping

do you think it's good/bad idea to restart httpd after squirrelmail update?
Comment 10 Joe Orton 2009-07-01 05:14:32 EDT
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?
Comment 11 Vadym Chepkov 2009-07-03 17:41:23 EDT
Yes, php-pecl-apc
Comment 12 Joe Orton 2009-07-07 06:38:41 EDT
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.
Comment 13 Michal Hlavinka 2009-07-07 07:16:28 EDT
(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.
Comment 14 Michal Hlavinka 2009-07-07 07:18:04 EDT
reassigning as per comment #12 and #13
Comment 15 Bug Zapper 2009-11-18 04:29:45 EST
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
Comment 16 Bug Zapper 2009-12-18 04:04:28 EST
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.

Note You need to log in before you can comment on or make changes to this bug.