Skip to main content

Aerospike systemd Daemon Management


This section describes how to manage the Aerospike daemon and server logs on certain systemd-based Linux distributions, using the standard systemd tools, systemctl and journalctl, rather than with the Aerospike SysV init script.


See Planning a Deployment for the list of currently-supported distributions.

systemctl with server commands

You can use systemctl with the following commmands to control the Aerospike daemon:

  • start
  • status
  • restart
  • stop

For more information about restart modes, see Restart Modes.

Start the server

systemctl with start intitates a Fast Restart in Enterprise Edition, and a Cold Start in Aerospike Community. To start the Aerospike database:

systemctl start aerospike

Get the server status

Use systemctl with status to see if the server is running:

systemctl status aerospike

Restart the server

systemctl with restart is equivalent to running stop followed by start:

systemctl restart aerospike

Stop the server

systemctl with stop shuts down the server:

systemctl stop aerospike

Control commands without systemctl

systemctl does not support application-specific commands.

Cold start

To force a cold start, use asd-coldstart:


For Aerospike Enterprise, a cold start forces the server to rebuild the in-memory index by scanning the persisted records. This may take a significant amount of time depending on the size of the data. For Aerospike Community this is the same behavior as start.

Service port status

To check thes status of the service port, use the *STATUSinfo command which will return "OK" when ready:

asinfo -v STATUS


Managing server logs under systemd

Under systemd, the journald is the standard facility for managing logs for all Linux daemon processes uniformly. A "structured, indexed centralized journal" is supposed to be better than the old fashioned way of text-based log files.

Access the Aerospike log with the journalctl command.

journalctl -u aerospike -a -o cat -f
  • The -a option ensures nothing is suppressed from the Aerospike log messages, even if some lines are very long.
  • The -o cat option presents the raw Aerospike log without prepending the journal's timestamp and other metadata to each line.
  • The -f option will "follow" the log as it is generated.

When running under systemd, it is still possible to direct the Aerospike Server to create (and rotate) log files. For more information on managing Aerospike Server log files, see Configuring Log Files.

Using asloglatency under systemd

To use the asloglatency tool under systemd, first extract the desired portion of the log into a temporary file using journalctl, e.g.:

journalctl -u aerospike -a -o cat --since "2023-03-17" --until "2023-03-18" | grep GMT > /tmp/aerospike.20230317.log

then run asloglatency on the extracted log file, e.g.:

asloglatency -h writes_master -f head -l /tmp/aerospike.20160317.log

Changing user and group under systemd


If upgrading to Aerospike Server or newer, the modifications to /etc/systemd/system/aerospike.service.d/user.conf step below should not be configured.

For *RHEL 7, Ubuntu 20.04, Debian 8+(distributions based on systemd) running versions prior to, the following additional steps are required (besides the steps described on the configuring as non root page):

cat > /etc/systemd/system/aerospike.service.d/user.conf <<EOF

Refer to this Knowledge-Base article: article for further details.

More information about the Journal daemon

Storage location

The default location for Journal files is /run/log/journal. When you configure /etc/systemd/journald.conf to use persistent storage, files are stored in /var/log/journal, and fallback to /run/log/journal. /run/log/journal is used for logging during early boot when the disk is not yet writable.

Log rotation

Journal rotates logs according to the configurations in /etc/systemd/journald.conf. You can configure logs to rotate based upon file size, directory size, and age of logs. You can also configure logs to live in memory and to not persist after reboot.

If you configure logs to rotate based on file size, Journal governs file size with the option SystemMaxFileSize in the journald.conf configuration file. This option sets a maximum file size for Journal files. SystemMaxUse sets the maximum storage allocated for Journal files. Supported size notation include no-suffix for bytes, K for Kibibyte (KiB), M for Mebibyte (MiB), G for Gibibyte (GiB), T for Tebibyte (TiB).

You can also use the Maxfilesec option to set a maximum age for entries in a single Journal file before rotating to the next one. This setting can be in: year, month, day, hour, or minute. The MaxRetentionSec option sets the maximum age for stored Journal files.

Aerospike recommends that you configure journald.conf to rotate logs every 24 hours, and to keep the logs for 90 days. You can refer to the sample journald.conf file at the end of this document.

Reviewing prior logs

When you review Journal files with journalctl, prior logs are automatically included. If the time period that you are reviewing spans two or more Journal files, journalctl displays the entries seamlessly.

Persistence in Journal

Persistence determines if and where you store the Journal files. You can modify /etc/systemd/journald.conf to configure persistence.

Config itemValueResult
StoragenoneJournal does not keep data
StoragevolatileJournal data is only held in memory
Storagepersistentlogs are held in /var/log/journal
use /run/log/journal for fallback during early boot if needed

Sample systemd Journal configuration file

This file is part of systemd, typically located at /etc/systemd/journald.conf.

# Compress=yes
# Seal=yes
# SplitMode=login
# SyncIntervalSec=5m
# RateLimitInterval=30s
# RateLimitBurst=100
# SystemKeepFree=
# SystemMaxFileSize=
# RuntimeMaxUse=
# RuntimeKeepFree=
# RuntimeMaxFileSize=
# ForwardToSyslog=yes
# ForwardToKMsg=no
# ForwardToConsole=no
# TTYPath=/dev/console
# MaxLevelStore=debug
# MaxLevelSyslog=debug
# MaxLevelKMsg=notice
# MaxLevelConsole=info