Public bug reported:
Automatic report from 18.04 installer
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: ubiquity 18.04.14
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CasperVersion:
@GB you might be able to work around the problem with an Upstart script,
but you're probably better off getting the latest version of nslcd
installed. 0.8.4 is fairly out-of-date, so it's likely the issue has
been resolved in a newer release.
--
You received this bug notification because you are
Hi Ricky, thanks for taking a look at this! Sorry I didn't get a chance
to follow up sooner.
Unfortunately it looks like futher efforts on this patch aren't
worthwhile: Ubuntu will soon be moving to the systemd init system. See
http://www.markshuttleworth.com/archives/1316. In the meantime, it
Hi Luke, thanks for the good news!
Please note that rev 10 of the patch uses debug mode (-d), which
Arthur (the upstream maintainer) does not recommend. I've attached
another patch rev that follows the upstream recommendation by using the
foreground (-n) commandline switch. It is otherwise
Excellent, many thanks!
On Sun, Aug 18, 2013 at 6:25 AM, Arthur de Jong adej...@debian.org wrote:
I've merged your change upstream in both the 0.8 and 0.9 branches.
Attached is a patch that should be suitable for dropping in
debian/patches for version 0.8.13-2.
** Patch added:
Good to know about the PID file, but as far as I know, there is no
mechanism in Upstart for utilizing PID files. This is an intentional design
decision, see
https://lists.ubuntu.com/archives/upstart-devel/2008-August/000735.html(the
section on the pid file stanza being removed)
Is there any
I'd agree that expect fork looks like the correct approach, and until the
latest release, using that stanza seemed to work without issue.
It's true that adding functionality to accommodate a service management
system is a poor separation of concerns, but nslcd's generation of a PID
file does
Hi Arther,
Good to know. I think the behavior I'm seeing is most likely a result of
some change to Upstart, because I'm using the same modified 0.8.10-1
package that I've used in the past. Even so, the process ID that Upstart
decides to track is very definitely incorrect whether I track the first
Another patch rev: after upgrading to Raring (nss-pam-ldapd 0.8.10), the
expect fork stanza no longer behaves correctly. Running script to
determine fork count (http://upstart.ubuntu.com/cookbook/#how-to-
establish-fork-count) indicated 6 calls to fork or clone when nslcd
starts.
To address this
Juan,
If nscld timeouts are causing slow boot times (which may or may not be the
case in the situation you describe--I'd recommend disabling nslcd to see if
the boot time improves), I don't know of clean solution except the init
scripts that I've written and attached to this bug report.
HTH
On
I recommend giving in to this temptation. ;) I'm happy to help with
testing in any way I can.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
Feature Request: Upstart scripts for nslcd
Okay, another patch rev and a big-huge post addressing Arthur's last
concerns (thanks again to him for taking the time to review the patch).
-Regarding serialization of network interface bring-ups, I've addressed
this by running the flock command asynchronously. As far as I can tell,
this doesn't
Another revision, this time using the correct target state when calling
the wait-for-start script, per http://upstart.ubuntu.com/cookbook/#job-
states
** Patch added: Path Rev 8
I noticed an error in the k5start Upstart script: the settings in the
/etc/defaults/nslcd file were being overridden. I've attached a revised
patch.
Still working on my reply to Arthur's latest.
** Patch added: Patch Rev 7
Okay, I've attached revised scripts that should be compatible with
Debian Wheezy (to the extent that I can readily test, which is a Wheezy
build using pbuilder). The lack of a separate System V init script for
nslcd-k5start does not seem to cause any issues.
All the technical issues Arthur raised
I do agree that the reasons for including the sleep.d script aren't very
clear, so I'm definitely in favor of reviewing the script's reason for
existence and removing it if removal is the appropriate action. I'll try
to establish contact with the Debian maintainer about this issue.
** Bug watch
Oops, I didn't realize Jeroen had already logged a Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689584
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1058883
Title:
start-on
** Description changed:
- The local-filesystems signal is not generated during a resume after
- suspend, so aiccu doesn't (re)start correctly during resume. The
- original reason for the local-filesystem condition to be present was to
- avoid issues with logging when the local filesystems aren't
I think it's worth noting that a great deal of confusion surrounding
aiccu restarts is probably related to inconsistencies in the daemon's
behavior.
When the daemon starts, it will terminate if it cannot contact the
tunneling service, which is very different from how the daemon behaves
once it's
On Fri, Oct 5, 2012 at 9:48 AM, Jeroen Massar jer...@unfix.org wrote:
When the daemon starts, it will terminate if it cannot contact the
tunneling service
At failures it will always log the error and terminate. This as that is
the way that a user will notice things and start looking into
I stumbled across another relevant bug report while working on an un-
related issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566910
** Bug watch added: Debian Bug tracker #566910
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566910
--
You received this bug notification because
I'm not sure why the restart is there. Perhaps it's trying to guarantee the
routing tables are correct. Or perhaps it's intended to start up the aiccu
daemon if the computer is suspended on a network with native IPv6 support,
then resumed on a network without native IPv6 support, where the aiccu
Looking at the Debian changelog, it appears this resume script has its
origins in this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531003
On Wed, Oct 3, 2012 at 1:49 PM, Jeroen Massar jer...@unfix.org wrote:
I'm not sure why the restart is there. Perhaps it's trying to
** Bug watch added: Debian Bug tracker #531003
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531003
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1058883
Title:
start-on conditions in Upstart
Seems I was mistaken in the initial report: the `local-filesystems` signal
is issued on resume, but it appears the combination of `local-filesystem`
and `net-device-up` can precede the final, working wlan connection (that
is, authenticated to AP, obtained IP address, set routes). After a bit of
In my case the issue arises when resuming from suspend on a laptop, using
wlan for network connectivity. After resuming, ifconfig doesn't show the
sixxs interface, and aiccu service status is stopped. Obviously IPv6
connectivity is unavailable in this situation.
I'll do some poking around to see
One potential solution is to put a script in /etc/network/if-up.d that
executes before any of the other scripts in that directory and waits for
a specific condition (e.g. an IP address is assigned, or a route becomes
available). I posted an example here:
Public bug reported:
The local-filesystems signal is not generated during a resume after
suspend, so aiccu doesn't (re)start correctly during resume. The
original reason for the local-filesystem condition to be present was to
avoid issues with logging when the local filesystems aren't mounted,
Ah, good to know. Thanks for the link.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
Feature Request: Upstart scripts for nslcd
To manage notifications about this bug go to:
Sounds quite nifty, but wouldn't that make the fix Ubuntu-specific? As I
understand it, the Ubuntu folks like to see a problem fixed upstream if
possible.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Arthur,
Thanks for looking at this, and taking the time to give your feedback.
- If Upstart isn't part of the base Debian install, I'd agree that
dropping the init script doesn't make sense, although the race
conditions that the Upstart scripts aim to address wouldn't be
addressed. Do you
So, any further recommendations or fixes? If not, what's the next step?
Should I be coordinating with Arthur to get this merged upstream?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
New revision. Changes:
-much cleaner mechanism for avoiding races in if-up.d script (thanks Clint!)
-Longer timeout waiting for credentials cache from k5start, to make sure
timeout errors from k5start get logged.
** Patch added: Patch rev 5
Hi Client,
No worries about the response time. I really appreciate your help in
making these scripts as excellent as possible.
The recommended method for serializing start attempts is working well.
I'll dogfood the change for a day or so, then post a revised patch.
--
You received this bug
Hi James,
Well, that's embarrassing--I did upload the wrong file. Thanks for
pointing that out. The correct patch file is attached.
I'll take a look at the instance stanza as well--it'd be be nice to have
a more elegant solution to that interface issue.
** Patch added: Upstart script patch,
I'm assuming the lack of comments indicates that there are no violent
objections to the path I'm taking. The current revision has been working
quite well on my system, as well as a testbed VM. So, I'm re-subscribing
ubuntu-sponsors and attaching the revised patch.
Overview of changes:
-changed
One further point: I don't think we can replace the defaults file with
env stanzas, because some of the variables that can be overridden in the
defaults file require expansion, which the env stanza doesn't support.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Hi Clint,
I can see how first recommended change (start on runlevel [2345] and
an if-up.d script) is an improvement: the if-up.d script makes sure we
try to start nslcd *every* time an interface comes up, not just the
*first* one.
However, I'm encountering another race condition with the if-up.d
Hi Clint! Many thanks for taking the time to review the patch! I'm
revising the scripts based on your feedback and should have a new
debdiff soon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Okay, after reading the Daemon Behavior section of the Upstart cookbook
(http://upstart.ubuntu.com/cookbook/#daemon-behaviour), I've settled on
a solution that I'm reasonably happy with: looping in a post-start
script until the ticket cache is detected on the file system _or_ a
timeout occurs (so
Seems like this is best fixed at the Debian level, but after wasting a
couple hours with configuration issues, crashes in the GTK interface,
and no clear way to reload a report from draft (why in the world would a
draft be helpful if I can't reload it?!) in reportbug, I've run out of
patience.
Adding gnome-panel to the Requires stanzas in xmonad's control file is
not correct--many people will want to install xmonad without using
Gnome. Adding gnome-panel to the Recommends stanza doesn't provide a
strong guarantee that the dependency will be met.
I believe the correct solution is a
Further details: with gnome-panel, login with the session (it will
fail), then switch to a virtual console (that is, hit Ctrl+Alt+F1).
Login, and cat .xsession-errors. It will contain a single line:
gnome-session [PID]: WARNING: Unable to find required component 'gnome-
panel'
--
You received
The odd behavior turned out to be a race condition between the nslcd and
nslcd-k5start scripts: per the Upstart docs
(http://upstart.ubuntu.com/cookbook/#expect), Upstart assumes the job
has started after the first PID that is generated in the script, unless
an expect stanza is present. So,
Thinking more about the way the sasl_mech and krb5_ccname options were
handled, I saw that the logic in the nslcd-k5start file wasn't very good
--we should only be looking for the kinit and k5start binaries if the
user enabled Kerberos, either through the defaults file override, or
with the
Hi Arther,
Thanks for taking the time to review the patch. :)
The motive for Upstart scripts instead of a init.d script is simple:
with the init.d script, I couldn't find a simple way to guarantee nslcd
started _after_ a network connection was available. At the time I logged
the feature request
Here's a debdiff against nss-pam-ldap 0.8.10 with the required changes.
** Patch added: upstart scripts for nslcd
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3213474/+files/nslcd-upstart.debdiff
--
You received this bug notification because you are a
I'm hesitant to call the no-daemonize Upstart script a fix because it
doesn't actually address the underlying problem. It seems like more of a
work-around to me.
However, I think Jan's concern is very valid. Pushing the changes into
the main repository might be the best option at this point:
I don't completely understand why, but using Cedric's backport PPA in
bug #873784 to get correct handling of the wtmp file also resolved the
issue with the session selection for me. Worth a try for those who are
affected by this bug.
--
You received this bug notification because you are a
I've posted this upstream, with some comments on how the issue might be
resolved: https://bugs.freedesktop.org/show_bug.cgi?id=43997
** Bug watch added: freedesktop.org Bugzilla #43997
https://bugs.freedesktop.org/show_bug.cgi?id=43997
--
You received this bug notification because you are a
Just a note that the 'no LDAP user is listed after reboot' is likely the
same bug reported in bug #873784
(https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/873784)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
51 matches
Mail list logo
