Bug#766943: systemd: server no longer gets networking after switching to systemd
On Wed, Nov 12, 2014 at 3:35 PM, Michael Biebl wrote: > Am 12.11.2014 um 23:59 schrieb Cameron Norman: >> But will services depending on network.target be started then? Or will >> they be prevented from starting in the case of an auto interface not >> being configured? > > How is that relevant for this patch? For some reason I thought that that particular behavior was changing. Upon re-reading, it is not. Sorry for the bother. Thank you, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766943: systemd: server no longer gets networking after switching to systemd
Am 12.11.2014 um 23:59 schrieb Cameron Norman: > But will services depending on network.target be started then? Or will > they be prevented from starting in the case of an auto interface not > being configured? How is that relevant for this patch? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
El mié, 12 de nov 2014 a las 6:30 , Michael Biebl escribió: Am 12.11.2014 um 05:04 schrieb Cameron Norman: On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl wrote: Am 11.11.2014 um 20:01 schrieb Michael Biebl: > Attached is a patch against /etc/init.d/networking. > While we discussed yesterday, to only run "udevadm settle" if there are > any auto interfaces, I changed it, to also cover allow-hotplug. > I also changed the init script to handle allow-hotplug interfaces. [..] > Please test and report back. Grr, the attached patch had a typo, please try this v2. So with this change, $network and network.target mean that all interfaces marked auto or allow-hotplug have been configured, or hotplug events have been settled and as many interfaces as could be brought up have been, correct? And if an "auto" interface is never brought up, that is ignored after udev settles? Are you sure that is desired behavior, seeing as allow-hotplug is the only configuration that explicitly references hotplug devices/events? I'm not quite sure what problem you're referring too, please elaborate. If you are using "auto" for an interface which is plugged in after "/etc/init.d/networking start" has been run, then yeah, it won't be configured. But the patch doesn't change that. But will services depending on network.target be started then? Or will they be prevented from starting in the case of an auto interface not being configured? Thank you, -- Cameron Norman
Bug#766943: systemd: server no longer gets networking after switching to systemd
Am 12.11.2014 um 05:04 schrieb Cameron Norman: > On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl wrote: >> Am 11.11.2014 um 20:01 schrieb Michael Biebl: >> > Attached is a patch against /etc/init.d/networking. >> > While we discussed yesterday, to only run "udevadm settle" if there are >> > any auto interfaces, I changed it, to also cover allow-hotplug. >> > I also changed the init script to handle allow-hotplug interfaces. >> >> [..] >> >> > Please test and report back. >> >> Grr, the attached patch had a typo, please try this v2. > > So with this change, $network and network.target mean that all > interfaces marked auto or allow-hotplug have been configured, or hotplug > events have been settled and as many interfaces as could be brought up > have been, correct? > > And if an "auto" interface is never brought up, that is ignored after > udev settles? Are you sure that is desired behavior, seeing as > allow-hotplug is the only configuration that explicitly references > hotplug devices/events? I'm not quite sure what problem you're referring too, please elaborate. If you are using "auto" for an interface which is plugged in after "/etc/init.d/networking start" has been run, then yeah, it won't be configured. But the patch doesn't change that. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
On Tue, 11 Nov 2014 20:05:53 +0100 Michael Biebl wrote: > Am 11.11.2014 um 20:01 schrieb Michael Biebl: > > Attached is a patch against /etc/init.d/networking. > > While we discussed yesterday, to only run "udevadm settle" if there are > > any auto interfaces, I changed it, to also cover allow-hotplug. > > I also changed the init script to handle allow-hotplug interfaces. > > [..] > > > Please test and report back. > > Grr, the attached patch had a typo, please try this v2. So with this change, $network and network.target mean that all interfaces marked auto or allow-hotplug have been configured, or hotplug events have been settled and as many interfaces as could be brought up have been, correct? And if an "auto" interface is never brought up, that is ignored after udev settles? Are you sure that is desired behavior, seeing as allow-hotplug is the only configuration that explicitly references hotplug devices/events? Thanks, -- Cameron Norman
Bug#766943: systemd: server no longer gets networking after switching to systemd
severity 766943 critical tags 766943 + jessie sid stop Since no one of you guys objected, and since it seems the appropriate level as per definition... >critical >makes unrelated software on the system (or the whole system) break, or >causes serious data loss, or introduces a security hole on systems >where you install the package. (and I guess breaking unrelated software applies here, i.e. other services that cannot longer start) ...I'm raising now the severity levels of this to make it RC. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#727073: Bug#766943: systemd: server no longer gets networking after switching to systemd
Hey. There's also that issue:#768514 It's smells after one of these three bugs here (#766943, #727073 and #766291), but OTOH, the 30s sleep ugly workaround is still in place right now, and all other daemons can bind to their addresses,... bind9 however can not and fails at start. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
Hey guys. Probably nothing new here, right? Since this seems to be a quite serious bug, i.e. no networking (which makes the nodes completely unreachable/unusable) when systemd is used which is the default init system in jessie... I'd say that this qualifies to be a RC bug. Unless you disagree (please explain why), I'd bump the severity accordingly. Cheers, chris. smime.p7s Description: S/MIME cryptographic signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
Oh and I should perhaps add: With allow-auto AND the sleep: all services find their addresses and start up correctly. With allow-auto WITHOUT the sleep,... well when waiting for my script to restart the networking, then of course no service (but ssh, which I've restarted from the script) was running correctly. But before I had my script in place, I got back access to the machine by simply n-times rebooting it via Ctrl-Alt-Del signal from the hosters web-interfaces... and after a so 5-15 reboots it usually worked once to at least have ssh back... but even then only *some* services (luckily including ssh) were running... others (especially bind and apache) always failed then too (probably because IPv6 was still not yet in place but only IPv4, which explains why sks started up, as it doesn't fail when it cannot bind to all addresses). With allow-hotplug (and without the sleep) I also had some services not staring up (as I wrote already last night). Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
On Mon, 2014-10-27 at 13:55 +0100, Andrew Shadura wrote: > /etc/init.d/networking doesn't check for systemd or anything, and it > works fine with sysv-rc, so this probably not a bug in ifupdown, but > in systemd. Well... I still suspect that something *is* fishy here... I mean the other two bugs against ifupdown that I've reported before, imply that... - IPv6 not ready for services (but IPv4 is) when allow-hotplug is used - DHCP not working when allow-auto is used That's all a bit strange... :/ But from the log output that I've sent before it rather looks, that with allow-auto (+systemd) there is no eth0 brought up at all (and not only too late), cause in the first "ifconfig before stage 1" it only has lo up. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
On Mon, 2014-10-27 at 13:51 +0100, Michael Biebl wrote: > allow-auto is a synonym for auto. Sure, I know,... I just do it for cosmetic reasons ^^ > The ifup@.service unit, as shipped by systemd, only deals with > "allow-hotplug" interfaces. Ah? Okay... interesting,... didn't know that... This is probably unrelated to this bug, but the whole networking stuff seems to be kinda mess right now (at least to people not deeper involved in both (ifupdown + systemd)... we still have networking.service, we have network.target, we have the ifup@.service... and I'm sure NM also has some service file (though I couldn't find it too hook in before network.target... Shouldn't the legacy sysvinit scripts go away,... and everything (including allow-auto/auto) be handled by a unit file proper? > "auto" interfaces are handled by /etc/init.d/networking, which is > shipped by ifupdown. Therefore re-assigning to ifupdown. Well as I've noted in my mails from yesterday... even with allow-hotplug there are still several things that don't work (i.e. services are being started before they can bind to the addresses)... Isn't this then something in systemd? Or is it rather a problem in the respective service's unit files? But at least apache and sks still use sysvinit legacy mode... so it probably cannot be their fault. Yesterday I've told you that I placed some cron job which is meant to restart the network+ssh every 10 minutes or so... and if this doesn't work he changes /e/n/interfaces to allow-hotplug and reboots. Attached is that script + it's logs, so that you can see what happens from that side. It's basically doing this: network-restarter.log is the main log, here with entries from two runs: 1st run: when the system was up and I connected to it and changed to allow-auto, but networking was still ok then I rebooted, the system did boot, but networking didn't come up again 2nd run: the script found that networking is down, and tried several things to bring it up again,... the output from these things and from ifconfig is in network-restarter.log.2. > Regarding logs: It would probably be helpful to boot with > systemd.log_level=debug and attach the output of journalctl -alb all attached + syslog from the last n runs... not sure if all the previous tries are helpful though,.. I did replace some privacy related stuff (ip addresses, domain names)... hopefully I didn't miss some private keys in my logs ;) > and > specifically the output of systemctl status networking.service. this is in the network-restarter.log.2 Cheers, Chris. network-restarter Description: application/shellscript cron run Tue Oct 28 03:35:55 CET 2014 stage 1: OK stage 2: OK cron run Tue Oct 28 03:40:01 CET 2014 ifdown:0 ifup:0 networking restart:0 ssh:0 stage 2: OK Tue Oct 28 03:40:01 CET 2014 *** ifconfig before stage 1 ** loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:672 errors:0 dropped:0 overruns:0 frame:0 TX packets:672 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:55584 (54.2 KiB) TX bytes:55584 (54.2 KiB) *** networking.service status before stage 1 * ● networking.service - LSB: Raise network interfaces. Loaded: loaded (/etc/init.d/networking) Drop-In: /run/systemd/generator/networking.service.d └─50-insserv.conf-$network.conf Active: active (exited) since Tue 2014-10-28 03:38:15 CET; 1min 46s ago Process: 366 ExecStart=/etc/init.d/networking start (code=exited, status=0/SUCCESS) Oct 28 03:38:15 kronecker systemd[1]: networking.service got final SIGCHLD for state start Oct 28 03:38:15 kronecker systemd[1]: networking.service changed start -> running Oct 28 03:38:15 kronecker systemd[1]: Job networking.service/start finished, result=done Oct 28 03:38:15 kronecker systemd[1]: Started LSB: Raise network interfaces.. Oct 28 03:38:15 kronecker ntpdate[629]: Can't find host ptbtime1.ptb.de: Name or service not known (-2) Oct 28 03:38:15 kronecker ntpdate[629]: Can't find host ptbtime2.ptb.de: Name or service not known (-2) Oct 28 03:38:15 kronecker systemd[1]: Child 607 belongs to networking.service Oct 28 03:38:15 kronecker systemd[1]: Child 628 belongs to networking.service Oct 28 03:38:15 kronecker systemd[1]: networking.service: cgroup is empty Oct 28 03:38:15 kronecker systemd[1]: networking.service changed running -> exited ifdown output *** ifdown: interface eth0 not configured *** ifconfig after ifdown loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:672 errors:0 dropped:0 overruns:0 frame:0
Bug#766943: systemd: server no longer gets networking after switching to systemd
Am 27.10.2014 um 14:19 schrieb Michael Biebl: > That /etc/init.d/networking succeeds to bring up eth0 under sysvinit but > not under systemd, might have different reasons: > a/ the service is not started at all or in the wrong order > b/ the timining is different under systemd and there is a race somewhere > c/ the sysv init script makes assumptions which aren't satisfied under > systemd Christoph, can you add a "sleep 30" to /etc/init.d/networking right before it calls ifup in its start action. If that makes the network come up properly, this might indicate that "ifup -a" is run before the eth0 interface is available. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
Hi Andrew, Am 27.10.2014 um 13:55 schrieb Andrew Shadura: > Hello, > > On 27 October 2014 13:51, Michael Biebl wrote: >> allow-auto is a synonym for auto. >> The ifup@.service unit, as shipped by systemd, only deals with >> "allow-hotplug" interfaces. >> "auto" interfaces are handled by /etc/init.d/networking, which is >> shipped by ifupdown. Therefore re-assigning to ifupdown. > >> Regarding logs: It would probably be helpful to boot with >> systemd.log_level=debug and attach the output of journalctl -alb and >> specifically the output of systemctl status networking.service. > > /etc/init.d/networking doesn't check for systemd or anything, and it > works fine with sysv-rc, so this probably not a bug in ifupdown, but > in systemd. That /etc/init.d/networking succeeds to bring up eth0 under sysvinit but not under systemd, might have different reasons: a/ the service is not started at all or in the wrong order b/ the timining is different under systemd and there is a race somewhere c/ the sysv init script makes assumptions which aren't satisfied under systemd The systemd team can help pinpoint the problem, but ultimately this looks like something which needs to be addressed in ifupdown. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
Hello, On 27 October 2014 13:51, Michael Biebl wrote: > allow-auto is a synonym for auto. > The ifup@.service unit, as shipped by systemd, only deals with > "allow-hotplug" interfaces. > "auto" interfaces are handled by /etc/init.d/networking, which is > shipped by ifupdown. Therefore re-assigning to ifupdown. > Regarding logs: It would probably be helpful to boot with > systemd.log_level=debug and attach the output of journalctl -alb and > specifically the output of systemctl status networking.service. /etc/init.d/networking doesn't check for systemd or anything, and it works fine with sysv-rc, so this probably not a bug in ifupdown, but in systemd. -- Cheers, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766943: systemd: server no longer gets networking after switching to systemd
Control: reassign -1 ifupdown Am 27.10.2014 um 06:56 schrieb Christoph Anton Mitterer: > I did however find what is likely to be the issue: > Changing "allow-auto eth0" to "allow-hotplug eth0" in /e/n/interfaces... > and the system did come up again every time (and I did like 5-8 reboots > with all my tests, also the one with netfilter-persistent above - just > to make sure that it's no coincidence). > > I switched back to "allow-auto eth0" for verification,... (with several > tests)... and again it usually didn't get networking. allow-auto is a synonym for auto. The ifup@.service unit, as shipped by systemd, only deals with "allow-hotplug" interfaces. "auto" interfaces are handled by /etc/init.d/networking, which is shipped by ifupdown. Therefore re-assigning to ifupdown. Regarding logs: It would probably be helpful to boot with systemd.log_level=debug and attach the output of journalctl -alb and specifically the output of systemctl status networking.service. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
On Mon, 2014-10-27 at 06:56 +0100, Christoph Anton Mitterer wrote:
> # systemctl -l status sks.service
> ● sks.service - (null)
>Loaded: loaded (/etc/init.d/sks)
>Active: active (running) since Mon 2014-10-27 06:52:22 CET; 4min 21s ago
> Process: 1991 ExecStart=/etc/init.d/sks start (code=exited,
> status=0/SUCCESS)
...
> Oct 27 06:52:23 kronecker sks[1991]: 2014-10-27 06:52:23 Failed to listen on
> 2a01:4f8:a0:4024::2:2:11370: Failure("Failure while binding socket. Probably
> another socket bound to this address")
FYI: I've reported the problem, that sks returns success, even though it
couldn't start up successfully as: #766949.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
Bug#766943: systemd: server no longer gets networking after switching to systemd
affects 766943 ifupdown
stop
Hey.
Some more information:
I finally came in again and could place some cron script which manually
brings the network up and restarts ssh every 15mins when it can't ping
google.com so testing should get a lot easier then.
I also have some additional information, namely on all my systems I use
a custom /etc/systemd/system/netfilter-persistent.service (attached)
since the original one is IMHO not guaranteed to run early enough.
However, this file is unlikely to be connected to this issue, since
removing it (and using the original one again) doesn't change anything.
I did however find what is likely to be the issue:
Changing "allow-auto eth0" to "allow-hotplug eth0" in /e/n/interfaces...
and the system did come up again every time (and I did like 5-8 reboots
with all my tests, also the one with netfilter-persistent above - just
to make sure that it's no coincidence).
I switched back to "allow-auto eth0" for verification,... (with several
tests)... and again it usually didn't get networking.
Using allow-hotplug however leads e.g. to these:
# systemctl -l status apache2.service
● apache2.service - LSB: Start/stop apache2 web server
Loaded: loaded (/etc/init.d/apache2)
Active: failed (Result: exit-code) since Mon 2014-10-27 06:52:28 CET; 2min
15s ago
Process: 2837 ExecStart=/etc/init.d/apache2 start (code=exited,
status=1/FAILURE)
Oct 27 06:52:27 kronecker systemd[2837]: Executing: /etc/init.d/apache2 start
Oct 27 06:52:28 kronecker apache2[2837]: Starting web server: apache2(99)Cannot
assign requested address: make_sock: could not bind to address
[2a01:4f8:a0:4024::c:0]:80
Oct 27 06:52:28 kronecker apache2[2837]: no listening sockets available,
shutting down
Oct 27 06:52:28 kronecker apache2[2837]: Unable to open logs
Oct 27 06:52:28 kronecker apache2[2837]: Action 'start' failed.
Oct 27 06:52:28 kronecker apache2[2837]: The Apache error log may have more
information.
Oct 27 06:52:28 kronecker apache2[2837]: failed!
Oct 27 06:52:28 kronecker systemd[1]: apache2.service: control process exited,
code=exited status=1
Oct 27 06:52:28 kronecker systemd[1]: Failed to start LSB: Start/stop apache2
web server.
Oct 27 06:52:28 kronecker systemd[1]: Unit apache2.service entered failed state.
# systemctl -l status bind9.service
● bind9.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
Drop-In: /run/systemd/generator/bind9.service.d
└─50-insserv.conf-$named.conf
Active: failed (Result: exit-code) since Mon 2014-10-27 06:52:23 CET; 3min
13s ago
Docs: man:named(8)
Process: 2161 ExecStop=/usr/sbin/rndc stop (code=exited, status=1/FAILURE)
Process: 1937 ExecStart=/usr/sbin/named -f -u bind (code=exited,
status=1/FAILURE)
Main PID: 1937 (code=exited, status=1/FAILURE)
Oct 27 06:52:23 kronecker systemd[1]: Forked /usr/sbin/rndc as 2161
Oct 27 06:52:23 kronecker systemd[1]: bind9.service changed running -> stop
Oct 27 06:52:23 kronecker systemd[2161]: Executing: /usr/sbin/rndc stop
Oct 27 06:52:23 kronecker rndc[2161]: rndc: couldn't get address for
'localhost.': not found
Oct 27 06:52:23 kronecker systemd[1]: Child 2161 belongs to bind9.service
Oct 27 06:52:23 kronecker systemd[1]: bind9.service: control process exited,
code=exited status=1
Oct 27 06:52:23 kronecker systemd[1]: bind9.service got final SIGCHLD for state
stop
Oct 27 06:52:23 kronecker systemd[1]: bind9.service changed stop -> failed
Oct 27 06:52:23 kronecker systemd[1]: Unit bind9.service entered failed state.
Oct 27 06:52:23 kronecker systemd[1]: bind9.service: cgroup is empty
# systemctl -l status sks.service
● sks.service - (null)
Loaded: loaded (/etc/init.d/sks)
Active: active (running) since Mon 2014-10-27 06:52:22 CET; 4min 21s ago
Process: 1991 ExecStart=/etc/init.d/sks start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/sks.service
├─2043 /usr/sbin/sks db
└─2046 /usr/sbin/sks recon
Oct 27 06:52:22 kronecker systemd[1]: sks.service changed dead -> start
Oct 27 06:52:22 kronecker systemd[1991]: Executing: /etc/init.d/sks start
Oct 27 06:52:22 kronecker sks[1991]: Starting sks daemons: sksdb.. sksrecon..
done.
Oct 27 06:52:22 kronecker systemd[1]: Child 1991 belongs to sks.service
Oct 27 06:52:22 kronecker systemd[1]: sks.service: control process exited,
code=exited status=0
Oct 27 06:52:22 kronecker systemd[1]: sks.service got final SIGCHLD for state
start
Oct 27 06:52:22 kronecker systemd[1]: sks.service changed start -> running
Oct 27 06:52:22 kronecker systemd[1]: Job sks.service/start finished,
result=done
Oct 27 06:52:22 kronecker systemd[1]: Started (null).
Oct 27 06:52:23 kronecker sks[1991]: 2014-10-27 06:52:23 Failed to listen on
2a01:4f8:a0:4024::2:2:11370: Failure("Failure while binding socket. Probably
another socket bound to this address")
So it seems all this is strongly connected to bugs #727073 and #766291,
which I've reported against ifupd
Bug#766943: systemd: server no longer gets networking after switching to systemd
Package: systemd Version: 215-5+b1 Severity: important Hi. Tonight I switched my last server still running with sysvinit to systemd, since I've experience no major problems with it on my other systems. That server however, didn't come up anymore (i.e. not even pinging back). I've sent a Ctrl-Alt-Del event via the hosting company's web interface, and it actually came back and I could log in. The logs from syslog didn't show much interesting stuff, only that apache httpd (which runs on that node) couldn't bind to the IPv4 addres. I've rebooted another time then (and several more times since then), but now it's back to no booting (or rather said: no networking - at least the first time where it didn't work, syslog showed, that it actually started up, and also got a clean shutdown). I can't say much about the system or logs right now,... it's a physical machine, IPv4 and v6 addresses, brought up via ifupdown using allow-auto for eth0 in /e/n/interfaces. It uses mdadm with a RAID1. The only other "special" thing that I remember is, that I use rootdelay=10 as a kernel parameter. TBH, I forgot why, but there was something that the disks were detected too lated and the initramfs could never mount the rootfs. But that shoudln't affect systemd, right? I write the bug already now, since it's really complicated to get access to the server by other means,... hetzner (the company) does provide some KVM interface, but that's implemented quite insecurely and it costs when one needs it for a longer time. So it would be great if you could already tell me in advance which logs to look for, and which things to test. Obviously I'll set systemd.log_level=debug at the kernel command line... anything else? Cheers, Chris. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-57 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.25.2-2 ii libc6 2.19-12 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-3 ii libgcrypt20 1.6.2-4 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-5+b1 ii sysv-rc 2.88dsf-57 ii udev215-5+b1 ii util-linux 2.25.2-2 Versions of packages systemd recommends: ii dbus1.8.8-2 ii libpam-systemd 215-5+b1 Versions of packages systemd suggests: ii systemd-ui 3-2 -- Configuration Files: /etc/systemd/logind.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
