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

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

Re: what binds to port

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

  Re: what binds to port Dan Ritter <dsr@randomstring.org> - 2021-07-30 13:10 +0200
    Re: what binds to port IL Ka <kazakevichilya@gmail.com> - 2021-07-30 13:30 +0200
      Re: what binds to port Greg Wooledge <greg@wooledge.org> - 2021-07-30 14:00 +0200
        Re: what binds to port IL Ka <kazakevichilya@gmail.com> - 2021-07-30 14:50 +0200
    Re: what binds to port Greg Wooledge <greg@wooledge.org> - 2021-07-30 13:50 +0200
      Re: what binds to port <tomas@tuxteam.de> - 2021-07-30 16:40 +0200
        Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-07-30 19:40 +0200
          Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-07-31 14:20 +0200
            Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-07-31 17:40 +0200
              Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-07-31 19:10 +0200
            Re: what binds to port Brian <ad44@cityscape.co.uk> - 2021-07-31 18:50 +0200
              Re: what binds to port songbird <songbird@anthive.com> - 2021-08-01 17:30 +0200
                Re: what binds to port Greg Wooledge <greg@wooledge.org> - 2021-08-01 17:40 +0200
                  Re: what binds to port Dan Ritter <dsr@randomstring.org> - 2021-08-01 18:00 +0200

#237915 — Re: what binds to port

mick crane wrote: 
> Can I assume there is something else binding to the scanner address ?
> How to find out what that might be ?


sudo netstat -ltp|grep sane-port

should tell you the PID and name of the process.

-dsr-

[toc] | [next] | [standalone]

#237916

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

>
> sudo netstat -ltp|grep sane-port
>

or

$ sudo ss -l4pon | grep [port]

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

#237919

On Fri, Jul 30, 2021 at 02:27:19PM +0300, IL Ka wrote:
> >
> > sudo netstat -ltp|grep sane-port
> >
> 
> or
> 
> $ sudo ss -l4pon | grep [port]

That grep command is wrong in a couple ways.

First, the unquoted [port] is a live glob pattern for the shell.  The
shell will look for files in the current working directory named "p"
or "o" or "r" or "t".  If it finds one or more of those, it will replace
the [port] glob with the list of the matching filenames, sorted by
your locale's collating order.

Second, even if [port] is quoted or doesn't match any files in the
current directory, grep is going to treat is as "match any line that
contains the letter p or the letter o or the letter r or the letter t".
That's going to generate way more matches than you probably want.

I believe what you were aiming for is this hack:

grep [p]ort

This is one of the cargo cult tricks that people use when they're
looking for a process in the output of ps.  Most people don't even
understand it; they just tried it once and it "worked" so they keep
doing it.

You apparently only half-remembered the trick, so you got it wrong.

Even worse, you applied the trick in a context where it isn't even
necessary.  You're not looking for processes in the output of ps, so
you didn't need to stop grep from finding itself by mangling the pattern.

Finally, you added the -n option to ss, which means it no longer prints
service names; it prints port numbers instead.  So the output is no
longer going to contain the word "sane-port", and therefore your grep
for "port" won't work.

(And now that I've written all of this, it occurs to me that maybe
you were using [port] as a syntactic symbol meaning "put the numeric
port number here".  Normally we'd use <port> or _port_ for that.  Or
else you'd actually type out the numeric equivalent of sane-port, so
the reader doesn't have to look it up themselves.  Square brackets
are reserved for "this is an optional argument", or else they're literal.)

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

#237921

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

>
> > $ sudo ss -l4pon | grep [port]
>
> That grep command is wrong in a couple ways.
>
> First, the unquoted [port] is a live glob pattern for the shell.


I meant port number here, i.e.:
$ sudo ss -l4pon | grep 80


> Finally, you added the -n option to ss, which means it no longer prints
> service names; it prints port numbers instead.


Exactly, because I had a port number in my mind


> (And now that I've written all of this, it occurs to me that maybe
> you were using [port] as a syntactic symbol meaning "put the numeric
> port number here".  Normally we'd use <port> or _port_ for that.


Yes, you are right. I should have written it as <port>, not [port].
Sorry for the misleading comment.

I was trying to say that in modern Linux netstat is not installed by default
and ``ss`` is a preferred way.

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

#237918

On Fri, Jul 30, 2021 at 12:37:40PM +0100, mick crane wrote:
> On 2021-07-30 11:59, Dan Ritter wrote:
> > mick crane wrote:
> > > Can I assume there is something else binding to the scanner address ?
> > > How to find out what that might be ?
> > 
> > 
> > sudo netstat -ltp|grep sane-port
> > 
> > should tell you the PID and name of the process.
> 
> it's inetd
> tcp        0      0 0.0.0.0:sane-port       0.0.0.0:*               LISTEN
> 869/inetd
> 
> Is this to be expected or might it be something to do with network manager ?

At this point, you look at your inetd.conf file and see what's in there.

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

#237924

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

On Fri, Jul 30, 2021 at 03:21:47PM +0100, mick crane wrote:
> >>> > Can I assume there is something else binding to the scanner address ?

[...]

> >>it's inetd
> >>tcp        0      0 0.0.0.0:sane-port       0.0.0.0:*
> >>LISTEN
> >>869/inetd

[...]

> The only thing not commented out is
> sane-port stream tcp nowait saned /usr/sbin/scanbm scanbm
> 
> The scanbd installer package must have put it there.
> I'm thinking inetd is the thing that is watching and tells scanbm to
> wake up.

Exactly: that's inetd's job (well, it used to be, until
systemd "reinvented" it).

Cheers
 - t

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

#237931

On Fri 30 Jul 2021 at 17:47:50 +0100, mick crane wrote:

> On 2021-07-30 15:36, tomas@tuxteam.de wrote:
> > On Fri, Jul 30, 2021 at 03:21:47PM +0100, mick crane wrote:
> > > >>> > Can I assume there is something else binding to the scanner address ?
> > 
> > [...]
> > 
> > > >>it's inetd
> > > >>tcp        0      0 0.0.0.0:sane-port       0.0.0.0:*
> > > >>LISTEN
> > > >>869/inetd
> > 
> > [...]
> > 
> > > The only thing not commented out is
> > > sane-port stream tcp nowait saned /usr/sbin/scanbm scanbm
> > > 
> > > The scanbd installer package must have put it there.
> > > I'm thinking inetd is the thing that is watching and tells scanbm to
> > > wake up.
> > 
> > Exactly: that's inetd's job (well, it used to be, until
> > systemd "reinvented" it).
> > 
> > Cheers
> >  - t
> 
> This is getting silly. Why have I got 2 scanners

You do not have two scanners. You have a single scanner capable of
using two different SANE backends, fujitsu: and escl:. Actually, you
are using a third backend, net:, too.

> mick@pumpkin:~$ scanimage -L
> device `net:localhost:fujitsu:fi-5750Cdj:107245' is a FUJITSU fi-5750Cdj
> scanner
> device `net:localhost:escl:fi-5750Cdj:107245' is a FUJITSU fi-5750Cdj
> scanner
> mick@pumpkin:~$
> what is this "escl" one?

Your are using bullseye. It comes with the territory.

  https://wiki.debian.org/SaneOverNetwork#escl

I might have missed it, but did you ever say in this thread what the
device is?

> How hard is it to get rid of this systemd and helper things stuff ?

Rhetorical, I hope? You haven't any evidence to believe it is the
source of any of your difficulties. User disparagement doesn't count.

> I like things to work but I'm quite capable  of breaking things on my own.

A sound principal for anyone to take note of.

-- 
Brian.

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

#237944

On Sat 31 Jul 2021 at 10:20:43 +0100, mick crane wrote:

> On 2021-07-30 18:30, Brian wrote:
> <...>
> >   https://wiki.debian.org/SaneOverNetwork#escl
> looking at those informative pages I think /dev/sg2 is the scanner
> should that not be in group scanner ?
> 
> root@pumpkin:/# ls -l /dev |grep cdrom
> lrwxrwxrwx  1 root root           3 Jul 30 17:36 cdrom -> sr0
> crw-rw----+ 1 root cdrom    21,   2 Jul 30 17:36 sg2
> brw-rw----+ 1 root cdrom    11,   0 Jul 30 17:36 sr0

I don't see why it should be. I too have

  crw-rw----+ 1 root cdrom    21,   2 Jul 30 17:36 sg1

on bullseye. Note the +. Its an ACL. systemd, and libpam-systemd have
taken care of the correct permissions on the scanner device file. Try

  getfacl /dev/sg2

(Did you ever say in this thread what the printer/scanner is?)

-- 
Brian.

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

#237951

On Sat 31 Jul 2021 at 14:37:49 +0100, mick crane wrote:

> On 2021-07-31 13:18, Brian wrote:
> > On Sat 31 Jul 2021 at 10:20:43 +0100, mick crane wrote:
> > 
> > > On 2021-07-30 18:30, Brian wrote:
> > > <...>
> > > >   https://wiki.debian.org/SaneOverNetwork#escl
> > > looking at those informative pages I think /dev/sg2 is the scanner
> > > should that not be in group scanner ?
> > > 
> > > root@pumpkin:/# ls -l /dev |grep cdrom
> > > lrwxrwxrwx  1 root root           3 Jul 30 17:36 cdrom -> sr0
> > > crw-rw----+ 1 root cdrom    21,   2 Jul 30 17:36 sg2
> > > brw-rw----+ 1 root cdrom    11,   0 Jul 30 17:36 sr0
> > 
> > I don't see why it should be. I too have
> > 
> >   crw-rw----+ 1 root cdrom    21,   2 Jul 30 17:36 sg1
> > 
> > on bullseye. Note the +. Its an ACL. systemd, and libpam-systemd have
> > taken care of the correct permissions on the scanner device file. Try
> > 
> >   getfacl /dev/sg2
> > 
> > (Did you ever say in this thread what the printer/scanner is?)
> 
> I thought it was in there, it's fujitsu fi-5750c

Thanks. The device appears to date from about 2007. I am surprised
that SANE's escl backend detects it and that scanning with

  xsane "escl:fi-5750Cdj:107245"

is possible. (Just a comment and nothing to do with your issues).

> The scanbd.conf says
> user saned
> group scanner

It is the saned user that has to be in the scanner group, not your
user.

  grep scanner /etc/groups
  cat /etc/default/saned

> I'm wondering if this is why I'm having difficulty saving scans anywhere
> other than /tmp
> and getting permission denied writing to a file with a script both in
> /etc/scanbd/scripts called from scanbd.conf

Probably not.

> How to find which is the scanner in /dev if it is supposed to be there?
> Xsane works fine.

I thought it was /dev/sg2.

-- 
Brian.

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

#237955

On Sat 31 Jul 2021 at 17:17:29 +0100, mick crane wrote:

> On 2021-07-31 16:32, Brian wrote:
> 
> >   grep scanner /etc/groups
> >   cat /etc/default/saned
> > 
> I keep thinking it should be groups and not group as well.

An embarassing typo :).

> me and saned are in scanner group
> /etc/default/saned
> RUN_AS_USER=saned

You do not need to be in the scanner group. This requirement disappeared
years ago but it still gets repeated (ad nauseam). See

  https://wiki.debian.org/Scanner#perms

> > > How to find which is the scanner in /dev if it is supposed to be
> > > there?
> > > Xsane works fine.
> > 
> > I thought it was /dev/sg2.
> I said I thought it might be sg2 and wondered how to find out.

Scanners are treated as SCSI devices and therefore come under /dev/sg*.
Look for the + and use getfacl.

As a really naff method, move the device file out of the way and see
whether you can scan.

-- 
Brian.

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

#237954

On Sat 31 Jul 2021 at 16:57:53 +0100, mick crane wrote:

> On 2021-07-31 14:37, mick crane wrote:
> when I say Xsane works fine.
> All I've deleted as far as I know are the .conf files for scanners I don't
> have.
> 
> In /etc/sane.d/dll.conf
> I removed all scanner names except
> net
> fujitsu
> #escl

That's OK.
 
> running Xsane I get to select
> fujitsu or net:localhost.. both of which work

I'd expect this too.

> but if I comment out fujitsu Xsane says "no devices available"
> /etc/sane.d/net.conf
> connect_timeout = 3
> localhost
> 
> Which I'm not understanding.

the net backend is for accessing another backend, either remotely or
on localhost. If you comment out fujitsu on localhost, there isn't
any suitable backend on localhost to contact and use the scanner.

-- 
Brian.

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

#237983

mick crane wrote:
> On 2021-07-31 17:40, Brian wrote:
><...>
> Doh! discovered have to restart scanbd.service after changing config 
> file.
> You'd have thought I would know that.
> changing group to scanner of directory want to save to seems to have 
> fixed permission issue.
> mick

  some will restart automatically when their config file changes
and others don't.  you have to know which do and which don't
since this isn't a universal feature yet.  preferably i do not
want things to reload unless i specifically tell them to just
in case i'm relying upon that process for something critical
until i've got everything synced up and then i restart or reboot
and all should be ok.


  songbird

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

#237985

On Sun, Aug 01, 2021 at 10:41:13AM -0400, songbird wrote:
> mick crane wrote:
> > Doh! discovered have to restart scanbd.service after changing config 
> > file.
> > You'd have thought I would know that.
> 
>   some will restart automatically when their config file changes
> and others don't.  you have to know which do and which don't
> since this isn't a universal feature yet.

Very few programs poll for changes to their configuration files.  That
would be a sloppy design.

If a program runs as a daemon (really running, i.e. you can see the
process in the output of ps -ef), and you change its configuration file,
you will typically need to take some action to notify the daemon that a
change has occurred.  This action may be sending a SIGHUP to the running
daemon, or it may be restarting the daemon.

If on the other hand a program is *not* continuously running as a daemon,
but is instead started on demand (e.g. by inetd or by systemd's socket
activation), then there's no need to take any action when the configuration
is changed.  The next instance of the program that gets launched will
by necessity read the configuration file.

So, in almost all cases, it's sufficient to figure out which of these
two designs you're dealing with.  Ideally, the documentation (the man
page) of the daemon will tell you.  In some cases, there are multiple
ways the service can be implemented (sshd comes to mind), and so the
man page has to list *both* possibilities, and *you* as the sysadmin
have to know which one is actually being used on your system.

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

#237987

Greg Wooledge wrote: 
> On Sun, Aug 01, 2021 at 10:41:13AM -0400, songbird wrote:
> > mick crane wrote:
> > > Doh! discovered have to restart scanbd.service after changing config 
> > > file.
> > > You'd have thought I would know that.
> > 
> >   some will restart automatically when their config file changes
> > and others don't.  you have to know which do and which don't
> > since this isn't a universal feature yet.
> 
> Very few programs poll for changes to their configuration files.  That
> would be a sloppy design.

The reason that this is a sloppy design is because editing a config file by hand
will inevitably lead to invalid configs.

Some long-running daemons instead listen for a signal to tell
them to re-load their config file without shutting down. The
really good ones run a syntax checker before trying to run the
new config, and emit an error message but continue on the old
config when the new one fails.

A daemon which is very quick to start and stop probably doesn't
implement that at all.

-dsr-

[toc] | [prev] | [standalone]

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

csiph-web