linux-traipu team mailing list archive

["Brian J. Murrell" <brian@xxxxxxxxxxxxxxx>]

On 11-12-14 01:38 AM, Mario Limonciello wrote:
> If you stop mythbackend, remove the file and restart, does the same
> behavior happen?

Yes.  That's exactly the behavior that produced the demonstrated file.

In fact, rsyslogd refused to write to the existing file owned by
mythtv.mythtv.  So I [re]moved the whole /var/log/mythtv directory to
see if it would create it and the file it wanted to write to.  It failed
to create the new file and didn't create a directory.  So I created the
directory (/var/log/mythtv) by hand and it still failed to create the
new file.  I then chmod'ed the directory (again, /var/log/mythtv) to 777
and finally rsyslog was able to create the new file, owned by
syslog.syslog, as was demonstrated in the ticket description.

It's very clear that the directives in the conf file are not having
their desired effect.  Running rsyslogd in debug mode shows the
directives are being read and acknowledged, just not acted on when it
comes time to creating the file.

> I'm wondering if it's only happening because of
> "existing" files.

Nope.

> The syntax looks correct according to
> http://rsyslog.com/doc/rsconf1_fileowner.html

Yeah.  I came across some writings that a corresponding file ownership
directive (which escapes me at the moment) was going to be deprecated in
version 4 of rsyslog due to some privilege dropping that was going to be
happening.  What I am seeing entirely smacks of what could happen if
rsyslogd were dropping privileges at some point and therefore being
unable to set arbitrary file ownerships (for which privilege would be
necessary).

It might be that those file ownership directives that the mythtv
rsyslogd conf file is using are only useful once (i.e. globally) for an
rsyslogd's lifetime, prior to it dropping privileges and going into it's
main loop.  That's just a theory on my part though.  I have not
researched enough to know that that is what is happening.

-- 
You received this bug notification because you are a member of UBUNTU -
AL - BR, which is subscribed to Mythbuntu.
https://bugs.launchpad.net/bugs/904099

Title:
  rsyslog configuration not working

Status in Mythbuntu, Ubuntu derivative focused upon MythTV:
  New

Bug description:
  I am running the nightly master builds currently at
  2:0.25.0~master.20111213.72d4370-0ubuntu0mythbuntu2

  At some point the logging for the backend in the mythbuntu packages
  was changed to use syslog together with an rsyslogd configuration
  stanza:

  ---- cut ----
  $FileOwner mythtv
  $FileGroup mythtv
  $FileCreateMode 0644
  $DirOwner mythtv
  $DirGroup mythtv
  $DirCreateMode 0755

  $template mythtvFile,"/var/log/mythtv/%programname%.log"

  local7.* ?mythtvFile
  & ~
  ---- cut ----

  This is not working as I think you expect it should be working.
  Specifically, the log files being created by rsyslogd are not
  owner.group mythtv.mythtv:

  -rw-r--r-- 1 syslog syslog 3456 2011-12-14 00:25 mythbackend.log

  Of course, I had to make the containing directory (/var/log/mythtv/)
  permissive to creating files with such ownership.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mythbuntu/+bug/904099/+subscriptions