[Touch-packages] [Bug 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs
Jurit (juritxyz) You need the following packages to downgrade systemd: libpam-systemd libsystemd0 systemd systemd-sysv you can get them from here https://launchpad.net/ubuntu/bionic/amd64/libpam-systemd/ https://launchpad.net/ubuntu/bionic/amd64/libsystemd0/ https://launchpad.net/ubuntu/bionic/amd64/systemd/ https://launchpad.net/ubuntu/bionic/amd64/systemd-sysv/ download the last working revision for all of them and install it. Afterwards the issue should be gone. However you have to set the four packages to hold with apt to ensure that they won't get updated ... to prevent issues until the problem gets resolved. As you said November update broke it, it would start with 237-3ubuntu10.8 and check if this solves it. You can also try a later revision but I assume this is good to go. -- 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/1804603 Title: systemd-tmpfiles-setup.service fails on btrfs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Last security update introduced a regression on btrfs based systems, causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded machines. * Cherrypick upstream fixes to resolve this. [Test Case] * Install VM using btrfs for / * Boot, check that systemd-tmpfiles-setup.service is started successfully with: $ systemctl status systemd-tmpfiles-setup.service [Regression Potential] * btrfs fd doesn't support the set of flags that systemd used, with this patch, a compat set of flags is set instead, thus resolving the introduced regression. The worst case scenario is that creating subvolumes/directories is still broken (as in, the current status quo). [Other Info] * Example bad output After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails with: Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and Directories... Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/var": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/home": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/srv": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files and Directories. This happens on btrfs root filesystems in real hardware and on our virtualized servers as well. 237-3ubuntu10.6 didnt show this errors and going back to 237-3ubuntu10 removes them as well. # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy systemd systemd: Installiert: 237-3ubuntu10.9 Installationskandidat: 237-3ubuntu10.9 Versionstabelle: *** 237-3ubuntu10.9 500 500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs
@Jurit (juritxyz) I was wrong you need an other versions of systemd (21.11, 21.10 is for 16.04.5) IDK which ones but you can get them from launchpad I assume you need e.g. this architecture: https://launchpad.net/ubuntu/bionic/amd64/systemd/ You need these packages for successful downgrade get the version before the issue occured: libpam-systemd libsystemd0 systemd systemd-sysv Are you even on Armbian? What is your distribution! If you are on Armbian please proceed to this thread https://forum.armbian.com/topic/8852-ssh-doesnt-work-on-orange-pi- zero/?page=2 @Dimitri John Ledkov (xnox) I assume he is not on Armbian because nothing indicates that but however the issue still persists on certain kernel versions, obviously. -- 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/1804603 Title: systemd-tmpfiles-setup.service fails on btrfs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Last security update introduced a regression on btrfs based systems, causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded machines. * Cherrypick upstream fixes to resolve this. [Test Case] * Install VM using btrfs for / * Boot, check that systemd-tmpfiles-setup.service is started successfully with: $ systemctl status systemd-tmpfiles-setup.service [Regression Potential] * btrfs fd doesn't support the set of flags that systemd used, with this patch, a compat set of flags is set instead, thus resolving the introduced regression. The worst case scenario is that creating subvolumes/directories is still broken (as in, the current status quo). [Other Info] * Example bad output After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails with: Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and Directories... Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/var": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/home": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/srv": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files and Directories. This happens on btrfs root filesystems in real hardware and on our virtualized servers as well. 237-3ubuntu10.6 didnt show this errors and going back to 237-3ubuntu10 removes them as well. # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy systemd systemd: Installiert: 237-3ubuntu10.9 Installationskandidat: 237-3ubuntu10.9 Versionstabelle: *** 237-3ubuntu10.9 500 500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs
@Jurit (juritxyz) Stop thinking about the Armbian (ARM) kernel, it has nothing to with your kernel and you won't be able to update to my kernel because as already said it is for ARM7-based SOCs. You are on x86_x64 which needs a proper kernel for your architecture. You can check what kernels are available for your platform and verify if there is a newer one which maybe solves the issue for you. However IDK if there is one. And no you should in no case update to Armbian kernel ... I assume it will break everything. Another option would be to downgrade to systemd 21.11 or 21.10 and hold the packages until the bug is fixed. -- 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/1804603 Title: systemd-tmpfiles-setup.service fails on btrfs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Last security update introduced a regression on btrfs based systems, causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded machines. * Cherrypick upstream fixes to resolve this. [Test Case] * Install VM using btrfs for / * Boot, check that systemd-tmpfiles-setup.service is started successfully with: $ systemctl status systemd-tmpfiles-setup.service [Regression Potential] * btrfs fd doesn't support the set of flags that systemd used, with this patch, a compat set of flags is set instead, thus resolving the introduced regression. The worst case scenario is that creating subvolumes/directories is still broken (as in, the current status quo). [Other Info] * Example bad output After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails with: Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and Directories... Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/var": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/home": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/srv": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files and Directories. This happens on btrfs root filesystems in real hardware and on our virtualized servers as well. 237-3ubuntu10.6 didnt show this errors and going back to 237-3ubuntu10 removes them as well. # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy systemd systemd: Installiert: 237-3ubuntu10.9 Installationskandidat: 237-3ubuntu10.9 Versionstabelle: *** 237-3ubuntu10.9 500 500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs
*x86/x64 18.04.01 -- 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/1804603 Title: systemd-tmpfiles-setup.service fails on btrfs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Last security update introduced a regression on btrfs based systems, causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded machines. * Cherrypick upstream fixes to resolve this. [Test Case] * Install VM using btrfs for / * Boot, check that systemd-tmpfiles-setup.service is started successfully with: $ systemctl status systemd-tmpfiles-setup.service [Regression Potential] * btrfs fd doesn't support the set of flags that systemd used, with this patch, a compat set of flags is set instead, thus resolving the introduced regression. The worst case scenario is that creating subvolumes/directories is still broken (as in, the current status quo). [Other Info] * Example bad output After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails with: Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and Directories... Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/var": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/home": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/srv": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files and Directories. This happens on btrfs root filesystems in real hardware and on our virtualized servers as well. 237-3ubuntu10.6 didnt show this errors and going back to 237-3ubuntu10 removes them as well. # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy systemd systemd: Installiert: 237-3ubuntu10.9 Installationskandidat: 237-3ubuntu10.9 Versionstabelle: *** 237-3ubuntu10.9 500 500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs
Jurit (juritxyz) I tested the above kernel on 16.04.05 Xenial. However it has to be said that the 4.19.13-sunxi is an ARM7 kernel (Armbian). I don't know on which platform you are but I can easily upgrade this kernel manually over the Armbian configuration application. I assume you are on x86/x64 which is the latest LTS so I assume you're already on the latest kernel supported for your distro. IDK why 4.19.13-sunxi solves it...I still consider this issue unsolved even if the latest kernel on my distro solves it... -- 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/1804603 Title: systemd-tmpfiles-setup.service fails on btrfs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Last security update introduced a regression on btrfs based systems, causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded machines. * Cherrypick upstream fixes to resolve this. [Test Case] * Install VM using btrfs for / * Boot, check that systemd-tmpfiles-setup.service is started successfully with: $ systemctl status systemd-tmpfiles-setup.service [Regression Potential] * btrfs fd doesn't support the set of flags that systemd used, with this patch, a compat set of flags is set instead, thus resolving the introduced regression. The worst case scenario is that creating subvolumes/directories is still broken (as in, the current status quo). [Other Info] * Example bad output After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails with: Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and Directories... Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/var": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/home": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/srv": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files and Directories. This happens on btrfs root filesystems in real hardware and on our virtualized servers as well. 237-3ubuntu10.6 didnt show this errors and going back to 237-3ubuntu10 removes them as well. # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy systemd systemd: Installiert: 237-3ubuntu10.9 Installationskandidat: 237-3ubuntu10.9 Versionstabelle: *** 237-3ubuntu10.9 500 500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1811580] Re: systemd fails to start sshd at reboot
@Dimitri John Ledkov (xnox) I know that in my case the Kernel is quite old, however it still affects the version I reported above and upgrading has some drawbacks in this case. What is the reason causing the issue I described? Are there any options fixing it without switching kernel version? Thanks in advance! -- 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/1811580 Title: systemd fails to start sshd at reboot Status in systemd package in Ubuntu: Incomplete Bug description: So far reported issues turned out to be: - obsolete/buggy/vulnerable 3rd party provided kernels - bad permissions on / Please ensure / is owned by root:root. Please ensure you are running up to date kernels. === Ubuntu 16.04.5, systemd 229-4ubuntu21.15 The latest systemd update has somehow changed the method it uses to start 'ssh.service' i.e. 'sshd'. systemd fails to start sshd if /etc/ssh/sshd_config contains "UsePrivilegeSeparation yes" and /var/run/sshd/ does not already exist. Being as this is the default, virtually EVERY Ubuntu 16.04 server in the world has UsePrivilegeSeparation set to yes. Furthermore, at the time when the user performs 'apt upgrade' and receives the newest version of systemd, /var/run/sshd/ already exists, so sshd successfully reloads for as long as the server doesn't get rebooted. BUT, as soon as the server is rebooted for any reason, /var/run/sshd/ gets cleaned away, and sshd fails to start, causing the remote user to be completely locked out of his system. This is a MAJOR issue for millions of VPS servers worldwide, as they are all about to get locked out of their servers and potentially lose data. The next reboot is a ticking time bomb waiting to spring. The bomb can be defused by implicitly setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config, however unsuspecting administrators are bound to be caught out by the millions. I got caught by it in the middle of setting up a new server yesterday, and it took a whole day to find the source. The appropriate fix would be to ensure that systemd can successfully 'start ssh.service' even when 'UsePrivilegeSeparation yes' is set. systemd needs to test that /var/run/sshd/ exists before starting sshd, just as the init.d script for sshd does. openssl could also be patched so that UsePrivilegeSeparation is no longer enabled by default, however that is not going to solve the problem for millions of pre- existing config files. Only an update to openssl to force-override that flag to 'no' would solve the problem. Thus systemd still needs to be responsible for ensuring that it inits sshd properly by ensuring that /var/run/sshd/ exists before it sends the 'start' command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580/+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 1804847] Re: systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz)
Upgrading to Linux pan 4.19.13-sunxi #5.70 SMP Sat Jan 12 15:43:21 CET 2019 armv7l armv7l armv7l GNU/Linux solved the issue for me. -- 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/1804847 Title: systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz) Status in systemd package in Ubuntu: Fix Released Bug description: The following description is taken from: https://answers.launchpad.net/ubuntu/+source/systemd/+question/676237 Hello everyone, I'm running 16.04 LTS on a virtual server which, I think, uses OpenVz. After a recent reboot I found most of my services to be in a failed state. The reason for that, I guess, are these log entries: Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/elasticsearch failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/php failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/postgresql failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/redis failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/screen failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/utmp failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif/links failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif/leases failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal/bbad3a438f4b4fb49e5d0700bd5981e8 failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal/bbad3a438f4b4fb49e5d0700bd5981e8/system.journal failed: Invalid argument To verify I tried this: /usr/lib/tmpfiles.d# SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --create elasticsearch.conf Reading config file "elasticsearch.conf". Running create action for entry d /var/run/elasticsearch Found existing directory "/var/run/elasticsearch". "/run/elasticsearch" has right mode 40755 chown "/run/elasticsearch" to 120.128 fchownat() of /run/elasticsearch failed: Invalid argument I can manually chown the directories, e.g. "chown elasticsearch:elasticsearch /var/run/elasticsearch" and restart the service successfully. My suspicion is, this is related to an upgrade of systemd to 229-4ubuntu21.8. At this point I don't know what to do. I'm also confused about the version I have installed, which I thought is systemd-229. Howver, I looked at https://github.com/systemd/systemd/blob/v229/src/tmpfiles/tmpfiles.c and found that fchownat() is only used from version 238+: Tag v237 (and earlier, including 229): /.../ if (chown(fn, i->uid_set ? i->uid : UID_INVALID, i->gid_set ? i->gid : GID_INVALID) < 0) return log_error_errno(errno, "chown(%s) failed: %m", path); } /.../ Tag v238 /.../ if (fchownat(fd, "", i->uid_set ? i->uid : UID_INVALID, i->gid_set ? i->gid : GID_INVALID, AT_EMPTY_PATH) < 0) return log_error_errno(errno, "fchownat() of %s failed: %m", path); /.../ Any help fixing this problem would be highly appreciated. Many thanks, Rafael === Notes === fchownat() was added to Linux in kernel 2.6.16; library support was added to glibc in version 2.4. checkinf if it is blocked/filtered/sandboxed, rarther than unavailable. glibc in bionic requires minimum linux 3.2. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs
Upgrade to Linux pan 4.19.13-sunxi #5.70 SMP Sat Jan 12 15:43:21 CET 2019 armv7l armv7l armv7l GNU/Linux solved the issue for me. -- 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/1804603 Title: systemd-tmpfiles-setup.service fails on btrfs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Last security update introduced a regression on btrfs based systems, causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded machines. * Cherrypick upstream fixes to resolve this. [Test Case] * Install VM using btrfs for / * Boot, check that systemd-tmpfiles-setup.service is started successfully with: $ systemctl status systemd-tmpfiles-setup.service [Regression Potential] * btrfs fd doesn't support the set of flags that systemd used, with this patch, a compat set of flags is set instead, thus resolving the introduced regression. The worst case scenario is that creating subvolumes/directories is still broken (as in, the current status quo). [Other Info] * Example bad output After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails with: Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and Directories... Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/var": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/home": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/srv": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Nov 21 13:44:12 node-blc49 systemd[1]: Failed to start Create Volatile Files and Directories. This happens on btrfs root filesystems in real hardware and on our virtualized servers as well. 237-3ubuntu10.6 didnt show this errors and going back to 237-3ubuntu10 removes them as well. # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy systemd systemd: Installiert: 237-3ubuntu10.9 Installationskandidat: 237-3ubuntu10.9 Versionstabelle: *** 237-3ubuntu10.9 500 500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603/+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 1811580] Re: systemd fails to start sshd at reboot
@Dimitri John Ledkov (xnox) I manully upgrade to Linux pan 4.19.13-sunxi #5.70 SMP Sat Jan 12 15:43:21 CET 2019 armv7l armv7l armv7l GNU/Linux and the issue seems also to be fixed for me now -- 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/1811580 Title: systemd fails to start sshd at reboot Status in systemd package in Ubuntu: Confirmed Bug description: Ubuntu 16.04.5, systemd 229-4ubuntu21.15 The latest systemd update has somehow changed the method it uses to start 'ssh.service' i.e. 'sshd'. systemd fails to start sshd if /etc/ssh/sshd_config contains "UsePrivilegeSeparation yes" and /var/run/sshd/ does not already exist. Being as this is the default, virtually EVERY Ubuntu 16.04 server in the world has UsePrivilegeSeparation set to yes. Furthermore, at the time when the user performs 'apt upgrade' and receives the newest version of systemd, /var/run/sshd/ already exists, so sshd successfully reloads for as long as the server doesn't get rebooted. BUT, as soon as the server is rebooted for any reason, /var/run/sshd/ gets cleaned away, and sshd fails to start, causing the remote user to be completely locked out of his system. This is a MAJOR issue for millions of VPS servers worldwide, as they are all about to get locked out of their servers and potentially lose data. The next reboot is a ticking time bomb waiting to spring. The bomb can be defused by implicitly setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config, however unsuspecting administrators are bound to be caught out by the millions. I got caught by it in the middle of setting up a new server yesterday, and it took a whole day to find the source. The appropriate fix would be to ensure that systemd can successfully 'start ssh.service' even when 'UsePrivilegeSeparation yes' is set. systemd needs to test that /var/run/sshd/ exists before starting sshd, just as the init.d script for sshd does. openssl could also be patched so that UsePrivilegeSeparation is no longer enabled by default, however that is not going to solve the problem for millions of pre- existing config files. Only an update to openssl to force-override that flag to 'no' would solve the problem. Thus systemd still needs to be responsible for ensuring that it inits sshd properly by ensuring that /var/run/sshd/ exists before it sends the 'start' command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580/+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 1811580] Re: systemd fails to start sshd at reboot
@Dimitri John Ledkov (xnox) I think I'm forced by Armbian to this kernel revision by default. TBH I don't know if a manual upgrade will break the OS or not. I also have not investigated on how to upgrade it manually. I have no permission issues like David (dasoto) I already checked that before I replied to this bug report. Everything on the root directory of my machine is root / root. -- 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/1811580 Title: systemd fails to start sshd at reboot Status in systemd package in Ubuntu: Confirmed Bug description: Ubuntu 16.04.5, systemd 229-4ubuntu21.15 The latest systemd update has somehow changed the method it uses to start 'ssh.service' i.e. 'sshd'. systemd fails to start sshd if /etc/ssh/sshd_config contains "UsePrivilegeSeparation yes" and /var/run/sshd/ does not already exist. Being as this is the default, virtually EVERY Ubuntu 16.04 server in the world has UsePrivilegeSeparation set to yes. Furthermore, at the time when the user performs 'apt upgrade' and receives the newest version of systemd, /var/run/sshd/ already exists, so sshd successfully reloads for as long as the server doesn't get rebooted. BUT, as soon as the server is rebooted for any reason, /var/run/sshd/ gets cleaned away, and sshd fails to start, causing the remote user to be completely locked out of his system. This is a MAJOR issue for millions of VPS servers worldwide, as they are all about to get locked out of their servers and potentially lose data. The next reboot is a ticking time bomb waiting to spring. The bomb can be defused by implicitly setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config, however unsuspecting administrators are bound to be caught out by the millions. I got caught by it in the middle of setting up a new server yesterday, and it took a whole day to find the source. The appropriate fix would be to ensure that systemd can successfully 'start ssh.service' even when 'UsePrivilegeSeparation yes' is set. systemd needs to test that /var/run/sshd/ exists before starting sshd, just as the init.d script for sshd does. openssl could also be patched so that UsePrivilegeSeparation is no longer enabled by default, however that is not going to solve the problem for millions of pre- existing config files. Only an update to openssl to force-override that flag to 'no' would solve the problem. Thus systemd still needs to be responsible for ensuring that it inits sshd properly by ensuring that /var/run/sshd/ exists before it sends the 'start' command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580/+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 1811580] Re: systemd fails to start sshd at reboot
@Dimitri John Ledkov (xnox) It's Armbian (Xenial) for OrangePI One. Here df -Th of my filesystem: udev devtmpfs 165M 0 165M0% /dev tmpfs tmpfs 50M3,9M 46M8% /run /dev/mmcblk0p1 ext4 7,2G4,1G 3,1G 57% / tmpfs tmpfs 248M 0 248M0% /dev/shm tmpfs tmpfs 5,0M4,0K 5,0M1% /run/lock tmpfs tmpfs 248M 0 248M0% /sys/fs/cgroup tmpfs tmpfs 248M 12K 248M1% /tmp /dev/zram0 ext4 49M 20M 27M 42% /var/log tmpfs tmpfs 50M 0 50M0% /run/user/999 tmpfs tmpfs 50M 0 50M0% /run/user/1000 -- 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/1811580 Title: systemd fails to start sshd at reboot Status in systemd package in Ubuntu: Confirmed Bug description: Ubuntu 16.04.5, systemd 229-4ubuntu21.15 The latest systemd update has somehow changed the method it uses to start 'ssh.service' i.e. 'sshd'. systemd fails to start sshd if /etc/ssh/sshd_config contains "UsePrivilegeSeparation yes" and /var/run/sshd/ does not already exist. Being as this is the default, virtually EVERY Ubuntu 16.04 server in the world has UsePrivilegeSeparation set to yes. Furthermore, at the time when the user performs 'apt upgrade' and receives the newest version of systemd, /var/run/sshd/ already exists, so sshd successfully reloads for as long as the server doesn't get rebooted. BUT, as soon as the server is rebooted for any reason, /var/run/sshd/ gets cleaned away, and sshd fails to start, causing the remote user to be completely locked out of his system. This is a MAJOR issue for millions of VPS servers worldwide, as they are all about to get locked out of their servers and potentially lose data. The next reboot is a ticking time bomb waiting to spring. The bomb can be defused by implicitly setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config, however unsuspecting administrators are bound to be caught out by the millions. I got caught by it in the middle of setting up a new server yesterday, and it took a whole day to find the source. The appropriate fix would be to ensure that systemd can successfully 'start ssh.service' even when 'UsePrivilegeSeparation yes' is set. systemd needs to test that /var/run/sshd/ exists before starting sshd, just as the init.d script for sshd does. openssl could also be patched so that UsePrivilegeSeparation is no longer enabled by default, however that is not going to solve the problem for millions of pre- existing config files. Only an update to openssl to force-override that flag to 'no' would solve the problem. Thus systemd still needs to be responsible for ensuring that it inits sshd properly by ensuring that /var/run/sshd/ exists before it sends the 'start' command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580/+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 1804603] Re: systemd-tmpfiles-setup.service fails on btrfs
To supplement the issue I will add more relevant links: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847 https://forum.armbian.com/topic/8852-ssh-doesnt-work-on-orange-pi-zero/ https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580 For me the issue also appeared with 229-4ubuntu21.9. Was fixed with 229-4ubuntu21.10 and now appeared again with 229-4ubuntu21.15. I'm on Armbian with ext4 and have the issue now again. Distribution / Kernel Linux xxx 3.4.113-sun8i #2 SMP PREEMPT Sat Jan 12 15:54:26 CET 2019 armv7l armv7l armv7l GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 16.04.5 LTS Release: 16.04 Codename: xenial Output of journalctl -b 0 -u systemd-tmpfiles-setup.service Jän 14 11:01:51 xxx systemd[1]: Starting Create Volatile Files and Directories... Jän 14 11:01:51 xxx systemd-tmpfiles[581]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/log: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/lib: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/sendsigs.omit.d: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /home: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /srv: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/lock/subsys: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/run/lighttpd: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/cache: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/cache/man: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/openvpn: Bad file descriptor Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Jän 14 11:01:51 xxx systemd[1]: Failed to start Create Volatile Files and Directories. Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state. Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Affected services: # dnsmasq.service loaded failed failed dnsmasq - A lightweight DHCP and caching DNS server # lighttpd.service loaded failed failed Lighttpd Daemon # openvpn@server.service loaded failed failed OpenVPN connection to server # ssh.service loaded failed failed OpenBSD Secure Shell server # systemd-tmpfiles-setup-dev.service loaded failed failed Create Static Device Nodes in /dev # systemd-tmpfiles-setup.service loaded failed failed Create Volatile Files and Directories -- 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/1804603 Title: systemd-tmpfiles-setup.service fails on btrfs Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Fix Released Status in systemd source package in Disco: Fix Released Bug description: [Impact] * Last security update introduced a regression on btrfs based systems, causing systemd-tmpfiles-setup.service to fail to start, resulting in degraded machines. * Cherrypick upstream fixes to resolve this. [Test Case] * Install VM using btrfs for / * Boot, check that systemd-tmpfiles-setup.service is started successfully with: $ systemctl status systemd-tmpfiles-setup.service [Regression Potential] * btrfs fd doesn't support the set of flags that systemd used, with this patch, a compat set of flags is set instead, thus resolving the introduced regression. The worst case scenario is that creating subvolumes/directories is still broken (as in, the current status quo). [Other Info] * Example bad output After update to systemd 237-3ubuntu10.9 systemd-tmpfiles-setup.service fails with: Nov 21 13:44:12 node-blc49 systemd[1]: Starting Create Volatile Files and Directories... Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/var": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/home": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd-tmpfiles[1226]: Failed to create directory or subvolume "/srv": Bad file descriptor Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Nov 21 13:44:12 node-blc49 systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Nov 21 13:44:12 node-blc49 systemd[1]: Failed to s
[Touch-packages] [Bug 1804847] Re: systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz)
Please forgive me if I don't get overall picture correctly because I'm not a professional in kernel development. Moreover I have no insights what is going on with the systemd changes and who is actually affected and why I'm affected. In the Armbian forums is stated that the problem originates in Ubuntu so I decided to share my information here. I just see right now that I'm limited to either upgrade the Ubuntu revision (reinstall my machine) or hold systemd updates on a revision not facing the issue. I would really appreciate more information if this will ever get fixed again or what options we have in the long run to surpass the issue because I doesn't sound that the problem will ever be fixed again. Sorry again for my stupid question but there might be more people affected with the same problem who probably want to know a resolution. -- 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/1804847 Title: systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz) Status in systemd package in Ubuntu: Fix Released Bug description: The following description is taken from: https://answers.launchpad.net/ubuntu/+source/systemd/+question/676237 Hello everyone, I'm running 16.04 LTS on a virtual server which, I think, uses OpenVz. After a recent reboot I found most of my services to be in a failed state. The reason for that, I guess, are these log entries: Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/elasticsearch failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/php failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/postgresql failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/redis failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/screen failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/utmp failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif/links failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/systemd/netif/leases failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal/bbad3a438f4b4fb49e5d0700bd5981e8 failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/log/journal/bbad3a438f4b4fb49e5d0700bd5981e8/system.journal failed: Invalid argument To verify I tried this: /usr/lib/tmpfiles.d# SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --create elasticsearch.conf Reading config file "elasticsearch.conf". Running create action for entry d /var/run/elasticsearch Found existing directory "/var/run/elasticsearch". "/run/elasticsearch" has right mode 40755 chown "/run/elasticsearch" to 120.128 fchownat() of /run/elasticsearch failed: Invalid argument I can manually chown the directories, e.g. "chown elasticsearch:elasticsearch /var/run/elasticsearch" and restart the service successfully. My suspicion is, this is related to an upgrade of systemd to 229-4ubuntu21.8. At this point I don't know what to do. I'm also confused about the version I have installed, which I thought is systemd-229. Howver, I looked at https://github.com/systemd/systemd/blob/v229/src/tmpfiles/tmpfiles.c and found that fchownat() is only used from version 238+: Tag v237 (and earlier, including 229): /.../ if (chown(fn, i->uid_set ? i->uid : UID_INVALID, i->gid_set ? i->gid : GID_INVALID) < 0) return log_error_errno(errno, "chown(%s) failed: %m", path); } /.../ Tag v238 /.../ if (fchownat(fd, "", i->uid_set ? i->uid : UID_INVALID, i->gid_set ? i->gid : GID_INVALID, AT_EMPTY_PATH) < 0) return log_error_errno(errno, "fchownat() of %s failed: %m", path); /.../ Any help fixing this problem would be highly appreciated. Many thanks, Rafael === Notes === fchownat() was added to Linux in kernel 2.6.16; library support was added to glibc in version 2.4. checkinf if it is blocked/filtered/sandboxed, rarther than unavailable. glibc in bionic r
[Touch-packages] [Bug 1804847] Re: systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz)
Hello Seth as I'm also facing a similar issue which is also related to this bug I'm now posting to this bug report as it has the highest heat concerning issues with systemd and systemd-tmpfiles (service do not start correctly). I don't think this is exclusively related to OpenVZ because I'm also affected I don't use OpenVZ. I have collected a few reports which also relate to the systemd changes which result in services not starting on boot up: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603 https://forum.armbian.com/topic/8852-ssh-doesnt-work-on-orange-pi-zero/ I'm on Armbian on an OrangePI One and I'm also affected by services that won't start anymore. The same was the case with systemd-229-4ubuntu21.9 and now with 229-4ubuntu21.15. All other systemd version did work without any issues. For the sake of completeness I will now also attach my system information and terminal output which relates to the issue. Distribution / Kernel Linux xxx 3.4.113-sun8i #2 SMP PREEMPT Sat Jan 12 15:54:26 CET 2019 armv7l armv7l armv7l GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 16.04.5 LTS Release: 16.04 Codename: xenial Output of journalctl -b 0 -u systemd-tmpfiles-setup.service Jän 14 11:01:51 xxx systemd[1]: Starting Create Volatile Files and Directories... Jän 14 11:01:51 xxx systemd-tmpfiles[581]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/log: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/lib: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/sendsigs.omit.d: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /home: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /srv: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/lock/subsys: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/run/lighttpd: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/cache: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/cache/man: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/openvpn: Bad file descriptor Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Jän 14 11:01:51 xxx systemd[1]: Failed to start Create Volatile Files and Directories. Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state. Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. Affected services: # dnsmasq.service loaded failed failed dnsmasq - A lightweight DHCP and caching DNS server # lighttpd.service loaded failed failed Lighttpd Daemon # openvpn@server.service loaded failed failed OpenVPN connection to server # ssh.service loaded failed failed OpenBSD Secure Shell server # systemd-tmpfiles-setup-dev.service loaded failed failed Create Static Device Nodes in /dev # systemd-tmpfiles-setup.service loaded failed failed Create Volatile Files and Directories -- 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/1804847 Title: systemd=229-4ubuntu21.8 use of fchownat failes on some systems (openvz) Status in systemd package in Ubuntu: Fix Released Bug description: The following description is taken from: https://answers.launchpad.net/ubuntu/+source/systemd/+question/676237 Hello everyone, I'm running 16.04 LTS on a virtual server which, I think, uses OpenVz. After a recent reboot I found most of my services to be in a failed state. The reason for that, I guess, are these log entries: Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/elasticsearch failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/kopano failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/php failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/postgresql failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/redis failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/screen failed: Invalid argument Nov 17 04:47:42 h2118376 systemd-tmpfiles[165]: fchownat() of /run/utmp failed: Invalid argument Nov 17 04:47:42 h2118376 s
[Touch-packages] [Bug 1811580] Re: systemd fails to start sshd at reboot
This problem is not new and it appears again with the new systemd "229-4ubuntu21.15" released. See also these bug reports which somehow relate to the issue: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804847 https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804603 As I'm no Linux pro I can't tell how these issues relate to each other but they definitely do. I don't quite understand why this issue was strictly focused on OpenVZ and then neglected because it definitely is not only OpenVZ related. I didn't face the issue in systemd versions https://forum.armbian.com/topic/8852-ssh-doesnt-work-on- orange-pi-zero/ Moreover it doesn't only affect SSH but rather many other services because from what I understand some directories aren't created on startup, because of some system-tmpfiles changes. Here is the output of journalctl -b 0 -u systemd-tmpfiles-setup.service Jän 14 11:01:51 xxx systemd[1]: Starting Create Volatile Files and Directories... Jän 14 11:01:51 xxx systemd-tmpfiles[581]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring. Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/log: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/lib: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/sendsigs.omit.d: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /home: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /srv: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/lock/subsys: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/run/lighttpd: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/cache: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /var/cache/man: Bad file descriptor Jän 14 11:01:51 xxx systemd-tmpfiles[581]: Failed to validate path /run/openvpn: Bad file descriptor Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=1/FAILURE Jän 14 11:01:51 xxx systemd[1]: Failed to start Create Volatile Files and Directories. Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Unit entered failed state. Jän 14 11:01:51 xxx systemd[1]: systemd-tmpfiles-setup.service: Failed with result 'exit-code'. In my case the following service won't start because of the systemd update. I'm no facing the exact same issue / behaviour like in systemd-229-4ubuntu21.9. Same service are affected, same errors. # dnsmasq.serviceloaded failed failed dnsmasq - A lightweight DHCP and caching DNS server # lighttpd.service loaded failed failed Lighttpd Daemon # openvpn@server.service loaded failed failed OpenVPN connection to server # ssh.serviceloaded failed failed OpenBSD Secure Shell server # systemd-tmpfiles-setup-dev.service loaded failed failed Create Static Device Nodes in /dev # systemd-tmpfiles-setup.service loaded failed failed Create Volatile Files and Directories I can't tell why this happens and this is everything on information I can provide. I would also provide you more info if you tell me what you need. I can rollback to a version <21.9 or >21.9 and <21.15 and everything will work again. But TBH I don't want to mark systemd on hold for too long. Maybe some sort of temporary fix other then rolling back would be fantastic... -- 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/1811580 Title: systemd fails to start sshd at reboot Status in systemd package in Ubuntu: New Bug description: Ubuntu 16.04.5, systemd 229-4ubuntu21.15 The latest systemd update has somehow changed the method it uses to start 'ssh.service' i.e. 'sshd'. systemd fails to start sshd if /etc/ssh/sshd_config contains "UsePrivilegeSeparation yes" and /var/run/sshd/ does not already exist. Being as this is the default, virtually EVERY Ubuntu 16.04 server in the world has UsePrivilegeSeparation set to yes. Furthermore, at the time when the user performs 'apt upgrade' and receives the newest version of systemd, /var/run/sshd/ already exists, so sshd successfully reloads for as long as the server doesn't get rebooted. BUT, as soon as the server is rebooted for any reason, /var/run/sshd/ gets cleaned away, and sshd fails to start, causing the remote user to be completely locked out of his system. This is a MAJOR issue for millions of VPS servers worldwide, as they are all about to get locked out of their servers and potentially lose data. The next reboo
