From 9d280168ccc67309ede60df194b8a830a164cf71 Mon Sep 17 00:00:00 2001 From: Sam Pointon Date: Fri, 26 Jun 2026 22:18:46 +0100 Subject: [PATCH] nixos/getty: allow disabling https://github.com/NixOS/nixpkgs/pull/480686 made getty unconditional, fixing several bugs and bad interactions. This imposes no runtime costs due to lazy systemd-based activation, but it does drag getty and its closure in to images. For many NixOS installations, this is fine - they want console login and such anyway - but it's a burden on lights-out containers aiming for minimal image sizes. This change adds a new configuration knob to totally disable getty for these sorts of headless/lights-out/appliance-style set-ups. The option's description is deliberately made stern to hopefully dissuade anyone from toggling it if their system isn't in that class. As the option defaults to enabling getty, there should be no behaviour change for anyone not explicitly opting themselves in - hopefully with full knowledge of the consequences. My local testing chopped a whole 15% off one of my images by being able to remove getty (the big contributor being util-linux and its friends), and that's just for one random image - others might be even bigger relative gains. I think that's more than enough to justify this configuration knob. I had a look for uses of getty in NixOS to see if anywhere wanted to either have a hard dependency on getty and hence explicitly enable it (so that weird configurations get picked up at evaluation time rather than runtime) or disable it. The use sites fall into two categories: 0. Virtualised set-ups that wire up units to getty listening on ttyS0. These probably don't want a hard dependency: it's reasonable to run these lights-out, and just disabling getty will DTRT here. 1. `modules/profiles/headless.nix`, which disables some of the getty units. This _could_ instead disable getty as a whole, but that might break e.g. `machinectl shell`, and I can imagine set-ups where you want that even without console login, so I have left it alone. Maybe someone else feels differently and more strongly, and then that someone else can put together a PR and argue their case. --- nixos/modules/services/ttys/getty.nix | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/nixos/modules/services/ttys/getty.nix b/nixos/modules/services/ttys/getty.nix index e8116920be47..693716e738d7 100644 --- a/nixos/modules/services/ttys/getty.nix +++ b/nixos/modules/services/ttys/getty.nix @@ -76,6 +76,24 @@ in ''; }; + enable = mkOption { + type = types.bool; + default = true; + description = '' + Include getty in the system. + + getty is quiescent until called into action and does not have + runtime costs if it is not used. The benefit of disabling it is + in reducing closure size. + + Disabling getty means that console login may not be possible, + `machinectl shell` and `login` may not work, and other ills. + It is only recommended for lights-out, headless containers, + appliances, and similar configurations not meant for any human + interaction ever. + ''; + }; + loginProgram = mkOption { type = types.path; default = "${pkgs.shadow}/bin/login"; @@ -133,7 +151,7 @@ in ###### implementation - config = { + config = mkIf cfg.enable { # Note: this is set here rather than up there so that changing # nixos.label would not rebuild manual pages services.getty.greetingLine = mkDefault ''<<< Welcome to ${config.system.nixos.distroName} ${config.system.nixos.label} (\m) - \l >>>'';