Date: Wed, 5 Jun 2019 07:56:29 -0600 From: "Janky Jay, III" <jankyj@unfs.us> To: Koichiro Iwao <meta@FreeBSD.org> Cc: freebsd-ports@freebsd.org Subject: Re: net/xrdp: Issue(s) with Channels/Clipboard. Message-ID: <1ed7c110-27f4-e4ff-2e5a-52eae2517e25@unfs.us> In-Reply-To: <18ef06f5-076b-9941-e951-4eb3c47570b5@unfs.us> References: <f95c8c0d-ce65-f98f-c65e-f7a6b98d3391@unfs.us> <20190217013706.nzqj3zlhmgtusbnl@icepick.vmeta.jp> <0c964258-8f24-74a4-b592-d4132128bdf0@unfs.us> <18ef06f5-076b-9941-e951-4eb3c47570b5@unfs.us>
next in thread | previous in thread | raw e-mail | index | archive | help
I think I may have found an/the issue here.
Comparing two systems (one that works and one that does not), I noticed
that "/usr/local/sbin/xrdp-chansrv" was not even running on system that
wasn't working. So, I manually ran it to find it was missing some
libraries which I checked with "ldd":
#~ ldd /usr/local/sbin/xrdp-chansrv
/usr/local/sbin/xrdp-chansrv:
libcommon.so.0 => /usr/local/lib/xrdp/libcommon.so.0 (0x800267000)
libSM.so.6 => /usr/local/lib/libSM.so.6 (0x800280000)
libICE.so.6 => /usr/local/lib/libICE.so.6 (0x80028a000)
libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x8002a7000)
libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x8002af000)
libX11.so.6 => /usr/local/lib/libX11.so.6 (0x8002bc000)
libfdk-aac.so.2 => not found (0)
libopus.so.0 => /usr/local/lib/libopus.so.0 (0x8003fd000)
libmp3lame.so.0 => not found (0)
libthr.so.3 => /lib/libthr.so.3 (0x80046f000)
libcrypto.so.111 => /lib/libcrypto.so.111 (0x80049a000)
libssl.so.111 => /usr/lib/libssl.so.111 (0x800787000)
libc.so.7 => /lib/libc.so.7 (0x80081c000)
libXext.so.6 => /usr/local/lib/libXext.so.6 (0x800c0f000)
libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x800c23000)
libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x800c2f000)
libm.so.5 => /lib/libm.so.5 (0x800c58000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x800c8a000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x800c8f000)
Here, I noticed that both "libfdk-aac" and "libmp3lame" are missing
which is keeping xrdp-chansrv from starting. I was able to install
"fdk-aac-2.0.0" via "pkg install" without any issues but installing
"audio/lame" does not appear to be an option via "pkg". Apparently,
there is a licensing issue. So, this needed to be built from ports. I
would imagine that these are important to people using sound (I am not)
so some audio dependencies should remain. However, I'm not sure it
should be "audio/lame" if there is not a package available for it.
Perhaps finding an alternative or removing it as a dependency from the
xrdp-devel package? Not sure.
Anyhow, getting these two libs installed fixed the chansrv timeout issue
for me. So, hopefully that can help troubleshoot the package install of
xrdp-devel (I haven't tried the port but I'd imagine it probably works
fine).
Regards,
Janky Jay, III
On 5/8/19 4:00 PM, Janky Jay, III wrote:
> Hello Koichiro,
>
> Is there any update to this? I've since upgraded both systems to
> FBSD 12.0-RELEASE-p3 and there have also been (I think) two (2) xrdp
> port/pkg updates as well but the problem still remains the same.
> Connections to chansrv work 100% of the time on one system and 0% of the
> time on the other.
>
> Also, can you please provide a link to the GH post/report that you
> created? I'd like to take a look and follow that as well if I can.
> Thanks again!
>
> Regards,
> Janky Jay, III
>
> On 2019-02-17 12:23, Janky Jay, III wrote:
>> Hello Meta,
>>
>> On 2/16/19 6:37 PM, Koichiro Iwao wrote:
>>> On Fri, Feb 15, 2019 at 11:31:36AM -0700, Janky Jay, III wrote:
>>>> This also causes the connection to take 16 seconds to open XFCE4 once
>>>> it finally gives up on channels. I see 4 errors so I'm guessing there's
>>>> a 4 second timeout between attempts. Something similar to the
>>>> issue/recommendation reported at
>>>> https://github.com/neutrinolabs/xrdp/issues/1288. I've tried the
>>>> recommended disallowing of channels to see if it would connect faster
>>>> but it does nothing. Still attempts the connections to "chansrv" and
>>>> takes 16 seconds.
>>> I don't think that is recommended in the upstream issue. Just he reporter
>>> tried as workaround. Who recommended? As commented in the ticket, disabling
>>> all channels don't stop connecting to chansrv. That's why *not to
>>> connect when all channels disabled* feature is suggedted.
>>>
>> I should have worded that differently. I suppose "recommended" was
>> incorrect. It was just a thought to see whether or not
>> disable/re-enabling might give me more insight into what was happening
>> via the logs (I tried adding the DEBUG log line to sesman.ini as well
>> but there was no relevant information).
>>
>>> I know some people have the same issue and already recoeded to upstream
>>> GH issue. Hang tight. If I need to know more detail of reproduction,
>>> I might ask you help.
>>>
>>> I also reproduce the issue but not 100%.
>>>
>> Sounds good! I can reproduce 100% of the time on one system right
>> now so if there is anything I can do to help, I will certainly do that.
>> Thank you!
>>
>> Regards,
>> Janky Jay, III
>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1ed7c110-27f4-e4ff-2e5a-52eae2517e25>