8

I asked a question earlier about viewing the history of notify-osd using the indicator-notifications app.

The answer was that I needed to add LOG=1 in my /etc/environment file.
That sounded suspicious and I didn't do it because:

  1. It's in the global configuration file.
  2. You really can't know what else will be logged other than the notifications.

I browsed around and saw this question which also highlights the issue. Look specifically at this answer:

Small warning: this could be a bad idea... LOG=1 in /etc/environment makes it a system wide variable and could break stuff... God knows what reacts on LOG (ofc. they should have made it something like NOTIFYOSDLOG). Maybe for starters I would add it to bashrc for 1 user just to be sure.

My question is, how will setting LOG=1 in /etc/environment affect the system? Which 'stuff' will be logged? Is this advisable?

EDIT

I solved the notification issue and now I'm just asking about the effects of setting LOG=1 in /etc/environment.

Look at my question above: "How will setting LOG=1 in /etc/environment affect the system? Which 'stuff' will be logged? Is this advisable?"

Community
  • 1
Parto
  • 15,325
  • 24
  • 86
  • 117
  • We could maybe edit and recompile notifyosd to check for NOTIFYOSDLOG instead.. – Seth Mar 27 '14 at 03:46
  • It is rather hard to tell how the system would be affected by LOG=1 without reading the documentation of each and every program and service that may be run and may make use of LOG in the environment. LOG is quite a generic name but unlike PATH, HOME or TERM it is not commonly used. So one may hope that not too many developers chose it as an environment variable for their program and therefore setting LOG won't do much. – Adaephon Apr 03 '14 at 05:57
  • Both answers are nice, I'll just let the 'system' award the bounty. Thanks Adaephon for that comment, LOG is not commonly used and hence kinda hard to know how the system would be affected by LOG=1. – Parto Apr 03 '14 at 13:17

2 Answers2

4

You could use something more user-local like ~/.pam_environment or ~/.profile. These are practically the same approach as /etc/environment except they'll only affect your user. They could still affect other applications.

While ~/.profile is similar to other script files, ~/.pam_environment has a bit of a twitchy syntax that needs to be adhered to (or you'll break your login):

LOG DEFAULT=1

The other approach that may work is changing whatever launches notify-osd to pass the environment variable along directly. In this case, it seems to be part of some cross-platform DBUS cascade controlled from usr/share/dbus-1/services/org.freedesktop.Notifications.service

[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/lib/x86_64-linux-gnu/notify-osd

I wonder if the Exec line could be changed to read:

Exec=LOG=1 /usr/lib/x86_64-linux-gnu/notify-osd

Or if that throws syntax wobblies:

Exec=sh -c "LOG=1 /usr/lib/x86_64-linux-gnu/notify-osd"

If that works it has the obvious advantage of only affecting notify-osd (any anything it launches).

Oli
  • 293,335
3

The NotifyOSD doc pages quotes:

(Note: logging to this file is enabled when the LOG environment variable is set to 1.)

In the Environmental Variable doc page, it has a list of common variables where "LOG" is not listed. It says:

Each application is free to define and use its own environment variables. Many manual pages include long lists of environment variables that can affect the behaviour of the application they describe. However, the most useful variables are common to many applications.

After googling for instances where LOG may be used, nothing comes up. "NOTIFYOSDLOG" would have been a more appropriate name. The use of LOG is completely dependent on applications so it's a mystery who does and doesn't use it. Since it isn't in the common variables list, it may be just a poorly named variable.

karel
  • 114,770
Mr.Lee
  • 891