Q: How do I make the moomps daemon record some data cells history in the database?

A: Here is the road map from start to finish:

• allow access to the database by properly filling the preferences database section (note that as a database user, you must have write access to the moodss database (contact your database administrator if in doubt)).
• try your configuration by using the file database load menu: that should give you no errors provided the moodss database exists and your database user is valid, else contact your database administrator and restart the procedure until it works.
• in the preferences daemon (moomps) section, choose the configuration file that the moomps daemon will use (of course you must have write access to that file) and validate: the database configuration is then saved for moomps to use when saving data cells histories (all see the moomps documentation).
• use an existing configuration (save) file, or load modules, ..., use the edit database menu and drop data cells in the dialog box that opens.
• save the configuration (file save menu) in the moomps directory for dashboard files (/srv/moomps/ by default, of course you must have write access to it).
• start or restart the moomps daemon (you may also dynamically modify dashboard files already loaded by a running moomps daemon: the modifications will be taken into account shortly thereafter).
• after a while, check that the data is actually stored from the file database load menu.

Q: Why some tables cannot be erased?

A: Those tables hold the module data and therefore can only be erased by unloading the corresponding module. They are easily recognizable since they are the only ones with a window bar including the module name.

Q: How do I know what the module does when loading?

A: What the module does when loading is really dependent on the module implementation itself. It should be described in the module documentation (accessible through the Help menu). A message appears in the moodss main window message area when each module is loading. Note that this message can be fugitive even if the module initialization takes a while and the module does it in the background (as it should so that other modules get a chance to also initialize).
If there are any errors, they will be reported in the message area. I suggest opening the trace window or loading the trace module is you want to precisely keep track of those errors.

Q: How do I delete a viewer?

A: There are several ways:

• when empty of monitored cells, drag and drop into the eraser
• drag the eraser and drop it into the viewer, even if not empty
• move the viewer (as usual, using the internal window manager handles) into the eraser

Q: How do I transfer a table or a viewer to another page?

A: Move it (as usual, using the internal window manager handles) into another page tab (wait until you see the drop black outline around the tab label to release the mouse button). The viewer can then be found in the upper left corner of the target page.

Q: When reloading a module fails from the File/Modules/Manage dialog box, the module disappears from the list and all its options values are lost. Why?

A: the internal implementation requires that reloading a module be done in 2 steps: unloading the existing module then loading it using the new options values. Those are not lost however (starting from moodss 17.6): they are reused when trying to load a new instance of the module from the File/Modules/Load dialog box.

Q: What happens if files are changed, deleted, added, ... in the directory that the moomps daemon is using for its dashboard files?

A: If a dashboard file that is monitored by moomps (see files and directory parameters in the usage moomps documentation section), is:

• changed: it is reloaded as soon as the daemon becomes aware of its recent modification time (depending on the monitoring poll time of the dashboard files, as described in the usage moomps documentation section).
• deleted: nothing happens (the moomps daemon does not unload the file, it needs to be restarted to take the change into account).
• added to the monitored directories: nothing happens for security reasons (the moomps daemon does not load the file, it needs to be restarted to take the change into account).

Q: What happens when, in the moodss GUI edit database dialog box, some data cells state is changed, and the moomps daemon is running?

A: Once the states are changed, the edit database dialog closed and the dashboard file saved using the File/Save menu, the moomps daemon sees that the file has been updated and reloads it, provided of course that the file is part of the files that the daemon is monitoring (see files and directory parameters in the usage section).
Thus such changes are taken into account quickly (depending of course on the monitoring poll time of the dashboard files, as described in the usage section).

Q: What is needed for Japanese support, including input?

A: I have successfully tested the following on a Red Hat Fedora Linux system:

# service canna start # (as root) $ export LC_ALL=ja_JP.eucJP XMODIFIERS=@im=kinput2 $ kinput2 -canna -xim & $ moodss

with the following software installed:

• Canna 3.6
• Kinput2 3.1

Then, for inputting Japanese text in say, a free text viewer, hit Shift-Space and type into the little window that appears near and below the insertion cursor.

Notes:

• you may need to adjust the font in Preferences
• dashboard files are encoded in EUC-JP when saved
• for archiving data, the following databases were successfully tested with Japanese comments in data cells: SQLite, MySQL

Q: Can post-mortem analysis be achieved?

A: Yes, as the following actual practicle example shows.

A webmaster faced the situation where its server became overloaded and started swapping after a while. Unable to log in, he could not determine the exact cause leading to that situation.

Building a dashboard including the cpustats, memstats, psbyname and psbyuser modules and using a simple SQLite file as a database storage mean helped find the problem. This dashboard was loaded by the moomps daemon on the web server and left running to capture data around the busiest periods. The SQLite file was then recovered from the web server and browsed from the moodss GUI on another computer.