To enable debug logging from UniTime, add the following lines to Tomcat/conf/catalina.properties

log4j.appender.unitimeLogFile=org.apache.log4j.DailyRollingFileAppender

log4j.appender.unitimeLogFile.File=${catalina.base}/logs/unitime-debug.log

log4j.appender.unitimeLogFile.DatePattern='.'yyyy-MM-dd

log4j.appender.unitimeLogFile.Append=true

log4j.appender.unitimeLogFile.layout=org.apache.log4j.PatternLayout

log4j.appender.unitimeLogFile.layout.ConversionPattern=[%-d{MM/dd/yy HH:mm:ss}] %-6p %c{1} -> %m%n

log4j.logger.org.unitime=DEBUG, unitimeLogFile

log4j.logger.net.sf.cpsolver=DEBUG, unitimeLogFile

After Tomcat is restarted, all UniTime related log messages will be written to Tomcat/logs/unitime-debug.log.

If you see the above message (or similar) in the tomcat log, the problem can be easily fixed by setting Java system property java.awt.headless to true. You can do this by adding the following line in Tomcat/conf/catalina.properties

java.awt.headless=true

prior to starting Tomcat.

On Lynux based systems, MySQL is case sensitive on table names by default. To change this, add the following line to the /etc/my.cnf file. This forces MySQL to translate all table names to lowercase before executing the statement.

lower_case_table_names=1

Was the user timetable created? Was there any error/message printed during the creation of the timetable database (execution of file schema.sql)? Are you using the default password (unitime)?

You can verify some of that by checking the content of table mysql.user (there should be a line withuser=timetable). You can also try to connect to the database as timetable user using mysql tool with the following options (also trying to use the same port and protocol as the UniTime application):
 

mysql --user=timetable --password=unitime --port=3306 --host=localhost --protocol=TCP timetable

If the localhost as the host for the timetable user does not work, try 127.0.0.1 or without it (which usually creates % as host -- that should work as any host, but usually does not). Also, you should post "flush privileges" after any change to make sure MySQL authentication knows about it.

create user timetable@`127.0.0.1` identified by 'unitime';

grant all on timetable.* to timetable@`127.0.0.1`;
create user timetable dentified by 'unitime';
grant all on timetable.* to timetable;
flush privileges;

So, you would have the following three timetable users in the user table.

mysql> select user,host,password from mysql.user where user = 'timetable';
+-----------+-----------+-------------------------------------------+
| user      | host      | password                                  |
+-----------+-----------+-------------------------------------------+
| timetable | %         | *2E46E61A1C47ADC309CADC6DF8D89654F013D3DD |
| timetable | localhost | *2E46E61A1C47ADC309CADC6DF8D89654F013D3DD |
| timetable | 127.0.0.1 | *2E46E61A1C47ADC309CADC6DF8D89654F013D3DD |
+-----------+-----------+-------------------------------------------+
3 rows in set (0.00 sec)

The host matching / restrictions is sometimes a pain with MySQL. The localhost usually works, however not 100%.

You may also need to check that MySQL allows for TCP/IP connections. TCP/IP connections are disabled when MySQL demon runs with skip-networking option.

Is the table timetable.users populated? If there are no row, it is likely because you have not run blank-data.sql or woebegon-data.sql after running schema.sql during the installation.

Besides of this, there should be a line in timetable_manager table with external_uid column set to 1 (i.e., there is a timetabling manager associated with the user admin). There should be also a line in tmtbl_mgr_to_roles table linking the timetabling manager with an administrator role (roles table). Also, there should be a line in the sessions table.

Is there any error in the tomcat's log? If not, please enable JAAS debug logging by adding the following line in Tomcat/conf/catalina.properties

log4j.logger.org.unitime.timetable.authenticate.jaas=DEBUG

Now, when you try to login (after restarting tomcat), there should be some messages in the log showing that the correct authentication module is used (message " Performing db authentication ...") and explaining why the login failed.

There is a possibility that a password hash is computed differently due to a use of a different Java or operation system (we are using MD5 encoding provided by Java class java.security.MessageDigest). If the password is incorrect, there should be the following messages in the log (when JAAS debugging is enabled):

Performing db authentication ...

Db authentication failed ...

ERROR execute -> Login Failure: all modules ignored

In such a case, please generate a new password hash using solver/timetable.jar that is a part of the UniTime distribution (solver folder), i.e., execute:

java -cp solver/timetable.jar org.unitime.timetable.authenticate.jaas.DbAuthenticateModule admin

It just prints one string which is the hash of the given argument admin, in my case, it is "ISMvKXpXpadDiUoOSoAfww==". This string needs to be set as password in the users table, i.e.,

update timetable.users set password='ISMvKXpXpadDiUoOSoAfww==' where username='admin';

commit;

You need to increase the memory limit for the tomcat (in order to prevent OutOfMemory exceptions, solver refuses to start unless there are 200MB available, which is an estimated size for solving of a problem with about 1000 classes). To increase the memory limit, you can for instance add -Xmx512m to JAVA_OPTS environmental variable before starting tomcat (this will allow tomcat to allocate up to 512MB of memory, default is 64MB):

On Unix/Linux/MacOS:

export JAVA_OPTS="${JAVA_OPTS} -Xmx512m"

On windows:

set JAVA_OPTS=%JAVA_OPTS% -Xmx512m

Alternatively, the limit on variable memory can be changed by setting the application property tmtbl.solver.mem_limit. This can be done using JAVA_OPTS environment variable before starting tomcat:

On Unix/Linix/MacOS:

export JAVA_OPTS="${JAVA_OPTS} -Dtmtbl.solver.mem_limit=50"

On Windows:

set JAVA_OPTS=%JAVA_OPTS% -Dtmtbl.solver.mem_limit=50

Or by adding the line in Tomcat/conf/catalina.properties

tmtbl.solver.mem_limit=50

This limit is megabytes, it is applicable only on the tomcat side, the same limit is used for all solver servers.