[Touch-packages] [Bug 1714039] [NEW] nslcd shuts down before sshd, causing errors
Public bug reported: 1] >lsb_release -rd Description:Ubuntu 17.04 Release:17.04 2] >apt-cache policy systemd systemd: Installed: 232-21ubuntu5 Candidate: 232-21ubuntu5 Version table: *** 232-21ubuntu5 500 500 http://dca-ubuntu-repo.ipipenet.com/ubuntu zesty-updates/main amd64 Packages 500 http://dca-ubuntu-repo.ipipenet.com/ubuntu-security zesty-security/main amd64 Packages 100 /var/lib/dpkg/status 232-21ubuntu2 500 500 http://dca-ubuntu-repo.ipipenet.com/ubuntu zesty/main amd64 Packages 3] i expected nslcd to not be terminated when sshd still needs it 4] it was logs: Aug 30 15:17:26 template nslcd[956]: thread 1 is still running, shutting down anyway Aug 30 15:17:26 template sshd[988]: pam_ldap(sshd:session): error opening connection to nslcd: No such file or directory Aug 30 15:17:26 template sshd[988]: pam_systemd(sshd:session): Failed to release session: Connection reset by peer Aug 30 15:17:26 template sshd[988]: pam_mail(sshd:session): user unknown Aug 30 15:17:26 template sshd[988]: fatal: login_init_entry: Cannot find user "jdoe" ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1714039 Title: nslcd shuts down before sshd, causing errors Status in systemd package in Ubuntu: New Bug description: 1] >lsb_release -rd Description: Ubuntu 17.04 Release: 17.04 2] >apt-cache policy systemd systemd: Installed: 232-21ubuntu5 Candidate: 232-21ubuntu5 Version table: *** 232-21ubuntu5 500 500 http://dca-ubuntu-repo.ipipenet.com/ubuntu zesty-updates/main amd64 Packages 500 http://dca-ubuntu-repo.ipipenet.com/ubuntu-security zesty-security/main amd64 Packages 100 /var/lib/dpkg/status 232-21ubuntu2 500 500 http://dca-ubuntu-repo.ipipenet.com/ubuntu zesty/main amd64 Packages 3] i expected nslcd to not be terminated when sshd still needs it 4] it was logs: Aug 30 15:17:26 template nslcd[956]: thread 1 is still running, shutting down anyway Aug 30 15:17:26 template sshd[988]: pam_ldap(sshd:session): error opening connection to nslcd: No such file or directory Aug 30 15:17:26 template sshd[988]: pam_systemd(sshd:session): Failed to release session: Connection reset by peer Aug 30 15:17:26 template sshd[988]: pam_mail(sshd:session): user unknown Aug 30 15:17:26 template sshd[988]: fatal: login_init_entry: Cannot find user "jdoe" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1714039/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1709384] Re: failed to unmount filesystems during shutdown, reboot hangs
i've figured out at least part of this issue. the system now no longer hangs at shutdown, but there are still filesystems it complains it is unable to unmount, and the system still hangs if it unable to unmount /home, which happens to be an nfs share [i'm uncertain if this is of particular relevance, but it is a characteristic unique among this system's filesystems]. the root cause was pam_systemd inadvertently excluded from the pam session config, following customization. this was causing another problem [ssh sessions hanging during shutdown instead of being cleanly terminated], and it was during troubleshooting of the ssh issue when it hit me that there was a relationship between the two. during shutdown, systemd brings down the network connection before ssh processes are gracefully disconnected/terminated. this leaves the client unaware, thus the hanging symptom. additionally, this appears to also leave processes active or files open, etc., in various locations, and thus affected filesystems are still in use and cannot be unmounted. to make matters worse, when the filesystem in use happens to be an nfs share [in this case, /home/foo.example.com/], the system hangs at shutdown. with pam_systemd properly configured in the pam session config, ssh processes/sessions get to gracefully close, /home/foo.example.com/ and /tmp/ are cleanly/successfully unmounted, and since the nfs share gets unmounted, the system does not hang. however, /var/ and /var/log/ still fail to be unmounted: Aug 30 03:27:09 template systemd[1]: Failed unmounting /var/log. Aug 30 03:27:09 template systemd[1]: Failed unmounting /var. this is still a problem which shouldn't be happening, but fortunately, since it's only the nfs unmount fail that makes the system hang, reboots aren't disastrous. there are still issues here that need to be addressed: 1] under nominal conditions, filesystems should cleanly unmount. unmounting should not fail. 2] if a filesystem fails to unmount [nfs or otherwise], the system should not hang during shutdown. this can be recreated by doing the following: • configure the system to mount an nfs share at boot [i used fstab]. it may also be enough to just mount an nfs share manually after boot • disable pam_systemd in the pam session config • ssh to the computer • change directory into the nfs share, so the filesystem is in use • reboot -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1709384 Title: failed to unmount filesystems during shutdown, reboot hangs Status in systemd package in Ubuntu: New Bug description: i'd done a new install of 17.04, and this had been working ok. this morning, i did an update, and now the system complains about being unable to unmount certain filesystems, as well as hanging during the shutdown process upon displaying "[ ok ] reached target shutdown" Aug 8 16:11:48 template systemd[1]: Failed unmounting /home/foo.example.com. Aug 8 16:11:49 template systemd[1]: Failed unmounting /var/log. Aug 8 16:11:49 template systemd[1]: Failed unmounting /tmp. Aug 8 16:11:49 template systemd[1]: Failed unmounting /home. Aug 8 16:11:49 template systemd[1]: Failed unmounting /var. 1] >lsb_release -rd Description: Ubuntu 17.04 Release: 17.04 2] >apt-cache policy systemd systemd: Installed: 232-21ubuntu5 Candidate: 232-21ubuntu5 Version table: *** 232-21ubuntu5 500 500 http://us.archive.ubuntu.com/ubuntu zesty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu zesty-security/main amd64 Packages 100 /var/lib/dpkg/status 232-21ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu zesty/main amd64 Packages 3] i expected the system to not fail when unmounting filesystems during shutdown 4] it did To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1709384/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1709384] [NEW] failed to unmount filesystems during shutdown, reboot hangs
Public bug reported: i'd done a new install of 17.04, and this had been working ok. this morning, i did an update, and now the system complains about being unable to unmount certain filesystems, as well as hanging during the shutdown process upon displaying "[ ok ] reached target shutdown" Aug 8 16:11:48 template systemd[1]: Failed unmounting /home/foo.example.com. Aug 8 16:11:49 template systemd[1]: Failed unmounting /var/log. Aug 8 16:11:49 template systemd[1]: Failed unmounting /tmp. Aug 8 16:11:49 template systemd[1]: Failed unmounting /home. Aug 8 16:11:49 template systemd[1]: Failed unmounting /var. 1] >lsb_release -rd Description:Ubuntu 17.04 Release:17.04 2] >apt-cache policy systemd systemd: Installed: 232-21ubuntu5 Candidate: 232-21ubuntu5 Version table: *** 232-21ubuntu5 500 500 http://us.archive.ubuntu.com/ubuntu zesty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu zesty-security/main amd64 Packages 100 /var/lib/dpkg/status 232-21ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu zesty/main amd64 Packages 3] i expected the system to not fail when unmounting filesystems during shutdown 4] it did ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1709384 Title: failed to unmount filesystems during shutdown, reboot hangs Status in systemd package in Ubuntu: New Bug description: i'd done a new install of 17.04, and this had been working ok. this morning, i did an update, and now the system complains about being unable to unmount certain filesystems, as well as hanging during the shutdown process upon displaying "[ ok ] reached target shutdown" Aug 8 16:11:48 template systemd[1]: Failed unmounting /home/foo.example.com. Aug 8 16:11:49 template systemd[1]: Failed unmounting /var/log. Aug 8 16:11:49 template systemd[1]: Failed unmounting /tmp. Aug 8 16:11:49 template systemd[1]: Failed unmounting /home. Aug 8 16:11:49 template systemd[1]: Failed unmounting /var. 1] >lsb_release -rd Description: Ubuntu 17.04 Release: 17.04 2] >apt-cache policy systemd systemd: Installed: 232-21ubuntu5 Candidate: 232-21ubuntu5 Version table: *** 232-21ubuntu5 500 500 http://us.archive.ubuntu.com/ubuntu zesty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu zesty-security/main amd64 Packages 100 /var/lib/dpkg/status 232-21ubuntu2 500 500 http://us.archive.ubuntu.com/ubuntu zesty/main amd64 Packages 3] i expected the system to not fail when unmounting filesystems during shutdown 4] it did To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1709384/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1633643] [NEW] unnecessary dependency upon isc-dhcp-client
Public bug reported: with xenial-updates, there is suddenly a dependency [isc-dhcp-client] not previously there. please mark this as recommends/suggests/enhances instead of as a depends, as it is not critical to the core functionality of the software. since ubuntu now defaults to installing recommends unless configured otherwise, this compromise accommodates both the unskilled users as well as those who know what they are doing and have disabled automatic installation of suggested packages. 1] >lsb_release -rd Description:Ubuntu 16.04.1 LTS Release:16.04 2] >apt-cache policy initramfs-tools initramfs-tools: Installed: 0.122ubuntu8.3 Candidate: 0.122ubuntu8.3 Version table: *** 0.122ubuntu8.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages 100 /var/lib/dpkg/status 0.122ubuntu8 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 3] i expected to not be forced to install unnecessary packages 4] i was forced to thanks ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1633643 Title: unnecessary dependency upon isc-dhcp-client Status in initramfs-tools package in Ubuntu: New Bug description: with xenial-updates, there is suddenly a dependency [isc-dhcp-client] not previously there. please mark this as recommends/suggests/enhances instead of as a depends, as it is not critical to the core functionality of the software. since ubuntu now defaults to installing recommends unless configured otherwise, this compromise accommodates both the unskilled users as well as those who know what they are doing and have disabled automatic installation of suggested packages. 1] >lsb_release -rd Description: Ubuntu 16.04.1 LTS Release: 16.04 2] >apt-cache policy initramfs-tools initramfs-tools: Installed: 0.122ubuntu8.3 Candidate: 0.122ubuntu8.3 Version table: *** 0.122ubuntu8.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main i386 Packages 100 /var/lib/dpkg/status 0.122ubuntu8 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 3] i expected to not be forced to install unnecessary packages 4] i was forced to thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1633643/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1594658] Re: diskless setup with nfs mounted home hangs on shutdown/reboot
it appears that my symptoms also relate to this bug report. however, i'd like to add that the feedback provided by the system, at least in my particular case, is extremely unhelpful. i think it can be better. i have a very minimal virtual guest, running 16.04. it has a "physical" wired connection, and an nfs mount in fstab: >cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # proc/proc proc nodev,noexec,nosuid 0 0 LABEL=root / ext4 errors=remount-ro 0 1 LABEL=var /var ext4defaults 0 2 LABEL=swap none swapsw 0 0 10.128.35.251:/foo_example_com /home/foo.example.com nfs rw,hard,intr 0 0 >cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 10.101.27.31/24 gateway 10.101.27.1 in this case, there is no [perceptible] delay during shutdown, but a lengthy delay at boot, while system waits for mounting to succeed/timeout. when there are network problems, the nfs mount attempt cannot succeed, and this is when the system says "a start job is running for raise network interfaces", while it sits for five minutes, yet ultimately proceeds, with a perfectly operational network interface. this sucks. while the root cause here, in terms of the actual problem, is that 1] the nfs mount obviously fails, and 2] the timeout for this failure is [imho] too long, the troubleshooting process to determine this was made much longer than it should have been due to the poor feedback about what was actually happening. in this particular case, the system should, at the minimum, at least tell the operator that there is a mount attempt waiting, and ideally, provide some actual detail about what mount attempt in particular. saying "a start job is running for raise network interfaces" is woefully inadequate. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1594658 Title: diskless setup with nfs mounted home hangs on shutdown/reboot Status in nfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Ubuntu 16.04 fresh install hangs when shutting down. The system is diskless PXE-booted with a couple of nfs mounted directories including homedir. As I have no persistent storage whatsoever, I don't have any logs, but in debug-shell, running journalctl -f I can see that it hangs at [ *] (1 of 2) A stop job running for Raise Network Interfaces (10s / 1min 30s)Jun 20 20:23:05 $hostname kernel: nfs: server $nfs-ip-address not responding, still trying Jun 20 20:23:05 $hostname kernel: nfs: server $nfs-ip-address not responding, still trying Jun 20 20:23:14 $hostname kernel: nfs: server $nfs-ip-address not responding, still trying Jun 20 20:24:08 $hostname kernel: nfs: server $nfs-ip-address not responding, still trying Second job in "(1 of 2)" is thermald, turning it off does not fix the problem. Also, this counter "(10s / 1min 30s)" stops visually updating. server $nfs-ip-address is not responding, because, all network interfaces are already down at this point. I am not exactly sure why this happens. Looks like there is a wrong ordering of shutdown of systemd services, which bring down interfaces before something nfs-related, but I am not sure if that's the reason of hanging. Workaround that fixes the problem: In /lib/systemd/system/networking.service comment following line: ExecStop=/sbin/ifdown -a --r
[Touch-packages] [Bug 1510143] Re: --verbose no longer works
it used to list certificates [files] being processed. it now does not: >update-ca-certificates --verbose --fresh Clearing symlinks in /etc/ssl/certs... done. Updating certificates in /etc/ssl/certs... Doing . 175 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done. > on 15.04: >update-ca-certificates --verbose -fresh Clearing symlinks in /etc/ssl/certs...done. Updating certificates in /etc/ssl/certs... Doing . Certinomis_-_Autorité_Racine.pem => d957f522.0 Certinomis_-_Autorité_Racine.pem => 7672ac4b.0 Thawte_Server_CA.pem => 6cc3c4c3.0 Thawte_Server_CA.pem => ddc328ff.0 Buypass_Class_3_Root_CA.pem => e8de2f56.0 Buypass_Class_3_Root_CA.pem => 2d9dafe4.0 AffirmTrust_Premium_ECC.pem => 9c8dfbd4.0 AffirmTrust_Premium_ECC.pem => ccc52f49.0 [...] Entrust.net_Premium_2048_Secure_Server_CA.pem => 3e7271e8.0 StartCom_Certification_Authority_G2.pem => 876f1e28.0 StartCom_Certification_Authority_G2.pem => ee90b008.0 ApplicationCA_-_Japanese_Government.pem => 57bbd831.0 ApplicationCA_-_Japanese_Government.pem => fac084d7.0 DigiCert_Assured_ID_Root_G2.pem => 9d04f354.0 DigiCert_Assured_ID_Root_G2.pem => 8d6437c3.0 175 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1510143 Title: --verbose no longer works Status in ca-certificates package in Ubuntu: Incomplete Bug description: following an update from 15.04 to 15.10, the --verbose option no longer prints verbose output 1] >lsb_release -rd Description: Ubuntu 15.10 Release: 15.10 2] >apt-cache policy ca-certificates ca-certificates: Installed: 20150426ubuntu1 Candidate: 20150426ubuntu1 Version table: *** 20150426ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages 100 /var/lib/dpkg/status 3] i expected --verbose to print verbose output 4] it did not To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1510143/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1510143] [NEW] --verbose no longer works
Public bug reported: following an update from 15.04 to 15.10, the --verbose option no longer prints verbose output 1] >lsb_release -rd Description:Ubuntu 15.10 Release:15.10 2] >apt-cache policy ca-certificates ca-certificates: Installed: 20150426ubuntu1 Candidate: 20150426ubuntu1 Version table: *** 20150426ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages 100 /var/lib/dpkg/status 3] i expected --verbose to print verbose output 4] it did not ** Affects: ca-certificates (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1510143 Title: --verbose no longer works Status in ca-certificates package in Ubuntu: New Bug description: following an update from 15.04 to 15.10, the --verbose option no longer prints verbose output 1] >lsb_release -rd Description: Ubuntu 15.10 Release: 15.10 2] >apt-cache policy ca-certificates ca-certificates: Installed: 20150426ubuntu1 Candidate: 20150426ubuntu1 Version table: *** 20150426ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ wily/main amd64 Packages 100 /var/lib/dpkg/status 3] i expected --verbose to print verbose output 4] it did not To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1510143/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1489550] [NEW] errors logged with new install
Public bug reported:
immediately following a new install with a minimal configuration, i've
found that two messages are logged regarding dhcpd:
Aug 27 12:46:34 server dhcpd: Can't create PID file /run/dhcp-
server/dhcpd.pid: Permission denied.
Aug 27 12:46:37 honeycomb kernel: audit: type=1400
audit(1440693994.041:11): apparmor="DENIED" operation="capable"
profile="/usr/sbin/dhcpd" pid=10990 comm="dhcpd" capability=1
capname="dac_override"
while dhcpd does continue starting, and appears [given rudimentary
testing] to operate properly, a fresh/new install of the software should
not produce messages like this.
here is the config being used:
log-facility local7;
ddns-update-style none;
default-lease-time 43200;
max-lease-time 86400;
authoritative;
subnet 172.31.0.0 netmask 255.255.255.240 {
range 172.31.0.7 172.31.0.14;
}
1] >lsb_release -rd
Description:Ubuntu 15.04
Release:15.04
2] >apt-cache policy isc-dhcp-server
isc-dhcp-server:
Installed: 4.3.1-5ubuntu2.2
Candidate: 4.3.1-5ubuntu2.2
Version table:
*** 4.3.1-5ubuntu2.2 0
500 http://us.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64
Packages
100 /var/lib/dpkg/status
4.3.1-5ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages
3] i expected a new install with a basic config to not produce message like the
above
4] messages were produced
** Affects: isc-dhcp (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1489550
Title:
errors logged with new install
Status in isc-dhcp package in Ubuntu:
New
Bug description:
immediately following a new install with a minimal configuration, i've
found that two messages are logged regarding dhcpd:
Aug 27 12:46:34 server dhcpd: Can't create PID file /run/dhcp-
server/dhcpd.pid: Permission denied.
Aug 27 12:46:37 honeycomb kernel: audit: type=1400
audit(1440693994.041:11): apparmor="DENIED" operation="capable"
profile="/usr/sbin/dhcpd" pid=10990 comm="dhcpd" capability=1
capname="dac_override"
while dhcpd does continue starting, and appears [given rudimentary
testing] to operate properly, a fresh/new install of the software
should not produce messages like this.
here is the config being used:
log-facility local7;
ddns-update-style none;
default-lease-time 43200;
max-lease-time 86400;
authoritative;
subnet 172.31.0.0 netmask 255.255.255.240 {
range 172.31.0.7 172.31.0.14;
}
1] >lsb_release -rd
Description: Ubuntu 15.04
Release: 15.04
2] >apt-cache policy isc-dhcp-server
isc-dhcp-server:
Installed: 4.3.1-5ubuntu2.2
Candidate: 4.3.1-5ubuntu2.2
Version table:
*** 4.3.1-5ubuntu2.2 0
500 http://us.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64
Packages
100 /var/lib/dpkg/status
4.3.1-5ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages
3] i expected a new install with a basic config to not produce message like
the above
4] messages were produced
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1489550/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1452538] Re: opendkim does not start properly when ldap server can't be contacted
it seems like in addition to the softstart issue, the init script is in need of some attention? it runs start-stop-daemon to check the config and start the process, but both commands are or'd with a return 1 or return 2. the check to handle exit status 78 can never happen, because the only way it will continue in that function is if the exit status for both start-stop-daemon commands is 0. then, regardless of any of that, the script exits 0 no matter what, so systemd never knows something didn't go right. it's left thinking the service is running, but it's not. when the init script is changed to exit with the exit status of dkim, then systemd knows what's going on and handles the outcome as expected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1452538 Title: opendkim does not start properly when ldap server can't be contacted Status in systemd package in Ubuntu: New Bug description: when starting opendkim, if ldap is in use and the server cannot be contacted, opendkim gets stuck in a state where the system appears to think it has started, but is not actually running: >systemctl -l status opendkim ● opendkim.service - LSB: Start the OpenDKIM service Loaded: loaded (/etc/init.d/opendkim) Active: active (exited) since Wed 2015-05-06 23:16:20 EDT; 1min 24s ago Docs: man:systemd-sysv-generator(8) Process: 589 ExecStart=/etc/init.d/opendkim start (code=exited, status=0/SUCCESS) May 06 23:16:19 server systemd[1]: Starting LSB: Start the OpenDKIM service... May 06 23:16:20 server opendkim[589]: Starting OpenDKIM: opendkim: /etc/opendkim/opendkim.conf: ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d): dkimf_db_open(): Can't contact LDAP server May 06 23:16:20 server opendkim[589]: opendkim. May 06 23:16:20 server systemd[1]: Started LSB: Start the OpenDKIM service. >ps -aefwww | grep -iF dkim root 858 815 0 23:18 pts/000:00:00 grep -iF dkim additional attempts to start opendkim don't indicate failure, but also don't work: >systemctl start opendkim > >ps -aefwww | grep -iF dkim root 863 815 0 23:19 pts/000:00:00 grep -iF dkim additionally, as can be seen in the above systemctl status output, systemd appears to think that opendkim has started successfully, but when testing manually, it does not: >/usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid opendkim: /etc/opendkim/opendkim.conf: ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d): dkimf_db_open(): Can't contact LDAP server >echo $? 78 lastly, stopping opendkim [even though it's not really running] and then starting it again then results in it actually running: >systemctl stop opendkim >systemctl start opendkim >ps -aefwww | grep -iF opendkim opendkim 1105 1 0 23:24 ?00:00:00 /usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid opendkim 1106 1105 0 23:24 ?00:00:00 /usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid root 1117 815 0 23:25 pts/000:00:00 grep -iF opendkim To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1452538/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1452538] Re: opendkim does not start properly when ldap server can't be contacted
some additional detail regarding SoftStart - it seems to not be working right [systemd issues excluded]: >egrep -v '(^[[:space:]]*#|^[[:space:]]*$)' opendkim.conf Syslog yes SyslogSuccess yes LogWhy yes UMask 002 BaseDirectory /etc/opendkim Socket inet:dkim-filter@localhost Modes Quarantine no RemoveOldSignatures no SubDomains no SoftStart yes LDAPUseTLS yes LDAPBindUser cn=opendkim,ou=exo,ou=services,ou=accounts,dc=example,dc=com LDAPBindPasswordxx InternalHosts localhost, 192.0.2.1 Selectordefault KeyFile /etc/opendkim/keys/default-private_key.pem Domain ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d) >/usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P >/var/run/opendkim/opendkim.pid opendkim: /etc/opendkim/opendkim.conf: ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d): dkimf_db_open(): Can't contact LDAP server >echo $? 78 according to the init script, exit status 78 indicates a configuration error? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1452538 Title: opendkim does not start properly when ldap server can't be contacted Status in systemd package in Ubuntu: New Bug description: when starting opendkim, if ldap is in use and the server cannot be contacted, opendkim gets stuck in a state where the system appears to think it has started, but is not actually running: >systemctl -l status opendkim ● opendkim.service - LSB: Start the OpenDKIM service Loaded: loaded (/etc/init.d/opendkim) Active: active (exited) since Wed 2015-05-06 23:16:20 EDT; 1min 24s ago Docs: man:systemd-sysv-generator(8) Process: 589 ExecStart=/etc/init.d/opendkim start (code=exited, status=0/SUCCESS) May 06 23:16:19 server systemd[1]: Starting LSB: Start the OpenDKIM service... May 06 23:16:20 server opendkim[589]: Starting OpenDKIM: opendkim: /etc/opendkim/opendkim.conf: ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d): dkimf_db_open(): Can't contact LDAP server May 06 23:16:20 server opendkim[589]: opendkim. May 06 23:16:20 server systemd[1]: Started LSB: Start the OpenDKIM service. >ps -aefwww | grep -iF dkim root 858 815 0 23:18 pts/000:00:00 grep -iF dkim additional attempts to start opendkim don't indicate failure, but also don't work: >systemctl start opendkim > >ps -aefwww | grep -iF dkim root 863 815 0 23:19 pts/000:00:00 grep -iF dkim additionally, as can be seen in the above systemctl status output, systemd appears to think that opendkim has started successfully, but when testing manually, it does not: >/usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid opendkim: /etc/opendkim/opendkim.conf: ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d): dkimf_db_open(): Can't contact LDAP server >echo $? 78 lastly, stopping opendkim [even though it's not really running] and then starting it again then results in it actually running: >systemctl stop opendkim >systemctl start opendkim >ps -aefwww | grep -iF opendkim opendkim 1105 1 0 23:24 ?00:00:00 /usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid opendkim 1106 1105 0 23:24 ?00:00:00 /usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid root 1117 815 0 23:25 pts/000:00:00 grep -iF opendkim To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1452538/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1452538] Re: opendkim does not start properly when ldap server can't be contacted
thanks for this. i'd tried LDAPSoftStart, which didn't work, missing that it had been renamed. i've added SoftStart yes to the config, but the behavior seems to be the same. i can corroborate that this seems new with 15.04/systemd. another older system like yours works ok. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1452538 Title: opendkim does not start properly when ldap server can't be contacted Status in systemd package in Ubuntu: New Bug description: when starting opendkim, if ldap is in use and the server cannot be contacted, opendkim gets stuck in a state where the system appears to think it has started, but is not actually running: >systemctl -l status opendkim ● opendkim.service - LSB: Start the OpenDKIM service Loaded: loaded (/etc/init.d/opendkim) Active: active (exited) since Wed 2015-05-06 23:16:20 EDT; 1min 24s ago Docs: man:systemd-sysv-generator(8) Process: 589 ExecStart=/etc/init.d/opendkim start (code=exited, status=0/SUCCESS) May 06 23:16:19 server systemd[1]: Starting LSB: Start the OpenDKIM service... May 06 23:16:20 server opendkim[589]: Starting OpenDKIM: opendkim: /etc/opendkim/opendkim.conf: ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d): dkimf_db_open(): Can't contact LDAP server May 06 23:16:20 server opendkim[589]: opendkim. May 06 23:16:20 server systemd[1]: Started LSB: Start the OpenDKIM service. >ps -aefwww | grep -iF dkim root 858 815 0 23:18 pts/000:00:00 grep -iF dkim additional attempts to start opendkim don't indicate failure, but also don't work: >systemctl start opendkim > >ps -aefwww | grep -iF dkim root 863 815 0 23:19 pts/000:00:00 grep -iF dkim additionally, as can be seen in the above systemctl status output, systemd appears to think that opendkim has started successfully, but when testing manually, it does not: >/usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid opendkim: /etc/opendkim/opendkim.conf: ldap://dsa.example.com/ou=domains,ou=mail,dc=example,dc=com?host?sub?(host=$d): dkimf_db_open(): Can't contact LDAP server >echo $? 78 lastly, stopping opendkim [even though it's not really running] and then starting it again then results in it actually running: >systemctl stop opendkim >systemctl start opendkim >ps -aefwww | grep -iF opendkim opendkim 1105 1 0 23:24 ?00:00:00 /usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid opendkim 1106 1105 0 23:24 ?00:00:00 /usr/sbin/opendkim -x /etc/opendkim/opendkim.conf -u opendkim -P /var/run/opendkim/opendkim.pid root 1117 815 0 23:25 pts/000:00:00 grep -iF opendkim To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1452538/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1452087] Re: slapd [or its init script] does not create necessary directory for nssov socket and fails to start
there was an apparmor message logged:
May 6 22:52:05 server kernel: audit: type=1400
audit(1430967118.381:12): apparmor="DENIED" operation="mkdir"
profile="/usr/sbin/slapd" name="/run/nslcd/" pid=1419 comm="slapd"
requested_mask="c" denied_mask="c" fsuid=108 ouid=108
adding to /etc/apparmor.d/local/usr.sbin.slapd [among some other
things]:
/etc/ldap/pki/** rw,
/{,var/}run/slapd/* rw,
/{,var/}run/nslcd/ rw,
/{,var/}run/nslcd/* rw,
seems to have addressed that, but the directory still isn't created.
temporarily changing /run/ to 777 seem to reinforce rtandy's reference.
the directory is then created, but not with adequate permissions:
dr-xr-xr-x 2 openldap openldap 40 May 6 23:01 nslcd/
slapd[2357]: nssov: bind() to /var/run/nslcd/socket failed: Permission
denied
adjusting them manually after creation confirms this, and slapd then
starts.
at the moment, i've added the following to the init script:
NSSOV_SOCKETDIR='/var/run/nslcd'
start_slapd() {
[ -d "${NSSOV_SOCKETDIR}" ] || ( mkdir -m 755 "${NSSOV_SOCKETDIR}" ; \
chown openldap.openldap "${NSSOV_SOCKETDIR}" )
which solves the problem for me [albeit the wrong way, imo], since it's
blindly doing it regardless of if the overlay is actually in use.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1452087
Title:
slapd [or its init script] does not create necessary directory for
nssov socket and fails to start
Status in openldap package in Ubuntu:
New
Bug description:
when used with the nss overlay, slapd fails to start, because
/var/run/nslcd/ does not exist, and slap cannot then create the socket
for this. additionally, creating the directory manually does not
help, because it disappears after every reboot.
1] >lsb_release -rd
Description: Ubuntu 15.04
Release: 15.04
2] >apt-cache policy slapd
slapd:
Installed: 2.4.31-1+nmu2ubuntu12
Candidate: 2.4.31-1+nmu2ubuntu12
Version table:
*** 2.4.31-1+nmu2ubuntu12 0
500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages
100 /var/lib/dpkg/status
3] i expected the necessary directory to be created when starting slapd if
the nss overlay is in use
4] it was not
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1452087/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1452087] [NEW] slapd [or its init script] does not create necessary directory for nssov socket and fails to start
Public bug reported: when used with the nss overlay, slapd fails to start, because /var/run/nslcd/ does not exist, and slap cannot then create the socket for this. additionally, creating the directory manually does not help, because it disappears after every reboot. 1] >lsb_release -rd Description:Ubuntu 15.04 Release:15.04 2] >apt-cache policy slapd slapd: Installed: 2.4.31-1+nmu2ubuntu12 Candidate: 2.4.31-1+nmu2ubuntu12 Version table: *** 2.4.31-1+nmu2ubuntu12 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status 3] i expected the necessary directory to be created when starting slapd if the nss overlay is in use 4] it was not ** Affects: openldap (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1452087 Title: slapd [or its init script] does not create necessary directory for nssov socket and fails to start Status in openldap package in Ubuntu: New Bug description: when used with the nss overlay, slapd fails to start, because /var/run/nslcd/ does not exist, and slap cannot then create the socket for this. additionally, creating the directory manually does not help, because it disappears after every reboot. 1] >lsb_release -rd Description: Ubuntu 15.04 Release: 15.04 2] >apt-cache policy slapd slapd: Installed: 2.4.31-1+nmu2ubuntu12 Candidate: 2.4.31-1+nmu2ubuntu12 Version table: *** 2.4.31-1+nmu2ubuntu12 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status 3] i expected the necessary directory to be created when starting slapd if the nss overlay is in use 4] it was not To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1452087/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
