So that answer is that, FLEET does not use global environment variables

FWIW, I usually set my software inventory variable in my dev build command.

FLEET_BETA_SOFTWARE_INVENTORY=1 ./build/fleet serve --dev

I am guessing you are using docker?

Yeah, we recommend docker for our dev environment

Btw, the availability of an environment variable is not controlled by the process that needs to access it (Fleet), but it's controlled by who (what other process/context) is launching such process. In the case of systemd, as other have said, you have to set the env var there. If you had launched it from bash, then it would've inherited those env vars.

what Stefano mentions is correct. That said, we should add that to the systemd documentation @Rachel Perkins

@Stefano Bonicatti indeed, I figured the variable was only going to bash, that's what I meant by fancy pants method, as in some way to give the fleet process the environment variable, because it is not reading it from /etc/environment (the global environment variables for all processes). Bash specific environment variables go in .bash_profile or .profile etc So when something says "set environment variable" and doesn't specify local or global, I would think it would read the global env vars. But maybe that is a limitation of systemd not fleet which is what I think you are saying?

@Mystery Incorporated I wouldn't necessarily call it a limitation, it's a choice of systemd, since it doesn't want to rely on PAM to read that file. But in general, what I was trying to say is that if any process is not receiving environment variables, you have to look into what's the parent process and check how it works/how it passes env vars.