lxc-start(1)

πŸ’– lxc-start(1) β€” like, the manual page but make it make sense πŸ’–

okay bestie, sit down, hydrate, and let me tell you about lxc-start from the lxc-start(1) manual. this is the one that actually boots your container. main character energy fr fr. 🫢


✨ NAME ✨

lxc-start β€” run an application inside a container.


🌸 SYNOPSIS 🌸

lxc-start {-n name} [-f config_file] [-c console_device] [-L
          console_logfile] [-d] [-F] [-p pid_file] [-s KEY=VAL] [-C]
          [--share-[net|ipc|uts] name|pid] [command]

like… yes, that's a lot of brackets. it's giving "choose your own adventure" and honestly? we love that for us. πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

so lxc-start runs the command you give it inside the container you picked with name. that's the whole vibe.

it sets the container up following the config you already made with lxc-create, or the config file you hand it through the parameter. and if there's no config at all? no stress β€” the default isolation gets used. lowkey iconic. ✨

and if you don't pass a command? lxc-start goes looking at lxc.init.cmd, and if that's not set either, it falls back to the default /sbin/init command, which is how you boot an actual system container. periodt. πŸ‘‘


πŸ’œ OPTIONS πŸ’œ

  • -d, --daemon β€” run the container as a daemon. heads up bestie: since the container has no more tty, if an error happens nothing will be displayed 😭 β€” you gotta go read the log file to check the error. (and plot twist: this is the default mode)
  • -F, --foreground β€” run the container in the foreground. in this mode the container console gets attached to your current tty, and signals get routed directly to the container. so like, it's right there with you. 🫢
  • -p, --pidfile pid_file β€” creates a file with the process id in it. cute little receipt of what's running.
  • -f, --rcfile config_file β€” specify the configuration file that configures the virtualization and isolation functionalities for the container.

and listen: this configuration file, if present, will be used even if there is already a configuration file present in the previously created container (the one you made via lxc-create). so it overrides, no cap.

  • -c, --console console_device β€” specify a device to use for the container's console, for example /dev/tty8. if you don't specify this option, the current terminal will be used β€” unless -d is specified.
  • -L, --console-log console_logfile β€” specify a file to log the container's console output to. so you can read what happened later. πŸ“
  • -s, --define KEY=VAL β€” assign value VAL to configuration variable KEY. this overrides any assignment done in config_file. yeah, it goes hard on purpose.
  • -C, --close-all-fds β€” if any file descriptors are inherited, close them. and if you don't specify this option, then lxc-start will exit with failure instead. 😬 Note: --daemon implies --close-all-fds.
  • --share-net name|pid β€” inherit a network namespace from a name container or a pid. the network namespace will continue to be managed by the original owner. the network configuration of the starting container is ignored, and the up/down scripts won't be executed. so… yeah, keep that in mind.
  • --share-ipc name|pid β€” inherit an IPC namespace from a name container or a pid.
  • --share-uts name|pid β€” inherit a UTS namespace from a name container or a pid. the starting LXC will not set the hostname β€” but the container OS may do it anyway. little gremlin behavior, we respect it. πŸ™ˆ

🌈 COMMON OPTIONS 🌈

these options are common to most of the lxc commands. so they show up everywhere, like that one friend who's at every party. πŸ’–

  • -?, -h, --help β€” print a longer usage message than normal.
  • --usage β€” give the usage message.
  • -q, --quiet β€” mute on πŸ”‡
  • -P, --lxcpath=PATH β€” use an alternate container path. the default is /var/lib/lxc.
  • -o, --logfile=FILE β€” output to an alternate log FILE. the default is no log.
  • -l, --logpriority=LEVEL β€” set log priority to LEVEL. the default log priority is ERROR. possible values are: FATAL, ALERT, CRIT, WARN, ERROR, NOTICE, INFO, DEBUG, TRACE.
note that this option is setting the priority of the events log in the alternate log file. it do not have effect on the ERROR events log on stderr. (yes, i copied that grammar exactly, it's part of the lore now πŸ’€)
  • -n, --name=NAME β€” use container identifier NAME. the container identifier format is an alphanumeric string.
  • --rcfile=FILE β€” specify the configuration file to configure the virtualization and isolation functionalities for the container.

and same tea as before: this configuration file if present will be used even if there is already a configuration file present in the previously created container (via lxc-create).

  • --version β€” show the version number. slay.

πŸ”₯ DIAGNOSTIC πŸ”₯

  • The container is busy β€” the specified container is already running an application. you should stop it before reuse this container or create a new one. like, it's occupied bestie, knock first. πŸšͺ

πŸ‘‘ 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)


aaaaand that's the whole page!! this one came from the lxc-start(1) manual, dated 2026-09-15 β€” go forth and start containers, you absolute legend. πŸ’…βœ¨πŸ¦‹

πŸ“¦ where this page comes from