On Tue, Jan 20, 2026 at 06:32:28AM +0000, Suresh H A wrote: > Hello Team, > > While working with mount.c , I observed that environment variables(say for > instance SYSTEMD_DEFAULT_MOUNT_RATE_LIMIT_BURST) defined through the usual > systemd mechanisms (Environment=, EnvironmentFile=, drop-ins, etc.) are not > accessible at this early stage of execution. The only working approach I’ve > found so far is to pass them via kernel boot arguments, which can then be > picked up reliably.
Hi, It sounds like you're conflating the variables in the manager and variables that are set by the manager for individual units. Variables defined with Environment= and EnvironmentFile=, no matter if directly the unit file or through drop-ins, are for the unit, and they are always available when units are started. Variables like SYSTEMD_DEFAULT_MOUNT_RATE_LIMIT_BURST are for the manager. In case of the system manager, that means that they must specified on the kernel command line, as you wrote. For the user manager, which runs in as a normal unit, any mechanism that can be used to configure environment for services can be used, i.e. Environment=/EnvironmentFile= in the unit file, or the system manager's set-environment call. (For sake of completeness, let's mention that variables for the system manager could also be set by injecting a different init, e.g. a shell script that modifies the environemnt and then exec's systemd. But this is not the normal thing to do.) > I wanted to check whether this is indeed the expected limitation, or if there > are alternative mechanisms within systemd to enable environment variables > during such an early phase without relying on kernel boot arguments. > Could you please advise if we are on the right track, or suggest other > approaches that might be viable? Yes, this is expected. Those variables are a debug/workaround mechanism. Zbyszek
