[Bug 1777286] [NEW] 18.04 installation crash
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: 1.394 CurrentDesktop: ubuntu:GNOME Date: Sat Jun 16 15:59:41 2018 InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity quiet splash --- LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: LANGUAGE=en_US.UTF-8 PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LC_NUMERIC=C.UTF-8 SourcePackage: ubiquity UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: ubiquity (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ubiquity-18.04.14 ubuntu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1777286 Title: 18.04 installation crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1777286/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
@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 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 should be pretty straight-forward to manually apply the Upstart scripts supplied in the patch. -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 identical to patch
rev 10.
** Patch added: "Patch Rev 11"
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3904833/+files/nslcd-upstart-11.debdiff
--
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:
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 806761] Re: Feature Request: Upstart scripts for nslcd
Excellent, many thanks! On Sun, Aug 18, 2013 at 6:25 AM, Arthur de Jong 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: "implement-nofork.patch" > > https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3776774/+files/implement-nofork.patch > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/806761 > > Title: > Feature Request: Upstart scripts for nslcd > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions > -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 establish a precedent for doing so, as does other daemons' use of the -n switch. it seems making this sort of compromises is a fairly common practice. Ultimately, though, I'm just trying to follow the path of least resistance to my goal of making it painless to have mobile access to LDAP account information. No custom scripts, no PPAs, no service restarts when I boot up my laptop and have to manually establish a wireless connection in a coffee shop. Right now, adding a -n switch to nslcd seems like the next step forward on that path. On Sat, Aug 17, 2013 at 2:33 PM, Arthur de Jong wrote: > According to the mailing list post you would expect that "expect fork" > should be the right thing to do. > > If you really want to implement a command-line switch for this (I think > it is a bit silly to have to do this for upstart), please name it -n > (this seems to be used by a few daemons that provide such an option). > The change itself shouldn't be too complicated. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/806761 > > Title: > Feature Request: Upstart scripts for nslcd > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions > -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 technical reason nslcd can't have a foreground mode? I'm happy to dive into the code and see about making the necessary modifications, but I wouldn't want to invest the time unless it's a feasible option. On Thu, Aug 15, 2013 at 1:04 AM, Arthur de Jong wrote: > Currently nslcd does not support not forking into the background outside > of debug mode. > > The pid of nslcd can be reliably determined by looking at > /var/run/nslcd/nslcd.pid. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/806761 > > Title: > Feature Request: Upstart scripts for nslcd > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions > -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 or second call to fork(). I'm running `ps auxw | grep nslcd` to verify the PID. Running in the foreground is the only way Upstart will reliably select the correct process ID. This is true for both my main workstation and a virtualized testbed. Is there some way to run nslcd in the foreground without enabling debug mode? On Wed, Aug 14, 2013 at 3:58 AM, Arthur de Jong wrote: > It is not recommended to run nslcd in debug mode in production. > > Anyway, on start-up nslcd will call daemon() to daemonise. I thought > that daemon() called fork() twice but according to the manual page it > only forks once. After that, it starts a number of threads (configured > by the threads option in nslcd.conf) and optionally starts another sub- > process to do cache invalidation. This last process is only started in > 0.9.0 and later if configured and is started before dropping privileges > so runs as root (while other processes commonly run as user nslcd). > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/806761 > > Title: > Feature Request: Upstart scripts for nslcd > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions > -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 issue, the latest patch rev runs nslcd in debug/foreground mode (-d). This has the added benefit of logging debug output to the nslcd job's log file, although it's a bit verbose for normal operation. ** Patch added: "Patch Rev 10" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3767356/+files/nslcd-upstart-10.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 Mon, Aug 5, 2013 at 8:00 AM, Juan Andrés Ghigliazza < 806...@bugs.launchpad.net> wrote: > I think that this bug is affecting me at boot. I am having a very slow > boot (2 minutes approximately), with some nslcd timeouts. After that, > the computer works ok. My distribution is Ubuntu 12.04. Can you suggest > me how to workaround it?. Thanks. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/806761 > > Title: > Feature Request: Upstart scripts for nslcd > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions > -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: 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 affect the serialization of nslcd startup attempts, which is all we really care about. Testing on my laptop and desktop has gone well. This change does mean that there is the possibility of a noticeable delay between the time a network interface comes up and the time nslcd is ready to service requests, but that strikes me as more of a login management concern. -I thought about only emitting an event when the nslcd-k5start script was actually needed. However, it would have made the nslcd script much more complicated (checking for the appropriate configuration options, etc). Having these checks in the nslcd-k5start scripted seemed like a much better separation of concerns, and also makes a future migration to a nslcd-kerberos package easier. -I do not know of a way to model the mail server dependency info in Upstart. Perhaps someone on the ubuntu-sponsors list has an idea about this. -I think Arthur's recommendation about waiting for a cache to be established is quite valid, but using the post-start stanza appears to be more idiomatically correct. See http://upstart.ubuntu.com/cookbook /#post-start -I added the nscd cache invalidation so the nscd cache was refreshed whenever a connection was established to the authoritative source (i.e. the LDAP directory). However, invalidating the cache has led to problems over unstable (e.g. WiFi) connections: if the connection comes up long enough to invalidate the cache and then drops, the cache contents are lost. On the other hand, relying on the nscd cache means that current, up-to-date user/group information isn't available to the user until the nscd cache expires, times out, or is manually invalidated. Computing the stability of a network connection is definitely outside the scope of this patch, so I've removed the cache invalidation for now. I think a good short-term solution to the issue of cache invalidation for stable connections would be a flag to control invalidation of the cache. Ideally, this flag would be per-connection. -I agree that the use of /etc/defaults/nslcd is a bit awkward (and apparently is being deprecated), but it's not only the nslcd user and group that use expansion: several of the k5start-related variables use it as well. I think we're sort of stuck with the defaults file until expansion is available in Upstart's "env" stanza. -I'm not seeing a lintian warning/error on Ubuntu. Since Arthur's wanting to test this out in Ubuntu first, I'd prefer to leave it as-is until such a time it seems expedient to merge the changes into Debian. ubuntu-sponsors: it would seem Arthur prefers to have this patch tested in Ubuntu first. What's the next step forward in that process? Also, any thoughts on modeling the mailserver dependency information in Upstart? ** Patch added: "Patch Rev 9" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3646993/+files/nslcd-upstart-9.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3639332/+files/nslcd-upstart-8.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3629296/+files/nslcd-upstart-7.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 have been addressed as well, in addition to log() functions that prefix log messages with date and time information. ** Patch added: "Patch Rev 6" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3384029/+files/nslcd-upstart.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
** 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 mounted, but - I'd say the conditional checks in the pre-start script are sufficient, - and the local-filesystems condition can be safely removed. + [EDIT] Per comment #4, the "local-filesystem" signal is not an issue. + New description: + + When resuming from suspend on a computer that takes time to re-establish + its network connection (e.g. a slow WiFi connection), the script + /etc/pm/sleep.d/60aiccu can cause the aiccu daemon to terminate. The + script checks for connectivity using ping6, and restarts the daemon if + ping6 fails. If network connectivity is still not available when the + daemon restarts, the daemon will terminate. Manual intervention or a + reboot is required to restart the aiccu daemon. + + [Original report] + 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, but I'd say the conditional checks in the pre-start script are sufficient, and the local-filesystems condition can be safely removed. ** Summary changed: - start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend + /etc/pm/sleep.d/60aiccu can cause aiccu to terminate -- 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: /etc/pm/sleep.d/60aiccu can cause aiccu to terminate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 added: Debian Bug tracker #689584 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 conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
On Fri, Oct 5, 2012 at 9:48 AM, Jeroen Massar 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 logs. > Unfortunately people seem to think that everything needs the Win95 > treatment and just restart things instead. > > >, which is very different from how the > > daemon behaves once it's started, where it is supposed to handle network > outages gracefully, without a restart. > > That is correct, but how is that inconsistent? > > > This bug report contains logs that illustrate the behavior: > https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825. > > The same behavior is present on my system running a fully patched Ubuntu > 12.04 release. > > That shows as the first line indicates that somebody decided to change > the startup method which then caused things to break as there was no > network yet. Simple solution: start it (once, btw, and not repeatedly) > when your network connectivity is up. > > > These inconsistencies > > That is not inconsistent. If there is an error condition (broken time, > no network) it exits. > > Now, if your IP address changes while it is already running, then it > will keep on working. > The inconsistency is in the daemon sometimes treating a lack of network connectivity as an error condition, and sometimes treating it as part of normal operation (as you said previously, the daemon should _not_ restart on resume, even though network connectivity might be lost). I'm not sure the "loud" failure that occurs when the daemon starts without network connectivity is worth the inconsistency, since a user is very likely to notice the lack of connectivity in other ways (e.g. can't connect to IPv6 sites, ping6 failing, and the sixxs interface missing from the ifconfig output). This is very much a design decision, of course, but I'm not sure it's optimal (see below for further reasons related to init system concerns). > > > Neither aiccu's built-in behavior or the Upstart > > Please note that Upstart is something from Ubuntu etc, do not start > blaming AICCU for the way that that start script handles it. > I do not know how assigning blame is related to the words I wrote. They simply state that neither piece of software was capable of correctly handling the described scenario without user intervention. > > > (recall the Upstart script looks for the local-file-system signal in > addition to the net-device-up signal). > > Then fix upstart. > It's probably quite possible to address the scenario using Upstart, but it is not a good idea to say the init system is responsible for addressing the scenario I've described. If init systems must handle such edge cases, systemd would have to implement a separate, incompatible method for detecting this scenario, which duplicates effort and leads to implementation-specific fixes that have to be ported manually. In short, it violates the principle of not repeating ourselves (I'm sure you have special appreciation for DRY after the number of times you've had to say aiccu shouldn't be restarted). Also, init systems like System V don't support event-based startup, so distros that use System V are in fact incapable of handling such scenarios with the init system. > > > Seems to me the best solution to these issues is for the aiccu daemon > to behave the same way on startup and while running. > > As it retrieves it's primary configuration details using TIC, it needs > them, in it's current incarnation it will thus properly exit. > What daemon configuration details are retrieved using TIC? Obviously the _tunnel_ configuration details requires TIC, but I can't imagine what details of _daemon_ configuration would require the _Tunnel_ Information and Control protocol (emphasis is mine). > > > Given the choice, I'd vote for handling network outages gracefully in > both scenarios: this makes the startup scripting very > > simple: start aiccu on boot, and let it handle everything from there. > > This is what will be likely the case in the next AICCU version, which I > want to finish but do not get around to unfortunately, maybe tomorrow > will be the right day though > I am happy to help test the next version, where can I find the source code? The AICCU downloads page doesn't seem to have any relevant links. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1058883 > > Title: > start-on conditions in Upstart script prevent aiccu from restarting > during resume from suspend > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions > -- 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
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 started, where it is supposed to handle network outages gracefully, without a restart. This bug report contains logs that illustrate the behavior: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825. The same behavior is present on my system running a fully patched Ubuntu 12.04 release. These inconsistencies will lead to behavior that I consider incorrect when a system boots up without network connectivity and later establishes a connection (e.g. booting a laptop while outside of wireless coverage, and later coming into range). Neither aiccu's built- in behavior or the Upstart script will handle such a scenario correctly (recall the Upstart script looks for the local-file-system signal in addition to the net-device-up signal). Seems to me the best solution to these issues is for the aiccu daemon to behave the same way on startup and while running. Given the choice, I'd vote for handling network outages gracefully in both scenarios: this makes the startup scripting very simple: start aiccu on boot, and let it handle everything from there. -- 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 script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1058883 Title: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
** 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 script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 wrote: > > I'm not sure why the restart is there. Perhaps it's trying to guarantee > the > > routing tables are correct. > > Why would they not be? > > > 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 > > daemon is needed. It also restarts aiccu if ping6 isn't found, not sure > why. > > There is no logic in the script or in the default AICCU for this. Thus > that cannot be it either. > > (Logic for detecting native IPv6 and optionally disabling tunneling, or > wel, at least the routes for it, is a wishlist item in upstream AICCU) > > > Just in case it wasn't clear, the sleep.d script is part of the default > > installation as well--I don't have a link, but it can be easily verified > by > > downloading the aiccu source package and looking for the file `60aiccu` > in > > the debian/ directory. > > Something in Debian/Ubuntu added it; but it is not in default, or maybe > better said, original/upstream AICCU. > This as one should not have to restart AICCU, ever. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1058883 > > Title: > start-on conditions in Upstart script prevent aiccu from restarting > during resume from suspend > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions > -- 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 script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 daemon is needed. It also restarts aiccu if ping6 isn't found, not sure why. Just in case it wasn't clear, the sleep.d script is part of the default installation as well--I don't have a link, but it can be easily verified by downloading the aiccu source package and looking for the file `60aiccu` in the debian/ directory. On Tue, Oct 2, 2012 at 11:00 PM, Jeroen Massar wrote: > > I found the file > `/etc/pm/sleep.d/60aiccu`. This appears to be the offending line: > > > > $P6 -I $INT -c 1 f.root-servers.net >/dev/null 2>&1 || invoke-rc.d > aiccu > restart > > And the million dollar prize question becomes: why is there a restart > there? > > > If I comment out the offending line and use the package's original > Upstart > > script (with the local-filesystem condition intact), the sixxs interface > is > > still present on resume. > > Always good to know that the unmodified version works fine ;) > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1058883 > > Title: > start-on conditions in Upstart script prevent aiccu from restarting > during resume from suspend > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions > -- 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 script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 head scratching and hair tearing I found the file `/etc/pm/sleep.d/60aiccu`. This appears to be the offending line: $P6 -I $INT -c 1 f.root-servers.net >/dev/null 2>&1 || invoke-rc.d aiccu restart If I redirect the output of ping6 to a file I get the following output: unknown host If I comment out the offending line and use the package's original Upstart script (with the local-filesystem condition intact), the sixxs interface is still present on resume. On Mon, Oct 1, 2012 at 12:13 PM, Caleb wrote: > 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 if I can identify a root cause. Sounds > like the real issue is whatever's causing aiccu to stop. > > > On Mon, Oct 1, 2012 at 12:15 AM, Lars Düsing wrote: > >> Celeb, I do not have any problems on resume - even on changing networks >> (I should try changing from wlan to ethernet or grps) >> Do you have any troubles? >> >> -- >> You received this bug notification because you are subscribed to the bug >> report. >> https://bugs.launchpad.net/bugs/1058883 >> >> Title: >> start-on conditions in Upstart script prevent aiccu from restarting >> during resume from suspend >> >> To manage notifications about this bug go to: >> >> https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions >> > > -- 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 script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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 if I can identify a root cause. Sounds like the real issue is whatever's causing aiccu to stop. On Mon, Oct 1, 2012 at 12:15 AM, Lars Düsing wrote: > Celeb, I do not have any problems on resume - even on changing networks (I > should try changing from wlan to ethernet or grps) > Do you have any troubles? > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1058883 > > Title: > start-on conditions in Upstart script prevent aiccu from restarting > during resume from suspend > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions > -- 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 script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] [NEW] start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
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, but I'd say the conditional checks in the pre-start script are sufficient, and the local-filesystems condition can be safely removed. ** Affects: aiccu (Ubuntu) Importance: Undecided Status: New -- 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 script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 702802] Re: event "net-device-up" is triggered too early
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: http://askubuntu.com/questions/194632/how-do-i-delay-upstarts-net- device-up-signal-until-a-condition-is-met -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/702802 Title: event "net-device-up" is triggered too early To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/702802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 989405] Re: GNOME with Xmonad session requires gnome-panel
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. https://bugs.launchpad.net/bugs/989405 Title: GNOME with Xmonad session requires gnome-panel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xmonad/+bug/989405/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 know if an equivalent to the "wait-for-start" Upstart script is available in Debian? I don't think Upstart has any direct knowledge of other service management systems, but I think the only affected functionality would be the `service` command. The Ubuntu manpage for `service` indicates that the Upstart job will take precedence over a System V init script: http://manpages.ubuntu.com/manpages/precise/man8/service.8.html. Looks like the Debian version of `service` would simply ignore the Upstart script: http://manpages.debian.net/cgi-bin/man.cgi?query=service I'm going to have to do some research on how the two service management systems might co-exist. I think the minimum requirement for co-existence would be a high-level lock to make sure Upstart didn't try to start nslcd while the System V script was running, and vice versa. - I'm not sure I understand flock's -c option well enough to know what failure modes would result from its absence, although the manpage certainly seems to indicate it's necessary. It bothers me that my tests haven't failed with the -c option absent. From what I'm reading in the manpages, I'd expect to get a pretty noisy failure without the -c option present, since the `start` obviously not a valid file descriptor. I think I need to run more tests... The "start" command is indeed part of Upstart, though. - the libsasl2-modules-gssapi-mit | libsasl2-modules-gssapi-heimdal recommendation is present because one of those modules is required to perform GSS-API (in our case, Kerberos) authentication to an LDAP server. So, it's actually a requirement (not just a recommendation) for Kerberos authentication to the LDAP server. I think the ideal solution would a separate `nslcd-kerberos` package with Kerberos-related scripts and those recommendations as requirements. That change seemed outside the scope of the original bug report, though, so I didn't include it in the patch. I'm not sure my initial assessment is correct, though-- thoughts? - good point regarding the checks for /etc/init.d/nscd: fixed - good point regarding the stopping of nscd in the post-stop script: it's been dropped. - leftover date commmand: fixed - if-up.d script's lack of non-Upstart environments noted. I think the fix will depend on how the service management system co-existence is implemented. - NSLCD_STATEDIR created before parsing: fixed - I'm not sure what you mean by "prestart or start missing". Are you thinking a pre-start script stanza is mandatory? - debian/rules tries to install nslcd-kerberos.upstart: fixed - Debian's lack of --upstart-only noted. (see comments regarding co- existence) - Passing --noscripts preventing nscld restart noted. (see comments regarding co-existence) - the post-start script in nslcd-k5start is invoked immediately after the main script starts, because we aren't using the `expect` stanza and daemonizing k5start (k5start doesn't seem to play nicely with Upstart's `expect` stanzas). So, if k5start is needed, the main script should continue running until the service is stopped. If k5start is not needed, the main script will terminate, which should cause the post-start script to terminate as well (see the clause that starts with "statusnow=`status`"). - tabs to spaces: changed. You and I obviously have different opinions of tabs vs. spaces, but there's much more important technical issues to be solved here. :) -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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: Feature Request: Upstart scripts for nslcd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3250735/+files/nslcd-upstart-rev5.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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, correct rev 4" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3243775/+files/nslcd-upstart-rev4.debdiff ** Patch removed: "Upstart script patch, rev 4" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3240212/+files/nslcd-upstart.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 "start on" condition to start once at runlevels [23456], and added a if-up.d script to signal nslcd to start whenever an interface comes up -took advantage of Upstart's built-in log facilities; removed redundant "starting..." messages. -check state of job in post-start loop -use "stop; exit 0" instead of "exit 1" -removed unused env stanzas -use install -d instead of mkdir+chown What hasn't changed: -The scripts still use an /etc/defaults file--I know of no way to do expansion with env variables, which is a requirement for several default values. -Logging of diangostic information when the job terminates because of an improperly configured environment (e.g. missing binaries) ** Patch added: "Upstart script patch, rev 4" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3240212/+files/nslcd-upstart.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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, 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 script
in testing. Suppose we have two interfaces, a "good" interface that can
connect us to the LDAP/Kerberos servers, and a "bad" interface that
can't. If the "bad" interface comes up first, the nslcd job will start,
and eventually terminate. However, it's possible the "good" interface
will come up _while the nslcd job is in the process of failing_. If so,
Upstart will see the nslcd job is running and refrain from launching a
duplicate job, which means the nslcd service will never be launched
without manual intervention.
Any ideas on how to resolve this? It seems like the if-up.d script needs
to wait until the nslcd job was either in the "started" or "stopped"
state--we can't assume the "starting" state is sufficient evidence that
the job is completely run. This could be done with a loop similar to the
one in the nslcd-kerberos post-start script, but hopefully you or
someone else knows of a more elegant solution.
Also, in the point about the use of 'exit 1', you say, "Also a non-
existant binary is not an error, so do not print anything or exit 1 for
that." I can understand using 'stop; exit 0' instead of 'exit 1', but
are you sure about the recommendation to not print anything? Many of my
most frustrating troubleshooting sessions in Linux are related to
services that fail to launch without providing any diagnostic output--
I'm sure others have had the same experience. It seems like good
practice to let the user/administrator know _why_ we can't start the
service instead of failing silently.
Thanks for your time and attention to making this patch as robust and
bullet-proof as possible. Every refinement gives me a warm fuzzy
feeling. :D
-Caleb
--
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:
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 Title: Feature Request: Upstart scripts for nslcd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 we don't stall the job start process indefinitely) Patch is attached. Contains the updated logic, as well as miscellaneous edits for clarity. ** Patch added: "nslcd-upstart.debdiff" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3225705/+files/nslcd-upstart.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 989405] Re: GNOME with Xmonad session requires gnome-panel
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. Hopefully somebody else with knowledge of the Debian BTS' idiosyncrasies is available and can handle the report. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/989405 Title: GNOME with Xmonad session requires gnome-panel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xmonad/+bug/989405/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 989405] Re: GNOME with Xmonad session requires gnome-panel
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 this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/989405 Title: GNOME with Xmonad session requires gnome-panel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xmonad/+bug/989405/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 989405] Re: GNOME with Xmonad session requires gnome-panel
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 separate xmonad-gnome package that installs the session and requires gnome-panel. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/989405 Title: GNOME with Xmonad session requires gnome-panel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xmonad/+bug/989405/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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, Upstart believes the nslcd-k5start job has started as soon as the calls to sed/hostname/etc are made and starts the nslcd job, which fails because it can't find the credentials cache it needs. I can think of three options, none of which look good: 1) Use kinit in a pre-start script for the nslcd-k5start job, and duplicate the K5START_START logic in both the pre-start script and the main script. 2) Re-solve the problem that Upstart's supposed to solve with a signalling system, like letting the nslcd job wait until the nslcd-k5start job had set a flag (or a timeout occurs). Something like a spin lock. 3) Stall the nslcd script for set period of time and hope the nslcd-k5start script doesn't take very long to start. At the moment, option 3 seems like the best of the bad options: introducing an extra dependency and duplicating control logic seems like a good way to introduce bugs, and implementing a lock system is robust but complicated. A revised debdiff that uses the third option is attached. I'm quite open to arguments in favor of another option, and I'd be delighted to know of a non-hackish solution. ** Patch added: "Revised Upstart scripts" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3220650/+files/nslcd-upstart.debdiff -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 nslcd.conf settings. Rewriting to account for this cleans up the logic quite a bit. I'm struggling with some very odd behavior (calling kinit and k5start in the same script stanza fails if the job is started as a pre-condition for some other job, but works fine if the job is started directly), but expect to submit a revised debdiff in the next day or so. -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 (I haven't tested this recently--I probably should), nslcd would simply terminate if no network connections were available, so there was a race condition between nslcd and the networking configuration scripts. The Upstart script is triggered by an event that's emitted when a network interface is fully configured (net-device- up), so that race condition is avoided. I removed the init.d script for a couple reasons. First, running `service nslcd restart` was preferring the init.d script to the Upstart script if the init.d script was present, leading to unexpected behavior. Second, it seemed best to have a single method for starting the daemon. Multiple, independent methods seemed like a good way to confuse users. When I built a test package with debuild in Ubuntu, wrappers for the Upstart scripts were placed in /etc/init.d/. I'd assume the same is true for Debian packages, but I haven't tested it. Point taken about the status 1 exit when sasl_mech or krb5_ccname isn't available--those two checks should definitely exit with status 0. I setup logging to the /tmp directory because AFAIK there's no good way to leverage existing log facilities with Upstart, and I understand that /tmp is usually available earlier in the boot process than /var. The log files contain diagnostic information about the startup process only--no secrets are shared. So, it seemed safe to have a log file, even though it wouldn't necessarily survive a reboot. Can you point out the duplicate checks? There's a lot of annoying redundancy in the variable initialization because Upstart's env directive doesn't support expansion (see https://bugs.launchpad.net/upstart/+bug/328366), but I tried to eliminate duplicate checks wherever possible. The one duplicate check I see is the initialization of the state directory, which happens in both nslcd and nslcd-kerberos scripts. That's there because we require a state directory for both daemons, but we can't assume one has run before the other. Resolving the race condition with networking configuration is the primary motive for moving to the Upstart script. Extracting the Kerberos-related initialization into a separate file doesn't improve the functionality at all; I did it so I could take advantage of Upstart's management features instead of manually killing the daemon. Also, it makes the core nslcd script much more readable, IMO. Hopefully that answers your questions. Just let me know if anything needs clarification. -- 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 806761] Re: Feature Request: Upstart scripts for nslcd
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 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: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 223825] Re: aiccu init.d script will race dhclient (upstart issue?)
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've seen nothing that indicates the forking problem in Upstart is going to be resolved soon, and there have been no recent updates to AICCU either. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/223825 Title: aiccu init.d script will race dhclient (upstart issue?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 897212] Re: lightdm ignores session selection of ldap users
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 member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/897212 Title: lightdm ignores session selection of ldap users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 873784] Re: reload_passwd uses fgetpwent rather than getpwent, ignoring /etc/nsswitch.conf
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 member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/873784 Title: reload_passwd uses fgetpwent rather than getpwent, ignoring /etc/nsswitch.conf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/873784/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 897212] Re: lightdm ignores session selection of ldap users
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. https://bugs.launchpad.net/bugs/897212 Title: lightdm ignores session selection of ldap users To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/897212/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
