ZhangHuangbin wrote:Phyrax wrote:after upgrade it worked, however after changing minimal characters for a user password from 8 to 12 i'm only getting internal server error when viewing user account. logging into to roundcube still work fine for all users.
- Any error in /var/log/syslog or /var/log/messages?
- Is service "mlmmjadmin" running?
/var/log/messages show this:
Apr 30 08:20:48 mail uwsgi: 127.0.0.1:7790 [pid: 17701|app: 0|req: 3/5] 127.0.0.1 () {32 vars in 666 bytes} [Tue Apr 30 08:20:48 2019] GET /api/subscriber/firstname.lastname@domainname.com/subscribed?query_all_lists=no&email_only=yes => generated 31 bytes in 1 msecs (HTTP/1.1 200) 1 headers in 51 bytes (2 switches on core 0)
Apr 30 08:20:48 mail uwsgi: 127.0.0.1:7790 [pid: 17698|app: 0|req: 1/6] 127.0.0.1 () {32 vars in 664 bytes} [Tue Apr 30 08:20:48 2019] GET /api/subscriber/firstname.lastname@domainname.com/subscribed?query_all_lists=no&email_only=no => generated 31 bytes in 13 msecs (HTTP/1.1 200) 1 headers in 51 bytes (2 switches on core 0)
Apr 30 08:20:50 mail uwsgi: Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/web/application.py", line 239, in process#012 return self.handle()#012 File "/usr/lib/python2.7/site-packages/web/application.py", line 230, in handle#012 return self._delegate(fn, self.fvars, args)#012 File "/usr/lib/python2.7/site-packages/web/application.py", line 420, in _delegate#012 return handle_class(cls)#012 File "/usr/lib/python2.7/site-packages/web/application.py", line 396, in handle_class#012 return tocall(*args)#012 File "/var/www/iRedAdmin-Pro-SQL-3.4/controllers/sql/user.py", line 477, in GET#012 msg=form.get('msg'),#012 File "/var/www/iRedAdmin-Pro-SQL-3.4/libs/iredbase.py", line 179, in render_template#012 return jinja_env.get_template(template_name).render(context)#012 File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 969, in render#012 return self.environment.handle_exception(exc_info, True)#012 File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 742, in handle_exception#012 reraise(exc_type, exc_value, tb)#012 File "/var/www/iRedAdmin-Pro-SQL-3.4/libs/../templates/default/sql/user/profile.html", line 46, in top-level template code#012 {% from "macros/msg_handlers.html" import user_msg_handler with context %}#012 File "/var/www/iRedAdmin-Pro-SQL-3.4/libs/../templates/default/layout.html", line 192, in top-level template code#012 {% block main %}{% endblock %}#012 File "/var/www/iRedAdmin-Pro-SQL-3.4/libs/../templates/default/sql/user/profile.html", line 509, in block "main"#012 {{ display_random_password(password_length=min_passwd_length,#012 File "/var/www/iRedAdmin-Pro-SQL-3.4/libs/../templates/default/macros/general.html", line 1914, in template#012 {% set random_password = password_length | generate_random_password %}#012 File "/var/www/iRedAdmin-Pro-SQL-3.4/libs/iredpwd.py", line 113, in generate_random_password#012 length -= 1#012TypeError: unsupported operand type(s) for -=: 'unicode' and 'int'
Apr 30 08:20:50 mail uwsgi: 0)
Apr 30 08:20:50 mail uwsgi: mail.domainname.com [pid: 6469|app: 1|req: 9/16] 10.100.10.25 () {54 vars in 1244 bytes} [Tue Apr 30 08:20:48 2019] GET /iredadmin/profile/user/general/firstname.lastname@domainname.com => generated 21 bytes in 1777 msecs (HTTP/1.1 500) 3 headers in 190 bytes (2 switches on core 0)
service mlmmjadmin status -l shows me this:
● mlmmjadmin.service - RESTful API server used to manage mlmmj mailing list manager
Loaded: loaded (/usr/lib/systemd/system/mlmmjadmin.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2019-04-29 23:35:51 CEST; 8h ago
Process: 17683 ExecStopPost=/usr/bin/rm -rf /var/run/mlmmjadmin (code=exited, status=0/SUCCESS)
Process: 17680 ExecStop=/usr/sbin/uwsgi --stop /var/run/mlmmjadmin/mlmmjadmin.pid (code=exited, status=0/SUCCESS)
Process: 17693 ExecStartPre=/usr/bin/chmod 0755 /var/run/mlmmjadmin (code=exited, status=0/SUCCESS)
Process: 17690 ExecStartPre=/usr/bin/chown mlmmj:mlmmj /var/run/mlmmjadmin (code=exited, status=0/SUCCESS)
Process: 17688 ExecStartPre=/usr/bin/mkdir /var/run/mlmmjadmin (code=exited, status=0/SUCCESS)
Main PID: 17695 (uwsgi)
CGroup: /system.slice/mlmmjadmin.service
├─17695 /usr/sbin/uwsgi --ini /opt/mlmmjadmin/rc_scripts/uwsgi/rhel.ini --pidfile /var/run/mlmmjadmin/mlmmjadmin.pid
├─17698 /usr/sbin/uwsgi --ini /opt/mlmmjadmin/rc_scripts/uwsgi/rhel.ini --pidfile /var/run/mlmmjadmin/mlmmjadmin.pid
├─17699 /usr/sbin/uwsgi --ini /opt/mlmmjadmin/rc_scripts/uwsgi/rhel.ini --pidfile /var/run/mlmmjadmin/mlmmjadmin.pid
├─17700 /usr/sbin/uwsgi --ini /opt/mlmmjadmin/rc_scripts/uwsgi/rhel.ini --pidfile /var/run/mlmmjadmin/mlmmjadmin.pid
├─17701 /usr/sbin/uwsgi --ini /opt/mlmmjadmin/rc_scripts/uwsgi/rhel.ini --pidfile /var/run/mlmmjadmin/mlmmjadmin.pid
└─17702 /usr/sbin/uwsgi --ini /opt/mlmmjadmin/rc_scripts/uwsgi/rhel.ini --pidfile /var/run/mlmmjadmin/mlmmjadmin.pid
Apr 29 23:35:51 mail.domainname.com uwsgi[17695]: spawned uWSGI worker 2 (pid: 17699, cores: 1)
Apr 29 23:35:51 mail.domainname.com uwsgi[17695]: spawned uWSGI worker 3 (pid: 17700, cores: 1)
Apr 29 23:35:51 mail.domainname.com uwsgi[17695]: spawned uWSGI worker 4 (pid: 17701, cores: 1)
Apr 29 23:35:51 mail.domainname.com uwsgi[17695]: spawned uWSGI worker 5 (pid: 17702, cores: 1)
Apr 30 08:20:48 mail.domainname.com uwsgi[17695]: 127.0.0.1:7790 [pid: 17701|app: 0|req: 3/5] 127.0.0.1 () {32 vars in 666 bytes} [Tue Apr 30 08:20:48 2019] GET /api/subscriber/firstname.lastname@domainname.com/subscribed?query_all_lists=no&email_only=yes => generated 31 bytes in 1 msecs (HTTP/1.1 200) 1 headers in 51 bytes (2 switches on core 0)
Apr 30 08:20:48 mail.domainname.com uwsgi[17695]: 127.0.0.1:7790 [pid: 17698|app: 0|req: 1/6] 127.0.0.1 () {32 vars in 664 bytes} [Tue Apr 30 08:20:48 2019] GET /api/subscriber/firstname.lastname@domainname.com/subscribed?query_all_lists=no&email_only=no => generated 31 bytes in 13 msecs (HTTP/1.1 200) 1 headers in 51 bytes (2 switches on core 0)
based on another forum post i've noticed that /var/vmail is owned by vmail:vmail and not root:root (755)
changed this to be owned by root with chmod 755 however this didn't change anything.
**Update**
downgraded to iRedAdmin-Pro-SQL-3.3 again and now it works as it should again.
please let me know when it's safe to upgrade to 3.4.
thanks!
