Startup Programs
Start programs once when a Sweets session becomes ready.
sweets.exec_once(command) starts a program once per Sweets session.
sweets.exec_once("waybar")
sweets.exec_once("veila")
sweets.exec_once("awww-daemon")Each argument is a non-empty shell command. Commands run in order, after Sweets
opens its Wayland socket and initializes IPC. They inherit WAYLAND_DISPLAY,
SWEETS_SOCKET, and any sweets.env
variables.
These run at startup only. Reloading sweets.lua changes the commands for the
next session but does not launch, stop, or restart anything in the current one.
Cleanup on logout
With systemd, each exec_once program in a real login session runs in a
per-session slice (sweets-session-<WAYLAND_DISPLAY>.slice) and stops
automatically at logout. This includes daemons that fork into the background, so
none survive into your next login.
This needs a systemd boot, a live user manager, and systemd-run. It also only
applies to a real login session — one started by sweets-session on a TTY or
through a display manager. A nested Sweets run spawns its programs directly and
never touches systemd units, so testing nested cannot stop your outer session's
daemons.
Without systemd (Artix with runit/OpenRC/dinit, or a missing user manager),
exec_once still starts every program. Sweets supervises the launched process
session and asks it to stop on clean shutdown, then forces termination after a
bound. This reaches descendants still in the process group.
A command that exits after backgrounding a daemon, or one that fully daemonizes into a new session, escapes portable tracking. Such daemons may still need logout scripting. Systemd slices remain the stronger cleanup path.
The systemd-managed session also starts standard XDG autostart entries.
Configure a program in one place only — its .desktop entry or
sweets.exec_once(...) — or it can start twice.