Language Technology at UiT

The Divvun and Giellatekno teams build language technology aimed at minority and indigenous languages

View GiellaLT on GitHub divvungiellatekno/giellalt.uit.no

Don’t Panic

This page is for people with access to the Tromsø servers!

What to do if …

The servers are down

Get an overview on the status monitor for Giellatekno and Divvun services running on our servers The overview is refreshed every 5 minutes.

Get them up and running

For the divvun.no, gtdict.uit.no, gtoahpa-01.uit.no, gtsvn-01.uit.no, gtweb-01.uit.no, satni.org servers at uit.no:

Note that gtsvn.uit.no redirects to gtsvn-01.uit.no, etc for all -01.

Restart processes afterward

Instructions for each server:

The following processes need to be restarted, and in the following way.

Specific processes

Test that everything is ok

Go back to the interactive monitor, refresh, and check whether the report has turned greener. (Remember: The monitor tests every 5 minutes).

A server is very slow

Log in to the machine via ssh and find out which processes are using most CPU resource by giving the command:

    htop

The top part of the screen shows CPU usage per core, as well as memory usage. Sort by CPU or Memory in the process list below, by typing shift-p or shift-m, respectively. Processes that seem to use a lot of either CPU or Memory should be restarted.

The output looks something like

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15221 neahtta   20   0  512m 303m 2848 R 19.2  3.9   2:24.15 python
 9405 neahtta   20   0  512m 303m 2848 S 13.9  3.9   1:28.60 python
 6239 mysql     20   0  896m 185m 5500 S  0.3  2.4  19:10.63 mysqld
.......

Observe the column %CPU. If some of the processes remains in the top of the table with a high value in this column then this is obviously the cause of the problem. To get more information about the problematic process give the command

    ps -fp *PID*

where you replace PID by the concrete number, e.g. 15221 in the given example.

If it is an Oahpa (python2.7) process then you can see from this output which Oahpa it is. First, you can try to restart the particular Oahpa instance. After doing that check with command top if the problem has disappeared. If not then you can stop the process using the command

    kill *PID*

(requires sudo rights)

Analysers do not work

The svn application is down, yet the gtsvn server is up-n-running (test it by logging into the server)

Reference document

Server Programs and Logs