[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: systemd troubleshooting (was ... Re: computer cann't shut down)



On Wed 23 Mar 2016 at 08:16:18 (-0500), John Hasler wrote:
> David Wright writes:
> > you have to take on trust, or check, that bar="some value" is
> > the default configured, or set elsewhere, for foo. OTOH, when
> > you copy /lib/systemd/system/... to /etc, you know you've got
> > hold of the default configuration. IOW, it's self-documenting.
> 
> Why is that better than /etc/systemd/system/halt.target.orig

To answer that, I have to make some unwritten assumptions.

I assume you mean that there will be some files
/etc/systemd/system/foo.target
/etc/systemd/system/bar.target
supplied by Debian, and that when you make a change, you write a new
/etc/systemd/system/foo.target and retain the previous/Debian version
as /etc/systemd/system/foo.target.orig, ok?

Now, every time there's a security fix, you're going to be quizzed
over what to do about your modified configuration file because Debian
wants to overwrite your modified /etc/systemd/system/foo.target.

Or at some time in the future, you decide to revert to the Debian
version. You have to juggle the files /etc/systemd/system/foo.target
and /etc/systemd/system/foo.target.orig instead of just removing
the link /etc/systemd/system/foo.target -> /lib/systemd/system/foo.target

> or
> /usr/share/doc/systemd/system/halt.target.default ?

I wrote "you know you've got hold of the default configuration".
You don't *know* that /usr/share/doc/systemd/system/foo.target.default
is the default configuration; foo never consults it. To *know* whether
it has the same contents, you have to
cmp /usr/share/doc/systemd/system/foo.target.default /lib/systemd/system/foo.target

To revert your change back to the Debian version, it would be foolish
to blindly copy /usr/share/doc/systemd/system/foo.target.default
over /etc/systemd/system/foo.target. Would you accept a bug report
for foo where some of the configuration files being actively used were
merely copies of documentation files?

So I *like* the scheme where /lib/systemd/system/foo.target is the
self-documenting default because the system actually reads that file,
unless the sysadmin has put a link in /etc/systemd/system/foo.target
to override it.

In both your examples, consider how easy it is to tell what changes
you have made over time.

In the first case, you have to list all the /etc files that end with
(you hope) [-.]orig [-.]original [-.]old [-.]previous [-.]default etc.

In the second, you have to cmp all the files in /etc with the files
in /usr/share/doc/systemd/system/ remembering 1) to handle any
file-not-found errors, 2) that you hopefully checked that there *was*
a default in the documentation, and 3) if there wasn't, you wrote one,
but now where did you put it because you can't write to /usr/share/doc.

Cheers,
David.


Reply to: