Services and day-to-day operations
This page describes an installed native deployment. Use Installation to create it, Upgrade to change versions, and Docker installation for Compose. Do not install duplicate CRON entries beside the timers.
Native units
| Unit | Purpose | Shipped schedule |
|---|---|---|
lbt-web.service | Web application | Continuous |
lbt-pipeline.service / .timer | Fetch, ingest, automatic processing and footprint intersections, in order | After boot, then hourly, with a small random delay |
lbt-integration.service / .timer | Checked or executed integration according to configuration | 03:30 Europe/Paris, plus up to 5 minutes |
lbt-segmentation.service / .timer | Optional nightly sections rebuild | 04:15 Europe/Paris, plus up to 5 minutes |
lbt-cleaning.service / .timer | Supported cache and metadata cleanup | 05:30 Europe/Paris, plus up to 5 minutes |
lbt-email-digests.service / .timer | Examine due email summaries | Five minutes after boot / previous completion |
Integration also requests segmentation after its execution. Ordering directives do not themselves launch the pipeline or prove new data exists. The installed unit and local overrides determine the effective schedule. The user account's time zone has no effect on these timers.
The integration timer does not catch up automatically on activation (Persistent=false). Segmentation and cleaning timers are persistent. A oneshot service being inactive after success is normal; inspect its result and its timer.
Read status and journals
sudo systemctl list-timers --all 'lbt-*'
sudo systemctl show lbt-integration.service -p Result -p ExecMainStatus
sudo journalctl -u lbt-integration.service -n 100 --no-pager
sudo journalctl -u lbt-segmentation.service -n 100 --no-pager
sudo journalctl -u lbt-pipeline.service -n 100 --no-pager
The integration unit treats exit 2 as an accepted business outcome. Confirm outcome, blockers and commit_confirmed in the report. Systemd success alone is not proof that all roots were integrated. Segmentation has its own result, even when invoked from the integration unit.
Configuration and files
.env.production.local: protected shared production configuration for web and jobs..env.development.local: development environment only..env.local: generated public version metadata, not a secret store..env.db: additional Docker database/Compose configuration.osm/integration/runs/: integration and segmentation evidence, under the application directory.
Use literal values as described in Installation; do not source the shared env file as a shell script. Reapply the documented permissions after replacing builds or dependencies. No additional digest env file is required by the current native procedure.
Cleaning and retention
The cleaning script removes eligible unused contributor/changeset metadata while preserving references from current changes and history. Its file cleanup is limited to old .log files in log/, .xml files in osm/changeset/ and .osc files in osm/osc_update/ according to retention settings.
It does not purge osm/source/, the replication queue files or osm/integration/runs/. Plan storage monitoring and evidence archiving separately. Do not infer automatic retention of every directory from a similarly named setting.
Operational routine
Check replication progress, failed/uncertain integrations, oldest blockers, segmentation freshness, email-worker activity and free disk space. Back up database and protected configuration together with the evidence needed for recovery. A successful backup command is not a substitute for periodically verifying restoration.