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

Re: masked service file



On 2021-09-01 16:22, Greg Wooledge wrote:
On Wed, Sep 01, 2021 at 04:06:37PM +0100, mick crane wrote:
On 2021-09-01 15:15, Brian wrote:
> * saned is socket activated.
> * saned@.service manages saned instances.
> * saned.service is masked because it is an empty file.
> * The file is empty to allow all instances to be managed together.

Sounds informative.  Maybe thie Brian person knows a thing or two about
saned and you should consider listening.

bit presumptive of you

I reinstalled the OS because I didn't like the LVM and also I wanted it to
be EFI and not BIOS.
So thought I'd install Bookworm as I'm about it, got loads of errors purging saned and scanbd, trying to get scanning to work again, something about
files not really being files.
I gave up and have reinstalled Bullseye as I know that works.
It's only a day to put everything back as I like, or maybe a bit more.

Backstory.  Probably irrelevant.

by way of closing thread as now irrelevant

My original question was why do things get masked.

Because the package maintainer thought it was a good idea, or because
you, the system administrator, thought it was a good idea.

You seem to think you can ask some kind of generic meta-question about
masking and get a meaningful answer.

You can't.

You need SPECIFIC information about a SPECIFIC situation.

YOUR situation.

Pretending that the details of your situation don't matter is ludicrous.

I would tend to disagree with that assertion as the software is confined within a structure
and things are easier to understand if you understand the structure.

"Systemctl status the-service" was saying it's masked because it's masked

YOU CANNOT FUDGE THE SERVICE NAMES IN YOUR REQUESTS FOR HELP!

Show the ACTUAL command you ran.  Show its ACTUAL output.


which is not very informative but it must be a nightmare for the maintainers
to cover all eventualities.

Well, what do you EXPECT?

Do you think your init system has some way to know WHY it was given a
command? And that it stores these reasons somewhere, and can cough them
up on demand?

Do you ask your shell why the user typed "ls /tmp"?  What do you expect
the shell to do -- guess the user's intentions?

Do you ask your email program why someone sent you a piece of email?

Do you ask your web browser why the URL you tried to visit has a 404 error?

"Why" is not generally a thing that computer programs understand.

we are not yet mechanical units until everybody has been jabbed.
=o)
mick

--
Key ID    4BFEBB31


Reply to: