[Touch-packages] [Bug 1608953] Re: PostgreSQL does not start in lx-brand container
This bug was fixed in the package systemd - 229-4ubuntu8 --- systemd (229-4ubuntu8) xenial-proposed; urgency=medium * Queue loading transient units after setting their properties. Fixes starting VMs with libvirt. (LP: #1529079) * Connect pid1's stdin/out/err fds to /dev/null also for containers. This fixes generators which expect a valid stdout/err fd in some container technologies. (LP: #1608953) * 73-usb-net-by-mac.rules: Do not run readlink for *every* uevent, and merely check if /etc/udev/rules.d/80-net-setup-link.rules exists. A common way to disable an udev rule is to just "touch" it in /etc/udev/rule.d/ (i. e. empty file), and if the rule is customized we cannot really predict anyway if the user wants MAC-based USB net names or not. (LP: #1615021) * systemd-networkd-resolvconf-update.service: Also pick up DNS servers from individual link leases, as they sometimes don't appear in the global ifstate. (LP: #1620559) -- Martin PittTue, 06 Sep 2016 14:16:29 +0200 ** Changed in: systemd (Ubuntu Xenial) Status: Fix Committed => Fix Released -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Released Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. SRU INFORMATION === Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial=6df46531727baa Regression potential: very low; this does not affect lxc and lxd (our officially supported container engines) nor nspawn, as they already set up pid1's stdout/stderr. And it's hard to imagine anything depending on pid1's stdout/err *not* being existant file descriptors, as in pretty much all cases they already are. Test case: Specific to lx-brand, must be verified by reporter. However, we need to verify that LXC, LXD, and nspawn containers still boot with this version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
** Tags removed: verification-needed ** Tags added: verification-done -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. SRU INFORMATION === Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial=6df46531727baa Regression potential: very low; this does not affect lxc and lxd (our officially supported container engines) nor nspawn, as they already set up pid1's stdout/stderr. And it's hard to imagine anything depending on pid1's stdout/err *not* being existant file descriptors, as in pretty much all cases they already are. Test case: Specific to lx-brand, must be verified by reporter. However, we need to verify that LXC, LXD, and nspawn containers still boot with this version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
I installed the systemd 229-4ubuntu8 package from xenial-proposed and it looks like the package fixes this bug. -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. SRU INFORMATION === Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial=6df46531727baa Regression potential: very low; this does not affect lxc and lxd (our officially supported container engines) nor nspawn, as they already set up pid1's stdout/stderr. And it's hard to imagine anything depending on pid1's stdout/err *not* being existant file descriptors, as in pretty much all cases they already are. Test case: Specific to lx-brand, must be verified by reporter. However, we need to verify that LXC, LXD, and nspawn containers still boot with this version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
TEST CASE: - Added xenial-proposed to /etc/apt/sources.list - Installed systemd: pt install systemd/xenial-proposed - Install postgres: apt-get install -y -q postgresql Verified the postgresql service is running: - su postgres - psql and also: - systemctl status postgresql - ystemctl status postgresql@9.5-main.service -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. SRU INFORMATION === Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial=6df46531727baa Regression potential: very low; this does not affect lxc and lxd (our officially supported container engines) nor nspawn, as they already set up pid1's stdout/stderr. And it's hard to imagine anything depending on pid1's stdout/err *not* being existant file descriptors, as in pretty much all cases they already are. Test case: Specific to lx-brand, must be verified by reporter. However, we need to verify that LXC, LXD, and nspawn containers still boot with this version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
Hello Christopher, or anyone else affected, Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu8 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: systemd (Ubuntu Xenial) Status: New => Fix Committed ** Tags added: verification-needed -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. SRU INFORMATION === Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial=6df46531727baa Regression potential: very low; this does not affect lxc and lxd (our officially supported container engines) nor nspawn, as they already set up pid1's stdout/stderr. And it's hard to imagine anything depending on pid1's stdout/err *not* being existant file descriptors, as in pretty much all cases they already are. Test case: Specific to lx-brand, must be verified by reporter. However, we need to verify that LXC, LXD, and nspawn containers still boot with this version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
** Description changed: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). - if (getpid() == 1 && detect_container() <= 0) { + if (getpid() == 1 && detect_container() <= 0) { - /* Running outside of a container as PID 1 */ - arg_running_as = MANAGER_SYSTEM; - make_null_stdio(); + /* Running outside of a container as PID 1 */ + arg_running_as = MANAGER_SYSTEM; + make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. - + SRU INFORMATION + === + Fix: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu-xenial=6df46531727baa + + Regression potential: very low; this does not affect lxc and lxd (our + officially supported container engines) nor nspawn, as they already set + up pid1's stdout/stderr. And it's hard to imagine anything depending on + pid1's stdout/err *not* being existant file descriptors, as in pretty + much all cases they already are. + + Test case: Specific to lx-brand, must be verified by reporter. However, + we need to verify that LXC, LXD, and nspawn containers still boot with + this version. -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no
[Touch-packages] [Bug 1608953] Re: PostgreSQL does not start in lx-brand container
So far it looks good. I awaiting feedback from a couple people and I'll let you know. -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
Great, thanks! We'll take a look at this today. -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
https://github.com/systemd/systemd/commit/6edefe0b06 is actually introducing a regression (disabling color mode for containers), and does not backport at all. I think https://github.com/systemd/systemd/commit/3a18b6048950405 is much closer to what you actually need here: Calling make_null_stdio() for containers as well. I backported that one change, verified that LXC and LXD still work fine, and put a test package into https://launchpad.net/~pitti/+archive/ubuntu /sru-test (systemd 229-4ubuntu7pitti1). I would appreciate if you could test this and confirm that it fixes the problem. There are no other packages in that PPA, so dist-upgrading to it is safe. Thanks! ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Martin Pitt (pitti) -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
** Changed in: systemd (Ubuntu Xenial) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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 1608953] Re: PostgreSQL does not start in lx-brand container
OK, thanks. Marking this as "hw-specific" then, which is not entirely accurate, but it essentially means "only the reporter can test a stable release update". I'll pull in the patch into the xenial branch and will ask you for testing once it gets into xenial-proposed (which might still take a while as this is low-priority). Thanks! ** Summary changed: - PostgreSQL does not start in container + PostgreSQL does not start in lx-brand container ** Tags added: hw-specific ** Changed in: systemd (Ubuntu) Status: Incomplete => Fix Released -- 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/1608953 Title: PostgreSQL does not start in lx-brand container Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Incomplete Bug description: We have a 16.04 Ubuntu lx-brand container image available in our public cloud and recently discovered a systemd bug that's related to running in a container environment. I'm forwarded below what one of our engineers discovered: After installing postgres (apt-get install -y -q postgresql), systemd does not actually start any of the postgres services. We tracked this down to a failure from sed from within the /lib/systemd/system- generators/postgresql-generator script. The sed command tries to close stderr (fd 2) which fails, so sed returns an error code, which causes the entire postgres generator to fail. The root cause of the problem lies in the systemd code. Because we are running inside of a container (see detect_container) we don't execute the following block of code in the systemd main(). if (getpid() == 1 && detect_container() <= 0) { /* Running outside of a container as PID 1 */ arg_running_as = MANAGER_SYSTEM; make_null_stdio(); The make_null_stdio function is what sets up fd 0-2 as /dev/null in systemd on bare metal. Having those fd's setup is what allows the postgres system-generator to work properly since sed expects to be able to close stderr. Because we never call make_null_stdio when inside any container, the low fd's wind up getting setup later using /dev/console with O_CLOEXEC, so when we actually run the system generator script, we don't have the low fd's setup at all like sed expects. Interestingly, looking at the master branch of systemd, at src/core/main.c this bug appears to no longer exist. The relevant code block has been moved so it is no longer conditional on being in a container, but the commit was not intended to fix this problem. It was apparently due to color handling on the console/ commit 3a18b60489504056f9b0b1a139439cbfa60a87e1 It would be great if this fix could be pulled in to an update for Ubuntu 16.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1608953/+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