gnome-system-log attempts to open bogus/inexistent logfiles

[Samium Gromoff]

Binary package hint: gnome-utils

gnome-system-log pops up an error message upon launch, telling that:

/var/log/XFree86.0.log: Произошла ошибка при получении сведений о файле «/var/log/XFree86.0.log»: No such file or directory
/var/log/cups/error_log: Произошла ошибка при получении сведений о файле «/var/log/cups/error_log»: No such file or directory
/var/log/cron: Произошла ошибка при получении сведений о файле «/var/log/cron»: No such file or directory
/var/log/maillog: Произошла ошибка при получении сведений о файле «/var/log/maillog»: No such file or directory
/var/log/sys.log: Произошла ошибка при получении сведений о файле «/var/log/sys.log»: No such file or directory
/var/log/secure: Произошла ошибка при получении сведений о файле «/var/log/secure»: No such file or directory

Obviously, years passed since /var/log/XFree86.0.log lost relevance, whereas things like
/var/log/sys.log and /var/log/secure never existed in the first place.

This bug report applies to Jaunty alpha3, gnome-utils version 2.25.2-0ubuntu1

[Sebastien Bacher (seb128)]

Thank you for your bug report, that's a known issue you can read about it on http://bugzilla.gnome.org/show_bug.cgi?id=567169

[KevinM (kevbert1)]

Same problem here on Kernel 2.6.28-6 64 bit. Not seen in Alpha3 but seen in Alpha4.

[Steve Beattie (sbeattie)]

In the upstream gnome bug report, TJ commented:

> The cause seems to be a user profile that has been upgraded from an older
> distro release, where the contents of /var/log/ haven't been inherited. It can
> also happen where multiple release installations share a common /home/$USER/.

However, I see this behavior with an entirely fresh install of jaunty into a test vm, where the user was entirely created from scratch.

'gconftool-2 -g /apps/gnome-system-log/logfiles' reports:

  [/var/log/cups/error_log,/var/log/XFree86.0.log,/var/log/Xorg.0.log,/var/log/cron,/var/log/maillog,/var/log/secure,/var/log/sys.log,/var/log/messages,/var/log/debug,/var/log/news/news.notice,/var/log/news/news.err,/var/log/news/news.crit,/var/log/mail.err,/var/log/mail.warn,/var/log/mail.info,/var/log/user.log,/var/log/mail.log,/var/log/lpr.log,/var/log/kern.log,/var/log/daemon.log,/var/log/syslog,/var/log/auth.log]

which also misses useful stuff like the wpa_supplicant log.

[TJ (tj)]

Thanks for pointing that out Steve. I moved an existing /home/ mount into the Jaunty environment. Now you've jogged my memory I think I do recall that with the default Jaunty user profile I saw a bunch of log-file warnings too. Now I only see one for /var/log/acpid.

The reason for it is that on package gnome-utils the gnome-log-viewer code has the defaults hard-coded in. logview/logview-prefs.c:

static char *default_logfiles[] = {
  "/var/log/sys.log",
#ifndef ON_SUN_OS
  "/var/log/messages",
  "/var/log/secure",
  "/var/log/maillog",
  "/var/log/cron",
  "/var/log/Xorg.0.log",
  "/var/log/XFree86.0.log",
  "/var/log/auth.log",
  "/var/log/cups/error_log",
#else

so what we need is a simple patch to alter the defaults

[TJ (tj)]

The patch above doesn't deal with the issue that gnome-log-viewer seemingly doesn't provide for the user deleting a log-file from the monitored list if that file doesn't exist on-disk.

[Sebastien Bacher (seb128)]

thank for your work but I'm not convinced by this approch, it should just lists all the available logs listed and not display an error dialog which has no use

[TJ (tj)]

On Fri, 2009-02-20 at 10:13 +0000, Sebastien Bacher wrote:
> thank for your work but I'm not convinced by this approch, it should
> just lists all the available logs listed and not display an error dialog
> which has no use

Hi Sebastien.

I wasn't attempting to fix the fundamental issue, just to modify the
upstream default enough to avoid users seeing error messages for
log-files that are never going to be found on Ubuntu systems.

I agree with your implication that the design adopted upstream that
causes this feels flawed, but I think that is something that should be
dealt with by upstream since it looks like it'll need significant
changes.

[Hernando Torque (htorque)]

How can I get rid of gnome-system-log in gconf? Uninstalling (and purging) gnome-utils didn't fix it.

I think you just need to check the existence of default_logfiles[i] in logview_prefs_fill_defaults (I did it with fopen - maybe overkill?) but as long as I have the gconf entry present it's not creating the initial logfile list and I cannot test if it works.

[Tomas Cassidy (tomas-cassidy)]

Hernando, you have to go into the directory ~/.gconf/apps/ and remove the directory gnome-system-log.

[Hernando Torque (htorque)]

Really strange. I always thought it's sufficient to purge a package to get rid of all gconf data but I needed to restart GDM for a clean gconf.

Ok, I tested the trivial fix (as already said I just check if default_logfiles[i] exist with fopen) and it seems to work.

Only Xorg.0.log gets added, the rest either doesn't exist on disk or already exists in /etc/syslog.conf.

[Hernando Torque (htorque)]

As for the user added files that no longer exist: I'd rather leave them in the log list (grayed out to visualize their absence) so the user can close them (which will permanently remove them from gconf) than remove them directly, but I don't know how to do that (lack of GTK programming experience).

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-utils - 2.25.92-0ubuntu1

---------------
gnome-utils (2.25.92-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    Baobab
    - Use g_return_val_if_fail instead of g_return_if_fail.
    Dictionary
    - Replace deprecated gtk_entry_set_editable.
    Floppy
    Screenshot
    - Initialize threads at startup and explicitely depend on GThreads.
    - If we are in a multi-monitor setup that is not rectangular
      blank out the "invisible" areas from the rectangular root window.
    - Don't try to shape the root window.
    - Add support for taking a screenshot of an user-defined selection.
    Search Tool
    - Get rid of deprecated libart calls.
    - Get rid of deprecated GTK_CHECK_* macros.
    System Log Viewer
    - Explicitely depend on GThreads.
    - Gather all the readable log files from /var/log and /etc/syslog.conf
      instead of hardcoding obsolete values. (lp: #318689)

 -- Sebastien Bacher <email address hidden> Mon, 02 Mar 2009 17:18:59 +0100

[Hernando Torque (htorque)]

That only fixes the warning for the first startup. Non existant files still cannot be removed via the application (you either have to remove them from the gconf list or recreate them on disk and then close them in the log viewer).

[nullack (nullack)]

Sebastien I'm confused - the bug is in a triaged status yet the janitor thinks this is fixed? It is *not* fixed, the behaviour is still occuring for me on:

nullack@PPP:~$ sudo apt-cache policy gnome-utils
gnome-utils:
  Installed: 2.25.92-0ubuntu1
  Candidate: 2.25.92-0ubuntu1
  Version table:
 *** 2.25.92-0ubuntu1 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Also why was this declined as a release target for Jaunty? Considering this report was raised on 19/1 why is it so difficult to resolve before the production release of Jaunty? Its things like this that are immediately apparent as broken things in the Ubuntu desktop that detracts from a users perception of apparent quality.

[Hernando Torque (htorque)]

As I said it's only fixed for the first startup. If you've already started the log viewer (with an earlier version) you need to unset the loglist in gconf-editor under /apps/gnome-system-log to realize the difference.

Making this list editable within the application would probably fix the remaining problem.

[Sebastien Bacher (seb128)]

the janitor has nothing to do with that, the issue reported there has been fixed, the logs file is not static but built on first start and users who didn't run previous jaunty version will have no such issue, I've reopen the bug to address the issue with the gconf key or log changes though

the nominations are there to mark blockers for jaunty, that issue now is a minor one happening for early jaunty users only and has no reason to be set as a blocker

[Thomas Templin (coastgnu)]

gnome-utils (2.25.92-0ubuntu1)

- still uses hardcoded obsolete values of bogus logfiles
- there is no value set for loglist in gconf-editor under /apps/gnome-system-log as mentioned by Hernando Torque

[Sebastien Bacher (seb128)]

> - still uses hardcoded obsolete values of bogus logfiles

no it doesn't

[Thomas Templin (coastgnu)]

Am Fr, 6. März 2009 09:49:46 schrieb Sebastien Bacher:
> > - still uses hardcoded obsolete values of bogus logfiles
>
> no it doesn't
Shure?

Before sending bug report I did the following:

- run gnome-system-log
  it shows the known list of nonexistant logfiles

- run gconf-editor and deleted '/apps/gnome-system-log/logfiles' value
  btw. it was empty but it says it is of the type bolean, strange I would say
  nevertheless I deleted the value

- restarted gconf-editor and it attempts to open the bogus input files again
  ('/apps/gnome-system-log/logfiles' value was empty)

- did a reboot

- '/apps/gnome-system-log/logfiles' shows the list as in
  "--8<--from gnome-system-log --8<--", see below.

- deleted nonexistant files in '/apps/gnome-system-log/logfiles'

- restarting gnome-system-log and voilla, no complains about nonexistant files
  anymore

---8<--- from gnome-system-log ---8<---
Could not open the following files:
/var/log/XFree86.0.log: Fehler beim Untersuchen der Datei
/var/log/XFree86.0.log mit fstat(): No such file or directory
/var/log/cron: Fehler beim Untersuchen der Datei /var/log/cron mit fstat(): No
such file or directory
/var/log/maillog: Fehler beim Untersuchen der Datei /var/log/maillog mit
fstat(): No such file or directory
/var/log/secure: Fehler beim Untersuchen der Datei /var/log/secure mit
fstat(): No such file or directory
/var/log/sys.log: Fehler beim Untersuchen der Datei /var/log/sys.log mit
fstat(): No such file or directory
---8<--- ---8<--- ---8<---

So I would say at least for the first run gnome-system-log uses the hardcoded
logfile-list nevertheless if thes exist or not.

reegards,
thomas

[Sebastien Bacher (seb128)]

ok, could you

- run "gnome-system-log --version"
- run "gconftool-2 --recursive-unset /apps/gnome-system-log" and try to start gnome-system-log and see if there is an error
- log as a new user or use a guest session and start gnome-system-log and see if you get an error

and then update the bug with those informations?

[Thomas Templin (coastgnu)]

[...]
> - run "gnome-system-log --version"
gnome-system-log - Version 2.25.92
...

(btw. was upgraded after my last bugreport update)

> - run "gconftool-2 --recursive-unset /apps/gnome-system-log" and try to
> start gnome-system-log and see if there is an error -
No error at all.

> log as a new user or
> use a guest session and start gnome-system-log and see if you get an error
> and then update the bug with those informations?
No error at all.

- My system is an 8.04 Hardy Heron installation upgraded to 8.10 Intrepid
  Ibex. In the moment its permanently upgraded to 9.04 Jaunty Jackalope.

May be the wrong variable type Integer I've seen for the filelist variable
results from one of the previous upgrades? Or could it be that gconf-editor
always asumes an empty string variable to be of type integer intead an empty
string variable?

Nevertheless, good to know that there might be a wrong variable type for
filelist of gnome-system-log.

regards,
thomas

[Derek White (d-man97)]

Just noticed this problem after a "rm /var/log/*.gz" to clean up my log directory...

I guess it's not going to be fixed until karmic?

[Pau Moll (paumoll-deactivatedaccount)]

> ok, could you

> - run "gnome-system-log --version"
> - run "gconftool-2 --recursive-unset /apps/gnome-system-log" and try to start gnome-system-log and see if there is an error

Thanks this solve my issue on Karmic Koala

[Cas (calumlind)]

I had this message about an old log file that no longer existed.

Running 'gconftool-2 --recursive-unset /apps/gnome-system-log' fixed the issue.

gnome-system-log - Version 2.32.0 on Natty

[boyan (boianbb)]

I upgraded from Ubuntu 9.04 to Ubuntu 10.04 LTS - the Lucid Lynx and I had the same problem.

gnome-system-log - Version 2.30.0

This is also work for my system:
Running 'gconftool-2 --recursive-unset /apps/gnome-system-log' fixed the issue.

[John Franklin (hondaman-nc)]

On 12.04 open dconf-editor and go to org.gnome.gnome-system-log, logfiles are defined here.

[[e-mail] (bojojo-orange)]

"[Bug 318689] Re: gnome-system-log attempts to open bogus/inexistent logfiles"
Cas doc