Bug#840056: shibboleth-sp2-utils: upgrade attempt of shibboleth-sp2-utils gets hung at restart of shibd service
On 10/11/2016 11:18 AM, Cantor, Scott wrote: >> I have been able to reproduce this now. Two minutes seems to be the >> requirement. > > That would imply a fairly slow machine + a fairly large metadata source. In > any event, the only real fix is moving to on-demand metadata, so whatever > your metadata source is, you need to be thinking in terms of making sure they > know they have to stop relying on aggregates. > > -- Scott I will pass on this suggestion to InCommon and my local IdP, the u of Washington, who are the sources. sb -- Stefani Banerian UW Clinical Cyclotron www.uwmcf.org UW School of Medicine UW Box 356043 206-598-0302 gpg key 6642E7EE fingerprint = BD13 875D 2D03 5E1D 1E3B 8BF7 F4B8 63AD 6642 E7EE
Bug#840056: shibboleth-sp2-utils: upgrade attempt of shibboleth-sp2-utils gets hung at restart of shibd service
On 10/11/2016 03:22 AM, Ferenc Wágner wrote: > "S. Banerian" <baner...@u.washington.edu> writes: > >> On 10/09/2016 05:25 PM, Ferenc Wágner wrote: >> >>> "S. Banerian" <baner...@u.washington.edu> writes: >>> >>>> On 10/07/2016 02:04 PM, Ferenc Wágner wrote: >>>> >>>>> Could you please make sure shibd isn't running >>>>> then show me the output of >>>>> >>>>> # sudo -u _shibd strace shibd -f -F >> [...] >> after some 12 hours of trying to start, failing, it finally started, >> created shibd.sock, and under a test, worked. > > Was this the doing of a single invocation of the above, or do you refer > to systemd continuously trying to restart it and succeeding eventually? this was systemd continually trying. i ensured no spurious shibd procs were running. >>> Can you provide a full GDB backtrace (after installing >>> shibboleth-sp2-utils-dbgsym; please yell if you need precise >>> instructions). >> >> does not appear to be in stretch. so i need the instructions. > > It is in a separate archive, see > https://wiki.debian.org/AutomaticDebugPackages. But let's exclude the > simple timeout problem beforehand. > >>>> Note: prior to the upgrade, shibboleth was working. >>> >>> Which version of shibboleth was working for you? >> >> the version just prior to this one 2.6.0+dfsg1-3+b1 on stretch. > > Do you mean 2.5.6+dfsg1-2? Your dpkg or apt logs should reveal the > upgraded version. yes. >>> Can you share your shibboleth2.xml? >> >> I'm a bit reluctant to provide some of the information in the >> RequestMapper sections. > > If configuring a longer timeout (below) does not help, please check if > you can reproduce the issue without the sensitive parts. > >> When I force a restart, systemctl restart shibd.service I get the issue >> as before, where >> >> \_ /bin/systemd-tty-ask-password-agent --watch >> >> stays there for a looong time, and is not returning, systemctl says it >> is started, but journalctl -xe gives: >> >> Oct 10 14:00:35 epics systemd[1]: shibd.service: Killing process 30980 >> (shibd) with signal SIGKILL. >> Oct 10 14:00:35 epics systemd[1]: shibd.service: Main process exited, >> code=killed, status=9/KILL >> Oct 10 14:00:35 epics systemd[1]: Failed to start Shibboleth Service >> Provider Daemon. >> -- Subject: Unit shibd.service has failed > > This really does not make much sense together... And I can't see any > systemd-tty-ask-password-agent processes at all for some reason. we agree. no reason to be seeing this. >> there is a shibd -f -F process running, but no shibd.sock file > > Are you sure that process isn't from some manual start attempt? Also, > if you start an instance manually while systemd's still trying to > occasionally restart shibd in the background, the socket may get lost. > > So, first of all, tell systemd to stop shibd and wait for it: > > # systemctl stop shibd > > Then you should see something like: > > # systemctl status shibd > [...] >Active: inactive (dead) [...] > [...] > Main PID: 360 (code=exited, status=0/SUCCESS) > [...] > Oct 11 11:34:39 elm systemd[1]: Stopped Shibboleth Service Provider Daemon. actually, after doing that, I got: systemctl status shibd.service ● shibd.service - Shibboleth Service Provider Daemon Loaded: loaded (/lib/systemd/system/shibd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:shibd(8) https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPshibd Oct 11 10:35:18 epics systemd[1]: Stopped Shibboleth Service Provider Daemon. Oct 11 10:35:18 epics systemd[1]: Starting Shibboleth Service Provider Daemon... Oct 11 10:36:48 epics systemd[1]: shibd.service: Start operation timed out. Terminating. Oct 11 10:36:54 epics systemd[1]: shibd.service: State 'stop-final-sigterm' timed out. Killing. Oct 11 10:36:54 epics systemd[1]: shibd.service: Killing process 5523 (shibd) with signal SIGKILL. Oct 11 10:36:54 epics systemd[1]: shibd.service: Main process exited, code=killed, status=9/KILL Oct 11 10:36:54 epics systemd[1]: Failed to start Shibboleth Service Provider Daemon. Oct 11 10:36:54 epics systemd[1]: shibd.service: Unit entered failed state. Oct 11 10:36:54 epics systemd[1]: shibd.service: Failed with result 'signal'. Oct 11 10:36:58 epics systemd[1]: Stopped Shibboleth Service Provider Daemon. > Then start it manually: > > # date; sudo -u _shibd /usr/sbin/shibd -f -F > > Meanwhile check /var/log/shibboleth/shibd.log for progress; the > timestamps should tell you where ti
Bug#840056: shibboleth-sp2-utils: upgrade attempt of shibboleth-sp2-utils gets hung at restart of shibd service
On 10/10/2016 02:03 PM, S. Banerian wrote: > On 10/09/2016 05:25 PM, Ferenc Wágner wrote: > Does shibd still consume significant CPU according to top? > > at this moment, no. >> What are its memory figures? > > nothing big. > >> Isn't your computer swapping heavily? > > no with the attempt to perform systemctl restart shibd.service I'm now seeing the CPU at 100% and memory (but not yet swap) near 100% also. and no shibd.sock. web app error message: shibsp::ListenerException The system encountered an error at Mon Oct 10 14:06:15 2016 To report this problem, please contact the site administrator at ... Please include the following message in any email: shibsp::ListenerException at ... Cannot connect to shibd process, a site administrator should be notified that this web server has malfunctioned. rebooting machine gave same result. I'll let it sit overnight to see what happens. -- Stefani Banerian UW Clinical Cyclotron www.uwmcf.org UW School of Medicine UW Box 356043 206-598-0302 gpg key 6642E7EE fingerprint = BD13 875D 2D03 5E1D 1E3B 8BF7 F4B8 63AD 6642 E7EE
Bug#840056: shibboleth-sp2-utils: upgrade attempt of shibboleth-sp2-utils gets hung at restart of shibd service
On 10/09/2016 05:25 PM, Ferenc Wágner wrote: > "S. Banerian" <baner...@u.washington.edu> writes: > >> On 10/07/2016 02:04 PM, Ferenc Wágner wrote: >> >>>> Manually trying to start /usr/sbin/shibd -f -F never produces the >>>> /run/shibboleth/shibd.sock nor any other files in that dir. >>> >>> This is really disturbing. You don't except the above command to give >>> back your prompt, right? >> >> correct. >> >>> Could you please make sure shibd isn't running >>> then show me the output of >>> >>> # sudo -u _shibd strace shibd -f -F >> >> the output is rather long... >> I shall attach. > > Thanks. Does it hang there indefinitely, with no further output for > minutes? after some 12 hours of trying to start, failing, it finally started, created shibd.sock, and under a test, worked. Its dpkg status is still iF Does shibd still consume significant CPU according to top? at this moment, no. > What are its memory figures? nothing big. > Isn't your computer swapping heavily? no > Can > you provide a full GDB backtrace (after installing > shibboleth-sp2-utils-dbgsym; please yell if you need precise > instructions). does not appear to be in stretch. so i need the instructions. >> Note: prior to the upgrade, shibboleth was working. > > Which version of shibboleth was working for you? the version just prior to this one 2.6.0+dfsg1-3+b1 on stretch. > Can you share your shibboleth2.xml? I'm a bit reluctant to provide some of the information in the RequestMapper sections. >> We did note that sometimes shibd was more well-behaved when starting >> from shell than via systemctl. > > Could you please make this more precise? How did it misbehave when > started by systemctl? this is where it hangs for minutes, says it might start, may or may not create /run/shibboleth/shibd.sock and the apache application only returns with shibboleth errors. Now, however, as it has sat over the weekend, and finally started, dpkg has let the upgrade complete, with no errors. When I force a restart, systemctl restart shibd.service I get the issue as before, where \_ /bin/systemd-tty-ask-password-agent --watch stays there for a looong time, and is not returning, systemctl says it is started, but journalctl -xe gives: Oct 10 14:00:35 epics systemd[1]: shibd.service: Killing process 30980 (shibd) with signal SIGKILL. Oct 10 14:00:35 epics systemd[1]: shibd.service: Main process exited, code=killed, status=9/KILL Oct 10 14:00:35 epics systemd[1]: Failed to start Shibboleth Service Provider Daemon. -- Subject: Unit shibd.service has failed there is a shibd -f -F process running, but no shibd.sock file I'm not convinced that systemd is behaving well. -- Stefani Banerian UW Clinical Cyclotron www.uwmcf.org UW School of Medicine UW Box 356043 206-598-0302 gpg key 6642E7EE fingerprint = BD13 875D 2D03 5E1D 1E3B 8BF7 F4B8 63AD 6642 E7EE
Bug#813539: [Pkg-privacy-maintainers] Bug#813539: tails-installer: tails installer fails to sense usb stick
On 02/02/2016 03:14 PM, intrigeri wrote: > Control: tag -1 + moreinfo > > Hi, > > Stefani Banerian wrote (02 Feb 2016 22:20:31 GMT) : >> in trying to use the gui, the usb stick was never displayed. > >> I did run the installer from command line: >> /usr/lib/tails-installer/tails-installer -v -f /dev/sdb > > We don't support running the installer this way (not all combinations > of options result in sane behaviour), that's why this program is not > in the $PATH. > > Can you please try to reproduce this problem using > tails-installer-launcher? > > And, still curious: any specific reason why are you picking your own > set of command-line options? If you have a use case that is not > addressed by tails-installer-launcher, I'm curious :) > > Cheers! well, whenever I try the tails-installer-launcher, it never shows the usb stick. that's why i tried CLI, to look for more debug information! :) If there is a way to use the launcher, and get the installer to sense the usb stick, that would be nice -- Stefani Banerian 206-598-0302 gpg key 6642E7EE fingerprint = BD13 875D 2D03 5E1D 1E3B 8BF7 F4B8 63AD 6642 E7EE
Bug#658896: sudo: setresuid(ROOT_UID, ROOT_UID, ROOT_UID): Operation not permitted.
Replacing libnss-ldap with libnss-ldapd and nscd with nslcd does not fix the problem. Related bug report is significant: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658739 This work-around was found to work on arch x86_64 / amd64 -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? S. Banerian 206-598-0302 UWMC Radiation Oncology gpg key 6642E7EE fingerprint = BD13 875D 2D03 5E1D 1E3B 8BF7 F4B8 63AD 6642 E7EE signature.asc Description: OpenPGP digital signature
Bug#397511: dbus fails on startup. segfaults, users can no longer log in
More information this item: dbus failed to start. but also updated packages login/passwd may be the culprit. This may actually be related to bug #447237 only one user can log in, and after that errors ensue.. additionally, getent segfaults, and that may lead to the dbus errors [EMAIL PROTECTED] wrote: Package: dbus Version: 1.1.2-1 Followup-For: Bug #397511 When trying to update system, dbus update fails. Segfaults reported. Users can no longer log in to system. facilities such as 'getent passwd' segfaults : -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dbus depends on: ii adduser 3.105 add and remove users and groups ii debianutils 2.28.2 Miscellaneous utilities specific t ii libc62.7-5 GNU C Library: Shared libraries ii libdbus-1-3 1.1.2-1 simple interprocess messaging syst ii libexpat11.95.8-4XML parsing C library - runtime li ii libselinux1 2.0.15-2+b1 SELinux shared libraries ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip Versions of packages dbus recommends: pn dbus-x11 none (no description available) -- no debconf information -- S. Banerian 206-598-0302 UWMC Radiation Oncology -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362027: backupninja: ldap handler fails on connection to ldaps (tls) server
Package: backupninja Severity: important in employing the ldap handler, backupninja failed in performing an ldapsearch form of backup as it had no apparent capability to deal with an ldaps (tls) host this could be dealt with in part by adding a 'host' option in the configuration file and a -H command line option passed to ldapsearch (example): /etc/backup.d/x.ldap: ldaphost = some.ldap.server tls = yes /usr/share/backupninja/ldap: add something like [ $tls = 'yes' ] URLBASE=ldaps ... EXECSTR= -H $URLBASE://$ldaphost -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312939: bamboo: incorrect assinment of file type in attachment/upload
Package: bamboo Version: 1.2-2 Severity: normal When files are uploaded, and made visible using the #attachment in a page, Excel spreadsheets *.xls can be incorrectly identified as application/msword -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-vs1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bamboo depends on: ii apache [httpd] 1.3.33-6versatile, high-performance HTTP s ii debconf 1.4.30.13 Debian configuration management sy ii php4 4:4.3.10-15 server-side, HTML-embedded scripti ii php4-sqlite 1.0.2-7 PHP4 bindings to SQLite, a file-ba ii sqlite 2.8.16-1command line interface for SQLite -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
