I thought I would just add another backtrace from a core file that occurred
today on a machine where winbind
crashed several times:
#0 0x7f089b9b6a75 in raise () from /lib/libc.so.6
#1 0x7f089b9ba5c0 in abort () from /lib/libc.so.6
#2 0x7f089de5c450 in dump_core () at
I just did a backtrace on another machine(bee37), of another core file,
the back trace takes a different path, but the final 3 calls are the
same as my previous post and the same last e calls as Mau's back trace:
rpc_pipe_np_smb_conn
rpccli_set_timeout
winbindd_lookup_sids
...
Unfortunately
Please, can someone raise the importance of this bug from Medium to whatever
the highest level is.
This winbind crashing problem is critical for us and is occurring with more
frequency on more machines,
daily if not hourly. It's affecting the confidence level of all our developers
and QA.
--
FYI:
I have reported this exact same backtrace (at least the last 3 calls) here
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/667269?comments=all
for us, winbind is dead, black screen on Console, no longer can ssh into
machine using
Active Directory credentials.
I must kill any winbind
1.)
Per https://launchpad.net/ubuntu/lucid/+package/winbind
there are several proposed versions to choose from:
winbind 2:3.4.7~dfsg-1ubuntu3.5 in amd64 (Proposed)
winbind 2:3.4.7~dfsg-1ubuntu3.6 in amd64 (Proposed)
i will choose the newer 3.6
winbind 2:3.4.7~dfsg-1ubuntu3.6 in amd64
Instead of downloading the .deb files, i did the more appropriate,
SynapticPackageManager -- repositories -- Updates and
Click Pre-released updated (lucid-proposed) check box
which when installing winbind, it pulled in the proposed
versions of libwbclient0, samba, samba-common, and smbclient.
I
It's been 36 hours, and have not got the rpc_pipe_np_smb_conn crash on any of
the 3 machines that I installed the 2:3.4.7~dfsg-1ubuntu3.6 package.
This particular rpc_pipe_np_smb_conn crash, as I call it, is covered here
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/753330.
So once this
*** This bug is a duplicate of bug 736757 ***
https://bugs.launchpad.net/bugs/736757
It's been 36 hours, and have not got the rpc_pipe_np_smb_conn crash on any of
the 3 machines that I installed the 2:3.4.7~dfsg-1ubuntu3.6 package.
Will still be monitoring this, and may even install it on a
It's been 36 hours, and have not got the rpc_pipe_np_smb_conn crash, as I
call it, on any of the 3 machines that I installed the 2:3.4.7~dfsg-1ubuntu3.6
package.
Will still be monitoring this, and may even install it on a few more machines,
today.
--
You received this bug notification because
It's been 6 days, and the 5 machines that I have this patch on now, are
doing fine.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/736757
Title:
[SRU] PANIC (pid 18442): internal
I pushed out the patch to 24 more machines ( 29 total) on Monday 2011-04-25
6:30 PM. All is fine since then.
Pushing out the patch to the rest of the 80 machines, right now.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in
Everything still working fine on all 80 machines since 2011-04-27.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/736757
Title:
[SRU] PANIC (pid 18442): internal error in winbindd
similar to the stack trace in comment #6 above, winbind crashed today
(on machine bee64) with this stack trace as gotten from gdb against the
core file left behind:
(gdb) bt
#0 0x7f70d81fda75 in raise () from /lib/libc.so.6
#1 0x7f70d82015c0 in abort () from /lib/libc.so.6
#2
Happens intermittently on our Ubuntu 10.04.3 LTS 64-bit systems.
I just checked 2 machines where smbd was not started after a reboot.
I notice the same smbd respawning too fast, stopped in /var/log/syslog.
This message is appearing up to12 seconds prior to Network Manager acquiring
an IP address,
from my original post, I want to strike that there is a core file. Since
then I have looked for a core file when the problem happens, and it is
not there. So don't waste time debugging the attached core file.
In regards to errr's note above, maybe why it is quick for him/her to fix, is
that
I have just installed the samba-dbg package.
When this problem happens again, what do I need to run, look at, provide back
to this forum, etc?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to samba in ubuntu.
I didn't specifically reproduce the problem, but the problem has happened, on
its own.
There also happens to be a recent core file around.
$ sudo find /var/log -type f | grep core | xargs sudo ls -al
-rw--- 1 root root 1564672 2010-12-27 04:12
/var/log/samba/cores/winbindd/core
I
Can we get some traction on this bug?
This problem still consistently occurs on at least 5 machines per week out of
our 80 machines.
Or throw me some ideas to either narrow down the problem further or
work-arounds.
I still feel that whatever winbind does to keep itself busy while being idle is
Is this what you need?
$ cd /etc/pam.d
$ cat common-auth common-session-noninteractive common-session common-password
common-account | grep -v ^#
auth[success=2 default=ignore] pam_unix.so nullok_secure
auth[success=1 default=ignore] pam_winbind.so krb5_auth
FYI:
I can get `passwd` to work if I change the line in common-password
From:
password [success=1 default=ignore] pam_winbind.so use_authtok
try_first_pass
To:
password sufficient pam_winbind.so
I'm not sure if I'm creating other problems with the above edit, since
I'm
FYI:
I can get `passwd` to work if I change one line in common-password
From the winbind default-configured line of:
password [success=1 default=ignore] pam_winbind.so use_authtok
try_first_pass
To:
password [success=1 default=ignore] pam_winbind.so try_first_pass
So looks like just the
I have interleaved the information, removed the timestamps and
substituted DOMAIN\first.last for the actual:
$ passwd
Changing password for DOMAIN\first.last
passwd[30381]: pam_unix(passwd:chauthtok): user DOMAIN\first.last
does not exist in /etc/passwd
passwd[30381]:
Public bug reported:
Binary package hint: samba
Occasionally on various Ubuntu 64-bit LucidLynx systems (10.04.1), winbind goes
into a state such that logging in fails.
(we use ActiveDirectory for logging in. We do not use the Likewise-open
product.)
Although, it appears that there are 1 or
** Attachment added: Core file found under: /var/log/samba/cores/winbindd/core
https://bugs.launchpad.net/bugs/667269/+attachment/1713033/+files/core
--
winbind crashes
https://bugs.launchpad.net/bugs/667269
You received this bug notification because you are a member of Ubuntu
Server Team,
Yes it works on HardyHeron.
I used likewise-open to faciitate the ActiveDirectory integration on HardyHeron,
rather than just the native samba/winbind integration on LucidLynx.
But that may have nothing to do with it, but is worthy of mentioning.
--
passwd : gives Authentication token
Correct, `passwd` works with likewise-open on hardy, and fails with winbind on
lucid.
I do not know what the outcome of `passwd` is on hardy without likewise-open,
nor
the outcome of `passwd` on lucid with likewise-open.
I will ask this on the Lucid forum at
i am not using likewise-open on Lucid cause likewise-open no longer supports
setting up Samba shares with ActiveDirectory integration.
Meaning from a Windows machine, I cannot access \\linuxmachinename\sharename
and this
is important to our Windows/Linux workplace.
(And I no longer see the
Public bug reported:
I am on 64-bit Lubuntu Trusty Tahr (development branch)
(64-bit Lubuntu nighlty build of 2014-03-14 with updates)
(this machine is set up with RAID-1, LVM and Encryption, in
case that matters.)
and am trying to set up an iSCSI target (and client).
2 years ago, I
I had logged bug 1293108, a duplicate of this bug, but I will log my
comment here as well.
Short Story:
The bug fix mentioned in comment #5 solved my compile error during the
installing of iscsitarget-dkms and iscsitarget.
Longer Story:
Today, 2014-03-26,
I updated my 64-bit Lubuntu Trusty Tahr
Public bug reported:
I am on 64-bit Lubuntu Trusty Tahr (development branch)
(64-bit Lubuntu nighlty build of 2014-03-14 with updates)
(this machine is set up with RAID-1, LVM, Encryption, iSCSI Target
and iSCSI client, in case that matters.)
Versions of iSCSI:
ii iscsitarget
I installed bootchart, which pulls in pybootchartgui and python-support,
rebooted,
and am uploading the .png file found in /var/log/bootchart.
(let me know if you want the .tgz file)
Interesting picture of the boot processes.
Looks like there is long 120 second idle time, for something, but I'm
Just for fun, I un-installed all the iSCSI software:
`sudo apt-get purge iscsitarget iscsitarget-dkms open-iscsi`
Rebooted.
Machine takes about 15 seconds to go from my entering my encryption
key/passphrase,
until I see the login dialog on the Lubuntu GUI screen.
So, my 120+ second boot with
32 matches
Mail list logo
