systemd-related hacks in the lxc templates for Debian containers

2016-08-05 Thread Antonio Terceiro 
Hello,

[please cc: me in replies; I'm not in the list]

I was approached by Michael some days ago about the systemd-related
hacks that are present in the lxc template for debian containers.

Back before the jessie release, I put together what made debian
containers with systemd mostly work for me, and there were a few
followups after that, and at the end today we have this (please wait
until you read everything before yelling at me!):

configure_debian_systemd()
{
path=$1
rootfs=$2
config=$3
num_tty=$4

# this only works if we have getty@.service to manipulate
if [ -f ${rootfs}/lib/systemd/system/getty\@.service ]; then
   sed -e 's/^ConditionPathExists=/# ConditionPathExists=/' \
   -e 's/After=dev-%i.device/After=/' \
   < ${rootfs}/lib/systemd/system/getty\@.service \
   > ${rootfs}/etc/systemd/system/getty\@.service
fi

# just in case systemd is not installed
mkdir -p ${rootfs}/{lib,etc}/systemd/system
mkdir -p ${rootfs}/etc/systemd/system/getty.target.wants

# Fix getty-static-service as debootstrap does not install dbus
if [ -e $rootfs//lib/systemd/system/getty-static.service ] ; then
local tty_services=$(for i in $(seq 2 $num_tty); do echo -n 
"getty@tty${i}.service "; done; )
sed 's/ getty@tty.*/'" $tty_services "'/g' \
$rootfs/lib/systemd/system/getty-static.service |  \
sed 's/\(tty2-tty\)[5-9]/\1'"${num_tty}"'/g' > 
$rootfs/etc/systemd/system/getty-static.service
fi

# This function has been copied and adapted from lxc-fedora
rm -f ${rootfs}/etc/systemd/system/default.target
chroot ${rootfs} ln -s /dev/null /etc/systemd/system/udev.service
chroot ${rootfs} ln -s /dev/null /etc/systemd/system/systemd-udevd.service
chroot ${rootfs} ln -s /lib/systemd/system/multi-user.target 
/etc/systemd/system/default.target
# Make systemd honor SIGPWR
chroot ${rootfs} ln -s /lib/systemd/system/halt.target 
/etc/systemd/system/sigpwr.target
# Setup getty service on the ttys we are going to allow in the
# default config.  Number should match lxc.tty
( cd ${rootfs}/etc/systemd/system/getty.target.wants
for i in $(seq 1 $num_tty) ; do ln -sf ../getty\@.service 
getty@tty${i}.service; done )

# Since we use static-getty.target; we need to mask 
container-getty@.service generated by
# container-getty-generator, so we don't get multiple instances of agetty 
running.
# See https://github.com/lxc/lxc/issues/520 and 
https://github.com/lxc/lxc/issues/484
( cd ${rootfs}/etc/systemd/system/getty.target.wants
for i in $(seq 0 $num_tty); do ln -sf /dev/null 
container-getty\@${i}.service; done )

return 0
}

These basically fixed two main issues at the time:

- the lack of udev in the container caused a significant (read f*ing
  long) delay in booting the container

- it was not possible to login using the consoles of the container,
  hande the getty-related hacks.

I built myself a locally-modified version of the lxc package removing
all of the above, and got the following results after testing both
jessie and stretch containers:

- no boot delays anymore. I assume the underlying issue has been fixed
  in systemd since.

- I again cannot login to the extra consoles (lxc-console -n
  $CONTAINER), in both jessie and stretch. I also tested this on an
  Ubuntu xenial container, and there it just works out of the box.

  Further info:

  - if I boot the Debian container in the foreground (lxc-start -F -n
$CONTAINER), then there is a main getty on /dev/console (from the
PoV of the container), on the same terminal where I started the
container, which does work (probably because /dev/console is already
in /etc/securetty).  The extra ones (pts/0, pts/1, pts/2) still
don't.

  - the getty processes are started with pretty much the same command
line on both stretch and xenial, AFAICT

  - /etc/securetty is the same on stretch and xenial

  - /etc/securetty does contain:

lxc/console
lxc/tty1
lxc/tty2
lxc/tty3
lxc/tty4

but from the point of view of the containers, the getty processes
attach to pts/* instead.

  - I can "make it work" on stretch and jessie by adding a line with
"pts/0" to the end of /etc/securetty.

  - there are not systemd-related bits in the Ubuntun templates AFAICT

  - The only tty-related bits I could find in the Ubuntu templates are:

# remove jobs for consoles 5 and 6 since we only create 4 consoles in
# this template
rm -f $rootfs/etc/init/tty{5,6}.conf

which seem to be actually related to upstart (/etc/init/*.conf) so I
am not convinced those have anything to do with it.

So AFAICS, if we can fix this issue with the consoles, either in systemd
or in lxc, we would be good to go to remove these hacks. Any ideas?


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing

Bug#823530: systemd 228 reduced maximum number of tasks in a cgroup to 512 by default

2016-05-06 Thread Antonio Terceiro 
Control: severity -1 important

On Thu, 05 May 2016 20:14:20 +0200 Sebastian Schmidt  wrote:
> Package: systemd
> Version: 229-3
> Severity: normal
> Tags: upstream
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> Whilst debugging why Chrome would regularly fail to create new
> threads[1] and zsh couldn’t fork I noticed that:
> - - All affected processes run in the /system.slice/xdm.service cgroup
> - - “systemctl status xdm.service” says “Tasks: 476 (limit: 512)”
> - - The changelog for systemd 228 reads[2]:
> 
> There's a new system.conf setting DefaultTasksMax= to control
> the default TasksMax= setting for services and scopes running on
> the system.
> […]
> The setting now defaults to 512, which means services that are
> not explicitly configured otherwise will only be able to create
> 512 processes or threads at maximum, from this version on.
> 
> - - Nothing in xdm’s PAM configuration would load pam_systemd for creating
>   a session.
> 
> I’m not sure whether using pam_systemd would actually fix that; but
> even then I find this new limit per cgroup at least surprising and
> it apparently breaks a lot of software.
> 
> Sebastian
> 
> 1: https://crbug.com/602002
> 2: 
> https://github.com/systemd/systemd/blob/ccddd104fc95e0e769142af6e1fe1edec5be70a6/NEWS#L373-393

I am seeing some inconsistency in this. On my laptop, I don't see any
limits being applied, even though I am on a fully up to date unstable
(tried both with my main account from a terminal emulator in GNOME, and
from a console login with a freshly created user account):

$ ulimit -u 22988

On a newly created VM, also on unstable, I do see limits, e.g. after
logging in on the console:

terceiro@sid:~$ ulimit -u 384

This has already biten my in 2 occasions:

* for several reasons, the arm64 machines I am using on ci.debian.net
  need a 4.4 kernel and systemd 228, so I several tests are failing on
  arm64 with "Can't fork: resource temporarily unavailable" during
  *package installation*.

* A bug was just reported against ruby2.3 because of a FTBFS on a stretch
  VM, apperently caused by this new systemd behavior (#823604)

I do appreciate the idea of systemd imposing sane limits on tasks, but
this will cause A LOT of breakage in all sorts of places, and we need
figure out a plan forward. Will every package need to start declaring
higher limits explicitly?


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#801822: deb-systemd-helper does not support template units (e.g. foo@.service)

2015-10-14 Thread Antonio Terceiro 
Package: init-system-helpers
Version: 1.24
Severity: normal

`deb-systemd-helper enable foo@1.service` will not work even if the
corresponding foo@.service is correctly in place.

Use case: in the new version of debci, you will be able to run multiple
worker instances on each system, but by default I want to enable and
start the first one in postinst.

I hope I understand how all of this is supposed to work, so I am
currently doing it like this:

http://anonscm.debian.org/cgit/collab-maint/debci.git/commit/?id=cef32ff04680607a4e41a9673649e8320f649c95

Are we supposed to have packages managing instanciated template units
like this?

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages init-system-helpers depends on:
ii  perl-base  5.20.2-6

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

-- no debconf information

-- 
Antonio Terceiro <terce...@debian.org>


signature.asc
Description: PGP signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#794744: systemd-logind: Lid closed event does not suspend

2015-09-20 Thread Antonio Terceiro 
On Sun, 20 Sep 2015 20:41:26 -0300 Antonio Terceiro <terce...@debian.org> wrote:
> I am experiencing exactly the same with the latest systemd on unstable;
> `systemctl suspend` works, but closing the lid does not suspend (at all).

after rebooting with systemd.log_level=debug, the journal now says:

Set 20 20:50:26 homer systemd-logind[619]: Lid closed.
Set 20 20:50:26 homer systemd-logind[619]: System is docked.
Set 20 20:50:26 homer systemd-logind[619]: Refusing operation, as it is turned 
off.
Set 20 20:50:26 homer systemd-logind[619]: System is docked.
Set 20 20:50:26 homer systemd-logind[619]: Refusing operation, as it is turned 
off.
Set 20 20:50:26 homer systemd[1]: systemd-logind.service: Got notification 
message from PID 619 (WATCHDOG=1)
Set 20 20:51:00 homer systemd-logind[619]: Lid opened.
Set 20 20:51:00 homer systemd[1]: systemd-logind.service: Got notification 
message from PID 619 (WATCHDOG=1)

the laptop is *not* docked, why would systemd think it is?

I was able to workaround this by adding `HandleLidSwitchDocked=suspend`
to /etc/systemd/logind.conf and restarting systemd-logind so that
closing the lid does suspend, but still systemd is incorrectly assuming
the system is docked when it isn't.

-- 
Antonio Terceiro <terce...@debian.org>


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#794744: systemd-logind: Lid closed event does not suspend

2015-09-20 Thread Antonio Terceiro 
rted Login Service.
Set 20 20:04:02 homer systemd-logind[11069]: New seat seat0.
Set 20 20:04:02 homer systemd-logind[11069]: Watching system buttons on 
/dev/input/event3 (Power Button)
Set 20 20:04:02 homer systemd-logind[11069]: Watching system buttons on 
/dev/input/event4 (Video Bus)
Set 20 20:04:02 homer systemd-logind[11069]: Watching system buttons on 
/dev/input/event2 (Power Button)
Set 20 20:04:02 homer systemd-logind[11069]: Watching system buttons on 
/dev/input/event1 (Lid Switch)
Set 20 20:04:02 homer systemd-logind[11069]: Watching system buttons on 
/dev/input/event10 (HP WMI hotkeys)
Set 20 20:04:02 homer systemd-logind[11069]: New session c1 of user Debian-gdm.
Set 20 20:04:02 homer systemd-logind[11069]: New session 1 of user terceiro.
Set 20 20:04:22 homer systemd-logind[11069]: Removed session c1.
Set 20 20:05:59 homer systemd-logind[11069]: Lid closed.
Set 20 20:06:15 homer systemd-logind[11069]: Lid opened.
Set 20 20:09:33 homer systemd-logind[11069]: New session c1 of user Debian-gdm.
Set 20 20:09:42 homer systemd-logind[11069]: New session 4 of user root.
Set 20 20:09:48 homer systemd-logind[11069]: Lid closed.
Set 20 20:09:52 homer systemd-logind[11069]: Removed session 1.
Set 20 20:10:09 homer systemd-logind[11069]: Lid opened.
Set 20 20:10:24 homer systemd-logind[11069]: Lid closed.
Set 20 20:10:41 homer systemd-logind[11069]: Lid opened.
Set 20 20:11:04 homer systemd-logind[11069]: New session c2 of user Debian-gdm.
Set 20 20:11:12 homer systemd-logind[11069]: New session 6 of user terceiro.
Set 20 20:11:12 homer systemd-logind[11069]: Removed session c2.
Set 20 20:11:32 homer systemd-logind[11069]: Removed session c1.

-- 
Antonio Terceiro <terce...@debian.org>


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#766233: LXC breakage and workarounds when upgrading VMs to jessie

2014-11-24 Thread Antonio Terceiro 
On Mon, Nov 24, 2014 at 07:48:28AM +0100, Tomas Pospisek wrote:
 On Mon, 24 Nov 2014, Marco d'Itri wrote:
 
 On Nov 24, Tomas Pospisek tpo_...@sourcepole.ch wrote:
 
 My first proposed text for the release-notes is below. Please let me
 know if you prefer me to submit a proper patch against a SVN checkout of
 ddp.
 
 Please also clarify that LXC containers *can* use systemd with no
 troubles if correctly configured.
 
 Could you please clarify what needs to be done to correctly configure a LXC
 container?

This:
https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010900.html

I am interacting with Daniel (Debian maintainer) to also get that into
jessie.

 * Is it sufficient to set: lxc.autodev = 1 in /var/lib/lxc/myvm/config?

Definitively not.

 * Does an upgrade also automatically switch to journald?
 
   * In which case one *must* also set lxc.kmsg=0 in
 /var/lib/lxc/myvm/config and remove /dev/kmsg inside the VM?
 
 * Is it possible to switch a system configured in such a way back and
   forth between systemd and sysvinit without having to change anything
   but the package selection? Or does that imply removing the configuration
   changes, i.e. removing lxc.autodev = 1 and lxc.kmsg=0 and recreating
   /dev/kmsg?
 
 * Is it possible to run the upgraded VM, that is correctly configured as
   you suggest on a normal wheezy host? Does the wheezy host need any
   special configuration?

I don't have answers for these questions yet.

-- 
Antonio Terceiro terce...@debian.org


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Re: Bug#766233: VM won't start after an automatic upgrade to systemd inside the VM

2014-10-28 Thread Antonio Terceiro 
Control: severity 766216 important

On Wed, Oct 22, 2014 at 11:01:36AM +0200, Holger Levsen wrote:
 3. jessie host with jessie lxc containers (=does work with systemd in the 
 container)

This does not work in my experience (reported as #766216), so at the
moment is not possible to run jessie containers that run systemd on
jessie, also running systemd. I don't know if running sysvinit in the
host would help.

I also had problems with a CentOS 7 container; the issue looks like the
one reported in
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1339781

However, in my case removing the drop of SETFCAP in centos.common.conf
did not help.

-- 
Antonio Terceiro terce...@debian.org


signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers