Mailing List Archive

On 29/11/12 13:45, Duncan Brown wrote:
> Hello All
>
> I'm not a huge fan of the current mythtv logging method which results in
> huge amounts of separate log files, so I've changed to using syslog.
>
> This involves changing the command in init.d/mythbackend to "--syslog
> local7" instead of "--logpath /var/log/mythtv/"
>
> This works great, but every time I upgrade the init.d file is
> overwritten. Is there anyway of stopping that file being overwritten by
> the upgrade each time?
>
> cheers
>
> Dunc
>

I probably ought to let someone with a /good/ suggestion come in here,
but I keep copies of foo_distrib.bar and foo_my.bar

After an upgrade, if diff foo.bar foo_distrib.bar is null,
cp foo_my.bar foo.bar

If the diff isn't null, some investigation is needed.

I doubt that it's rigorously correct but it seems to work.

John P




_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On Thu, Nov 29, 2012 at 10:30 AM, John Pilkington <J.Pilk@tesco.net> wrote:

> On 29/11/12 13:45, Duncan Brown wrote:
>
>> Hello All
>>
>> I'm not a huge fan of the current mythtv logging method which results in
>> huge amounts of separate log files, so I've changed to using syslog.
>>
>> This involves changing the command in init.d/mythbackend to "--syslog
>> local7" instead of "--logpath /var/log/mythtv/"
>>
>> This works great, but every time I upgrade the init.d file is
>> overwritten. Is there anyway of stopping that file being overwritten by
>> the upgrade each time?
>
>
Sorry, replying here since I don't have the original email...

You could use my systemd service file (RPM Fusion) instead of SysV. This
way you can override the behavior permanently.

Take the file that normally goes in /lib/systemd/system and copy it to
/etc/systemd/system (or something like that). SystemD will search this
directory first and will override any files of the same name in /lib...

All you need to do after that is keep an eye on any changes/improvements to
the packaged systemd file so you know if you need to update yours.

Richard

On 11/29/2012 08:45 AM, Duncan Brown wrote:
> Hello All
>
> I'm not a huge fan of the current mythtv logging method which results in
> huge amounts of separate log files, so I've changed to using syslog.
>
> This involves changing the command in init.d/mythbackend to "--syslog
> local7" instead of "--logpath /var/log/mythtv/"
>
> This works great, but every time I upgrade the init.d file is
> overwritten. Is there anyway of stopping that file being overwritten by
> the upgrade each time?

System local stuff belongs in /etc/sysconfig/mythbackend

(at least it used to, I'm still running Fedora 14 on my mythtv backend
server.)

You might have to get the --logfile stuff parameterized such that you
could override it with something in /etc/sysconfig/mythbackend in the
distribution first....

> cheers
>
> Dunc

--
Kevin J. Cummings
kjchome@verizon.net
cummings@kjchome.homeip.net
cummings@kjc386.framingham.ma.us
Registered Linux User #1232 (http://www.linuxcounter.net/)

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

John Pilkington wrote at about 16:30:15 +0000 on Thursday, November 29, 2012:
> On 29/11/12 13:45, Duncan Brown wrote:
> > Hello All
> >
> > I'm not a huge fan of the current mythtv logging method which results in
> > huge amounts of separate log files, so I've changed to using syslog.
> >
> > This involves changing the command in init.d/mythbackend to "--syslog
> > local7" instead of "--logpath /var/log/mythtv/"
> >
> > This works great, but every time I upgrade the init.d file is
> > overwritten. Is there anyway of stopping that file being overwritten by
> > the upgrade each time?
> >
> > cheers
> >
> > Dunc
> >
>
> I probably ought to let someone with a /good/ suggestion come in here,
> but I keep copies of foo_distrib.bar and foo_my.bar
>
> After an upgrade, if diff foo.bar foo_distrib.bar is null,
> cp foo_my.bar foo.bar
>
> If the diff isn't null, some investigation is needed.
>
> I doubt that it's rigorously correct but it seems to work.
>

I do a similar thing but I go a step further.
Whenever I modify a config file, I copy the original to
config_file.xorig.
Then I edit a copy of it as config_file.xnew.
Finally, I symbolically link config_file -> config_file.xnew

Whenever a new install occurs, it will write over the link.
So, all I need to do is search for places where config_file.xnew is no
longer linked to config_file and I know that some new version has
overwritten my config files.

I have written a script that goes through my /etc tree (and other
relevant places) looking for such broken links. Actually, my script
also checks to make sure that the permissions, ownership, and SELinux
parameters are consistent across the versions...

Hope this is helpful...

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On 29/11/2012 21:33, Kevin J. Cummings wrote:
> On 11/29/2012 08:45 AM, Duncan Brown wrote:
>> Hello All
>>
>> I'm not a huge fan of the current mythtv logging method which results in
>> huge amounts of separate log files, so I've changed to using syslog.
>>
>> This involves changing the command in init.d/mythbackend to "--syslog
>> local7" instead of "--logpath /var/log/mythtv/"
>>
>> This works great, but every time I upgrade the init.d file is
>> overwritten. Is there anyway of stopping that file being overwritten by
>> the upgrade each time?
> System local stuff belongs in /etc/sysconfig/mythbackend
>
> (at least it used to, I'm still running Fedora 14 on my mythtv backend
> server.)
>
> You might have to get the --logfile stuff parameterized such that you
> could override it with something in /etc/sysconfig/mythbackend in the
> distribution first....
>
>> cheers
>>
>> Dunc
Thanks for all the suggestions guys, I imagine I'll be using a
combination of the lot!

cheers

Dunc

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users