I can confirm the issue still occurring in 12.04.
openssh-client and openssh-server version 1:5.9p1-5ubuntu1
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/592434
Title:
ssh -X
I can confirm the issue still occurring in 12.04.
openssh-client and openssh-server version 1:5.9p1-5ubuntu1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/592434
Title:
ssh -X user@machine hangs
Thank you very much for an explanation. I understand that thus is not a
trivial fix, but I would nevertheless ask you to reconsider your
position. As we can see in this bug report, many users consider this
issue important and the workaround problematic. For some users this
issue alone is a show
May I kindly ask why this bug has been fixed in Quantal, but marked as
won't fix for Precise - current LTS release that will most likely be
used as VM host OS for the next couple of years?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
On my mail server postfix and dovecot depend on nis. Currently this
particular dependency is handled properly, because all three daemons are
started by means of /etc/rc?.d in the correct order. Please correct me
if I am wrong, but I worry that the solution suggested by Clint Byrum in
#18 might
On my mail server postfix and dovecot depend on nis. Currently this
particular dependency is handled properly, because all three daemons are
started by means of /etc/rc?.d in the correct order. Please correct me
if I am wrong, but I worry that the solution suggested by Clint Byrum in
#18 might
Further investigation revealed that in my case autofs was not racing
with statd, but rather with nis (client daemon): bug 569757 and bug
570513. The workaround #15 appeared to work in some cases, because it
introduced a small delay into autofs init script, which gave time for
the nis daemon to
Further investigation revealed that in my case autofs was not racing
with statd, but rather with nis (client daemon): bug 569757 and bug
570513. The workaround #15 appeared to work in some cases, because it
introduced a small delay into autofs init script, which gave time for
the nis daemon to
On yet another machine autofs would not start correctly neither with the
workaround from comment #15, nor without it. My efforts to convince
Upstart to run startup scripts in a correct sequence ended in an utter
failure. What I did instead is to modify /etc/init/autofs.conf so that
Upstart doesn't
On yet another machine autofs would not start correctly neither with the
workaround from comment #15, nor without it. My efforts to convince
Upstart to run startup scripts in a correct sequence ended in an utter
failure. What I did instead is to modify /etc/init/autofs.conf so that
Upstart doesn't
For those for whom workarounds in comments #8 and #13 do not work and
who use autofs, there is a separate Upstart-induced problem related to
statd: it races not only with mountall, but also with autofs. Bug 573919
has more information. Autofs users should also see bug 579858 if they
wish to have
For me workaround given in comment #8 in bug 525154 worked on four
systems, but on the fifth it was not enough, and I had to combine it
with #15 from this bug report. I have to admit that number of problems
caused by Upstart is astoundingly high, and they crop up unexpectedly in
a random fashion.
For me workaround given in comment #8 in bug 525154 worked on four
systems, but on the fifth it was not enough, and I had to combine it
with #15 from this bug report. I have to admit that number of problems
caused by Upstart is astoundingly high, and they crop up unexpectedly in
a random fashion.
I am also experiencing this problem on Ubuntu 10.04, openssh-server
1:5.3p1-3ubuntu4, as well as on Ubuntu 9.10. I would like to clarify
that the problem appears to lie within the server, not the client. My
client is running CentOS 5.5 and the problem occurs when connecting to
Ubuntu servers, but
I am also experiencing this problem on Ubuntu 10.04, openssh-server
1:5.3p1-3ubuntu4, as well as on Ubuntu 9.10. I would like to clarify
that the problem appears to lie within the server, not the client. My
client is running CentOS 5.5 and the problem occurs when connecting to
Ubuntu servers, but
The workaround provided in the previous comment works splendidly.
Unfortunately every update to ia32-libs overwrites libpam.so.0.81.6 with
the original unpatched version. While the bug is waiting to be fixed,
would it be possible, as a temporary workaround, to rename libpam.so in
the ia32-libs
101 - 116 of 116 matches
Mail list logo
