This section of the tour discusses a group of miscellaneous commands available on the administrators menu.

The Who's on Manhattan? command actually does two things:
It gives you a list of people who are currently logged in.
It deletes "stale keys", which are small session files left on the server by users who are long gone, but never logged out properly.
The output of the Who's on Manhattan? provides two lists, one for "Normal" or centralized courses, and one for "Standalone" courses. Here's the top few lines of the centralized listing for a busy server:

Recall that a student or a teacher can be a member of several Manhattan courses. When they log in, they are shown a "My Manhattan" page that lists all of their courses. They can then enter a particular course by clicking on its title. The first column in the above screenshot shows the number of courses each user has entered from their initial list of courses. Prof. Hakala has apparently just entered Manhattan and is looking at his list of courses - he has not yet entered any of them. Near the middle of the list, Michael has thus far entered three of his Manhattan courses.
The "Minutes since last command" column shows the number of minutes that have elapsed since the user last clicked on a command button or link within Manhattan. This value gets reset to 0 minutes only when a person clicks on a button or link that is truly part of Manhattan. (The person may otherwise be very busy working with a Word file they downloaded as an attachment, or browsing through an attached website.) The list is sorted with the most active users at the top - those with the lowest "Minutes since last command". The next screenshot shows the bottom few lines of the same "Who's on Manhattan?" list:

Note that the last person on the list has been inactive for 239 minutes. It turns out that by default (you can change this setting in custom.h) users are automatically logged out after 240 minutes. You should never see a value higher than 239 minutes since last command on these lists. If you wait a minute, then refresh the page, you'll find the last user will get dropped from the list.
The text at the bottom of the table says that 465 central "keys" were examined, and that 422 were in use. A "key" is a small file that's used to track a user's activity within Manhattan. When a user logs in, a new key is created. The key is deleted when the user properly exits Manhattan by clicking the Log Out button. Thus, the number of "keys in use" is technically the number of people who are logged into Manhattan at this moment. That would be information you can count on if users always logged out of Manhattan properly. In practice, many, many Manhattan users don't bother to log out. (This does no harm for those working from their own personal computers.)
So how many people are actually logged in? The best you can do is use your own judgement based on the "minutes since last command". Certainly people with 0 or 1 or 2 minutes since their last command are actively using Manhattan, but even a person with 30 minutes since their last command could be working on an exam or reading material posted by the teacher. The moment they click a button or Manhattan program link, they'll be moved to the top of the list.
Finally, note the lines that read "Deleted N expired user keys" and "Deleted N expired session files". This is the result of clean-up work that the Who's on Manhattan? command does whenever it's run. For users who haven't touched a command in 240 minutes, the keys and "session files" (small files created when they enter a particular classroom) are deleted, thus freeing up a bit of disk space. It turns out that a user's "expired" keys and session files are automatically deleted the next time he logs in anyway, so you need not worry too much about them accumulating on the server. It's not a bad idea, however, to see "Who's on Manhattan?" whenever you login to the administrative system.
The purpose of the Lock server command is to allow you, as system administrator, to perform maintenance on either the physical server or perhaps on the Manhattan software (e.g. to upgrade to a new version). When you click the Lock server link (and after responding OK to an "Are you sure?" prompt):
Teachers and students will be prevented from logging in. When they do enter a correct username/password, they'll get a message stating that the server has been locked for maintenance.
Users that are already logged in can continue to work, however they'll be logged out automatically (with a message stating that the server has been locked for maintenance) the next time they visit the "My Manhattan" page, or the Main Menu for any one of their classes.
How do you know when everyone is really off the server? You should repeatedly use Who's on Manhattan? to see who is still actively using Manhattan. As discussed in that section, it can be difficult to know with 100% certainty whether or not everyone is off. You'll have to use your judgement.
When the server is locked, the link on the administrator's menu changes to Unlock server to remind you that no one can log in to their accounts:

Clicking on the Unlock server link returns the installation to normal so users can log in again.
There are two occasions when temporary files might be left on the server:
A user clicked their Stop button, or otherwise caused their browser to stop sending data to the server in the middle of posting a new Manhattan message.
A user was viewing an "Attached website" within a Manhattan classroom, and never returned to the classroom.
When a Manhattan message is sent, the raw data is first stored in the tmp directory of your Manhattan installation. The name of the file starts with CGI_DATA_. Once this data is parsed and stored as a true Manhattan message, this temporary file is deleted. Unfortunately it often happens that users somehow stop the process in the middle of sending a message. Most frequently, they are trying to send a large attachment and have underestimated how long it should take using their slow Internet connection. Whatever the reason, an aborted send leaves the CGI_DATA_* file in the tmp directory within your Manhattan installation. The Clean up command deletes any CGI_DATA_* files in the tmp directory that's more than 240 minutes (4 hours) old.
![]() |
It's fairly important to at least occassionally run the Clean up because temporary files of the kind described above are never cleaned automatically. If you have the know-how and the desire, you're free to run your own cron job to automatically remove these files. |
![]() |
The tmp directory we're referring to is within your Manhattan installation. It is not the same as the /tmp directory that's part of the standard Linux/Unix filesytem. Manhattan never writes any files outside of its own installation directory. |
The second type of temporary file deleted by the Clean up command are symbolic links found in the images/links directory of your Manhattan installation. Whenever a user views an "Attached website" (see the Teacher's Reference for details) within a Manhattan classroom, a symbolic link is created for that user within the image/links directory of your installation. If that user never returns to the classroom from that attached website, the symbolic link remains. While the Clean up command also deletes any stale symbolic links it finds, it so happens that these symbolic links are also somewhat self-cleaning. The next time the user logs in to Manhattan, any stale symbolic links he left on the server during his last visit are automatically removed.

The Disk space command simply shows you the output of the standard Linux/Unix df ("disk free") command. Example output might be:

The point, of course, is to allow you to see how much free disk space you have on your server. You will need to know something about your server's disks and how they are mounted to make use of this information. The above screenshot shows 5 filesystems, only the system administrator knows which one is home for this particular installation of Manhattan.
If you're working through this chapter as a tutorial, take the time to experiment with these miscellaneous commands. In particular, it's useful to see how a "locked" server looks like to an end-user.
Lock the server, then try to login as Prof. Einstein.
Unlock the server, then login as Prof. Einstein and enter his Introduction to Physics course. Start composing a message in any module, but don't hit the Send Message button. From another browser window or computer, use the administrative system to lock the server. Switch back to Prof. Einstein's view and click the Send Message button. What happens? Did the message get sent?
Extra credit. The online information within Manhattan explains that creating (or deleting) a file named SYSTEM_LOCKED within your installation's tmp directory has the same effect as using the Lock server or Unlock server from within the web based administration system. Verify that this is true.