Logger: Dispatching RFC 5424 Syslog Messages, Integrating Shell Pipelines Into Journald, and Standardizing Production Audit Trails

Every systems administrator and DevOps engineer has lived some version of this nightmare. In Unix computing, there is an unforgiving law: if an event is not durably recorded by the operating system’s central event log, it might as well have never happened at all. When maintenance scripts, background cron tasks, and CI/CD pipelines rely on fragile redirection hacks like >> /tmp/output.log, critical error codes and diagnostic breadcrumbs evaporate the moment a process terminates or a server reboots.

The solution to this blind spot has been quietly sitting in Unix distributions for decades. The logger command-line utility provides a direct bridge between your transient shell scripts and the operating system’s permanent, structured logging architecture. Instead of casting diagnostic messages into temporary text files, logger wraps your data in standardised syslog envelopes and delivers them straight to the system logging daemon or modern systemd journal.

To see how immediately transformative this tool is, consider the single most useful command you can run in your shell right now:

logger -s -p local0.warn -t DB_BACKUP --id=$$ "Database snapshot completed with 2 non-fatal index warnings"

<132>Aug 18 08:04:12 DB_BACKUP[14820]: Database snapshot completed with 2 non-fatal index warnings

In one concise line, this command computes a formal syslog priority level, stamps the entry with an application tag (DB_BACKUP), attaches your current shell's process identifier ($$), prints a real-time copy to your screen (-s), and durably commits the event to the system log. If your SSH connection drops half a second later, the audit trail remains permanently etched into the operating system.

What It Does in Plain English

At its core, logger is the universal adapter of Linux observability. Shell scripts naturally communicate through plain text printed to standard output and standard error streams. Modern operating systems, however, manage system health through structured event pipelines like systemd-journald or enterprise log repositories.

The logger utility takes raw strings, pipeline streams, or entire files, enriches them with precise operational context—such as subsystem classifications, severity rankings, process IDs, and high-resolution timestamps—and dispatches them directly across local Unix domain sockets or over network connections. By dropping logger into your scripts, any routine backup job or deployment harness instantly inherits enterprise-grade auditing, automatic log rotation, and central dashboard indexing.

Core Flags and Operational Mechanics

Modern implementations of logger (part of the core util-linux package) offer granular control over how messages are classified, framed, and routed:

• -p, --priority <facility.level>: Sets the message priority using a standard composite of subsystem facility (such as daemon, authpriv, or local0 through local7) and severity level (such as emerg, alert, crit, err, warning, notice, info, or debug).
• -t, --tag <tag>: Prefixes every log entry with a recognisable string identifier (such as a script name or pipeline phase), allowing effortless filtering in log viewers.
• -i, --id[=<PID>]: Records the process ID of the logger instance or an explicitly provided parent script PID.
• -s, --stderr: Duplicates the formatted message to standard error, ensuring terminal operators see real-time output while the log is simultaneously recorded.
• -u, --socket <socket>: Routes the message to an explicit Unix domain socket path rather than the default /dev/log.
• -n, --server <host> & -P, --port <port>: Bypasses the local machine’s logging daemon entirely to transmit log datagrams across the network to a remote collector.
• -T, --tcp & -d, --udp: Chooses between reliable TCP streaming or lightweight UDP datagram transport when routing logs over a network.
• --rfc5424[=<format>]: Formats the payload according to the strict RFC 5424 standard, unlocking microsecond-accurate timestamps and structured data parameters.
• --sd-id <name> & --sd-param <key=val>: Injects machine-readable key-value pairs into the log header, allowing search platforms like Elasticsearch to index attributes instantly.
• --no-act: Executes a dry-run test, displaying the fully structured log string on standard error without dispatching it to any socket.

Architectural Foundations: Sockets, Facilities, and Syslog Framing

To use logger effectively in mission-critical environments, it helps to understand the underlying mechanics of how Unix systems classify and transmit events.

Syslog Priority (PRI) Calculation

Every syslog message carries an integer priority code (PRI) that encapsulates both who generated the event (the facility) and how severe it is (the severity level). The mathematical formula is simple:

The /dev/log Unix Domain Socket

Under standard Unix conventions, applications write log messages to the standard C library interface syslog(3), which communicates with the system logger via a local Unix domain socket located at /dev/log.

In modern Linux systems powered by systemd, /dev/log is actually a symlink to /run/systemd/journal/dev-log. When logger sends a datagram across this socket, the systemd-journald.service(8) daemon intercepts the message. Crucially, the kernel enriches this datagram with trusted metadata—such as the caller’s real User ID (_UID), Process ID (_PID), SELinux security context, and originating systemd unit—making it impossible for unprivileged scripts to forge their identity.

RFC 3164 vs. RFC 5424 Syslog Standards

Logging standards have evolved significantly over time. The historical standard, RFC 3164 (often called "BSD Syslog"), is lightweight but lacks essential detail: its timestamps omit timezone offsets and years, hostnames can truncate unpredictably, and log bodies are completely unstructured text:

RFC 3164 Format:
<34>Oct 11 22:14:15 srv-app01 myapp[1234]: Transaction 9874 failed

Modern infrastructure demands the precision of RFC 5424. This standard establishes a rigid, non-ambiguous structure featuring microsecond-precision ISO 8601 timestamps, explicit protocol versions, and structured key-value parameters:

RFC 5424 Format:
<34>1 2026-08-18T08:04:15.123456+00:00 srv-app01 myapp 1234 ID47 [audit@32473 user="admin" ip="10.0.4.1"] Transaction 9874 failed

With logger, your shell scripts can emit fully compliant RFC 5424 telemetry with a single command-line flag.

Five Real-World Production Use Cases

1. Standardising Script Error Handling with POSIX Trap Handlers

The Operational Scenario

A mission-critical schema migration script runs unattended in an automated provisioning pipeline. When unexpected runtime errors occur—such as a network glitch or a full disk—standard shell scripts crash silently without recording diagnostic context. You need an automated harness that intercepts any abnormal script termination, captures the exact line number and exit code, and emits a high-priority alert into the system journal.

Production Implementation

Save the following script as /usr/local/bin/deploy-schema.sh:

#!/usr/bin/env bash
set -Eeuo pipefail

# Initialize Script Context
readonly SCRIPT_NAME="SCHEMA_MIGRATE"
readonly SCRIPT_PID="$$"
readonly START_TIME=$(date +%s)

# Global Telemetry Dispatcher Function
log_telemetry() {
    local severity="$1"
    local message="$2"
    logger -p "local3.${severity}" \
           -t "${SCRIPT_NAME}" \
           --id="${SCRIPT_PID}" \
           -- "${message}"
}

# Automated Failure Trap Handler
trap_handler() {
    local exit_code="$?"
    local line_no="$1"
    local end_time=$(date +%s)
    local duration=$(( end_time - START_TIME ))

    if [[ "${exit_code}" -ne 0 ]]; then
        log_telemetry "crit" "CRITICAL: Script execution aborted at line ${line_no} with exit code ${exit_code}. Elapsed time: ${duration}s."
    else
        log_telemetry "notice" "SUCCESS: Pipeline completed without error. Total execution time: ${duration}s."
    fi
}

trap 'trap_handler ${LINENO}' EXIT

log_telemetry "info" "Starting migration sequence for cluster: prod-db-replica-01."

# Simulated failure: Attempting to query an unreachable database endpoint
if ! nc -z -w 2 192.0.2.50 5432; then
    log_telemetry "err" "Target database endpoint 192.0.2.50:5432 unreachable. Initiating abort."
    exit 28
fi

Executing the Workflow and Inspecting Journal Output

/usr/local/bin/deploy-schema.sh || true
journalctl -t SCHEMA_MIGRATE --output=verbose -n 3

Tue 2026-08-18 08:05:02.102941 UTC [s=a1b2c3d4e5...;i=492;b=...;m=...;t=...;x=...] srv-node01 SCHEMA_MIGRATE[29384]: Starting migration sequence for cluster: prod-db-replica-01.
    PRIORITY=6
    SYSLOG_FACILITY=19
    SYSLOG_IDENTIFIER=SCHEMA_MIGRATE
    SYSLOG_PID=29384
    _PID=29385
    _COMM=logger
    _UID=0
    _SYSTEMD_UNIT=session-1.scope

Tue 2026-08-18 08:05:04.148912 UTC [s=f6e5d4c3b2...;i=493;b=...;m=...;t=...;x=...] srv-node01 SCHEMA_MIGRATE[29384]: Target database endpoint 192.0.2.50:5432 unreachable. Initiating abort.
    PRIORITY=3
    SYSLOG_FACILITY=19
    SYSLOG_IDENTIFIER=SCHEMA_MIGRATE
    SYSLOG_PID=29384

Tue 2026-08-18 08:05:04.150122 UTC [s=0a9b8c7d6e...;i=494;b=...;m=...;t=...;x=...] srv-node01 SCHEMA_MIGRATE[29384]: CRITICAL: Script execution aborted at line 37 with exit code 28. Elapsed time: 2s.
    PRIORITY=2
    SYSLOG_FACILITY=19
    SYSLOG_IDENTIFIER=SCHEMA_MIGRATE
    SYSLOG_PID=29384

Line-by-Line Telemetry Breakdown

• PRIORITY=2: Automatically decoded by systemd-journald from the local3.crit flag (Facility 19 * 8 + Level 2 = PRI 154).
• SYSLOG_FACILITY=19: Confirms the event is isolated to the local3 custom facility, preventing pollution of standard system daemon logs.
• SYSLOG_IDENTIFIER=SCHEMA_MIGRATE: Custom tag that makes querying simple across a cluster using journalctl -t SCHEMA_MIGRATE.
• SYSLOG_PID=29384: The parent script's PID injected via --id="${SCRIPT_PID}", tying together every log entry generated across the script's lifespan.
• _COMM=logger: Kernel-verified attribute identifying the binary that made the socket write.

What the Admin Does Next

The on-call engineer reads the exact failure point (line 37) and exit code (28), immediately recognising a network connectivity failure to 192.0.2.50:5432. Instead of guessing or digging through application code, they pivot straight to investigating firewall rules and network routing.

2. Streaming Multi-Line Application Pipelines into systemd-journald

The Operational Scenario

A proprietary analytics engine (compute-engine) outputs diagnostic records across both standard output and standard error. It lacks native syslog support and was previously writing raw text to an unmonitored flat file on disk, eventually causing disk space alarms. You need to stream both output streams in real time into systemd-journald, mapping standard output to daemon.info and standard error to daemon.err while preserving line buffering.

Production Implementation

Execute the process pipeline using process substitution and stream redirection:

#!/usr/bin/env bash
# Real-time multi-stream log piping harness

# Set up dedicated logging pipes
exec > >(logger -p daemon.info -t "COMPUTE_STDOUT" --id=$$)
exec 2> >(logger -p daemon.err  -t "COMPUTE_STDERR" --id=$$)

echo "Initializing multi-threaded compute worker pool..."
echo "Worker thread 04 failed memory allocation verification!" >&2
echo "Worker pool initialized with 15 active nodes."

Alternatively, when managing this application under a systemd unit, configure /etc/systemd/system/compute-engine.service:

[Unit]
Description=High-Throughput Analytics Engine
After=network.target

[Service]
Type=simple
ExecStart=/opt/bin/compute-engine --verbose
StandardOutput=journal
StandardError=journal
SyslogIdentifier=COMPUTE_ENGINE
SyslogFacility=daemon
SyslogLevel=info
SyslogLevelPrefix=true

[Install]
WantedBy=multi-user.target

Executing the Pipeline and Viewing Journal Interception

journalctl -u compute-engine.service -o json-pretty -n 2

{
    "__CURSOR" : "s=1234567890abcdef...",
    "__REALTIME_TIMESTAMP" : "1787040304123456",
    "_BOOT_ID" : "9876543210fedcba...",
    "_TRANSPORT" : "stdout",
    "_PID" : "31405",
    "_UID" : "1001",
    "_SYSTEMD_UNIT" : "compute-engine.service",
    "SYSLOG_IDENTIFIER" : "COMPUTE_ENGINE",
    "PRIORITY" : "3",
    "MESSAGE" : "Worker thread 04 failed memory allocation verification!"
}

Line-by-Line Telemetry Breakdown

• _TRANSPORT="stdout": Confirms that systemd-journald captured the log stream via standard output redirection rather than a direct socket API call.
• PRIORITY="3": Because SyslogLevelPrefix=true was enabled, journald automatically parsed the error stream and tagged the record with priority 3 (Error).
• SYSLOG_IDENTIFIER="COMPUTE_ENGINE": Unifies stdout and stderr under a single searchable namespace.

What the Admin Does Next

The administrator creates an automated filter rule with journalctl -u compute-engine.service -p err --since "1 hour ago" or configures a log forwarder (such as Vector or Fluentbit) to alert whenever PRIORITY=3 entries appear.

3. Emitting Structured RFC 5424 Telemetry for SIEM Compliance

The Operational Scenario

Under compliance frameworks such as SOC2 and PCI-DSS, privileged security events—such as TLS certificate renewals and credential revocations—must be recorded using machine-readable key-value pairs containing actor identities, source IP addresses, and unique event IDs. Free-text log strings fail automated SIEM parsing. You need to emit fully compliant RFC 5424 messages containing structured enterprise data.

Production Implementation

Execute the following logger command using structured data flags:

logger --rfc5424 \
       -p authpriv.notice \
       -t SEC_VAULT \
       --id="$$" \
       --msgid="AUTH_CERT_ROTATION" \
       --sd-id "auditEvent@41058" \
       --sd-param actor="svc_deploy_bot" \
       --sd-param target_cert="api.internal.corp" \
       --sd-param finger_sha256="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" \
       --sd-param source_ip="10.240.12.88" \
       -- "TLS Certificate successfully renewed and distributed to edge ingress proxies."

Inspecting the Wire-Level Datagram

Inspecting the inbound socket using a debugging tap reveals the exact formatted datagram emitted across the wire:

<85>1 2026-08-18T08:05:30.412891+00:00 srv-app-gateway-01 SEC_VAULT 32104 AUTH_CERT_ROTATION [auditEvent@41058 actor="svc_deploy_bot" target_cert="api.internal.corp" finger_sha256="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" source_ip="10.240.12.88"] TLS Certificate successfully renewed and distributed to edge ingress proxies.

Line-by-Line Telemetry Breakdown

• <85>1: Priority code 85 (authpriv facility value 10 * 8 + notice severity 5), immediately followed by syslog protocol version 1.
• 2026-08-18T08:05:30.412891+00:00: ISO 8601 timestamp with microsecond accuracy and explicit UTC offset, eliminating chronological ambiguity across global data centres.
• srv-app-gateway-01: Fully qualified hostname resolved by logger.
• SEC_VAULT 32104 AUTH_CERT_ROTATION: Conveys application tag, process ID, and message ID in standard positional fields.
• [auditEvent@41058 ... ]: Structured data block. The number @41058 is an IANA Private Enterprise Number (PEN) ensuring parameter names never conflict across different vendor schemas.
• actor="svc_deploy_bot": Key-value attributes immediately indexed by log platforms without brittle regex parsing.

What the Admin Does Next

The security team writes an automated SIEM detection query keyed directly on MSGID == "AUTH_CERT_ROTATION" and actor != "svc_deploy_bot" to flag any unauthorised certificate changes instantly.

4. Forwarding Out-of-Band Audit Manifests over TCP During Server Decommissioning

The Operational Scenario

During automated bare-metal server decommissioning, local storage filesystems are unmounted and local system daemons (including systemd-journald) are stopped. Before physical drive sanitisation begins, the decommissioning script must transmit a cryptographically signed hardware audit manifest directly to a central syslog collector over the corporate network. Because local logging is offline, logger must bypass /dev/log and establish a direct TCP connection.

Production Implementation

Save the following routine as part of the decommissioning harness:

#!/usr/bin/env bash
set -Eeuo pipefail

REMOTE_SIEM="syslog-collector.mgmt.internal"
SIEM_PORT="6514"
AUDIT_FILE="/root/sanitization-manifest.json"

if [[ ! -f "${AUDIT_FILE}" ]]; then
    echo "Manifest missing. Aborting." >&2
    exit 1
fi

echo "Transmitting final hardware sanitization manifest to remote SIEM..."

# Stream sanitized JSON manifest over TCP
logger --server "${REMOTE_SIEM}" \
       --port "${SIEM_PORT}" \
       --tcp \
       --priority local7.emerg \
       --tag "DECOM_AUDIT" \
       --id="$$" \
       --file "${AUDIT_FILE}"

echo "Telemetry dispatch verified. Proceeding with block device wipe."

Remote Collector Output (/var/log/remote/decom.log)

Aug 18 08:05:45 srv-blade-09 DECOM_AUDIT[4102]: {"timestamp": "2026-08-18T08:05:40Z", "node_uuid": "4a7b9c1d-8e2f-4a0b-9c3d-1e2f3a4b5c6d", "action": "NIST_SP_800_88_PURGE", "operator": "automation_agent_v3", "drives": ["/dev/nvme0n1", "/dev/nvme1n1"], "status": "PENDING_ERASURE"}

Line-by-Line Telemetry Breakdown

• --server ... --port ... --tcp: Instructs logger to create a direct network socket and perform a TCP three-way handshake with the remote collector, bypassing /dev/log.
• --priority local7.emerg: Marks the payload with maximum severity (Level 0), prompting immediate disk flushes on the central server.
• --file "${AUDIT_FILE}": Directs logger to read directly from disk and transmit the file contents line by line without spawning subshell expansions like cat.

What the Admin Does Next

The infrastructure engineer checks the central management console to verify receipt of the JSON payload before issuing the final cryptographic wipe command to the NVMe controllers.

5. Testing Logging Sockets and Validating CI/CD Golden Images

The Operational Scenario

An infrastructure team uses Packer and Ansible to build hardened operating system golden images. Before certifying an image for production deployment, the CI/CD pipeline must verify that: 1. The /dev/log socket is active, valid, and accepting datagrams. 2. Security policies (SELinux or AppArmor) do not prevent unprivileged processes from logging. 3. Log parsing and syntax verification can be tested safely in dry-run mode.

Production Implementation

Create the automated verification script /opt/ci/test-logging-pipeline.sh:

#!/usr/bin/env bash
set -Eeuo pipefail

echo "=================================================="
echo " STAGE 1: Dry-Run Syntax and Header Validation   "
echo "=================================================="

# Test logger parsing logic without sending a message across the socket
logger --no-act \
       --stderr \
       --rfc5424 \
       -p local0.debug \
       -t CI_PROBE \
       --sd-id "test@12345" \
       --sd-param run_id="build-9821" \
       "CANARY_PAYLOAD_VALIDATION"

echo -e "\n=================================================="
echo " STAGE 2: Live Socket Injection & Verification   "
echo "=================================================="

CANARY_UUID="canary-$(uuidgen)"
TEST_SOCKET="/dev/log"

if [[ ! -S "${TEST_SOCKET}" ]]; then
    echo "FATAL: Target socket ${TEST_SOCKET} does not exist or is not a socket!" >&2
    exit 2
fi

# Transmit unique canary payload
logger -u "${TEST_SOCKET}" \
       -p local0.info \
       -t "CI_CANARY" \
       "VALIDATION_TOKEN=${CANARY_UUID}"

# Sleep briefly to ensure systemd-journald processes the datagram
sleep 0.5

# Query systemd-journald for exact token match
if journalctl -t "CI_CANARY" -n 5 | grep -q "${CANARY_UUID}"; then
    echo "SUCCESS: Logging pipeline verified. Canary token [${CANARY_UUID}] successfully committed."
    exit 0
else
    echo "FAILURE: Canary token was not found in journald database!" >&2
    exit 3
fi

Executing the CI Validation Pipeline

/opt/ci/test-logging-pipeline.sh

==================================================
 STAGE 1: Dry-Run Syntax and Header Validation   
==================================================
<135>1 - - CI_PROBE - - [test@12345 run_id="build-9821"] CANARY_PAYLOAD_VALIDATION

==================================================
 STAGE 2: Live Socket Injection & Verification   
==================================================
SUCCESS: Logging pipeline verified. Canary token [canary-f81d4fae-7dec-11d0-a765-00a0c91e6bf6] successfully committed.

Line-by-Line Telemetry Breakdown

• logger --no-act --stderr: Validates option parsing and outputs the exact formatted wire string to stderr without connecting to any socket.
• -u "${TEST_SOCKET}": Explicitly directs the test payload to /dev/log, immediately exposing broken symlinks or missing socket endpoints.
• journalctl -t "CI_CANARY": Validates that the entire path—from socket write to journal storage indexing—succeeded seamlessly.

What the Admin Does Next

This test script is configured as an automated gate in the CI/CD pipeline; if it returns a non-zero exit code, the machine image build fails automatically before broken configurations can reach production.

Command Usage Reference

What Can Go Wrong: Architectural Pitfalls and Mitigations

Even a lightweight, venerable utility like logger can cause stability issues if deployed without understanding system buffers and process execution overhead.

1. The Remote TCP Blocking Trap

When logger connects directly to a remote syslog server using -T, --tcp, it initiates a synchronous network connection. If the remote server experiences an outage, severe latency, or silent firewall packet drops, the logger process will block in the kernel's connect() or write() syscall until the TCP timeout expires—which can take several minutes under standard Linux settings. If this occurs inside a script, your entire deployment pipeline will freeze.

Prevention and Remediation

Avoid synchronous remote TCP logging in latency-critical scripts. Instead, write logs locally to /dev/log and let dedicated background daemons (such as systemd-journald, rsyslog, or Vector) handle disk buffering, retries, and network forwarding. If direct network dispatch is unavoidable, isolate the command in a background subshell:

# Isolate remote network logging in a detached subshell
( logger --server 192.0.2.100 --port 514 --tcp -p local0.info "Network Event" ) &

2. Subshell Fork Bombing from Unbounded Shell Loops

A common mistake is reading large files line by line in a bash while loop and invoking logger on every iteration:

# DANGEROUS ANTI-PATTERN: DO NOT USE IN PRODUCTION
cat /var/log/massive-dump.csv | while read -r line; do
    logger -p local0.info "${line}" # Spawns thousands of distinct processes
done

This antipattern executes a separate fork(), execve(), socket allocation, and close() sequence for every single line. On a 100,000-line file, this will spawn 100,000 distinct processes, causing massive CPU context-switching overhead, exhausting process IDs (PIDs), and potentially triggering the Linux Out-Of-Memory (OOM) killer.

Prevention and Remediation

Always stream data into a single, long-running logger process using standard input redirection or the --file parameter:

# Efficient single-process execution
logger -p local0.info -t "DATA_INGEST" --file /var/log/massive-dump.csv

# Or stream directly through a single pipe:
cat /var/log/massive-dump.csv | logger -p local0.info -t "DATA_INGEST"

In this mode, logger opens a single socket connection, maintains internal line buffers, and streams data efficiently.

3. Silent Message Truncation under Legacy Syslog Limits

When emitting logs without the --rfc5424 flag on older systems, messages adhere to the legacy RFC 3164 standard, which imposes a strict maximum packet size:

Prevention and Remediation

When logging JSON blobs, long stack traces, or comprehensive audit trails: 1. Always enable modern framing with the --rfc5424 flag, ensuring at least 2048 bytes of buffer capacity (with most modern receivers supporting up to 64KB). 2. Log directly to systemd-journald via /dev/log to eliminate arbitrary length truncations entirely. 3. Validate payload lengths in CI using logger --no-act --stderr.

Authoritative References and Technical Documentation

To explore the underlying kernel interfaces, specifications, and architecture in greater depth, consult these authoritative resources:

• logger(1) — Linux Manual Page (man7.org): The definitive reference manual for the util-linux logger command.
• RFC 5424 — The Syslog Protocol (IETF Datatracker): The official IETF standard for modern structured system logging.
• RFC 3164 — The BSD Syslog Protocol (IETF Datatracker): The historical BSD syslog specification detailing legacy constraints.
• systemd-journald.service(8) Manual Page: Reference covering systemd's unified event-collection subsystem.
• syslog(3) — Linux Programmer's Manual: Detailed documentation of the C standard library logging interface.
• ArchWiki: Systemd/Journal Guide: An extensive practical and architectural guide to Linux system logging.

Today's Takeaway

The difference between a fragile amateur script and dependable infrastructure software comes down to how it handles observability. In the next five minutes, pick the most important custom shell script, maintenance cron job, or deployment task on your machine, and replace its fragile echo "something broke" >> /tmp/error.log redirects with logger -p local0.err -t "DEPLOY" --id=$$ "$MESSAGE". By plugging your shell scripts directly into the operating system’s native logging socket, you transform disposable terminal output into permanent, searchable, and structured system telemetry—ensuring that when the next 2am alert arrives, you'll never be left searching in the dark again.