The problems with this are the same as with the dbus-update-activation-environment tool, which this just a reinvention of by the way.
There are a whole bunch of environment variables appropriate to a login session that are not appropriate to daemon processes that are running outwith a login session. From the headlined article one can pick quite a number of variables that are at best pointless in, and often outright misleading to and wrong for, daemon programs:
There are good reasons that daemons are run with known environments; and there are about four decades of system administrator horror stories of running daemons with things like the old "service" command and getting environment variables from a login session inherited into the service processes, to learn better from. Pushing the entire environment from an arbitrarily selected login session into the environments of services is a bad idea. At best, one should push only a carefully selected set of variables.
On Debian with the "new" per-user service management, the Desktop Bus people use dbus-update-activation-environment to push just three environment variables: DBUS_SESSION_BUS_ADDRESS, DISPLAY, and XAUTHORITY.
Of course, the elephant in the room is server daemons that are written to talk to arbitrary X displays that erroneously demand that they run with a DISPLAY variable already in the environment of the server daemon when it starts. A well-designed daemon arranges to have the DISPLAY information passed in to it. (In Unicode rxvt in its client-server mode, for example, the urxvtc program passes its DISPLAY environment variable in the message that it sends to the urxvtd server.)
JdeBP|8 years ago
There are a whole bunch of environment variables appropriate to a login session that are not appropriate to daemon processes that are running outwith a login session. From the headlined article one can pick quite a number of variables that are at best pointless in, and often outright misleading to and wrong for, daemon programs:
There are good reasons that daemons are run with known environments; and there are about four decades of system administrator horror stories of running daemons with things like the old "service" command and getting environment variables from a login session inherited into the service processes, to learn better from. Pushing the entire environment from an arbitrarily selected login session into the environments of services is a bad idea. At best, one should push only a carefully selected set of variables.On Debian with the "new" per-user service management, the Desktop Bus people use dbus-update-activation-environment to push just three environment variables: DBUS_SESSION_BUS_ADDRESS, DISPLAY, and XAUTHORITY.
Of course, the elephant in the room is server daemons that are written to talk to arbitrary X displays that erroneously demand that they run with a DISPLAY variable already in the environment of the server daemon when it starts. A well-designed daemon arranges to have the DISPLAY information passed in to it. (In Unicode rxvt in its client-server mode, for example, the urxvtc program passes its DISPLAY environment variable in the message that it sends to the urxvtd server.)