lxc-autostart(1)
π lxc-autostart(1) β the manual, but make it make sense
okay so bestie, this is the page for lxc-autostart, from the lxc-autostart(1) manual. it's literally the tool that handles your auto-started containers at boot and shutdown, and honestly? it's giving project manager energy. let's get into it π«Ά
β¨ NAME β¨
lxc-autostart β start/stop/kill auto-started containers, no cap π₯
πΈ SYNOPSIS πΈ
lxc-autostart [-k] [-L] [-r] [-s] [-a] [-A] [-g groups] [-t timeout]
that's the whole vibe. short, iconic, does what it says π
π¦ DESCRIPTION π¦
so lxc-autostart processes containers that have lxc.start.auto set. that's the whole assignment. it lets you start, shutdown, kill, and restart containers in the right order, waiting the right amount of time β which is honestly so much more than most tools do for you, we love a considerate icon π
it supports filtering by lxc.group, or you can just run it against all defined containers if that's the mood. it can also be used by external tools in list mode, where literally no action gets performed and instead you just get shown the list of affected containers (and, if relevant, delays). very "here's your lineup, no notes" energy β¨
now, the options that pick the action are [-r], [-s], and [-k]. if none of them is specified, then the containers will be started β that's the default, main character behaviour. π
[-a] and [-g] are the ones that say which containers get affected. by default, only containers without a lxc.group set will be affected (iykyk β the NULL group thing, we'll get there).
and [-t TIMEOUT] specifies the maximum amount of time to wait for the container to complete the shutdown or reboot. patience is a virtue, but it does have a limit, periodt β³
π OPTIONS π
-r,--rebootβ request a reboot of the container. just a request, bestie, it's asking nicely π-s,--shutdownβ request a clean shutdown. BUT β and this is the important bit β if a[-t timeout]greater than 0 is given and the container has not shut down within this period, it will be killed as with the[-k kill]option. so it's polite until the clock runs out ππ-k,--killβ rather than requesting a clean shutdown of the container, explicitly kill all tasks in the container. no negotiating, no goodbye speech, just vibes removed πͺ¦-L,--listβ rather than performing the action, just print the container name and wait delays until starting the next container. it's the "show me the plan, don't do the plan" option πβ¨-t,--timeout TIMEOUTβ waitTIMEOUTseconds before hard-stopping the container. countdown mode activated β±οΈ-g,--groups GROUPβ comma separated list of groups to select (defaults to those without alxc.groupβ the NULL group). okay so this one has layers, stay with me:- this option may be specified multiple times, and the arguments get concatenated π§΅
- the NULL or empty group may be specified as a leading comma, trailing comma, embedded double comma, or empty argument where the NULL group should be processed π«Ά
- groups are processed in the order specified on the command line
- multiple invocations of the
-goption may be freely intermixed with the comma separated lists and will be combined in specified order β so go off, mix and match, it's all tracked π
-a,--allβ ignorelxc.groupand select all auto-started containers. everyone's invited to this party π-A,--ignore-autoβ ignore thelxc.start.autoflag. combined with-a, this will select all containers on the system. yes, all of them. absolutely everyone. no filtering, no chill π
π§ AUTOSTART AND SYSTEM BOOT π§
the lxc-autostart command is used as part of the LXC system service, when enabled to run on host system at bootup and at shutdown. it's the one that selects which containers to start, in what order, and how much to delay between each startup when the host system boots. honestly? logistics queen π
each container can be part of any number of groups, or no group at all. and two groups are special:
- the NULL group β i.e. the container does not belong to any group π«₯
- the
"onboot"group β the β¨ special β¨ one π
here's the boot sequence, and it's lowkey a whole choreography:
- when the system boots with the LXC service enabled, it will first attempt to boot any containers with
lxc.start.auto == 1that are a member of the"onboot"group. - the startup will be in order of
lxc.start.order. - if an
lxc.start.delayhas been specified, that delay will be honored before attempting to start the next container β giving the current container time to begin initialization and reducing overloading the host system π (thoughtful!!) - after starting the members of the
"onboot"group, the LXC system will proceed to boot containers withlxc.start.auto == 1which are not members of any group (the NULL group) β and proceed as with the onboot group.
so yeah. onboot first, NULL group second, delays respected, host not overloaded. slay. β¨
π STARTUP GROUP EXAMPLES π
real examples, because reading is one thing and seeing is another:
-g "onboot,"β start the"onboot"group first, then the NULL group. this is the equivalent of:-g onboot -g "".-g "dns,web,,onboot"β starts the"dns"group first, the"web"group second, then the NULL group, followed by the"onboot"group. this is the equivalent of:-g dns,web -g ,onbootor-g dns -g web -g "" -g onboot.
see? the double comma is doing real work there. iconic behaviour honestly π
π₯ SEE ALSO π₯
lxc(7), lxc-create(1), lxc-copy(1), lxc-destroy(1), lxc-start(1), lxc-stop(1), lxc-execute(1), lxc-console(1), lxc-monitor(1), lxc-wait(1), lxc-cgroup(1), lxc-ls(1), lxc-info(1), lxc-freeze(1), lxc-unfreeze(1), lxc-attach(1), lxc.conf(5)
the whole friend group, go say hi π«Ά
ngl bestie, if you're scripting this at boot, double-check your group order and your timeouts.-kdoes not ask nicely, and-Acombined with-areally will go after every container on the system. no take-backs π
and that's the page!! source/version and date energy for the sign-off: this was the lxc-autostart(1) page dated 2026-05-01. mwah π go start some containers responsibly, ily π¦π
π¦ where this page comes from
- alpine 3.24: lxc-doc 7.0.0-r0 Β· LGPL-2.1-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms