Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

--logfile vs. --logpath (was: mythbackend won't start during bootup on fc16)

 

 

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded


thomas at mashos

May 21, 2012, 11:56 AM

Post #26 of 29 (311 views)
Permalink
Re: --logfile vs. --logpath [In reply to]

On Mon, May 21, 2012 at 11:22 AM, Michael T. Dean
<mtdean [at] thirdcontact> wrote:
> On 05/21/2012 01:27 PM, Stephan Seitz wrote:
>>
>> On Mon, May 21, 2012 at 12:43:23PM -0400, Michael T. Dean wrote:
>>>
>>> You do realize you can easily find the current log file with something
>>> like:
>>> ls -t /var/log/mythtv/mythbackend-*.log | head -n1
>>> and could even have your mythbackend/mythfrontend start script create a
>>> link with a name like /var/log/mythtv/mythbackend.log using information
>>> obtained that way.
>>
>>
>> Of course, we will certainly find other complicated hacks to get standard
>> behaviour.
>>
>>>> Piping the log output through syslog to get proper logfile names is only
>>>> a workaround for a buggy software.
>>>
>>> Using the definition of buggy = something I don't understand/like?
>>
>>
>> Buggy = something that doesn’t follow the good old unix way.
>
>
> MythTV is different from many/most other *nix apps in that there are often
> multiple instances of applications running--and logging
> information--concurrently. That said, the only "good old unix way" of
> logging I know of is, in fact, syslog--everything else is pretty much
> non-standard, application-specific logging practices (where the vast
> majority of those applications have only one instance or an application to
> worry about, too).
>
>
>>> Why not just use syslog? The syslog logging is the approach we've
>>
>>
>> Well, for now I’m using syslog according to your nice examples you quoted.
>> It is working but I still consider it a workaround, especially since
>> everything was right before 0.25.
>>
>> This is bad for distributions as well. How should mythtv be packaged? With
>> logpath and then having a directory with lots of confusing files? With
>> syslog and then try to figure out which facility is not used and how to
>> configure the different log daemons (Debian has three at least)?
>
>
> FWIW, you don't need an unused log facility with the simple configuration
> (which I just moved to a separate page so it's easier to quote/easier to
> distinguish as separate).
>
> http://www.mythtv.org/wiki/Simple_rsyslog_Configuration
>
> As for dealing with multiple syslog implementations, I'd suppose packagers
> could handle it as they do for other syslog-using applications. (That said,
> I know nothing of packaging, but I do know of many applications that use
> syslog.)
>
>
> Mike
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

FWIW, that is pretty much exactly what we ship.

rsyslog configuration (notice we don't need to look for an open facility)
https://github.com/MythTV/packaging/blob/master/deb/debian/40-mythtv.conf

logrotate configuration for the backend
https://github.com/MythTV/packaging/blob/master/deb/debian/mythtv-backend.logrotate

Thanks,

Thomas Mashos
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


stse+mythtv at fsing

May 21, 2012, 11:56 AM

Post #27 of 29 (308 views)
Permalink
Re: --logfile vs. --logpath [In reply to]

On Mon, May 21, 2012 at 02:22:36PM -0400, Michael T. Dean wrote:
>MythTV is different from many/most other *nix apps in that there are
>often multiple instances of applications running--and logging
>information--concurrently. That said, the only "good old unix way" of

You mean like a mail server like postfix with its different applications
like smtpd, qmgr, cleanup or postscreen being able to receive and handle
mails in parallel and logging each process without exploding computers?

>logging I know of is, in fact, syslog--everything else is pretty much
>non-standard, application-specific logging practices (where the vast
>majority of those applications have only one instance or an application
>to worry about, too).

Well, show me an application with the same behaviour as mythtv. The
applications (like apache) which don’t use syslog can be told to log into
a certain file. Some can rotate the logfiles themself, others need
logrotate, but you always know which file will contain the current
logoutput.

>FWIW, you don't need an unused log facility with the simple
>configuration (which I just moved to a separate page so it's easier to
>quote/easier to distinguish as separate).
>http://www.mythtv.org/wiki/Simple_rsyslog_Configuration
>As for dealing with multiple syslog implementations, I'd suppose
>packagers could handle it as they do for other syslog-using
>applications. (That said, I know nothing of packaging, but I do know of
>many applications that use syslog.)

It isn’t that easy. Your rsyslog examples will only work with rsyslog,
and only rsyslog has the rsyslog.d directory. If the system uses
syslog-ng or sysklogd you must manipulate one global configuration file.
syslog-ng and sysklogd will support filtering according to facility, but
I don’t know if you can filter for application names.

I would certainly not try to put such a logic into a package.

On the other hand, mythtv generates to much logs to put everything into
/var/log/syslog.

Shade and sweet water!

Stephan

--
| Stephan Seitz E-Mail: stse [at] fsing |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |
Attachments: smime.p7s (3.54 KB)


thomas at mashos

May 21, 2012, 2:06 PM

Post #28 of 29 (306 views)
Permalink
Re: --logfile vs. --logpath [In reply to]

On Mon, May 21, 2012 at 11:56 AM, Stephan Seitz
<stse+mythtv [at] fsing> wrote:
> On Mon, May 21, 2012 at 02:22:36PM -0400, Michael T. Dean wrote:
>>
>> MythTV is different from many/most other *nix apps in that there are often
>> multiple instances of applications running--and logging
>> information--concurrently. That said, the only "good old unix way" of
>
>
> You mean like a mail server like postfix with its different applications
> like smtpd, qmgr, cleanup or postscreen being able to receive and handle
> mails in parallel and logging each process without exploding computers?
>
>> logging I know of is, in fact, syslog--everything else is pretty much
>> non-standard, application-specific logging practices (where the vast
>> majority of those applications have only one instance or an application to
>> worry about, too).
>
>
> Well, show me an application with the same behaviour as mythtv. The
> applications (like apache) which don’t use syslog can be told to log into a
> certain file. Some can rotate the logfiles themself, others need logrotate,
> but you always know which file will contain the current logoutput.
>
>> FWIW, you don't need an unused log facility with the simple configuration
>> (which I just moved to a separate page so it's easier to quote/easier to
>> distinguish as separate).
>> http://www.mythtv.org/wiki/Simple_rsyslog_Configuration
>> As for dealing with multiple syslog implementations, I'd suppose packagers
>> could handle it as they do for other syslog-using applications. (That said,
>> I know nothing of packaging, but I do know of many applications that use
>> syslog.)
>
>
> It isn’t that easy. Your rsyslog examples will only work with rsyslog, and
> only rsyslog has the rsyslog.d directory. If the system uses syslog-ng or
> sysklogd you must manipulate one global configuration file.  syslog-ng and
> sysklogd will support filtering according to facility, but I don’t know if
> you can filter for application names.
>
> I would certainly not try to put such a logic into a package.
>
> On the other hand, mythtv generates to much logs to put everything into
> /var/log/syslog.
>
> Shade and sweet water!
>
>        Stephan
>
> --
> | Stephan Seitz          E-Mail: stse [at] fsing |
> | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

A single global configuration file? Yuck. What distro do you use?

Thanks,

Thomas Mashos
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

May 21, 2012, 3:51 PM

Post #29 of 29 (306 views)
Permalink
Re: --logfile vs. --logpath [In reply to]

On 05/21/2012 02:56 PM, Stephan Seitz wrote:
> On Mon, May 21, 2012 at 02:22:36PM -0400, Michael T. Dean wrote:
>> MythTV is different from many/most other *nix apps in that there are
>> often multiple instances of applications running--and logging
>> information--concurrently. That said, the only "good old unix way" of
>
> You mean like a mail server like postfix with its different
> applications like smtpd, qmgr, cleanup or postscreen being able to
> receive and handle mails in parallel and logging each process without
> exploding computers?
>
>> logging I know of is, in fact, syslog--everything else is pretty much
>> non-standard, application-specific logging practices (where the vast
>> majority of those applications have only one instance or an
>> application to worry about, too).
>
> Well, show me an application with the same behaviour as mythtv. The
> applications (like apache) which don’t use syslog can be told to log
> into a certain file. Some can rotate the logfiles themself, others
> need logrotate, but you always know which file will contain the
> current logoutput.
>
>> FWIW, you don't need an unused log facility with the simple
>> configuration (which I just moved to a separate page so it's easier
>> to quote/easier to distinguish as separate).
>> http://www.mythtv.org/wiki/Simple_rsyslog_Configuration
>> As for dealing with multiple syslog implementations, I'd suppose
>> packagers could handle it as they do for other syslog-using
>> applications. (That said, I know nothing of packaging, but I do know
>> of many applications that use syslog.)
>
> It isn’t that easy. Your rsyslog examples will only work with rsyslog,
> and only rsyslog has the rsyslog.d directory. If the system uses
> syslog-ng or sysklogd you must manipulate one global configuration file.

Having used syslog-ng in the past, I know it supports includes:

http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/syslog-ng-ose-v3.3-guide-admin-en.html/including-config-files.html

> syslog-ng and sysklogd will support filtering according to facility,
> but I don’t know if you can filter for application names.

and filtering by application (program() filter function--even allowing
regexp usage for matching):

http://www.balabit.com/sites/default/files/documents/syslog-ng-ose-3.3-guides/syslog-ng-ose-v3.3-guide-admin-en.html/reference_filters.html

and, as a matter of fact, it's actually a recommended feature of the
official protocol ( http://tools.ietf.org/html/rfc5424#section-6.2.5 ),
so I'd assume even syslogd supports it.

> I would certainly not try to put such a logic into a package.
>
> On the other hand, mythtv generates to much logs to put everything
> into /var/log/syslog.

Agreed--just jamming everything into any one log file (whether a syslog
log file or one specifically for mythtv) makes a huge, unreadable,
unusable mess.

However, I'm pretty sure all it would take to get a good syslog-ng
configuration on the wiki is a motivated individual who actually has
syslog-ng and MythTV installed and a bit of reading and trial and error.
(FWIW, that's how I came up with the rsyslog ones.) Chances are, someone
could also do a syslogd configuration--if anyone still uses it. :)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.