1. Installing GemStone/S 64 Bit Version 3.5

Next chapter

This chapter describes the procedure for installing GemStone/S 64 Bitâ„¢ version 3.5. We recommend that you set up GemStone initially on a single machine, to ensure that all the pieces work together. At the end of this chapter, we suggest refinements you might want to make. Further setup to run a distributed system are described in the System Administration Guide. You will need to adjust the installation process to meet your specific needs.

If you are upgrading to this release from a previous version of GemStone/S 64 Bit, follow the instructions in the appropriate later chapter of this Installation Guide. These upgrade instructions will provide details on steps that need to be taken before and after the installation as described in this chapter.

Review the Installation Procedure

The following list summarizes the steps to install GemStone/S 64 Bit.

Check the System Requirements

Before you install GemStone/S 64 Bit, ensure that the following system requirements are satisfied. Systems meeting these requirements are suitable for installing GemStone/S 64 Bit and beginning development, but additional system resources may be necessary to support large applications.

For Compiler and Debugger versions, refer to the GemBuilder for C manual.


  • System with an x86_64-compatible processor.

RAM and Swap space

  • While small installations can run on systems with only a few GB of physical RAM, increasing RAM is important for GemStone performance.

Total swap space should be at least equal to the amount of RAM. Due to the way GemStone uses memory, systems with insufficient swap space allocated have a risk of memory errors even if there is available RAM.

Disk space

  • Space for the installed distribution files—you need approximately 450 MB for GemStone/S 64 Bit, and additional space for other products.
  • Additional disk space as required for your repository.

The repository files should be located on a disk drive that does not contain swap space. Use of multiple disk drives is advisable for servers.

Operating system

  • Red Hat Linux ES 6.9
    kernel version 2.6.32-696.18.7.el6.x86_64 and glibc-2.12-1.209.el6_9.2.x86_64
  • Red Hat Linux ES 7.4
    kernel version 3.10.0-693.11.6.el7.x86_64 and glibc-2.17-196.el7_4.2.x86_64
  • Ubuntu 16.04 LTS
    kernel version 4.4.0-97-generic and glibc 2.23-0ubuntu9
  • Ubuntu 18.04 LTS
    kernel version 4.15.0-45-generic and glibc 2.27-0ubuntu1
  • SUSE Linux 12
    kernel version 3.12.44-52.10-default and glibc-2.19-20.3.x86_64

Configure the Operating System

The kernel must be configured to support shared memory and semaphores. See your operating system documentation for further information. These requirements apply both to server nodes and to client nodes.

1. Shared memory

The upper limit for shared memory single segment size and total usage should be set to values larger than your desired Shared Page Cache size, and not more than 75% of your real memory size.

The single segment maximum size, shmmax, is set in bytes, and the total shared memory limit, shmall, is configured in pages, with a base page size of 4KB. Note that the results of ipcs may be reported in kbytes.

For example, if you have 8192 MB of real memory:

8192 MB * .75 = 6144 MB
6144 MB * 220 = 6442450944 bytes
6442450944 / 4K = 1572864

To set shared memory sizes, you would append the following text to the /etc/sysctl.conf file. The settings are read from this file during the boot process.

# Shared Memory setting for GemStone
kernel.shmall = 1572864
kernel.shmmax = 6442450944

For more details, consult your Linux operating system documentation.

2. Semaphores

You may need to increase the settings for semaphores. These settings are configured by setting kernel.sem to a 4-element array, with the equivalent to the old semmsl, semmns, semopm, and semmni. For example, append the following to the /etc/sysctl.conf file.

kernel.sem=1000 512000 64 2048

The first element sets the maximum number of semaphores per id (per semaphore set). This parameter limits the number of GemStone sessions that can log in to a particular Stone and connect to its shared page cache.

On the Stone’s node, this parameter must provide two semaphores for each user who will log in to that Stone from any node plus an overhead of four. In distributed systems, nodes that have only user sessions must provide two semaphore for each user session on that node plus an overhead of one.

The number of semaphores actually requested for a particular shared page cache depends on the GemStone configuration file read by the process that starts the cache and is (SHR_PAGE_CACHE_NUM_PROCS * 2) + 1.

The second value sets the total number of semaphores in the system, which must be increased to along with the first.

3. File Descriptors

Each user session requires two file descriptors, and others are needed for extents, transaction logs, and other overhead. The default setting for fs.file-max setting is usually sufficient.

4. Locking the Shared Page Cache in memory

If you intend to lock the shared page cache into memory via the stone configuration option SHR_PAGE_CACHE_LOCKED, then the linux user starting the stone must either have the Linux capability CAP_IPC_LOCK, or have a RLIMIT_MEMLOCK resource limit set greater than the size of the SPC.

5. OOM Killer

If your system runs low on memory, the Linux OOM killer may select GemStone processes to terminate. To protect the shared page cache and other critical GemStone processes, each GemStone process’s oom_score_adj, which is used to select processes to terminate, is adjusted. If the userid that will be running the server processes has the CAP_SYS_RESOURCE privilege, critical GemStone processes have their oom_score_adj reduced, making them safer; if the user does not have CAP_SYS_RESOURCE, then non-critical processes such as Gems have their score increased, so they will be selected rather than more critical processes.

To set CAP_SYS_RESOURCE on kernels v2.6.32 and later, set the capability on the executables:

a. Install libcap2-bin

b. for i in pgsvrmain gem stoned shrpcmonitor; do sudo setcap cap_sys_resource=pe $GEMSTONE/sys/$i ; done

c. for i in startstone topaz; do sudo setcap cap_sys_resource=pe $GEMSTONE/bin/$i ; done

6. PAM

If you are using UNIX authentication for GemStone logins, or if you run NetLDI as root with setuid (i.e. not in guest mode), you must have PAM (Pluggable Authentication Module) configured on the server. You may include a specific GemStone authorization service name, or allow the default “other” authentication definitions to be used.

PAM authentication definitions are in files under the directory /etc/pam.d. Alternatively, they can be lines in the configuration file /etc/pam.conf, but this usage is deprecated on many distributions. On these distributions, the presence of the /etc/pam.d directory will cause /etc/pam.conf to be ignored.

The specific GemStone service file names are gemstone.gem for user authentication, and gemstone.netldi for a NetLDI running with authentication.

The libraries that are specified in the stack depend on how you are configuring PAM to perform the authentication. The examples below are for PAM configured to invoke LDAP for authentication.

For example, to allow GemStone UNIX authentication, which uses PAM, to authenticate via LDAP, create a file named /etc/pam.d/gemstone.gem with the following contents:

auth	required	pam_ldap.so

For NetLDI authentication, again using LDAP, create a file named /etc/pam.d/gemstone.netldi with the following contents:

auth	required	pam_ldap.so

Red Hat, by default, installs a file /etc/pam.d/other which disables “other” authentication. On Ubuntu, it is enabled by default. You can allow the “other” authentication stack to be used for GemStone authentication by ensuring that the file /etc/pam.d/other has the following contents:

auth	required	pam_ldap.so

Consult your System Administrators for more information on how authentication is handled on your system.

7. Large Memory Pages

The default size for memory pages is 4KB. If you have a large repository, using large pages (in Linux, these are called Huge Pages) may improve performance. Linux supports 2MB and 1GB huge pages; a Linux installation may be configured to support one or both of these. To use large pages, you must determine the huge page size and the number of huge pages needed, configure Linux to allocate the required number of pages, and configure GemStone to use large pages.

To configure the use of large pages:

a. Determine pages sizes available on your Linux system, and decide on the size you intend to use. Smaller repositories may use 2MB pages, but repositories with multi-GB shared page cache sizes may benefit more from 1GB pages.

To determine the default huge page size, execute:

unix> grep -e '^Huge' /proc/meminfo

which reports, for example,

   HugePages_Total:    5000
   HugePages_Free:     2756
   HugePages_Rsvd:        0
   HugePages_Surp:        0
   Hugepagesize:       2048 kB

To determine if you have another page size available, execute:

unix> ls /sys/kernel/mm/hugepages/

If you have 2MB pages, it will return:


If you have both 2MB and 1GB pages, it will report:

   hugepages-1048576kB  hugepages-2048kB

b. Determine the number of huge pages that will be needed, based on your GemStone configuration. This is calculated by the utility largememorypages. This utility needs several details to compute the number of required pages: the shared page cache size, the maximum number of GemStone processes, and the number of shared counters. These can be provided by arguments or read from an existing configuration file.

largememorypages [-e path ] [-z path] [-F cacheFrames | -M cacheKB]
  [ -P maxProcesses] [-C maxSharedCounters] [-p largeMemoryPageSize]

You may specify the required values using a valid configuration file. This is parsed as a Stone configuration file and the necessary values extracted.

-e path
specifies an executable config file (same as startstone -e).

-z path
specifies a system config file (same as startstone -z).

If a config file is not specified, then -M or -F and -P and -C are required. These arguments can be used in addition to the configuration file, in which case they override values set or computed in the configuration file:

-F cacheFrames
shared cache size expressed in 16 KB frames

-M cacheKB
shared cache size with a optional units suffix.

-P maxProcesses

-C maxSharedCounters

-p largeMemoryPageSize
setting for SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_SIZE_MB. Optional; the default is 2MB, may also specify 1 GB (or equivalent using appropriate units).

The following example is for an (approximately) 20GB shared page cache, 200 processes, and 1900 shared counters, with 2 MB memory pages:

unix> largememorypages -p 2MB -M 20GB -C 1900 -P 200
Cache config is 1310720 pages = 20480 MB,  total is 21384 MB,  overhead 4% of configured size
Large page size requested is: 2 MB.
Large page overhead: 1.12 MB
For 1310720 pages, 200 processes and 1900 shared counters, 10 pusherThreads
  required cache size is 22422749184 bytes.
Number of 2 MB large pages required: 10692
<with further update commands>

c. Configure Linux to use large pages, according to the instructions for your Linux distribution. The following commands may be used. You must execute these as root.

To enable large/huge pages until the next system reboot:

echo numpages > /sys/kernel/mm/hugepages/hugepages-hugePageSize/nr_hugepages

For example:

unix> echo 10692 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

To permanently enable large pages:

echo "vm.nr_hugepages=numpages" >> /etc/sysctl.conf

Note nr_hugepages may fail if insufficient contiguous memory is available. You can confirm the number of large memory pages that are available for use using grep -e '^Huge' /proc/meminfo.

d. Ensure that the executables can use large pages.

You can configure the executables to use large pages, by using setcap:

unix> setcap cap_ipc_lock=pe $GEMSTONE/sys/startshrpcmon
unix> setcap cap_ipc_lock=pe $GEMSTONE/sys/shrpcmonitor

Alternatively, the SPC monitor process can be run with an effective user ID of root:

chown root $GEMSTONE/sys/shrpcmonitor $GEMSTONE/sys/startshrpcmon
chmod u+s $GEMSTONE/sys/shrpcmonitor $GEMSTONE/sys/startshrpcmon

Configure GemStone to request large pages by set the configuration option SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_POLICY. This can be set to 1 or 2; with a setting of 1, the cache will be started anyway if the request for large pages is denied, while a setting of 2 indicates that startup should fail if large pages cannot be allocated.

If you are using 1GB pages, you will also need to update the setting for SHR_PAGE_CACHE_LARGE_MEMORY_PAGE_SIZE_MB. By default, this is set to 2; if you are using 1GB pages, set this to 1024.

8. Configuring GemStone’s Shared Page Cache

The configuration option SHR_PAGE_CACHE_SIZE_KB defines the size (in KBytes) of extent page space in the shared page cache. The maximum acceptable value for this configuration option is limited by system memory, kernel configurations, cache space allocated by SHR_PAGE_CACHE_NUM_PROCS and space allocated for other GemStone caches.

For more general information about these and other configuration options, see Appendix A of the System Administration Guide.

9. System clock

The system clock must be set to the correct time. When GemStone opens the repository at startup, it compares the current system time with the recorded checkpoint times as part of a consistency check. A system time earlier than the time at which the last checkpoint was written may be taken as an indication of corrupted data and prevent GemStone from starting. The time comparisons use GMT.

10. TCP keepalive option

GemStone processes ordinarily use the TCP keepalive option to determine how long they will wait after communications activity ceases unexpectedly. This setting can be useful for reaping stale RPC Gems, but the operating system default may not be appropriate for this purpose. For further information, refer to your operating system documentation.

11. Unset LD_BIND_NOW

On some Linux distributions, setting the environment variable LD_BIND_NOW may result in process startup failures due to loading incorrect shared libraries.

Prepare for Installation

Installing GemStone can be done as a regular user, but in order to setup shared security, some portions of the installation should be done when logged in as the root user. Other steps of the installation are done as the unix user who will be the GemStone administrative account.

In addition to the installation directory, these are the portions of the system that are affected by the installation of GemStone:

Optional raw partitions for repository extents and transaction logs.

Internet services database, for NetLDI name lookup.

Default location for server lock files, host name id file, and log files for GemStone network servers (NetLDIs). See the System Administration Guide for details.

1. Log in as the GemStone administrator to the machine on which you are installing GemStone. This part of the installation should not be done as root, to ensure all the files are not owned by root.

2. Determine that adequate swap space is available.:

unix> cat /proc/swaps

3. Select the drive on which you will install the GemStone software, and the installation directory on this drive, InstallDir. Make this directory the current working directory.

We recommend that you avoid choosing either an NFS-mounted partition or one containing UNIX swap space for the initial installation. Mounted partitions can result in executables running on the wrong machine and in file permission problems. Existence of swap space on the same drive can dramatically slow GemStone disk accesses.

4. GemStone/S 64 Bit is provided as a zipped archive file with a name similar to GemStone64Bit3.5.0-x86_64.Linux.zip. Move this distribution file to the directory location in which GemStone will be installed, InstallDir.

5. Unzip the distribution file using unzip.

6. The InstallDir now contains a GemStone directory with a name similar to GemStone64Bit3.5.0-x86_64.Linux.

In addition to subdirectories, this directory also contains two text files: PACKING, which lists all of the GemStone files, and version.txt, which identifies this particular product and release of GemStone.

Set the Environment

Perform the following steps to properly configure the operating environment.

1. Set the environment variable GEMSTONE.

a. If more than one installation of any GemStone/S product resides on this machine, check for existing GemStone environment variables:

> env | grep GEM

All GemStone environment variables are displayed.

b. If any environment variables exist and are not appropriate for the new installation, you must specifically unset each one. For example:


c. Set the environment variable GEMSTONE to the full pathname (starting with a slash) of your new GemStone installation directory. For example:

> export GEMSTONE=InstallDir/GemStone64Bit3.5.0-x86_64.Linux

Set the GemStone Key File

To run GemStone, you must have a key file for the correct version of GemStone/S 64 Bit and for the appropriate platform. The keyfile must be located where GemStone can find it on startup:

  • A file specified by the KEYFILE configuration parameter in the configuration file used by the stone. This is not set by default, but may be defined to read a keyfile with any name in any location.
  • $GEMSTONE/sys/gemstone.key
  • $GEMSTONE/sys/community.starter.key

Licensed Customer key file

Licenced customers can email keyfiles@gemtalksystems.com or contact GemTalk Technical Support to request a keyfile for version 3.5 for their platform or platforms. Keyfiles for previous versions of GemStone are not valid with v3.5.

Community key file

The GemStone distribution includes a community key file, community.starter.key., with product and system limits per the Community and Web Edition License. See https://gemtalksystems.com/licensing for details on the license terms.

If you do not install a custom keyfile, this starter keyfile will be used instead.

Installing a keyfile

To specify the location and name of the keyfile using the KEYFILE configuration parameter, edit the configuration file that will be used by the v3.5 stone to include the location and name of the keyfile.

You may also put the keyfile in the default location, $GEMSTONE/sys/gemstone.key. This requires modifying the write permissions of the $GEMSTONE/sys directory; ensure you change this back to not writable, after this update.

Verify TCP/IP

To run GemStone, TCP/IP must be functioning, even if your machine is not connected to a network.

Verify that TCP/IP networking software is functioning:

> /bin/ping hostname

where hostname is the name of your machine. If ping responds with statistics, TCP/IP is functioning.

Define the NetLDI Service

The NetLDI service, by default gs64ldi, should be defined in your system services database. A NetLDI is required for certain kinds of local and remote sessions to log into GemStone, and if it cannot be resolved by name, you must refer to it by port number. For clients on remote machines, the same NetLDI service name and port number must be defined on the remote machines as well as the main host.

If you are upgrading from a previous version, you may need to keep the NetLDI for that version running. In this case, select a distinct name and port for the NetLDI for GemStone/S 64 Bit 3.5.

1. Determine whether the gs64ldi service is already defined. How to do this will depend on how your system is set up. The GemStone distribution includes an executable that will allow you to do this:

unix> $GEMSTONE/install/getservbyname gs64ldi
s_name=gs64ldi s_port = 50377 s_proto = tcp

If gs64ldi is defined, skip the rest of this procedure and continue with the installation at Run the Installation Script.

If it is not defined, continue performing this procedure.

2. Add an entry similar to the following to the system services database:

gs64ldi 50377/tcp #GemStone/S 64 Bit 3.5

Choose a port number that is not being used by another service. The port number should be in the range 49152 <= port <= 65535, to confirm to IANA standards (http://www.iana.org/assignments/port-numbers).

3. If several machines will be running GemStone, have the UNIX system administrator update the system services database for each machine. This includes Windows client machines as well as UNIX nodes. Note that the port number must be the same for every machine.

Run the Installation Script

1. Log in as root.

Although you can complete the installation as a non-root user, we do not recommend this when installing a multi-user system. During installation, GemStone system security is established through file permissions and process attributes. To ensure that the installation is successful, you must install as root. See the System Administration Guide for details on setting up GemStone server file security.

2. Invoke the installation script from the install subdirectory:

unix> cd $GEMSTONE/install
unix> ./installgs

installgs is an interactive script that analyzes your system configuration and makes suggestions to guide you through installing GemStone on your machine.

You can usually terminate execution of the installation script with Ctrl-C without risk to your files. When it is not safe to do so, the message Please do not interrupt appears on the screen. If this happens, wait for the message now it is OK to interrupt before you interrupt the script. You can run the script again from the beginning as many times as necessary.

3. Log out as root

After running installgs, log out as user root. Further work, such as setting the TimeZone, is done as the GemStone administrative user.

Decisions to Make During Installation

During installation, you are asked several questions. The entire installation dialog is not reproduced here, but the main points are addressed. Some questions may not be asked, depending on answers to previous questions.

Whenever you are asked to answer “yes” or “no,” answer with y or n. When the script offers a default answer in square brackets (such as “[y]”), press Enter to accept the default.

Do you want the installation script to set up directories for server lock files and NetLDI logs?

The default location for server lock files and NetLDI log files is /opt/gemstone, although for compatibility with earlier products /usr/gemstone is used only if it exists. If the environment variable GEMSTONE_GLOBAL_DIR is defined to point to a valid directory, this overrides the default server lock files and log file location; however, all Gemstone processes that will interact on this machine must have this environment variable set to the same directory.

If these directories do not exist, the installation script offers to create /opt/gemstone and the subdirectories locks and log. Then, the script offers to set access (770) to these directories.

If you answer no to creating the directories, you must create them (or provide a symbolic link) before starting the server.

Do you want the installation script to set the owner and group for all the files in the GemStone distribution?

If you answer yes, the script will prompt you for the owner and group you want to use. Refer to Chapter 1 of the System Administration Guide for more information about setting owner and group permissions.

If you answer no, the permissions will remain the same as when the files were extracted from the distribution media.

Do you want the installation script to protect the repository file?

The default, which we recommend, gives only the owner read and write access (600) through ordinary UNIX commands. Other users can read and write the repository through a GemStone session. If you choose not to protect the repository, the setuid bit is cleared from all executables, which causes them to run under ownership of the user who invokes them.

Default: Set the repository permission to 600, and leave the setuid bit applied.

Allow NetLDI to Run as Root?

Do you want the installation script to allow non-root users to start a NetLDI that runs as root?

The NetLDI is a network server that permits remote processes to interact with the repository. There are two ways to set up a NetLDI so that it can provide services to all GemStone users: it can run as root, or it can run in guest mode with a captive account.

  • To run NetLDIs as root, accept the default “yes” response. Ownership of the NetLDI executable is changed to root, and the setuid bit is set. Any GemStone user will be able to start a NetLDI process that is accessible to all GemStone users because it will always run as root. For certain services, users will need to authenticate themselves by supplying a password. Alternatively, answer “no” but log in as root before starting the NetLDI.

If the NetLDI uses a port number less than 1024, it must run as root.

  • To run NetLDIs in guest mode with a captive account, answer “no” to the prompt, because those modes are not permitted if the NetLDI runs as root. “Guest mode” means that GemStone users do not have to supply a UNIX password to use NetLDI services. The “captive account” is an account that owns all processes the NetLDI starts; typically, it is the GemStone administrative account that owns the files. You must start the NetLDI while logged in as that account.

Default: Change ownership of the netldi executable to root, and set its setuid bit.

Set up an Extent?

Do you want the installation script to set up an extent now?

GemStone is distributed with a read-only copy of the initial repository in
$GEMSTONE/bin/extent0.dbf. Before you can start GemStone, this file must be copied to a suitable location and made writable. The script offers to copy the file to its default location of $GEMSTONE/data.

If you are a new GemStone user, we recommend that you answer y. If you are an existing GemStone user, you might prefer to answer n, then copy the extent to a different location yourself. (If you choose a location other than the default, you must edit your configuration file before starting GemStone. For information, see the System Administration Guide.)

Default: Place a writable copy of extent0.dbf in $GEMSTONE/data.

Start a NetLDI?

Do you want the installation script to start a NetLDI?

If you prefer, you can start these processes manually at any time.

Almost every host needs a NetLDI. You must start a NetLDI when the Stone repository monitor or Gem session processes will run on this machine.

You can start a NetLDI that runs as root by answering yes to this prompt and the confirmation that follows. However, if you want to start the NetLDI in guest mode with a captive account, you must do that after completing the installation. For more information about guest mode with captive account, see Chapter 3 of the System Administration Guide.

Default: Do not start a NetLDI at this time.

Start an Object Server?

As root, you cannot start an object server, but the script offers to start one as another user. You will start the server later in the installation, so answer no.

Default: Do not start an object server at this time.

Change Passwords for Administrative Accounts

GemStone comes with a number of built-in System user accounts, which are needed to perform administrative operations (such as adding application user accounts).

The initial password for these administrative accounts is swordfish.

Access to each of these accounts should be restricted; you should always change the passwords for these accounts, to provide basic security for your application.

The chapter entitled User Accounts and Security in the System Administration Guide tells you how to change the passwords

Add Users

For each of the users in your system, you should establish GemStone accounts, which involves creating an individual UserProfile in GemStone.

The chapter entitled “User Accounts and Security” in the System Administration Guide provides information on how create accounts for GemStone users, and the options for authentication. This task can be done by executing Smalltalk code, or using GemBuilder for Smalltalk tools. See the GemBuilder for Smalltalk Users’s Guide for information on the GUI tools in GemBuilder.

Users must set environment

After GemStone/S 64 Bit 3.5 has been installed, you should notify each person who will be using GemStone about the installation, and explain how to setup their environment.

Each user must:

  • Set the environment variable GEMSTONE to the full pathname (starting with a slash) of the GemStone/S 64 Bit 3.5 directory.
  • update their path to include the $GEMSTONE/bin directory.
  • Optionally, update the man path (MANPATH variable) to include the $GEMSTONE/doc directory. GemStone provides man pages for utility functions.

These last two steps can be done using scripts that are part of the GemStone distribution. The directory $GEMSTONE/bin contains the files gemsetup.sh and gemsetup.csh, which define the GemStone environment for users by modifying the PATH and MANPATH variables to include $GEMSTONE/bin and $GEMSTONE/doc, respectively.

For example:

> export GEMSTONE=installdir
> export PATH=$GEMSTONE/bin:$PATH

If the user will use GemStone frequently, consider adding these steps to the login shell initialization file.

Install the default TimeZone

GemStone/S 64 Bit is shipped with a default time zone of US Pacific. If you are in another Time Zone, edit the file installtimezone.txt in the GemStone upgrade directory, then file it in as SystemUser.

Further Configuration and Administration

This chapter has guided you through installation of GemStone/S 64 Bit 3.5, with the objective of getting a simple, default configuration up and running.

The next chapters explain the process of upgrading a previous version of GemStone/S 64 Bit to version 3.5; and Chapter 5 provides information on GemBuilder for Smalltalk.

For more information and details on customizing your GemStone object server, Gem client processes, and setting up distributed configurations, see the System Administration Guide.

Next chapter