cannot create log files in /var/log

Bug #1256695 reported by Para Siva on 2013-12-01
46
This bug affects 9 people
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)
Critical
Colin Watson
Trusty
Critical
Colin Watson

Bug Description

With the latest rsyslog upgrade (to 7.4.4-1ubuntu1) in trusty the desktop installer syslogs are no more copied to /var/log/installer/ The issue is visible from 20131129 , seen in both amd64 and i386 images and break smoke tests during VM provisioning.

Steps to reproduce:
1. Install a trusty desktop vm.
2. Once the installation is over, it could be noticed that the installer syslog is not copied to /var/log/installer/

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: rsyslog 7.4.4-1ubuntu1
ProcVersionSignature: Ubuntu 3.12.0-4.12-generic 3.12.1
Uname: Linux 3.12.0-4-generic x86_64
ApportVersion: 2.12.7-0ubuntu1
Architecture: amd64
Date: Sun Dec 1 19:42:13 2013
InstallationDate: Installed on 2013-12-01 (0 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20131201)
SourcePackage: rsyslog
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :

Tar file of /var/log/ is attached.

summary: - Installation logs are not copied to /var/log/installer/syslog
+ Trusty desktop Installation logs are not copied to /var/log/installer/
description: updated

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in rsyslog (Ubuntu):
status: New → Confirmed
Paul Larson (pwlars) wrote :

This seems to be affecting only the desktop runs, and not server.

Colin Watson (cjwatson) on 2013-12-04
Changed in rsyslog (Ubuntu):
importance: Undecided → Critical
Changed in rsyslog (Ubuntu Trusty):
assignee: nobody → Colin Watson (cjwatson)
summary: - Trusty desktop Installation logs are not copied to /var/log/installer/
+ cannot create log files in /var/log
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rsyslog - 7.4.4-1ubuntu2

---------------
rsyslog (7.4.4-1ubuntu2) trusty; urgency=low

  * debian/rsyslog.postinst: Make sure /var/log is owned by group syslog and
    is group-writeable (LP: #1256695).
  * Ensure that rsyslogd can create files in group adm, even when dropping
    group privileges to syslog (LP: #484336):
    - debian/patches/10-initgroups.patch: Try to set appropriate
      supplementary groups before dropping UID.
    - debian/rsyslog.postinst: Add syslog user to group adm.
 -- Colin Watson <email address hidden> Wed, 04 Dec 2013 13:12:07 +0000

Changed in rsyslog (Ubuntu Trusty):
status: Confirmed → Fix Released
Michael Marley (mamarley) wrote :

I seem to still be experiencing this bug, both on Kubuntu desktop and on server. On both systems, none of the log files that rsyslog normally creates are created and all logging output is lost.

I can, however, work around the issue by creating the log files and chowning them to syslog:adm before starting rsyslog.

Akshay Moghe (akshay-moghe) wrote :

I'm running into this as well.

On:
---
Description: Ubuntu 14.04 LTS
Release: 14.04
Codename: trusty

Running:
-------
rsyslog 7.4.4-1ubuntu2

/var/log permissions are:
---------------------------
drwxrwxr-x 6 root root 4096 Apr 30 07:11 log

Running rsyslog in the foreground with debugging flags results in this sequence of messages:

2009.061284547:7f7636f81780: cnf:global:cfsysline: $PrivDropToUser syslog
2009.061356413:7f7636f81780: uid 101 obtained for user 'syslog'
2009.061373099:7f7636f81780: cnf:global:cfsysline: $PrivDropToGroup syslog
2009.061464895:7f7636f81780: gid 103 obtained for group 'syslog'
...
2009.173401545:7f763387f700: file '/var/log/syslog' opened as #-1 with mode 416
2009.173429557:7f763387f700: strm 0x7f762c000b70: open error 13, file '/var/log/syslog': Permission denied

As mentioned in other comments, possible workarounds are:
0. Touch (and ensure syslog:adm perm) on the file before the daemon starts
1. Make /var/log permissions more permissive (allowing adm to write to it).

Martin Konecny (martin-konecny) wrote :

This bug appears to still be present as of May 19 2014, on a Trust Tahr system with the latest updates. Applying the solution of #6 worked for me.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers