After updating to the latest packages, this issue is solve. I can lxc-
start, lxc-attach, lxc-stop, and lxc-execute.
I do get some warning/error spew when running lxc-execute though. If
this looks unexpected, I can open a separate bug for it:
$ lxc-execute -n t1 -- /bin/bash
lxc-execute: utils.c:
Thanks. The chown solves the issue. I didn't need to make the
modification to the pam config file at all. I do need to do the chown
every time I log in though, with or without the pam change.
FWIW, when I ssh into the working server, the relevant /sys directory is
owned by swarren:swarren without
Could you please expand on "Then re-chown your current systemd cgroup"?
I'm not sure exactly how/where cgroups get mounted, so I'm not sure what
path I should chown.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https:/
Yes, I'm running lightdm.
$ cat /etc/pam.d/common-session
session [default=1] pam_permit.so
session requisite pam_deny.so
session requiredpam_permit.so
session optionalpam_umask.so
session requiredpa
Switching the linode system to the Ubuntu kernel (booted via pv-grub)
didn't make that system fail. Perhaps the difference is cgroup setup via
ssh vs XFCE/GUI login?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to lxc in Ubuntu.
https:/
I have 2 Xenial systems. They are both fully up-to-date as of 5 minutes
ago. The failing system is a laptop running XFCE GUI, and I'm attempting
to use LXC from a GUI terminal. The other system is a linode that I
access via ssh, and LXC works fine there. I believe I've configured the
two systems th
Public bug reported:
On Ubuntu Xenial pre-release, I see the following, so can't start a
container:
[swarren@sprint ~]$ lxc-create -t download -n t2 -- -d ubuntu -r trusty -a amd64
Using image from local cache
Unpacking the rootfs
---
You just created an Ubuntu container (release=trusty, arch=am
This also affects Lucid, and I would guess Precise. I can't quite tell
how to add extra releases in to the list above.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to spamassassin in Ubuntu.
https://bugs.launchpad.net/bugs/1397706
Titl
Well, I just rebooted 25 times in a row and couldn't reproduce this
issue any more, although it was happening perhaps 25-50% of the time a
while back (since then, I got hibernate working, so haven't rebooted so
often). I suppose that'll pay me for being lazy about filing the bug; I
should have file
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/48691748/Dependencies.txt
--
slapd sometimes doesn't start in lucid; can't log in if using nss_ldap
https://bugs.launchpad.net/bugs/582627
You received this bug notification because you are a member of Ubuntu
Server Team, w
Public bug reported:
When I reboot my machine running lucid, slapd often doesn't start at
all. Since my non-system users are all stored in the ldap database via
nss_ldap etc., this means that I can't log in.
Note: This problem is intermittent; it doesn't happen every time by any
means. After upgr
> When you say "still log in as root to fix this", did you have to make
> additional edits after you got slapd running again (as you mentioned in
> your original problem description)? That is, were you locked out just
> because slapd wasn't running, and then back to normal again once you got
> sla
Re: the mention of symptoms in comment #12 above: My symptom was that I
could not log in at all, and in existing sessions, sudo wouldn't work
etc. I store user information in LDAP, with just system users in
/etc/passwd etc., so luckily I could still log in as root to fix this.
--
slapd 2.4.21-0ub
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/45859593/Dependencies.txt
--
slapd 2.4.21-0ubuntu5 corrupts olcDatabase={-1}frontend.ldif with duplicate
olcAccess lines (again)
https://bugs.launchpad.net/bugs/571057
You received this bug notification because you are a m
Public bug reported:
Bug 526230 is back.
I had slapd 2.4.21-0ubuntu4 installed, then "apt-get dist-upgrade",
which pulled in slapd 2.4.21-0ubuntu5. This modified
/etc/ldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif by adding
duplicate olcAccess lines without any {0} index prefix, causing sla
** Attachment added: "/etc/ldap from jaunty"
http://launchpadlibrarian.net/39587719/ldap.tar.bz2
--
jaunty -> karmic upgrade modifies cn=config DB definition, creates syntax
error, slapd won't start
https://bugs.launchpad.net/bugs/526230
You received this bug notification because you are a m
Public bug reported:
I had a couple of systems with jaunty installed, running the openldap
server, configured to use "cn=config" for configuration. On both
systems, when I upgraded to karmic, something rewrote
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif (or perhaps it
was olcDatabase={1
Thanks. Is there any chance of including this in at least Karmic?
--
Postfix not sending SMFIC_RCPT to milter, libmilter rejecting state transition
https://bugs.launchpad.net/bugs/501364
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to post
Public bug reported:
Binary package hint: postfix
I reported a bug to the postfix mailing list regarding an incorrect
interaction between postfix and milters. Wietse created a patch which I
tested, and it works OK. I'd hoped this would be rolled into a new
postfix release, but this seems to be ta
Public bug reported:
Binary package hint: dovecot-common
The dovecot package include *a* sieve plugin (CMU sieve), but not
dovecot's own sieve plugin:
r...@severn:/usr/lib/dovecot/modules/lda# ls -l|grep -i sieve
-rw-r--r-- 1 root root 191910 2009-04-20 02:23 lib90_cmusieve_plugin.a
-rw-r--r-- 1
20 matches
Mail list logo
