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

Re: masked service file



On Wed, Sep 01, 2021 at 07:54:02PM +0100, Brian wrote:
> As a non-professional sysadmin, this "Brian person" is wondering why
> the OP's question (clearly relating to saned) is sidelined in favour
> of other concerns.

I'm not sure *what* the OP's question really is.  They're on an X-Y
tangent about masking, which is extremely irritating to me, since they
aren't giving enough information even to be able to answer the tangential
question, let alone to solve the original problem.

We can't do *anything* with the lack of information we're being given.

>  > Why would a service file be masked ?

1) Because it was installed that way by the package.

2) Because something masked it:

 * Because a human being maksed it, by running one of multiple possible
   commands.

 * Because some other package masked it in their post-install script,
   for reasons I can only begin to guess.

 * Because some system event occurred which caused the masking to occur,
   perhaps as a failure mode, to prevent some sort of catastrophe.

Who the hell knows?  Maybe if we had some *details* we might be able to
formulate a guess.

>  > Can I find out why it's masked ?

There is no command which will simply spit out that information.

Learning "why" something happened requires an investigation, and time
and effort, and often luck.  In many cases, we never know for sure.

>  > Can I just unmask it or do I need to find a working service file first?

If we knew what "it" was, it's possible that someone with expertise
in the field of "it" might know the answer to that.

If we assume that "it" is something with the word "sane" in its name,
then that person is probably Brian.

Given the pieces we've got, it's possible that the service name in question
is something like "sane.service" or "saned.service".  We could plug those
filenames into packages.debian.org to search for which package they
come from.  If we find the package, then we could read its documentation,
and maybe the documentation will tell us how the package is intended to
be used, what the service in question does, and why it might be masked
under certain (or all) circumstances.

Or we might read the service unit file itself, and there could be comments
inside it which might tell us something.  One of the fields in a unit
file is even explicitly reserved for telling the sysadmin which man page
to read to understand the service.

(That same information is also presented by "systemctl status", which is
one of the pieces of information we requested *multiple* times, and did
not get.)

But sure, OP, keep on not providing information.  It's so useful.  It's
getting you such high quality answers.


Reply to: