No admins can login, front end gone a bit wrong too

[Franck]

I changed "Lifetime of log-entries" to manual on 19/01 at 23:27:52 so there should have been no "Automated Task Succeeded PruneAdminlogTask", right ? But the next one appeared on 20/01 at 19:36:36 and 20 minutes later the first error message and impossible admin login.

By the way, as it happens on one hosting only, maybe it's a matter of server configuration?

[Jos]

I encountered the same issue on a site that has been upgraded to 2.1.5 since october 2016.

I also see some relation to PruneAdminlogTask

Code: Select all

An error has occurred	Unable to load template module_db_tpl 'MleCMS;mle_template' in 'tpl_body:9'	20-01-17 12:07:11
Automated Task Succeeded	PruneAdminlogTask	20-01-17 12:07:10
CGSmartImage	Kan geen bestand vinden in: uploads/routes/	20-01-17 12:06:32

Also couldn't login the backend. Using the "password lost" function solves that. After that clearing the cache and the site was up and running again.

Today I couldn't login again. (yes, I'm sure using the correct password) The Frontend was working OK though.
There has not been an PruneAdminlogTask log after I cleared the cache yesterday.

----------------------------------------------
Cms Version: 2.1.5
Installed Modules:
AdminSearch: 1.0.2
Banners: 2.9.1
BatchMail: 0.5
CGExtensions: 1.53.13
CGJobMgr: 1.3.4
CGSimpleSmarty: 1.10
CGSmartImage: 1.21.5
CMSContentManager: 1.1.1
CMSMailer: 6.2.14
Captcha: 0.5.3
CustomGS: 3.0
DesignManager: 1.1.1
FAQ: 2.0.1
FEUMailer: 0.9.4
FileManager: 1.5.2
FormBrowser: 0.5
FormBuilder: 0.8.1.4
FrontEndUsers: 1.26
GBFilePicker: 1.3.3
Gallery: 2.1.6
Gbook: 2.2.2
JMFilePicker: 1.0
LISE: 1.2.1.1
LISENMSitems: 1.2.1.1
LISEProgramma: 1.2.1.1
LISERoutes: 1.2.1.1
MenuManager: 1.50.2
MicroTiny: 2.0.3
MleCMS: 2.0-alpha2
ModuleManager: 2.0.4
NMS: 2.9.5
Navigator: 1.0.3
News: 2.50.5
Search: 1.50.2
ThemeManager: 1.1.8

Config Information:
php_memory_limit:
max_upload_size: 64000000
url_rewriting: mod_rewrite
page_extension: .html
query_var: page
auto_alias_content: true
locale: nl_NL
set_names: true
timezone:
permissive_smarty: false

Php Information:
phpversion: 5.5.37
md5_function: On (True)
json_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_ALL: 32759
E_STRICT: 2048
E_DEPRECATED: 8192
test_file_timedifference: No time difference found
test_db_timedifference: No time difference found
create_dir_and_file: 1
memory_limit: 256M
max_execution_time: 30
register_globals: Off (False)
output_buffering: On
disable_functions: symlink, popen, system, exec, proc_get_status, proc_nice, proc_terminate, define_syslog_variables, syslog, openlog, closelog, escapeshellcmd, passthru, ocinumcols, ini_alter, leak, listen, chgrp, apache_note, apache_setenv, debugger_on, debugger_off, ftp_exec, dl, dll, ftp, disk_free_space, disk_total_space, shell_exec, eval, proc_close, proc_open, allow_url_fopen, show_source, get_current_user, getmyuid, apache_child_terminate, pfsockopen, posix_ctermid, posix_get_last_error, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam, posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix_getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit, posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid, posix_setuid, posix_strerror, posix_times, posix_ttyname, posix_uname
open_basedir: /home/p4d/domains/paarden4daagse.nl/:/home/p4d/domains/include/:/tmp:/var/tmp:/usr/local/lib/php/:/usr/local/php55/lib/php/:/usr/local/php70/lib/php/
test_remote_url: Success
file_uploads: On (True)
post_max_size: 64M
upload_max_filesize: 64M
session_save_path: No check because open basedir active
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)
check_ini_set: On (True)
curl: On

Performance Information:
allow_browser_cache: On (True)
browser_cache_expiry: 5
php_opcache: Off (False)
smarty_cache: On (True)
smarty_compilecheck: Off (False)
smarty_cache_udt: On (True)
auto_clear_cache_age: On (True)
Server Information:
Server Software: Apache/2
Server Api: apache2handler
Server Os: Linux 2.6.18-417.el5PAE On i686
Server Db Type: MySQL (mysqli)
Server Db Version: 5.6.29
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

Permission Information:
tmp: /home/p4d/domains/paarden4daagse.nl/public_html/tmp (0755)
tmp_cache: /home/p4d/domains/paarden4daagse.nl/public_html/tmp/cache (0755)
templates_c: /home/p4d/domains/paarden4daagse.nl/public_html/tmp/templates_c (0755)
modules: /home/p4d/domains/paarden4daagse.nl/public_html/modules (0755)
uploads: /home/p4d/domains/paarden4daagse.nl/public_html/uploads (0755)
File Creation Mask (umask): /home/p4d/domains/paarden4daagse.nl/public_html/tmp/cache (0755)
config_file: 0755
----------------------------------------------

[Franck]

Every two days now.

[SFITCS]

Delete contents of folders tmp/cache and tmp/templates_c

I had different errors in the apache2 error.log, but the same problem (blank admin page).

After deleting most of the contents of the two directories you mention above I was able to login. Unfortunately I didn't see this thread until after I solved the problem (searched for variations of "blank admin page").

[cyrcle]

I noticed on my site that the task "PruneAdminlogTask" is executed every day (about every 24h and 20min). In this cycle, this task is always followed by the "ClearCacheTask" task. In these cases, the problem does not appear.
But sometimes, in addition to this cycle, "PruneAdminlogTask" is executed alone and this is where the problem appears.

Moreover, I doubt that disabling the automatic clear cache function solves the problem because the cache on my site was set to 0 when the problem occurred.

[Franck]

Just had the same problem with auto clear cache disabled (set to 0). So I'm afraid it can't be a temporary solution either.

[pwg]

We are having the same problem with one of our sites.

I had had Lifetime of log entries set to manual, however the problem is still an oddly regular occurrence, so changed it to 6 months and seeing if this does anything.
When this problem happens the site frontend doesn't display {metadata} (and perhaps no module content?) info, so no css etc. Hard to tell exactly, as I've cleared cache asap, to keep client happy!

System info below

----------------------------------------------
Cms Version: 2.1.6
Installed Modules:
AceEditor2: 1.05
AdminSearch: 1.0.2
CGBlog: 1.14.1
CGCalendar: 2.1.4.3
CGExtensions: 1.53.15
CGHeadMaster: 1.0.9.2
CGSimpleSmarty: 2.1.5
CGSmartImage: 1.21.5
CMSContentManager: 1.1.4
CMSMailer: 6.2.14
CompanyDirectory: 1.23.3
DesignManager: 1.1.1
FileManager: 1.5.2
FormBuilder: 0.8.1.4
FrontEndUsers: 2.2.0.6
Gallery: 2.2
JMFilePicker: 1.0
JQueryTools: 1.3.9
LISE: 1.2.3
LISEMembers: 1.2.3
MicroTiny: 2.0.3
ModuleManager: 2.0.5
Navigator: 1.0.3
News: 2.50.6
Search: 1.50.2
Snippet: 0.1.8
Widgets: 1.1

Config Information:
php_memory_limit:
max_upload_size: 10000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: Australia/NSW
permissive_smarty: false

Php Information:
phpversion: 5.5.29
md5_function: On (True)
json_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_ALL: 22519
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: No time difference found
test_db_timedifference: No time difference found
create_dir_and_file: 1
memory_limit: 256M
max_execution_time: 60
register_globals: Off (False)
output_buffering: On
disable_functions:
open_basedir:
test_remote_url: Success
file_uploads: On (True)
post_max_size: 10M
upload_max_filesize: 10M
session_save_path: /tmp (1777)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)
check_ini_set: On (True)
curl: On

Performance Information:
allow_browser_cache: Off (False)
browser_cache_expiry: 0
php_opcache: Off (False)
smarty_cache: Off (False)
smarty_compilecheck: Off (False)
smarty_cache_udt: Off (False)
auto_clear_cache_age: On (True)
Server Information:
Server Software: Apache
Server Api: cgi-fcgi
Server Os: Linux 2.6.32-642.3.1.el6.x86_64 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.5.52
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

Permission Information:
tmp: /home/ampccom/public_html/tmp (0777)
tmp_cache: /home/ampccom/public_html/tmp/cache (0777)
templates_c: /home/ampccom/public_html/tmp/templates_c (0777)
modules: /home/ampccom/public_html/modules (0777)
uploads: /home/ampccom/public_html/uploads (0777)
File Creation Mask (umask): /home/ampccom/public_html/tmp/cache (0777)
config_file: 0444
----------------------------------------------

Thanks for any help, as it appears to be a somewhat widespread issue.

Cheers,

Paul

[Trenia]

I experience the same problem. Can`t log into admin. I run Showtime2 3.5.3 and cmsms 2.1.6.

[Trenia]

This is weird.. how is this possible? I have uninstalled and deleted Showtime2 from my main website to avoid further login problems, BUT I still can`t log into the site that is installed on a sub-domain (mobile version). Somehow that site was also affected. Showtime was never used on that install and I have never had any problems logging in before. I have tried to clear the tmp/cache and tmp/templates_c, and even reinstalled everything from an older back up. Nothing helps. Both sites are 2.1.6. Any suggestions?

[Trenia]

This is weird.. how is this possible? ...

Anyone who can help me with this? Please PM me if you can.

[cyrcle]

While waiting for the problem to be solved, I created a UDT to notify me by email when my website crash. You can try that :
https://www.cmscanbesimple.org/blog/mou ... ate-errors

[calguy1000]

This problem is almost certainly not related to a single module, or to the adminlog task. But to a race condition happening when two requests happen almost simultaneously that would require some portion of cached data to be rebuilt.

Unfortunately, we do not have enough information as to exactly what the problem is (nothing from error logs, no consistent method of reproducing the problem, etc).

[pwg]

Hi, still having the same issue, oddly it only effects one of many sites on the same server. The difference? This site has the FrontEndUsers module installed. The others don't.

Just checking other posted system info here, it seems FrontEndUsers is installed to all sites with the issue?

calguy1000 mentioned it was unlikely to be only one module, but maybe worth checking? If I knew how to, I'd do it myself, so very appreciative of any help. So too, I assume would be my exasperated client, who goes into meltdown whenever the site is down, no matter how many times I tell them to clear the cache.

Cheers,

Paul

[Rolf]

@pwg you have got a pm

[chandra]

If I knew how to, I'd do it myself, so very appreciative of any help.

It's not difficult ... please go to folder /modules and rename only non core modules like AnyModule to _AnyModule, step by step. And check if the trouble is gone.