Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
On Fri, Feb 10 2017, Michael Biebl wrote: > Looks similar to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848044 and a lot like > https://github.com/systemd/systemd/issues/1620 Uhm, it does. Aside from the fact that it's not at all harmless as mentioned, since the root fs is not unmounted. And since the journal itself becomes corrupted, the log is lost. However there seem to be no real progress on any front, including in the bugs regarding cryptsetup and lvm2 (which I've seen before). I cannot explain why given the exact same partition/volume scheme by lvm/cryptsetup, in one case I can shutdown cleanly, and in the other it breaks. I looked at the documentation twice, but I couldn't see any way to somehow simulate the chain of events that shutdown.target should generate. I guess there's no way? ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processing of systemd_232-17_amd64.changes
systemd_232-17_amd64.changes uploaded successfully to localhost along with the files: systemd_232-17.dsc systemd_232-17.debian.tar.xz libnss-myhostname-dbgsym_232-17_amd64.deb libnss-myhostname_232-17_amd64.deb libnss-mymachines-dbgsym_232-17_amd64.deb libnss-mymachines_232-17_amd64.deb libnss-resolve-dbgsym_232-17_amd64.deb libnss-resolve_232-17_amd64.deb libnss-systemd-dbgsym_232-17_amd64.deb libnss-systemd_232-17_amd64.deb libpam-systemd-dbgsym_232-17_amd64.deb libpam-systemd_232-17_amd64.deb libsystemd-dev-dbgsym_232-17_amd64.deb libsystemd-dev_232-17_amd64.deb libsystemd0-dbgsym_232-17_amd64.deb libsystemd0_232-17_amd64.deb libudev-dev_232-17_amd64.deb libudev1-dbgsym_232-17_amd64.deb libudev1-udeb_232-17_amd64.udeb libudev1_232-17_amd64.deb systemd-container-dbgsym_232-17_amd64.deb systemd-container_232-17_amd64.deb systemd-coredump-dbgsym_232-17_amd64.deb systemd-coredump_232-17_amd64.deb systemd-dbgsym_232-17_amd64.deb systemd-journal-remote-dbgsym_232-17_amd64.deb systemd-journal-remote_232-17_amd64.deb systemd-sysv_232-17_amd64.deb systemd_232-17_amd64.buildinfo systemd_232-17_amd64.deb udev-dbgsym_232-17_amd64.deb udev-udeb_232-17_amd64.udeb udev_232-17_amd64.deb Greetings, Your Debian queue daemon (running on host usper.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
systemd_232-17_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 10 Feb 2017 11:52:46 +0100 Source: systemd Binary: systemd systemd-sysv systemd-container systemd-journal-remote systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libnss-systemd libsystemd0 libsystemd-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb Architecture: source amd64 Version: 232-17 Distribution: unstable Urgency: medium Maintainer: Debian systemd Maintainers Changed-By: Martin Pitt Description: libnss-myhostname - nss module providing fallback resolution for the current hostname libnss-mymachines - nss module to resolve hostnames for local container instances libnss-resolve - nss module to resolve names via systemd-resolved libnss-systemd - nss module providing dynamic user and group name resolution libpam-systemd - system and service manager - PAM module libsystemd-dev - systemd utility library - development files libsystemd0 - systemd utility library libudev-dev - libudev development files libudev1 - libudev shared library libudev1-udeb - libudev shared library (udeb) systemd- system and service manager systemd-container - systemd container/nspawn tools systemd-coredump - tools for storing and retrieving coredumps systemd-journal-remote - tools for sending and receiving remote journal logs systemd-sysv - system and service manager - SysV links udev - /dev/ and hotplug management daemon udev-udeb - /dev/ and hotplug management daemon (udeb) Closes: 854392 854394 854396 Changes: systemd (232-17) unstable; urgency=medium . * Add libcap2-bin build dependency for tests. This will make test_exec_capabilityboundingset() actually run. (Closes: #854394) * Add iproute2 build dependency for tests. This will make test_exec_privatenetwork() actually run; it skips if "ip" is not present. (Closes: #854396) * autopkgtest: Run all upstream unit tests as root. Ship all upstream unit tests in libsystemd-dev, and run them all as root in autopkgtest. (Closes: #854392) This also fixes the FTBFS on non-seccomp architectures. * systemd-resolved.service.d/resolvconf.conf: Allow writing to /run/resolvconf. Upstream PR #5283 will introduce permission restrictions for systemd-resolved.service, including the lockdown to writing /run/systemd/. This will then cause the resolvconf call in our drop-in to fail as that needs to write to /run/resolvconf/. Add this to ReadWritePaths=. (This is a no-op with the current unrestricted unit). Checksums-Sha1: 74279f7b1b10bf7a7495667b9d5a88a6fa3b0aa9 4769 systemd_232-17.dsc b852b003033ae4326b76d49ca973eb1b7ffbe588 178684 systemd_232-17.debian.tar.xz f9d6fb80a1a1afbe162fbb27d89b41ebaf498a96 86946 libnss-myhostname-dbgsym_232-17_amd64.deb 3add4003903b04300e283062db733fde9476ef2a 101068 libnss-myhostname_232-17_amd64.deb 22c4859232e4462792ec95916fe9a8b3eea2e196 440680 libnss-mymachines-dbgsym_232-17_amd64.deb eba9afaec5f3d2a58f598b0f9a6fa7517b1dbb42 183290 libnss-mymachines_232-17_amd64.deb 43ca53d062117dd37ccfcad821505fd7b1027da5 429890 libnss-resolve-dbgsym_232-17_amd64.deb 7e5629ea641a7e39f4811432d2587f4d05faabec 182680 libnss-resolve_232-17_amd64.deb 694580aa9b2c15de10b58bd26d5cb5eac4e5b1cf 427108 libnss-systemd-dbgsym_232-17_amd64.deb 8497236309ea9d3e08a516833ec1e68c187912a2 180720 libnss-systemd_232-17_amd64.deb 76db134e59199f5199d5819f135fea7957eeef99 424420 libpam-systemd-dbgsym_232-17_amd64.deb d79ae5c6a8d8f6485475b4abb9c4894378234445 183868 libpam-systemd_232-17_amd64.deb a18db599e5e563661d782d51faa7e7042026393c 10285476 libsystemd-dev-dbgsym_232-17_amd64.deb 2f53dfed6fbe3b724a2dcbf4ed8ce37acad6f869 1954468 libsystemd-dev_232-17_amd64.deb c7228fb3f9631f653cc6653fe05949db6ae1fdf4 661478 libsystemd0-dbgsym_232-17_amd64.deb fdb4e40996147c3e4fbe50ee5a6fcaa112cef13c 275854 libsystemd0_232-17_amd64.deb 2384d58c512ac5d10f7916ae16fea6e1580be78d 87206 libudev-dev_232-17_amd64.deb 07d7d2f788a869b1a06e629514ac34a71968a293 157550 libudev1-dbgsym_232-17_amd64.deb d0e3f22f01277b8d7e6c53182503f493197eee68 48602 libudev1-udeb_232-17_amd64.udeb b1700d3559e66c21b42eb0419ce0120c8751525d 120800 libudev1_232-17_amd64.deb 7e180d1479b9c871905e9cbcaeea68b1407a6f5f 485106 systemd-container-dbgsym_232-17_amd64.deb 7ba27f7d44338e4ca7b7d398451e2d693a37d484 285324 systemd-container_232-17_amd64.deb fa9c42fa4c7948f27f70d3abbcbf0a8e015942ad 71706 systemd-coredump-dbgsym_232-17_amd64.deb acea9974925f3141311269882e725d0d415b5765 105928 systemd-coredump_232-17_amd64.deb 4d913b4246516cfa61016b9acf67d019c989d565 5991464 systemd-dbgsym_232-17_amd64.deb 333ddbb5ad3ba2ed724a067559865481e97fbf72 110758 systemd-journal-remote-dbgsym_232-17_amd64.deb 7a1570b4081df6ae3d91253b6e9624ab9dc8fc9a 125242 systemd-journal-remote_232-17_amd64.deb 180f60f2199654eda6ac380cb495cb0ae403504e 77286 systemd-sysv_232-17_amd64.deb 3e1c63da5963a906867ca1e2febf0db6bc90cd
Bug#854392: marked as done (Run "make check" as root via autopkgtest)
Your message dated Fri, 10 Feb 2017 12:04:28 + with message-id and subject line Bug#854392: fixed in systemd 232-17 has caused the Debian Bug report #854392, regarding Run "make check" as root via autopkgtest to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 854392: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: systemd Version: 232-15 Severity: normal Several of the upstream tests require root privileges as otherwise they do nothing: if (geteuid() != 0) return; It seems we missed issues because of that like the recent RAS/seccomp incident has shown [1]. E.g. test-seccomp was rightfully failing on i386, because the seccomp sandboxing is not working properly there, but this went unnoticed. Copying individual tests into the -dev packages [2] is a slight improvement, but it's kinda ugly to ship the test binaries in the package and it requires ongoing maintenance. Most importantly, it's incomplete, there are a few more tests which require root privs and that list is changing over time. We should run the complete test suite as root via autopkgtest. [1] https://github.com/systemd/systemd/issues/5215#issuecomment-277162523 [2] https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=ac866cbd3825e1 -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.127 ii udev 232-15 -- no debconf information --- End Message --- --- Begin Message --- Source: systemd Source-Version: 232-17 We believe that the bug you reported is fixed in the latest version of systemd, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 854...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Martin Pitt (supplier of updated systemd package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 10 Feb 2017 11:52:46 +0100 Source: systemd Binary: systemd systemd-sysv systemd-container systemd-journal-remote systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libnss-systemd libsystemd0 libsystemd-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb Architecture: source amd64 Version: 232-17 Distribution: unstable Urgency: medium Maintainer: Debian systemd Maintainers Changed-By: Martin Pitt Description: libnss-myhostname - nss module providing fallback resolution for the current hostname libnss-mymachines - nss module to resolve hostnames for local container instances libnss-resolve - nss module to resolve names via systemd-resolved libnss-systemd - nss module providing dynamic user and group name resolution libpam-systemd - system and service manager - PAM module libsystemd-dev - systemd utility library - development files libsystemd0 - systemd utility library libudev-dev - libudev development files libudev1 - libudev shared library libudev1-udeb - libudev shared library (udeb) systemd- system and service manager systemd-container - systemd container/nspawn tools systemd-coredump - tools for storing and retrieving coredumps systemd-journal-remote - tools for sending and receiving remote journal logs systemd-sysv - system and service manager - SysV links udev - /dev/ and hotplug management daemon udev-udeb - /dev/ and hotplug management daemon (udeb) Closes: 854392 854394 854396 Changes: systemd (232-17) unstable; urgency=medium . * Add libcap2-bin build dependency for tests. This will make test_exec_capabilityboundingset() actually run. (Closes: #854394) * Add iproute2 build dependency for tests. This will make test_exec_privatenetwork() actually run; it skips if "ip" is not present. (Closes: #854396)
Bug#854396: marked as done (test_exec_privatenetwork is not run due to missing ip)
Your message dated Fri, 10 Feb 2017 12:04:28 +
with message-id
and subject line Bug#854396: fixed in systemd 232-17
has caused the Debian Bug report #854396,
regarding test_exec_privatenetwork is not run due to missing ip
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
854396: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854396
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: systemd
Version: 232-15
Severity: normal
In test-execute.c the test_exec_privatenetwork test is not run if
the ip binary is not found:
src/test/test-execute.c:r = find_binary("ip", NULL);
src/test/test-execute.c-if (r < 0) {
src/test/test-execute.c-log_error_errno(r, "Skipping
test_exec_privatenetwork, could not find ip binary: %m");
src/test/test-execute.c-return;
src/test/test-execute.c-}
Since iproute2 is neither essential nor build-essential, we should add
to Build-Depends: iproute2
-- Package-specific info:
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd is related to:
pn dracut
ii initramfs-tools 0.127
ii udev 232-15
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: systemd
Source-Version: 232-17
We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 854...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Martin Pitt (supplier of updated systemd package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 10 Feb 2017 11:52:46 +0100
Source: systemd
Binary: systemd systemd-sysv systemd-container systemd-journal-remote
systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines
libnss-resolve libnss-systemd libsystemd0 libsystemd-dev udev libudev1
libudev-dev udev-udeb libudev1-udeb
Architecture: source amd64
Version: 232-17
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Martin Pitt
Description:
libnss-myhostname - nss module providing fallback resolution for the current
hostname
libnss-mymachines - nss module to resolve hostnames for local container
instances
libnss-resolve - nss module to resolve names via systemd-resolved
libnss-systemd - nss module providing dynamic user and group name resolution
libpam-systemd - system and service manager - PAM module
libsystemd-dev - systemd utility library - development files
libsystemd0 - systemd utility library
libudev-dev - libudev development files
libudev1 - libudev shared library
libudev1-udeb - libudev shared library (udeb)
systemd- system and service manager
systemd-container - systemd container/nspawn tools
systemd-coredump - tools for storing and retrieving coredumps
systemd-journal-remote - tools for sending and receiving remote journal logs
systemd-sysv - system and service manager - SysV links
udev - /dev/ and hotplug management daemon
udev-udeb - /dev/ and hotplug management daemon (udeb)
Closes: 854392 854394 854396
Changes:
systemd (232-17) unstable; urgency=medium
.
* Add libcap2-bin build dependency for tests. This will make
test_exec_capabilityboundingset() actually run. (Closes: #854394)
* Add iproute2 build dependency for tests. This will make
test_exec_privatenetwork() actually run; it skips if "ip" is not present.
(Closes: #854396)
* autopkgtest: Run all upstream unit tests as root.
Ship all upstream unit tests in libsystemd-dev, and run them all as root
in autopkgtest. (Closes: #854392) This also fixes the FTBFS on non-seccomp
architectures.
* systemd-resolved.service.d/resolvconf.conf: Allow writing to
/run/resolvconf. Upstream PR #5283 will introduce
Bug#854394: marked as done (test_exec_capabilityboundingset is not run due to missing capsh)
Your message dated Fri, 10 Feb 2017 12:04:28 +
with message-id
and subject line Bug#854394: fixed in systemd 232-17
has caused the Debian Bug report #854394,
regarding test_exec_capabilityboundingset is not run due to missing capsh
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
854394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854394
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: systemd
Version: 232-15
Severity: normal
In test/test-execute.c the test_exec_capabilityboundingset is skipped if
capsh is not found:
test/test-execute.c:/* We use capsh to test if the capabilities are
test/test-execute.c:r = find_binary("capsh", NULL);
test/test-execute.c:log_error_errno(r, "Skipping
test_exec_capabilityboundingset, could not find capsh binary: %m");
We should add libcap2-bin
to Build-Depends.
-- Package-specific info:
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd is related to:
pn dracut
ii initramfs-tools 0.127
ii udev 232-15
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: systemd
Source-Version: 232-17
We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 854...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Martin Pitt (supplier of updated systemd package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Fri, 10 Feb 2017 11:52:46 +0100
Source: systemd
Binary: systemd systemd-sysv systemd-container systemd-journal-remote
systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines
libnss-resolve libnss-systemd libsystemd0 libsystemd-dev udev libudev1
libudev-dev udev-udeb libudev1-udeb
Architecture: source amd64
Version: 232-17
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Martin Pitt
Description:
libnss-myhostname - nss module providing fallback resolution for the current
hostname
libnss-mymachines - nss module to resolve hostnames for local container
instances
libnss-resolve - nss module to resolve names via systemd-resolved
libnss-systemd - nss module providing dynamic user and group name resolution
libpam-systemd - system and service manager - PAM module
libsystemd-dev - systemd utility library - development files
libsystemd0 - systemd utility library
libudev-dev - libudev development files
libudev1 - libudev shared library
libudev1-udeb - libudev shared library (udeb)
systemd- system and service manager
systemd-container - systemd container/nspawn tools
systemd-coredump - tools for storing and retrieving coredumps
systemd-journal-remote - tools for sending and receiving remote journal logs
systemd-sysv - system and service manager - SysV links
udev - /dev/ and hotplug management daemon
udev-udeb - /dev/ and hotplug management daemon (udeb)
Closes: 854392 854394 854396
Changes:
systemd (232-17) unstable; urgency=medium
.
* Add libcap2-bin build dependency for tests. This will make
test_exec_capabilityboundingset() actually run. (Closes: #854394)
* Add iproute2 build dependency for tests. This will make
test_exec_privatenetwork() actually run; it skips if "ip" is not present.
(Closes: #854396)
* autopkgtest: Run all upstream unit tests as root.
Ship all upstream unit tests in libsystemd-dev, and run them all as root
in autopkgtest. (Closes: #854392) This also fixes the FTBFS on non-seccomp
architectures.
* systemd-resolved.service.d/resolvconf.conf: Allow writing to
/run/resolvconf. Upstream PR #5283 will introduce permission restrictions
for systemd-resolved.service, including the lockdown to writin
Bug#854805: systemd: dbus interraction problems leading to timeouts
Le 10/02/2017 à 16:47, Vincent Danjean a écrit :
> Looking at the logs ("journalctl -b"), the first errors I see are:
Here is the start of "journalctl -b" (got as:
socat EXEC:"journalctl --no-pager -b",pty GOPEN:boot.log
so "less -R boot.log" show colors)
Regards,
Vincent
--
Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
boot.log.xz
Description: application/xz
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#854814: Fails to start systemd-resolved
Package: systemd Version: 232-17 Severity: normal With the update to 232-17, systemd-resolved fails to start with the following error: Feb 10 17:46:31 test systemd[1]: Starting Network Name Resolution... -- Subject: Unit systemd-resolved.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-resolved.service has begun starting up. Feb 10 17:46:31 test systemd[10963]: systemd-resolved.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-resolved: No such file or directory -- Subject: Process /lib/systemd/systemd-resolved could not be executed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The process /lib/systemd/systemd-resolved could not be executed and failed. -- -- The error number returned by this process is 2. Feb 10 17:46:31 test systemd[1]: systemd-resolved.service: Main process exited, code=exited, status=226/NAMESPACE Feb 10 17:46:31 test systemd[1]: Failed to start Network Name Resolution. -- Subject: Unit systemd-resolved.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-resolved.service has failed. -- -- The result is failed. -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.11.0-2 ii libaudit1 1:2.6.7-1 ii libblkid1 2.29.1-1 ii libc6 2.24-9 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.6-1 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-5 ii libkmod223-2 ii liblz4-10.0~r131-2 ii liblzma55.2.2-1.2 ii libmount1 2.29.1-1 ii libpam0g1.1.8-3.5 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3 ii libsystemd0 232-17 ii mount 2.29.1-1 ii util-linux 2.29.1-1 Versions of packages systemd recommends: ii dbus1.10.14-1 ii libpam-systemd 232-17 Versions of packages systemd suggests: ii policykit-10.105-17 pn systemd-container ii systemd-ui 3-4 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.127 ii udev 232-17 -- Configuration Files: /etc/systemd/journald.conf changed [not included] /etc/systemd/logind.conf changed [not included] /etc/systemd/resolved.conf changed [not included] /etc/systemd/timesyncd.conf changed [not included] ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
dh-systemd seems not to support multiple service units
Dear pkg-systemd Maintainers, I've been trying to deliver a package that has a mix of enabled/disable and started/not started service units. The situation I encounter seems to be reflected at the manpage, when calling dh_systemd_enable, quoting: "Note that this command is not idempotent. dh_prep(1) should be called between invocations of this command (with the same arguments). Otherwise, it may cause multiple instances of the same text to be added to maintainer scripts" Which is exactly what I end up with, a really long postinst file repeating the postinst instructions generated in the previous dh_systemd_enable call On the other hand, I may not be properly understanding the reference in the manpage that states to trigger dh_prep between dh_system. If I understand correctly, dh_prep will actually remove everything writing up to that point into the respective debian/ directory's package entry, which I double checked it does: dh_prep --name=service_on_by_default rm -f debian/python3-mypackage.substvars rm -f debian/python3-mypackage.*.debhelper rm -rf debian/python3-mypackage/ rm -f debian/binaries-pkg.substvars rm -f debian/binaries-pkg.*.debhelper rm -rf debian/binaries-pkg/ rm -rf debian/tmp What am I doing wrong? This is what the debian/rules looks like: override_dh_systemd_enable: dh_systemd_enable --name=service_on_by_default dh_prep --name=service_on_by_default dh_systemd_enable --no-enable --name=non_tipical_service Much appreciated, Cheers, Dererk ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#854814: Fails to start systemd-resolved
Same bug here, temporary workaroud is to edit : /usr/lib/systemd/system/systemd-resolved.service.d/resolvconf.conf and quote as following : [Service] ExecStartPost=+/bin/sh -c '[ ! -e /run/resolvconf/enable-updates ] || echo "nameserver 127.0.0.53" | /sbin/resolvconf -a systemd-resolved' #ReadWritePaths=/run/resolvconf -- *Goran LAZAREVIC* ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#854814: Fails to start systemd-resolved
Am 10.02.2017 um 17:49 schrieb Yuri D'Elia: > Package: systemd > Version: 232-17 > Severity: normal > > With the update to 232-17, systemd-resolved fails to start with the > following error: > > -- The error number returned by this process is 2. > Feb 10 17:46:31 test systemd[1]: systemd-resolved.service: Main process > exited, code=exited, status=226/NAMESPACE > Feb 10 17:46:31 test systemd[1]: Failed to start Network Name Resolution. > -- Subject: Unit systemd-resolved.service has failed Slightly related: Martin, what do you think about adding an autopkgtest which starts all daemons (manually) that are shipped by systemd, no matter whether it is enabled or not, and simply checks the return code of the start attempt. (we can of course add more elaborate checks to test whether the service is functional, but a successful start is the baseline) With the recent changes upstream to enable more sandboxing features, this could be helpful, I guess. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#854814: Fails to start systemd-resolved
Processing control commands: > severity -1 important Bug #854814 [systemd] Fails to start systemd-resolved Severity set to 'important' from 'normal' -- 854814: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854814 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#854814: Fails to start systemd-resolved
Control: severity -1 important Am 10.02.2017 um 17:49 schrieb Yuri D'Elia: > > With the update to 232-17, systemd-resolved fails to start with the > following error: > > -- The error number returned by this process is 2. > Feb 10 17:46:31 test systemd[1]: systemd-resolved.service: Main process > exited, code=exited, status=226/NAMESPACE > Feb 10 17:46:31 test systemd[1]: Failed to start Network Name Resolution. > -- Subject: Unit systemd-resolved.service has failed This is caused by the addition of ReadWritePaths= in /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf I guess this should only be used in addition with ProtectSystem=, which is a recent upstream change but the Debian version does not use that yet. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#854699: Shutdown fails with an encrypted filesystem on virtio device
Am 10.02.2017 um 12:14 schrieb Yuri D'Elia: > On Fri, Feb 10 2017, Michael Biebl wrote: >> Looks similar to >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848044 and a lot like >> https://github.com/systemd/systemd/issues/1620 > > Uhm, it does. Aside from the fact that it's not at all harmless as > mentioned, since the root fs is not unmounted. And since the journal > itself becomes corrupted, the log is lost. > > However there seem to be no real progress on any front, including in the > bugs regarding cryptsetup and lvm2 (which I've seen before). > > I cannot explain why given the exact same partition/volume scheme by > lvm/cryptsetup, in one case I can shutdown cleanly, and in the other it > breaks. While I can reproduce the error messages on shutdown, it does *not* cause a dirty file system (in particular /var) here. I do have persistent journal enabled on the test VM, but the filing killing/unmount spree in systemd-shutdown properly unmounts /var. So it seems mostly cosmetic to me. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Re: Bug#804908: service is not started under systemd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Control: tags 804908 + pending
Hi,
Thanks for your report.
>Am 12.11.2015 um 20:19 schrieb Michael Biebl:
>> That is a symlink though, which is only created if the user explicitly
>> runs "systemctl enable --user obex.service", which in my case will
>> result in
>> Created symlink from
>> /home/michael/.config/systemd/user/dbus-org.bluez.obex.service to
>> /usr/lib/systemd/user/obex.service.
>>
>>
>> There is no infrastructure to run that systemctl enable command for
>> every user and I think obexd should be enabled by default. I therefor
>> suggest to change /usr/share/dbus-1/services/org.bluez.obex.service and
>> use
>> SystemdService=obex.service
>
>
>An alternative is to enable the user service system wide via
>systemctl enable --global obex.service
>
>Unfortunately, we don't have support for such services in
>dh_systemd/init-system-helpers (yet) and simply running systemctl enable
>in postinst is discouraged.
>So for now I think it's best if SystemdService=obex.service is used,
>which doesn't require explicit enablement.
>
I see.
I will fix this by changing SystemdService to obex.service in
org.bluez.obex.service.
Best regards,
Nobuhiro
- --
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEXmKe5SMhlzV7hM9DMiR/u0CtH6YFAlienrsACgkQMiR/u0Ct
H6b97g//fHBKaUhHHd1yMj3kKJwEtG/0qM2qgZHXn1d6cfgRDuJ/if0vtPAm9AUU
B4zrvzAm9xXGlhOz09PKdYt7qniHG5S3D5Ogi6V5oS7Jd5e2B3z6mZLn4X1kcVon
xNZt6BFNiYyi/3Mo24aGPav0Rct1x6Y5nhw8+teOTyGyATvqB73x2tDpJEt4hY7h
M7/pgvhOpe+CPF5aZKKtH7ayqtpMmVf++SCLyJVXHYAaZ3I7FTlEROFKyQpMHCFG
zkASzZWp6OPLEJR79JMEBLAp+oSRaNFq00Z1Nun8FErJ0/9aIoQzbU/k4yszU0im
be3Ni/pEY6EpIHMF0d34Fk+PrcjDeCVtIHK2YIsUO1w92QPcB26ZYGuj+7pTGnh1
mK20RMqJDN4Pc5cedTFgtZqYryzmXs5GRr+nxKYXRmRbiyfW3lYwtJipYOROSxfv
NuLK9F2FjPvs9Ao1aT+5fSWSZw5NWH7OprUZqiDxWfyDjguJYit9lTJ+kv+0jywc
i9fBx50YMcw3YqOwIfHkFJ7e1kyXHmoHBWhQBo3x2o8ugMbeqh5R1aksNFgyezo2
BuTS88iQQE/wS4I15IpX9wTH32yZwV1g2ueZhW+spT/qmTdRpI5EZvUGjHqo9oqY
Jaur9tKQ+8ZXmb9dF+wIXNwbEuCHtTRguygud2ivU1P7RnzCRXs=
=eDBS
-END PGP SIGNATURE-
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
