Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #239537 > unrolled thread

masked service file

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  masked service file mick crane <mick.crane@gmail.com> - 2021-08-31 19:40 +0200
    Re: masked service file john doe <johndoe65534@mail.com> - 2021-08-31 19:50 +0200
      Re: masked service file Greg Wooledge <greg@wooledge.org> - 2021-08-31 20:50 +0200
        Re: masked service file Brian <ad44@cityscape.co.uk> - 2021-08-31 21:00 +0200
          Re: masked service file Greg Wooledge <greg@wooledge.org> - 2021-08-31 21:30 +0200
            Re: masked service file Brian <ad44@cityscape.co.uk> - 2021-09-01 00:20 +0200
              Re: masked service file Brian <ad44@cityscape.co.uk> - 2021-09-01 16:20 +0200
                Re: masked service file Greg Wooledge <greg@wooledge.org> - 2021-09-01 17:30 +0200
                  Re: masked service file Dan Ritter <dsr@randomstring.org> - 2021-09-01 20:00 +0200
                    Re: masked service file Greg Wooledge <greg@wooledge.org> - 2021-09-01 20:10 +0200
                    Re: masked service file Brian <ad44@cityscape.co.uk> - 2021-09-01 21:00 +0200
                      Re: masked service file Greg Wooledge <greg@wooledge.org> - 2021-09-01 21:20 +0200
                        Re: masked service file "Andrew M.A. Cater" <amacater@einval.com> - 2021-09-05 16:00 +0200
                          Re: masked service file <tomas@tuxteam.de> - 2021-09-05 17:10 +0200
                            Re: masked service file Curt <curty@free.fr> - 2021-09-08 18:10 +0200
                            Re: masked service file <tomas@tuxteam.de> - 2021-09-08 18:10 +0200
                  Re: masked service file Curt <curty@free.fr> - 2021-09-02 12:00 +0200
                    Re: masked service file Greg Wooledge <greg@wooledge.org> - 2021-09-02 17:30 +0200
                      Re: masked service file Brian <ad44@cityscape.co.uk> - 2021-09-02 19:00 +0200
                        Re: masked service file Brian <ad44@cityscape.co.uk> - 2021-09-03 00:30 +0200
                          Re: masked service file Brian <ad44@cityscape.co.uk> - 2021-09-03 01:30 +0200

Page 1 of 2  [1] 2  Next page →

#239537 — masked service file

Since I didn't really need LVM and I wasn't thrilled with having the 
intrid.img at 70,000000 bytes big I installed bookworm afresh.
After installing all the software I might want it's grown from 13,000000 
to 30,000000 but that's OK.
Most things are back working except having some bother with the scanner 
which seems to be because the saned service file is masked. I don't know 
if it came masked or is something I've done.

Why would a service file be masked ?
Can I find out why it's masked ?
Can I just unmask it or do I need to find a working service file first?

regards

mick

-- 
Key ID    4BFEBB31

[toc] | [next] | [standalone]

#239538

On 8/31/2021 7:36 PM, mick crane wrote:
> Since I didn't really need LVM and I wasn't thrilled with having the
> intrid.img at 70,000000 bytes big I installed bookworm afresh.
> After installing all the software I might want it's grown from 13,000000
> to 30,000000 but that's OK.
> Most things are back working except having some bother with the scanner
> which seems to be because the saned service file is masked. I don't know
> if it came masked or is something I've done.
>
> Why would a service file be masked ?

To have it fully disabled ('stop', 'disable', 'mask').

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

You can simply 'unmask' it and see how it goes.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#239541

On Tue, Aug 31, 2021 at 07:31:22PM +0100, mick crane wrote:
> On 2021-08-31 18:49, john doe wrote:
> > You can simply 'unmask' it and see how it goes.
> 
> Is there a way to find out why it is masked ?

Starting from a point of zero context?  Probably not.

You MIGHT be able to scroll back through your terminal history and
see what happened when you installed whatever package contains this
mystery service.  Maybe there will be informative output.

If there's no terminal still containing the session where you installed
the package, you can check /var/log/apt/term.log* and maybe one of those
will have a copy of the session and its output.  Again, maybe there will
be informative output in the session's output.  Maybe there won't.

Maybe there will be documentation under /usr/share/doc/PKGNAME that
tells you why the service is masked, and that you need to perform steps
X, Y, Z to be able to use the service.  Maybe there won't.  Hard to tell
without knowing the name of the package and the name of the service.

[toc] | [prev] | [next] | [standalone]

#239543

On Tue 31 Aug 2021 at 14:48:02 -0400, Greg Wooledge wrote:

> On Tue, Aug 31, 2021 at 07:31:22PM +0100, mick crane wrote:
> > On 2021-08-31 18:49, john doe wrote:
> > > You can simply 'unmask' it and see how it goes.
> > 
> > Is there a way to find out why it is masked ?
> 
> Starting from a point of zero context?  Probably not.
> 
> You MIGHT be able to scroll back through your terminal history and
> see what happened when you installed whatever package contains this
> mystery service.  Maybe there will be informative output.
> 
> If there's no terminal still containing the session where you installed
> the package, you can check /var/log/apt/term.log* and maybe one of those
> will have a copy of the session and its output.  Again, maybe there will
> be informative output in the session's output.  Maybe there won't.
> 
> Maybe there will be documentation under /usr/share/doc/PKGNAME that
> tells you why the service is masked, and that you need to perform steps
> X, Y, Z to be able to use the service.  Maybe there won't.  Hard to tell
> without knowing the name of the package and the name of the service.

The OP doesn't say whether he can scan or or not.

He could give the name of the scanner he is using and what is given
by

  scanimage -L

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#239544

On Tue, Aug 31, 2021 at 07:54:43PM +0100, Brian wrote:
> On Tue 31 Aug 2021 at 14:48:02 -0400, Greg Wooledge wrote:
> 
> > On Tue, Aug 31, 2021 at 07:31:22PM +0100, mick crane wrote:
> > > On 2021-08-31 18:49, john doe wrote:
> > > > You can simply 'unmask' it and see how it goes.
> > > 
> > > Is there a way to find out why it is masked ?
> > 
> > Starting from a point of zero context?  Probably not.
> > 
> > You MIGHT be able to scroll back through your terminal history and
> > see what happened when you installed whatever package contains this
> > mystery service.  Maybe there will be informative output.
> > 
> > If there's no terminal still containing the session where you installed
> > the package, you can check /var/log/apt/term.log* and maybe one of those
> > will have a copy of the session and its output.  Again, maybe there will
> > be informative output in the session's output.  Maybe there won't.
> > 
> > Maybe there will be documentation under /usr/share/doc/PKGNAME that
> > tells you why the service is masked, and that you need to perform steps
> > X, Y, Z to be able to use the service.  Maybe there won't.  Hard to tell
> > without knowing the name of the package and the name of the service.
> 
> The OP doesn't say whether he can scan or or not.
> 
> He could give the name of the scanner he is using and what is given
> by
> 
>   scanimage -L

It would also be nice to see "systemctl status <servicename>".

[toc] | [prev] | [next] | [standalone]

#239547

On Tue 31 Aug 2021 at 15:27:13 -0400, Greg Wooledge wrote:

> On Tue, Aug 31, 2021 at 07:54:43PM +0100, Brian wrote:
> > On Tue 31 Aug 2021 at 14:48:02 -0400, Greg Wooledge wrote:
> > 
> > > On Tue, Aug 31, 2021 at 07:31:22PM +0100, mick crane wrote:
> > > > On 2021-08-31 18:49, john doe wrote:
> > > > > You can simply 'unmask' it and see how it goes.
> > > > 
> > > > Is there a way to find out why it is masked ?
> > > 
> > > Starting from a point of zero context?  Probably not.
> > > 
> > > You MIGHT be able to scroll back through your terminal history and
> > > see what happened when you installed whatever package contains this
> > > mystery service.  Maybe there will be informative output.
> > > 
> > > If there's no terminal still containing the session where you installed
> > > the package, you can check /var/log/apt/term.log* and maybe one of those
> > > will have a copy of the session and its output.  Again, maybe there will
> > > be informative output in the session's output.  Maybe there won't.
> > > 
> > > Maybe there will be documentation under /usr/share/doc/PKGNAME that
> > > tells you why the service is masked, and that you need to perform steps
> > > X, Y, Z to be able to use the service.  Maybe there won't.  Hard to tell
> > > without knowing the name of the package and the name of the service.
> > 
> > The OP doesn't say whether he can scan or or not.
> > 
> > He could give the name of the scanner he is using and what is given
> > by
> > 
> >   scanimage -L
> 
> It would also be nice to see "systemctl status <servicename>".

And even
 
 systemctl status saned.socket

 and 

 systemctl status saned@.service"

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#239559

On Tue 31 Aug 2021 at 23:15:22 +0100, Brian wrote:

> On Tue 31 Aug 2021 at 15:27:13 -0400, Greg Wooledge wrote:
> 
> > On Tue, Aug 31, 2021 at 07:54:43PM +0100, Brian wrote:
> > > 
> > > The OP doesn't say whether he can scan or or not.
> > > 
> > > He could give the name of the scanner he is using and what is given
> > > by
> > > 
> > >   scanimage -L
> > 
> > It would also be nice to see "systemctl status <servicename>".
> 
> And even
>  
>  systemctl status saned.socket
> 
>  and 
> 
>  systemctl status saned@.service

* 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.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#239561

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.

> 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.

> 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.

> "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.

[toc] | [prev] | [next] | [standalone]

#239570

Greg Wooledge wrote: 
> On Wed, Sep 01, 2021 at 04:06:37PM +0100, mick crane wrote:
> 
> 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?

Speaking as a professional sysadmin, I would welcome a required
comment field on many system altering commands, so that a log
could be kept and spit back on demand.

# service saned status
saned is not running
20210704 14:02:33 user root stopped saned saying "interfering with new printer?"

Yeah, that would be nice.

-dsr-

[toc] | [prev] | [next] | [standalone]

#239571

On Wed, Sep 01, 2021 at 01:52:21PM -0400, Dan Ritter wrote:
> Greg Wooledge wrote: 
> > On Wed, Sep 01, 2021 at 04:06:37PM +0100, mick crane wrote:
> > 
> > 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?
> 
> Speaking as a professional sysadmin, I would welcome a required
> comment field on many system altering commands, so that a log
> could be kept and spit back on demand.
> 
> # service saned status
> saned is not running
> 20210704 14:02:33 user root stopped saned saying "interfering with new printer?"
> 
> Yeah, that would be nice.

I'd imagine that in practice, most people would put nothing, or "x", as
the reason, if they had to type a reason after every single command
they run as root.

That said, one of the data points you *can* get out of Debian for most
events is *when* they happened.  If mick crane wanted to ask *when*
the service was masked, and if they'd tell us the frickin' NAME of the
service they're asking about, we could probably tell them how to discover
when the service was masked.

In many cases, the timing can be a vital clue in one's explorations.

[toc] | [prev] | [next] | [standalone]

#239572

On Wed 01 Sep 2021 at 13:52:21 -0400, Dan Ritter wrote:

> Greg Wooledge wrote: 
> > On Wed, Sep 01, 2021 at 04:06:37PM +0100, mick crane wrote:
> > 
> > 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?
> 
> Speaking as a professional sysadmin, I would welcome a required
> comment field on many system altering commands, so that a log
> could be kept and spit back on demand.
> 
> # service saned status
> saned is not running
> 20210704 14:02:33 user root stopped saned saying "interfering with new printer?"
> 
> Yeah, that would be nice.

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.

A reminder:

 > Why would a service file be masked ?
 > Can I find out why it's masked ?
 > Can I just unmask it or do I need to find a working service file first?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#239574

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.

[toc] | [prev] | [next] | [standalone]

#239716

On Wed, Sep 01, 2021 at 03:09:59PM -0400, Greg Wooledge wrote:
> 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.
> 
> 
> 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 ?
> 
> But sure, OP, keep on not providing information.  It's so useful.  It's
> getting you such high quality answers.
> 

People in general == all the contributors to this thread.

I can sense the exasperation: I can feel the tension. Believe me, I understand
where you are all coming from

BUT

You've prompted my (almost weekly) reminder to 

* adhere to the code of conduct.

* play the ball not the man - don't engage in disguised personal attacks

* step aside from emotion and ask technical questions dispassionately and
  clearly

* make this mailing list a worthwhile place to read

There is a space for frustration and annoyance that somehow, despite your
very best efforts, the person typing at the other end doesn't "get it" no
matter how clear you are - but it's a general annoyance that you can't
get across what you know to help them, rather than hitting out at someone.

There's a minimal space for banter and back and forth comments and being able
to rely on regular commenters to answer - and an inward feeling of "Oh, no, 
not THAT topic again from THAT person" when some things come out again for
the Nth time -  but no space for belittling people for what they do/do not
know or contribute.

There's a space for knowing when to stop, when to not hit reply, when to
step away from the keyboard or give it up as a lost cause. That step might
be to be silent - or it might be a chance to put in a reflective comment on
"The following topics come up regularly" and a collected summation of
several discussions.

There is space for a better "How to ask meaningful questions" topic
either here or in wiki.debian.org. There's certainly space for a better
"These come up regularly FAQ" but there isn't really space from experienced 
folk for some of the behaviour that happens here.

For the avoidance of doubt: I can be (and have been) guilty of a lot of the
less good behaviour outlined above on various lists and forums over the years
- this is not a holier than thou post - but it's sometimes good to look back 
dispassionately and see what impression some threads leave. 

I'm also more than willing to try and draft better FAQs.

With every good wish, as ever,

Andy Cater

[As a member of the Community Team]

[toc] | [prev] | [next] | [standalone]

#239718

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 05, 2021 at 01:56:30PM +0000, Andrew M.A. Cater wrote:

[...]

> * play the ball not the man - don't engage in disguised personal attacks

Yes, pretty please.

Thank you, Andrew.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#239795

On 2021-09-05, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
>
>
>> * play the ball not the man - don't engage in disguised personal attacks
>
> Yes, pretty please.
>

Yep. Never disguise your personal attacks.

[toc] | [prev] | [next] | [standalone]

#239796

[Multipart message — attachments visible in raw view] — view raw

On Wed, Sep 08, 2021 at 03:55:25PM +0100, mick crane wrote:
> On 2021-09-05 16:01, tomas@tuxteam.de wrote:
> >On Sun, Sep 05, 2021 at 01:56:30PM +0000, Andrew M.A. Cater wrote:
> >
> >[...]
> >
> >>* play the ball not the man - don't engage in disguised personal
> >>attacks
> >
> >Yes, pretty please.
> >
> >Thank you, Andrew.
> 
> I am the OP

Oops. Sorry for the mis-attribution. So thank, you, Mick.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#239583

On 2021-09-01, mick crane <mick.crane@gmail.com> wrote:
> 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
>
>

It's not presumptive, it's empirical. Our veteran participants get a
sense of who knows what about what over time, observationally (and who,
of course, inversely, is totally full of shit).

As always, separating the wheat from the chaff is left as the
traditional human exercise.

[toc] | [prev] | [next] | [standalone]

#239585

On Thu, Sep 02, 2021 at 04:13:34PM +0100, mick crane wrote:
> I'll just presume you are grumpy because you have had the jab.

Please stop.

Take a breath.  In.  Out.

Now: what is the problem you're experiencing?  Start with a high level
description: "My scanner doesn't work", for example.

After that introduction, give the background information.  Tell us what
version of Debian you're using, what model the scanner is (assuming it's
a scanner problem), and what software you've installed to try to make
it work.

After that, tell us the *specific* details about your problem.  What
actions are you taking, and what results do you get?  Tell us the exact
commands you're running, and paste their actual output into the email.
If there are relevant log file snippets, paste those into the email.

(I understand that identifying which information is relevant is an art
form.  Mistakes are OK.  Do your best, and if someone asks for more
information, be prepared to include that in a follow-up email.)

[toc] | [prev] | [next] | [standalone]

#239587

On Thu 02 Sep 2021 at 17:05:10 +0100, mick crane wrote:

> On 2021-09-02 16:22, Greg Wooledge wrote:
> > On Thu, Sep 02, 2021 at 04:13:34PM +0100, mick crane wrote:
> > > I'll just presume you are grumpy because you have had the jab.
> > 
> > Please stop.
> > 
> > Take a breath.  In.  Out.
> > 
> > Now: what is the problem you're experiencing?  Start with a high level
> > description: "My scanner doesn't work", for example.
> > 
> > After that introduction, give the background information.  Tell us what
> > version of Debian you're using, what model the scanner is (assuming it's
> > a scanner problem), and what software you've installed to try to make
> > it work.
> > 
> > After that, tell us the *specific* details about your problem.  What
> > actions are you taking, and what results do you get?  Tell us the exact
> > commands you're running, and paste their actual output into the email.
> > If there are relevant log file snippets, paste those into the email.
> > 
> > (I understand that identifying which information is relevant is an art
> > form.  Mistakes are OK.  Do your best, and if someone asks for more
> > information, be prepared to include that in a follow-up email.)
> 
> my original question was a request for self help information as to why a
> service would be masked.

You have been given the reason for the masking: saned.service is an
empty file. See the manual for systemd.unit.

  If a unit file is empty (i.e. has the file size 0) or is
  symlinked to /dev/null, its configuration will not  be loaded
  and it appears with a load state of "masked", and cannot be
  activated. Use this as an effective way to fully disable a unit,
  making it impossible to start it even manually.

The masking is intentional. It is by design. Your question is a
decent one, but understanding why it isn't of any consquence to
managing the saned service needs to be grasped.

> I'm guessing that masking saned service is part of scanbd installation
> because of using inetd or something.

It is nothing to do with inetd. saned.service is not intended to be
used for managing saned. That is the job of saned.socket (in
conjunction with saned@service).

  systemctl stop saned.socket
  systemctl start saned.socket 

> As previously mentioned I was getting so many error messages (Bookworm) that
> I couldn't fathom that reverted installation to Bullseye and everything so
> far is working again.
> Which is what we want.
> mick

Regarding Greg Wooledge's exhortations to provide information about
an issue: You were asked explicity to provide some; you never did.
As it happens, I do not think the problems you have encountered
have anything to do with saned. You have picked the wrong target.

-- 
Brian.


> -- 
> Key ID    4BFEBB31
> 

[toc] | [prev] | [next] | [standalone]

#239598

On Thu 02 Sep 2021 at 21:06:59 +0100, mick crane wrote:

> On 2021-09-02 17:57, Brian wrote:
> 
> > Regarding Greg Wooledge's exhortations to provide information about
> > an issue: You were asked explicity to provide some; you never did.
> > As it happens, I do not think the problems you have encountered
> > have anything to do with saned. You have picked the wrong target.
> 
> What does this even mean "You have picked the wrong target"?
> I've got one guy battering me for specifics when it should be clear what I'm
> saying.
> I've got another guy intimating I'm an idiot.
> I was quite happy when you could work stuff out from the documentation but
> then this systemd came along
> now I haven't a clue what's going on.

Please go back and read your very first post. You asked three questions.
Which one has not been answered?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web