CMS Made Simple Forums

This instance of CMSMS dates from 2006 and has been upgraded in the last 3 months or so to V 2.x (can't remember exactly).

When I try to login with my admin password I see "User name or password incorrect" (it is correct). Other backend users have the same issue. Was working correctly in November.

When I look at table cms_users I see a modified date for my login as 2009 which looks about right. So password has not been modified (the official way, at least).

Table cms_version shows version 201.

Table cms_adminlog shows nothing that looks suspicious.

When I view PHP error log for the root directory I see only tedious PHP warnings which I believe are unrelated:
Can't get in to PHP error log for the admin directory yet, 66MB of error log there, working on that with the host.

Front end: All pages are showing. The complete HTML seems to be there. A Showtime2 header is not showing in the browser (although appears to be in the HTML OK). The {title} has changed from what it was to "CMSMS Site".

Help

Thanks in advance

Have you tried to clear cache through cPanel, Plesk or FTP?

Delete contents of folders tmp/cache and tmp/templates_c

grtz. Rolf

I had not. But I have done so now with cpanel.

With no further changes, the front end is now back to normal and the back end looks normal too after logging in OK.

Any ideas on the root cause of this? I have saved copies of all files in those 2 directories in case it might help with troubleshooting.

Thanks Rolf!

----------------------------------------------
Cms Version: 2.1.5
Installed Modules:
AdminSearch: 1.0.2
CGCalendar: 2.1.4.2
CGExtensions: 1.53.13
CGSimpleSmarty: 2.1.4
CMSContentManager: 1.1.1
CMSMailer: 6.2.14
CustomGS: 3.0
DesignManager: 1.1.1
FileManager: 1.5.2
FrontEndUsers: 2.1.1
Gallery: 2.1.6
ListIt2: 1.4.1
ListIt2GovernorTeam: 1.4.1
MenuManager: 1.50.2
MicroTiny: 2.0.3
ModuleManager: 2.0.4
Navigator: 1.0.3
News: 2.50.5
Search: 1.50.2
Showtime2: 3.5.3
SimpleSiteInfo: 3.1.1
Statistics: 1.2.1.2
ThemeManager: 1.1.8
TinyMCE: 3.1.4
UsersGuide: 2.0

Config Information:
php_memory_limit:
max_upload_size: 50000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: Europe/London
permissive_smarty: false

Php Information:
phpversion: 5.6.24
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: 128M
max_execution_time: 120
register_globals: Off (False)
output_buffering: 4096
disable_functions:
open_basedir:
test_remote_url: Success
file_uploads: On (True)
post_max_size: 50M
upload_max_filesize: 50M
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: 60
php_opcache: Off (False)
smarty_cache: Off (False)
smarty_compilecheck: Off (False)
smarty_cache_udt: Off (False)
auto_clear_cache_age: Off (False)
Server Information:
Server Software: Apache
Server Api: cgi-fcgi
Server Os: Linux 2.6.18-471.3.1.el5.lve0.8.72 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.6.30
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

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

Some diagnostic info gathered from the site's admin log:

This seems fairly normal, with people logging in and changing pages etc. Until this:
5 seconds after this I see:
There are then hundreds of lines like the above and the first of many where back end users are unable to login, e.g.:
So could it be the PruneAdminlogTask somehow causing this, since it ran 5 seconds before it all went wrong?

Noticed the PruneAdminlogTask ran twice within about an hour on 18 December when the site crashed, before that the task was running roughly once every 24 hours:

Checked the PHP error logs for 18 December the root. Nothing but PHP Warnings:
The only item in the PHP error log for the admin area that is not a PHP Warning is this from way before the crash:

----------------------------------------------
Cms Version: 2.1.6
Installed Modules:
AdminSearch: 1.0.2
CGEcommerceBase: 1.6.2
CGExtensions: 1.53.15
CGJobMgr: 1.3.4
CGPaymentGatewayBase: 1.6.1
CGSimpleSmarty: 2.1.5
CGSmartImage: 1.21.5
CMSContentManager: 1.1.4
CMSMailer: 6.2.14
Cart2: 1.2.2
CustomContent: 1.10
DesignManager: 1.1.1
FileManager: 1.5.2
FormBuilder: 0.8.1.4
FrontEndUsers: 2.1.1
JQueryTools: 1.3.9
MenuManager: 1.50.2
MicroTiny: 2.0.3
ModuleManager: 2.0.5
NMS: 2.12.2
Navigator: 1.0.3
News: 2.50.6
Orders: 1.18.4
PaypalGateway: 2.5.2
Products: 2.25.3
Search: 1.50.2
SelfRegistration: 1.9.7
ThemeManager: 1.1.8
TinyMCE: 3.1.4

Config Information:
php_memory_limit:
max_upload_size: 128000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
auto_alias_content: true
locale: fr_FR.utf-8
set_names: true
timezone: Europe/Paris
permissive_smarty: false

Php Information:
phpversion: 5.6.25
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: 512M
max_execution_time: 300
register_globals: Off (False)
output_buffering: 4096
disable_functions: _dyuweyrj4, _dyuweyrj4r, dl
open_basedir:
test_remote_url: Success
file_uploads: On (True)
post_max_size: 64M
upload_max_filesize: 128M
session_save_path: /tmp (0700)
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: 60
php_opcache: On (True)
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: fpm-fcgi
Server Os: Linux 3.14.79-grsec-hosting-web-3.14 On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.5.52
Server Db Grants: Could not find a suitable "GRANT ALL" permission, this does not necessarily lead to problems... But if you have problems installing/removing modules or adding and deleting items/pages this could be the cause!

Permission Information:
tmp: /home/xmy/www/tmp (0705)
tmp_cache: /home/xmy/www/tmp/cache (0705)
templates_c: /home/xmy/www/tmp/templates_c (0705)
modules: /home/xmy/www/modules (0705)
uploads: /home/xmy/www/uploads (0705)
File Creation Mask (umask) : /home/xmy/www/tmp/cache (0705)
config_file: 0444
----------------------------------------------

Hello,
I have the same problem for a website with 23 pages, 185 articles, 990 FEU users, where most articles are reserved to FEU members.
This instance has been upgraded from CMSMS 1.12.X to 2.x on November 14, 2016.
The website is configured with HTTPS.
All pages on the site are "cachables" except:
• The user registration and modification pages for FEU
• The search engine result page
• The "Process" page used by CG Job Processing Manager

This instance of CMSMS worked very well until 15 days ago. Now, errors occur between 2 times a day to 1 time every 3 days :
  1. Administrator's passwords are no longer accepted, they are required to reset their passwords to regain access to the admin.
  2. FEU users are no longer recognized, they have this message :
      ⁃ "Login failed. This probably means that you entered an invalid username or password. But your account may have also expired or been disabled by an administrator. Please double check your login credentials, and if they are correct you may need to contact the site administrator."
  3. Errors appear in the admin log:
      ⁃ Unable to load template module_db_tpl 'NMS; archivelist_' in 'content: content_en'
      ⁃ Unable to load template module_db_tpl 'Orders; billingform_' in 'content: content_en'

To solve all these problems, I must empty the cache, but I can't find the origin of the problem.
I have not detected corruption of the CMS files. I applied the 2.1.6 update on 2.1.5, but the problem returned quickly.
I analyzed the log files of the web server which reveal nothing abnormal.
During the 10 days before the problem occurred, the administrators made no changes to the site.
The day that this problem appeared, they simply added articles.
I'm thinking about a CMSMS cache saturation problem. In the global settings, I changed the "Server Cache Settings", instead of 0 (auto), I put 10 days, then 2 days, but the problem remains.

I have quite the same problem on (only) one 2.1.6 site: on the frontend, what's in the global parameters disappears (like you I have "CMSMS site" instead of its name), and no admin user can access to the admin anymore. Then, with a cache cleared, everything's back to normal. I saw nothing in the logs.

It happens regularly, I'd say almost once a month.

Try to disable the automatic clear cache function "0"

I tried several values for this setting, and nothing changed. The bug even seems to appear more often. What can be the problem?

System info?

Cyrcle and I noticed the very same message as Paul Baker on the admin logs just before the bug: ----------------------------------------------

Cms Version: 2.1.6

Installed Modules:

AceEditor2: 1.05
AdminSearch: 1.0.2
CGCalendar: 1.15.8
CGCalendarSync: 1
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
DesignManager: 1.1.1
ExaExternalizer: 0.6
FileManager: 1.5.2
FormBuilder: 0.8.1.4
FrontEndUsers: 2.2.0.6
Gallery: 2.2
MicroTiny: 2.0.3
ModuleManager: 2.0.5
Navigator: 1.0.3
News: 2.50.6
Search: 1.50.2
SelfRegistration: 1.10
SimpleSiteInfo: 3.2
TinyMCE: 3.1.4
UsersGuide: 2.0


Config Information:

php_memory_limit:
max_upload_size: 128000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: Europe/Paris
permissive_smarty: true


Php Information:

phpversion: 5.6.22-0+deb8u1
md5_function: On (Vrai)
json_function: On (Vrai)
gd_version: 2
tempnam_function: On (Vrai)
magic_quotes_runtime: Off (Faux)
E_ALL: 22519
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: Aucune différence de date du système trouvée
test_db_timedifference: Aucune différence de date du système trouvée
create_dir_and_file: 1
memory_limit: 128M
max_execution_time: 180
register_globals: Off (Faux)
output_buffering: 8192
disable_functions: pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped, pcntl_wifsignaled, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal, pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo, pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority,
open_basedir:
test_remote_url: Valable
file_uploads: On (Vrai)
post_max_size: 128M
upload_max_filesize: 128M
session_save_path: /srv/data/var/php/www (0770)
session_use_cookies: On (Vrai)
xml_function: On (Vrai)
xmlreader_class: On (Vrai)
check_ini_set: On (Vrai)
curl: On


Performance Information:

allow_browser_cache: On (Vrai)
browser_cache_expiry: 60
php_opcache: On (Vrai)
smarty_cache: Off (Faux)
smarty_compilecheck: Off (Faux)
smarty_cache_udt: Off (Faux)
auto_clear_cache_age: On (Vrai)

Server Information:

Server Software: Apache/2.4.20
Server Api: fpm-fcgi
Server Os: Linux 3.14.53-grsec-paas-3117c5c On x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 5.5.49
Server Db Grants: Impossible de trouver un privilège "GRANT ALL". Cela ne conduit pas nécessairement à des problèmes... Mais si vous avez des problèmes pour installer/retirer des modules ou ajouter/supprimer des éléments de contenu ou pages cela pourrait en être la cause.


Permission Information:

tmp: /srv/data/web/vhosts/www.com/htdocs/tmp (0775)
tmp_cache: /srv/data/web/vhosts/www.com/htdocs/tmp/cache (0755)
templates_c: /srv/data/web/vhosts/www.com/htdocs/tmp/templates_c (0775)
modules: /srv/data/web/vhosts/www.com/htdocs/modules (0775)
uploads: /srv/data/web/vhosts/www.com/htdocs/uploads (0775)
Masque de création de fichier (umask) : /srv/data/web/vhosts/www.com/htdocs/tmp/cache (0755)
config_file: 0444

----------------------------------------------

Cyrcle and I noticed the very same message as Paul Baker on the admin logs just before the bug:
Code:
Automated Task Succeeded PruneAdminlogTask

Well, you can disable that too to see if it makes a differnce!

Global Settings > Advanced Setup > Lifetime of log-entries

Indeed. Done. I'll see.

I must also say that hopefully it doesn't occur each time this automated task runs.

I hope it does!