Re: Transport endpoint is not connected

[Charles Curley]

On Wed, 28 Jun 2023 23:32:56 -0400
hlyg <hlyg...@outlook.com> wrote:

> my usb extension line might cause trouble, it connect to back of pc
> case at one end, at the other end is usb hub, it's handy because it
> turns one usb socket to four sockets, and it works most of time, but
> sometime it can cause trouble, i notice data transfer becomes slow
> thru it

Two thoughts here.

* Does your hub use an external power supply or does it depend on the
computer for power? If the latter, that could be a problem if the
total load exceeds what the computer supplies.

* It could be just a loose connector, although I haven't seen that in a
long time. It is possible to fix this for some types of connectors
(RCA connectors being particularly susceptible) by crimping the
connector very lightly with a pair of pliers.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[David Wright]

On Wed 28 Jun 2023 at 23:32:56 (-0400), hlyg wrote:
> my general impression of bookworm for i386 is slow
>
> i suppose support for i386 becomes poor as its user base shrink

I'm guessing that new releases use more room as they increase in
complexity and functionality. This can result in more swapping,
for example. With bullseye, I ceased trying to run Firefox on an
i386 with 500MB RAM.

> even shutdown is slow, i see it painfully show " Transport endpoint is
> not connected"

So is it waiting for a timeout to expire?

> my usb extension line might cause trouble, it connect to back of pc
> case at one end, at the other end is usb hub, it's handy because it
> turns one usb socket to four sockets, and it works most of time, but
> sometime it can cause trouble, i notice data transfer becomes slow
> thru it
>

> msg in last line is in red, such thing as device name  has been edited
> for privacy (wlx123), usb wifi adapter is connected to usb hub

Do you have other things plugged into the hub with mounted filesystems?
If so, what sort of filesystems?

> Jun 28 20:10:14 debian ifdown[752]: For info, please visit
> https://www.isc.org/software/dhcp/
> Jun 28 20:10:14 debian ifdown[752]: Listening on LPF/wlx123...
> Jun 28 20:10:14 debian ifdown[752]: Sending on   LPF/wlx123...
> Jun 28 20:10:14 debian ifdown[752]: Sending on   Socket/fallback
> Jun 28 20:10:14 debian ifdown[752]: DHCPRELEASE of 192.168.43.89 on
> wlx123 to 192.168.43.208 port 67
> Jun 28 20:10:14 debian systemd-journald[824]: Failed to send READY=1
> notification message: Transport endpoint is not connected

Do you only see this message at closedown?
Do you have any filesystems mounted via the network?

Cheers,
David.

[David Wright]

On Fri 30 Jun 2023 at 13:06:49 (+0800), hlyg wrote:
> Thank David! i suppose it close wifi connection (say goodbye to hot
> spot of cell phone) as i shutdown, i don't have network FS

So I assume you use have a wifi dongle, connected to the hub, that
communicates with the tethered phone's hotspot.

> i don't have usb disk plugged to usb hub

So what's the hub for?

> bookworm for both i386 and amd64 seem uncomfortable with my usb hub.
>
> last few lines below show errors
>
> i am now using bullseye, bookworm isn't stable enough for me

Just because of this hub, or for other reasons? Sorry, but I only see
snippets of information, and no intentions/reasons.

> Jun 27 05:38:10 debian kernel: usb 1-2: new high-speed USB device
> number 2 using ehci-pci
> Jun 27 05:38:10 debian kernel: usb 1-2: New USB device found,
> idVendor=14cd, idProduct=8601, bcdDevice= 0.00
> Jun 27 05:38:10 debian kernel: usb 1-2: New USB device strings: Mfr=1,
> Product=3, SerialNumber=0
> Jun 27 05:38:10 debian kernel: usb 1-2: Product: USB 2.0 Hub
> Jun 27 05:38:10 debian kernel: usb 1-2: Manufacturer: USB Device
> Jun 27 05:38:10 debian kernel: hub 1-2:1.0: USB hub found
> Jun 27 05:38:10 debian kernel: hub 1-2:1.0: 4 ports detected
> Jun 27 05:38:10 debian kernel: usb 1-3: new high-speed USB device
> number 3 using ehci-pci
> Jun 27 05:38:10 debian kernel: usb 1-3: device descriptor read/64, error -71
> Jun 27 05:38:10 debian kernel: usb 1-3: device descriptor read/64, error -71
> Jun 27 05:38:10 debian kernel: usb 1-3: new high-speed USB device
> number 4 using ehci-pci
> Jun 27 05:38:10 debian kernel: usb 1-3: device descriptor read/64, error -71
> Jun 27 05:38:10 debian kernel: usb 1-3: device descriptor read/64, error -71
> Jun 27 05:38:10 debian kernel: usb usb1-port3: attempt power cycle

I don't have much experience of interpreting these numbers, but isn't
this error coming from the device plugged into the hub (1-3) rather
than the hub itself (1-2)?

Cheers,
David.

[Stanislav Vlasov]

вт, 4 июл. 2023 г. в 13:25, hlyg <hlyg...@outlook.com>:

> i have installed deb12 in usb disk by kingston, it's slow
>
> today i install it in sandisk's, it's normal(fast)
>
> i don't know how to use tool to test usb disk speed

Try fio with config copied from /usr/share/doc/fio/examples/ssd-test.fio
In config set appropriate size and directory and run `fio new_config`

--
Stanislav

[D. R. Evans]

hlyg wrote on 6/28/23 21:32:

> notification message: Transport endpoint is not connected
>

FWIW, since upgrading to bookworm, I see:
sh: 0: getcwd() failed: Transport endpoint is not connected
when I ssh into the upgraded box.

I have no idea why. (And, just to be clear, this has never happened before,
through many releases of debian stable.)

I'm assuming, for now, that:
1. I can use the box as usual despite the message;
2. the problem will be fixed at some point soon.

I haven't seen any other obvious problems if I proceed to use the ssh session
as normal.

Doc

--
Web: http://enginehousebooks.com/drevans

[to...@tuxteam.de]

On Tue, Jul 04, 2023 at 01:40:18PM -0600, D. R. Evans wrote:
> hlyg wrote on 6/28/23 21:32:
>
> > notification message: Transport endpoint is not connected
> >
>
> FWIW, since upgrading to bookworm, I see:
> sh: 0: getcwd() failed: Transport endpoint is not connected
> when I ssh into the upgraded box.

This seems to be coming from getcwd() (aka get current working
directory, see man page). Asking the intertubes, it seems to
happen often when it or its ancestors are mounted over FUSE.

> I have no idea why. (And, just to be clear, this has never happened before,
> through many releases of debian stable.)
>
> I'm assuming, for now, that:
> 1. I can use the box as usual despite the message;
> 2. the problem will be fixed at some point soon.
>
> I haven't seen any other obvious problems if I proceed to use the ssh
> session as normal.

Are you able to access all the directories you expect to? How
is, e.g. the user's $HOME mounted? Its parent?

Cheers
--
t

[D. R. Evans]

to...@tuxteam.de wrote on 7/4/23 22:23:

>>
>> FWIW, since upgrading to bookworm, I see:
>> sh: 0: getcwd() failed: Transport endpoint is not connected
>> when I ssh into the upgraded box.
>
> This seems to be coming from getcwd() (aka get current working
> directory, see man page). Asking the intertubes, it seems to
> happen often when it or its ancestors are mounted over FUSE.
>

This is a plain ol' ssh login, so I don't think that FUSE is involved.

>> I have no idea why. (And, just to be clear, this has never happened before,
>> through many releases of debian stable.)
>>
>> I'm assuming, for now, that:
>> 1. I can use the box as usual despite the message;
>> 2. the problem will be fixed at some point soon.
>>
>> I haven't seen any other obvious problems if I proceed to use the ssh
>> session as normal.
>
> Are you able to access all the directories you expect to? How
> is, e.g. the user's $HOME mounted? Its parent?

Yep... can't see any unusual behaviour at all. So far, anyway.

If I get some time, I'll try to figure out exactly where and why it's
happening; but at this point, since it never happened before in 15 years of
sshing into the box and there seems to be no obvious consequences other than
the appearance of the message at login, I'm assuming there's nothing really
wrong and it's some bug -- probably a race condition, perhaps involving
systemd, since that seems to have a history of them -- introduced in bookworm
that will get fixed fairly quickly.

[to...@tuxteam.de]

On Wed, Jul 05, 2023 at 08:15:14AM -0600, D. R. Evans wrote:
> to...@tuxteam.de wrote on 7/4/23 22:23:
>
> > >
> > > FWIW, since upgrading to bookworm, I see:
> > > sh: 0: getcwd() failed: Transport endpoint is not connected
> > > when I ssh into the upgraded box.
> >
> > This seems to be coming from getcwd() (aka get current working
> > directory, see man page). Asking the intertubes, it seems to
> > happen often when it or its ancestors are mounted over FUSE.
> >
>
> This is a plain ol' ssh login, so I don't think that FUSE is involved.

I think this happens "next", after login and hasn't much to do with
ssh. Somethingsomething session [1] (waves hands).

Anything in the logs?

> > > I have no idea why. (And, just to be clear, this has never happened before,
> > > through many releases of debian stable.)
> > >
> > > I'm assuming, for now, that:
> > > 1. I can use the box as usual despite the message;
> > > 2. the problem will be fixed at some point soon.
> > >
> > > I haven't seen any other obvious problems if I proceed to use the ssh
> > > session as normal.
> >
> > Are you able to access all the directories you expect to? How
> > is, e.g. the user's $HOME mounted? Its parent?
>
> Yep... can't see any unusual behaviour at all. So far, anyway.
>
> If I get some time, I'll try to figure out exactly where and why it's
> happening; but at this point, since it never happened before in 15 years of
> sshing into the box and there seems to be no obvious consequences other than
> the appearance of the message at login, I'm assuming there's nothing really
> wrong and it's some bug -- probably a race condition, perhaps involving
> systemd, since that seems to have a history of them -- introduced in
> bookworm that will get fixed fairly quickly.

Makes sense :)

Cheers

[1] session is a huge and mushy thing.
--
t

[Greg Wooledge]

On Wed, Jul 05, 2023 at 04:49:04PM +0200, to...@tuxteam.de wrote:
> On Wed, Jul 05, 2023 at 08:15:14AM -0600, D. R. Evans wrote:
> > to...@tuxteam.de wrote on 7/4/23 22:23:
> >
> > > >
> > > > FWIW, since upgrading to bookworm, I see:
> > > > sh: 0: getcwd() failed: Transport endpoint is not connected
> > > > when I ssh into the upgraded box.
> > >
> > > This seems to be coming from getcwd() (aka get current working
> > > directory, see man page). Asking the intertubes, it seems to
> > > happen often when it or its ancestors are mounted over FUSE.
> > >
> >
> > This is a plain ol' ssh login, so I don't think that FUSE is involved.
>
> I think this happens "next", after login and hasn't much to do with
> ssh. Somethingsomething session [1] (waves hands).
>
> Anything in the logs?

I'm still waiting for setup details to be provided. Is "sh" the user's
login shell, or is it some kind of transient shell that's being used
internally by ssh, e.g. to set up privilege separation? (I somehow
doubt a shell is used there, but I'm grasping at straws because we're
being given no useful details at all.)

Is /bin/sh a symlink to dash, or to bash?

If I remember correctly, bash has to do a getcwd() at startup time to
set up certain variables for POSIX conformance. But I'm going off of
memories from years ago. And I don't know whether other shells do things
the same way.

> > > Are you able to access all the directories you expect to? How
> > > is, e.g. the user's $HOME mounted? Its parent?
> >
> > Yep...

See, this is not a complete answer.

Is $HOME on an NFS server? An iSCSI disk? An sshfs mount? Is autofs
or another automounter involved in any way?

Show us the relevant line(s) in fstab and in the output of "mount"?

Is "sh" the user's shell, or is their shell /bin/bash or something else?

Anything you could tell us would be better than just "Yep".

[D. R. Evans]

Greg Wooledge wrote on 7/5/23 08:59:

> I'm still waiting for setup details to be provided. Is "sh" the user's

I was merely trying to inform the OP that he wasn't alone in seeing this
"Transport endpoint is not connected" message coming from bookworm when prior
versions of debian stable were silent when performing the same activity.

I wasn't actually seeking help -- if I had've been, I would have made some
attempt to get to the bottom of the problem first, and then provided complete
details here if I were unable to fix it myself. None of that seemed worthwhile
just for a message that doesn't seem to be indicating a real problem.

So you were going beyond my expectations when you attempted to help, and I'm
sorry for the miscommunication.

[Andrew M.A. Cater]

On Fri, Jul 07, 2023 at 12:34:48AM -0400, hlyg wrote:
> deb12 is slow, it complains floppy error. in bios floppy drive is set to
> 1.44M though i have no floppy drive. this isn't problem for deb10/11. it's
> easy to correct bios setting but i am afraid deb12 is still slow.
>

If you don't have a floppy drive - don't set it up in the BIOS,

If you're running off a disk that's connected via USB - it will be slower
than the same disk directly attached to SATA.

Debian 12 is (probably) no slower than Debian 11 - but it is more up to date.
Some file sizes do get bigger, however, and the steady state is that you
never have quite enough memory as newer releases are made.

> Jul 06 23:50:00 bw kernel: scsi 4:0:0:0: Direct-Access USB      SanDisk
> 3.2Gen1 1.00 PQ: 0 ANSI: 6
> Jul 06 23:50:00 bw kernel: sd 4:0:0:0: [sdc] 60088320 512-byte logical
> blocks: (30.8 GB/28.7 GiB)
> Jul 06 23:50:00 bw kernel: sd 4:0:0:0: [sdc] Write Protect is off
> Jul 06 23:50:00 bw kernel: sd 4:0:0:0: [sdc] Mode Sense: 43 00 00 00
> Jul 06 23:50:00 bw kernel: sd 4:0:0:0: [sdc] Write cache: disabled, read
> cache: enabled, doesn't support DPO or FUA
> Jul 06 23:50:00 bw kernel:  sdc: sdc1 sdc2 sdc3
> Jul 06 23:50:00 bw kernel: sd 4:0:0:0: [sdc] Attached SCSI removable disk
> Jul 06 23:50:00 bw kernel: random: crng init done
> ...
> Jul 06 23:50:00 bw kernel: I/O error, dev fd0, sector 0 op 0x0:(READ) flags
> 0x0 phys_seg 1 prio class 2
> Jul 06 23:50:00 bw kernel: floppy: error 10 while reading block 0
> Jul 06 23:50:00 bw kernel: I/O error, dev fd0, sector 0 op 0x0:(READ) flags
> 0x0 phys_seg 1 prio class 2
> Jul 06 23:50:00 bw kernel: floppy: error 10 while reading block 0
>

Changed to respond to the list first
With every good wish,

Andy Cater