Bug#814758: Case power button is ignored unless dbus is installed.

[Ansgar Burchardt]

Josh Triplett  writes:
> If systemd-logind just needs dbus to check for possible inhibitors,
> could systemd-logind simply ignore inhibitors without dbus?

systemd-logind failed to start if dbus isn't available (#772700). That's
why ConditionPathExists=/lib/systemd/system/dbus.service was added in
Debian's systemd-logind.service.

Ansgar

___
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#814758: Case power button is ignored unless dbus is installed.

[Josh Triplett]

On Mon, 15 Feb 2016 14:45:18 +0100 Michael Biebl  wrote:
> Am 15.02.2016 um 08:27 schrieb Trent W. Buck:
> > It's failing because dbus isn't installed.
> > Installing dbus fixes the problem.
> > 
> > systemd Recommends: dbus.
> > 
> > dbus is Priority: standard.
> > 
> > If a system is created with debootstrap,
> > this means dbus is never installed,
> > and the power button doesn't work:
> 
> This is correct. We discussed this issue a while ago and considered
> making dbus either a hard dependency or bumping its priority to
> important. We decided against it, as we want a minimal debootstrapped
> system to not have dbus installed.

If systemd-logind just needs dbus to check for possible inhibitors,
could systemd-logind simply ignore inhibitors without dbus?
Environments that make use of the inhibitor interface should necessarily
have dbus installed, so without dbus installed, systemd-logind could
still respond to the power button by doing an orderly shutdown.

That seems like useful default behavior in a server environment.

- Josh Triplett

___
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#737825: hangs on systemd-tty-ask-password-agent reproduced

[Antoine Beaupré]

Package: systemd
Version: 215-17+deb8u3

I have reproduced the issues described in the bug reports #774153 and
#737825 (they look like duplicates to me, really).

After a minor apt upgrade run here (libgraphite2 stable update and
darktable backport upgrade), needrestart asked me if I wanted to restart
some services which seemed to need restart.

I checked all boxes - i seem to recall that udev was checked off by
default but i rechecked it. It seems this may have been the cause of the
problem, because after that, I ended up having problems with the
following services which wouldn't restart properly:

 * colord.service
 * ModemManager.service
 * udev.service
 * udisks.service
 * udisks2.service

I would also have my logs more or less (1/sec) flooded with:

fév 15 19:55:46 marcos systemd[1]: Looping too fast. Throttling execution a 
little.

Installing a new package (sopel) also would hang on the
systemd-tty-ask-password-agent call, oddly enough. Restarting udev
unhang the install:

Paramétrage de sopel (6.3.0-1) ...
Warning! D-Bus connection terminated.
Failed to wait for response: Succès
invoke-rc.d: initscript sopel, action "start" failed.
dpkg: erreur de traitement du paquet sopel (--install) :
 le sous-processus script post-installation installé a retourné une erreur de 
sortie d'état 1

It also allowed me to restart the other services.

I also tried `systemctl daemon-reexec` as recommended in #774153, not
sure what impact it had.

There was definitely something wrong, but it's recoverable. This could
be a udev bug of some sort, but since this is all systemd now... who
knows!? ;)

Thanks,

A.

-- 
Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu.
Usenet dans ces conditions, c'est comme le web avec lynx, on prend
trop conscience du vide, c'est déprimant.
- JLC dans le Guide du linuxien pervers:
  "Coup de cafard..."

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

Processed: [bts-link] source package systemd

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package systemd
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian.org (was 
bts-link-de...@lists.alioth.debian.org).
> # remote status report for #734007 (http://bugs.debian.org/734007)
> # Bug title: document implicit After= of service on socket
> #  * https://github.com/systemd/systemd/issues/418
> #  * remote status changed: open -> closed
> #  * closed upstream
> tags 734007 + fixed-upstream
Bug #734007 [systemd] document implicit After= of service on socket
Added tag(s) fixed-upstream.
> usertags 734007 - status-open
Usertags were: status-open.
Usertags are now: .
> usertags 734007 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
734007: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734007
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[bts-link] source package systemd

[bts-link-upstream]

#
# bts-link upstream status pull for source package systemd
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user bts-link-upstr...@lists.alioth.debian.org

# remote status report for #734007 (http://bugs.debian.org/734007)
# Bug title: document implicit After= of service on socket
#  * https://github.com/systemd/systemd/issues/418
#  * remote status changed: open -> closed
#  * closed upstream
tags 734007 + fixed-upstream
usertags 734007 - status-open
usertags 734007 + status-closed

thanks

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

Здравствуйте

[Марианна]

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

Processed: block 814528 with 814778

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 814528 with 814778
Bug #814528 [src:systemd] systemd: Please build with IDN support
814528 was not blocked by any bugs.
814528 was not blocking any bugs.
Added blocking bug(s) of 814528: 814778
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
814528: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814528
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Bug#814758: marked as done (Case power button is ignored unless dbus is installed.)

[Debian Bug Tracking System]

Your message dated Mon, 15 Feb 2016 14:45:18 +0100
with message-id <56c1d66e.9030...@debian.org>
and subject line Re: Bug#814758: Case power button is ignored unless dbus is 
installed.
has caused the Debian Bug report #814758,
regarding Case power button is ignored unless dbus is installed.
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
814758: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814758
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 215-17+deb8u3
Severity: normal

My computers have physical power buttons on their cases.
When the button is pressed, I want it to initiate a clean shutdown.

On a desktop install, this happens because systemd-logind handles it:

root@het:~# journalctl -fu systemd-logind
-- Logs begin at Mon 2016-02-15 15:42:58 AEDT. --
Feb 15 15:43:08 het systemd-logind[470]: New seat seat0.
Feb 15 15:43:08 het systemd-logind[470]: Watching system buttons on 
/dev/input/event1 (Power Button)
Feb 15 15:43:08 het systemd-logind[470]: Watching system buttons on 
/dev/input/event5 (Video Bus)
Feb 15 15:43:08 het systemd-logind[470]: Watching system buttons on 
/dev/input/event0 (Power Button)
[...]
Feb 15 17:50:47 het systemd-logind[470]: Power key pressed.
Feb 15 17:50:47 het systemd-logind[470]: Powering Off...
Feb 15 17:50:47 het systemd-logind[470]: System is powering down.

On a server install, this does not happen,
The logs indicate systemd-logind started without issue, then nothing:

root@alpha-understudy:~# journalctl -u systemd-logind
-- Logs begin at Mon 2015-11-23 15:29:23 AEDT, end at Mon 2016-02-15 
17:45:16 AEDT. --
Nov 23 15:29:29 alpha-understudy.cyber.com.au systemd[1]: Started Login 
Service.

However, on closer inspection it has actually failed:

root@alpha-understudy:~# systemctl status systemd-logind
● systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
   Active: inactive (dead)
   start condition failed at Mon 2015-11-23 15:29:29 AEDT; 2 months 
23 days ago
   ConditionPathExists=/lib/systemd/system/dbus.service was not met
 Docs: man:systemd-logind.service(8)
   man:logind.conf(5)
   http://www.freedesktop.org/wiki/Software/systemd/logind
   http://www.freedesktop.org/wiki/Software/systemd/multiseat

Nov 23 15:29:29 alpha-understudy.cyber.com.au systemd[1]: Started Login 
Service.

root@alpha-understudy:~# pgrep logind
root@alpha-understudy:~# pgrep dbus
root@alpha-understudy:~# dpkg-query -W '*dbus*'
dbus
libdbus-1-3:amd64   1.8.20-0+deb8u1

It's failing because dbus isn't installed.
Installing dbus fixes the problem.

systemd Recommends: dbus.

dbus is Priority: standard.

If a system is created with debootstrap,
this means dbus is never installed,
and the power button doesn't work:

# script -c 'sh -xc "debootstrap jessie /tmp/bootstrap/delete-me 
http://apt.cyber.com.au/debian;' typescript
# grep dbus typescript
[no hits]

I believe debian-install users get Priority: standard packages via tasksel 
defaults,
though they can opt-out of this.

systemd-logind wants dbus so that shutdown "inhibitors" can be used.


AFAICT these are the available options:

  * change systemd Recommends: dbus to systemd Depends: dbus.

I strongly dislike this option,
because it will force dbus & expat on minbase installs.

(Also, even upstream doesn't say dbus is mandatory.)

  * change systemd so the power button works without dbus.

I like this best, but I expect upstream to hate it.

  * change systemd so when systemd-logind fails to start (as above),
it actually SAYS THERE'S A PROBLEM in the journal/syslog.

I expect upstream to hate this, too.

  * change systemd's Description, and/or the Debian release notes,
to warn users about this.

  * do nothing.



PS: I used to install acpid & acpi-support-base to work around this issue,
until I discovered that on my faster production hosts,
acpid doesn't start reliably under systemd.
About 48% of the time, acpid starts before /dev/input/ is made, giving:

acpid: inotify_add_watch() failed: No such file or directory (DIGITS)

Sigh.
--- End Message ---
--- Begin Message ---
Am 15.02.2016 um 08:27 schrieb Trent W. Buck:

> It's failing because dbus isn't installed.
> Installing dbus fixes the problem.
> 
> systemd Recommends: dbus.
> 
> dbus is Priority: standard.
> 
> If a system is created with debootstrap,
> 

Bug#814240: systemd triggers break upgrades within unstable

[Michael Biebl]

Control: reassign -1 aptitude

Thanks for the feedback, Guillem.
Reassigning to aptitude.

Zack, I guess the aptitude maintainers will want to know which aptitude
version you are using.

Regards,
Michael

Am 15.02.2016 um 10:48 schrieb Guillem Jover:
> Hi!
> 
> On Thu, 2016-02-11 at 00:08:12 +0100, Michael Biebl wrote:
>> Somehow this looks like an issue in dpkg, if it triggers a package which
>> is in an inconsistent state.
> 
> After a very quick look it does not seem to me to be an issue in either
> systemd nor dpkg, see below.
> 
>> But maybe we just made a mistake in our use of triggers in systemd:
>>  
>> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.triggers
>>  
>> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.postinst#n15
> 
> These look fine.
> 
>> Am 09.02.2016 um 14:12 schrieb Zack Weinberg:
>>> Package: systemd
>>> Version: 228-6
>>> Severity: normal
>>>
>>> libpam-systemd, systemd, and libsystemd0 have = dependencies on each
>>> other.  This invariant can be temporarily violated in the middle of a
>>> large upgrade, and AIUI that is normal and to be expected.  However,
>>> systemd has several dpkg triggers that can fire while the = dependencies
>>> are violated, and when this happens, the entire upgrade bombs out.
>>> Worse, one of those triggers seems to be armed and immediately fired *by
>>> upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
>>> proper, so this is guaranteed to happen any time the systemd packages
>>> are upgraded.
>>>
>>> It's possible to recover by manually installing the new versions of
>>> libpam-systemd, systemd, and libsystemd0, but there's got to be some
>>> way to make apt do the Right Thing, right?  (I don't really understand
>>> triggers.  I thought they were supposed to postpone work until the *end*
>>> of a large upgrade, but they seem to go off all the time in the middle.)
>>>
>>> Example upgrade transcript:
>>>
>>> # aptitude safe-upgrade
>>> [...]
>>> Extracting templates from packages: 100%
>>> Preconfiguring packages ...
>>> [...snip...]
>>> (Reading database ... 289818 files and directories currently installed.)
>>> Preparing to unpack .../linux-image-4.3.0-1-amd64_4.3.5-1_amd64.deb ...
>>> Unpacking linux-image-4.3.0-1-amd64 (4.3.5-1) over (4.3.3-7) ...
>>> Preparing to unpack .../archives/udev_228-6_amd64.deb ...
>>> Unpacking udev (228-6) over (228-5) ...
>>> Preparing to unpack .../libpam-systemd_228-6_amd64.deb ...
>>> Unpacking libpam-systemd:amd64 (228-6) over (228-5) ...
>>> Preparing to unpack .../libsystemd0_228-6_amd64.deb ...
>>> Unpacking libsystemd0:amd64 (228-6) over (228-5) ...
>>> Setting up libsystemd0:amd64 (228-6) ...
>>> Processing triggers for libc-bin (2.21-7) ...
>>> dpkg: dependency problems prevent processing triggers for systemd:
>>>  systemd depends on libsystemd0 (= 228-5); however:
>>>   Version of libsystemd0:amd64 on system is 228-6.
>>>
>>> dpkg: error processing package systemd (--triggers-only):
>>>  dependency problems - leaving triggers unprocessed
>>> Processing triggers for man-db (2.7.5-1) ...
>>> Errors were encountered while processing:
>>>  systemd
>>> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Well it does not seem like aptitude even tried to unpack systemd
> itself. And then it was requested via --triggers-only to process
> triggers, so any attempt to get the dependencies sorted out will fail.
> 
>>> Failed to perform requested operation on package.  Trying to recover:
>>> Setting up libquadmath0:amd64 (5.3.1-8) ...
>>> Setting up linux-image-4.3.0-1-amd64 (4.3.5-1) ...
>>> [...snip...]
>>> Setting up libobjc4:amd64 (5.3.1-8) ...
>>> dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
>>>  libpam-systemd:amd64 depends on systemd (= 228-6); however:
>>>   Version of systemd on system is 228-5.
>>>
>>> dpkg: error processing package libpam-systemd:amd64 (--configure):
>>>  dependency problems - leaving unconfigured
>>> Setting up libx32gcc1 (1:5.3.1-8) ...
>>> [...snip...]
>>> Setting up udev (228-6) ...
>>> addgroup: The group `input' already exists as a system group. Exiting.
>>> update-initramfs: deferring update (trigger activated)
>>> dpkg: dependency problems prevent processing triggers for systemd:
>>>  systemd depends on libsystemd0 (= 228-5); however:
>>>   Version of libsystemd0:amd64 on system is 228-6.
>>>
>>> dpkg: error processing package systemd (--configure):
>>>  dependency problems - leaving triggers unprocessed
>>> Setting up libx32asan2 (5.3.1-8) ...
>>> [..snip...]
>>> Processing triggers for libc-bin (2.21-7) ...
>>> Processing triggers for initramfs-tools (0.122) ...
>>> update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
>>> Errors were encountered while processing:
>>>  libpam-systemd:amd64
>>>  systemd
>>> Press Return to continue.
>>>
>>> # aptitude safe-upgrade
>>> Performing actions...
>>> Reading changelogs... Done
>>> Extracting templates from packages: 

Processed: Re: Bug#814240: systemd triggers break upgrades within unstable

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 aptitude
Bug #814240 [systemd] systemd triggers break upgrades within unstable
Bug reassigned from package 'systemd' to 'aptitude'.
No longer marked as found in versions systemd/228-6.
Ignoring request to alter fixed versions of bug #814240 to the same values 
previously set

-- 
814240: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814240
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Processed: reassign to i-s-h

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 814666 init-system-helpers
Bug #814666 [sysv-rc] sysv-rc: update-rc.d prints incomplete usage (missing 
'defaults')
Bug reassigned from package 'sysv-rc' to 'init-system-helpers'.
No longer marked as found in versions sysvinit/2.88dsf-59.2.
Ignoring request to alter fixed versions of bug #814666 to the same values 
previously set
> retitle 814666 update-rc.d: prints incomplete usage (missing 'defaults')
Bug #814666 [init-system-helpers] sysv-rc: update-rc.d prints incomplete usage 
(missing 'defaults')
Changed Bug title to 'update-rc.d: prints incomplete usage (missing 
'defaults')' from 'sysv-rc: update-rc.d prints incomplete usage (missing 
'defaults')'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
814666: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814666
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Bug#814240: systemd triggers break upgrades within unstable

[Guillem Jover]

Hi!

On Thu, 2016-02-11 at 00:08:12 +0100, Michael Biebl wrote:
> Somehow this looks like an issue in dpkg, if it triggers a package which
> is in an inconsistent state.

After a very quick look it does not seem to me to be an issue in either
systemd nor dpkg, see below.

> But maybe we just made a mistake in our use of triggers in systemd:
>  
> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.triggers
>  
> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.postinst#n15

These look fine.

> Am 09.02.2016 um 14:12 schrieb Zack Weinberg:
> > Package: systemd
> > Version: 228-6
> > Severity: normal
> > 
> > libpam-systemd, systemd, and libsystemd0 have = dependencies on each
> > other.  This invariant can be temporarily violated in the middle of a
> > large upgrade, and AIUI that is normal and to be expected.  However,
> > systemd has several dpkg triggers that can fire while the = dependencies
> > are violated, and when this happens, the entire upgrade bombs out.
> > Worse, one of those triggers seems to be armed and immediately fired *by
> > upgrading libsystemd0*, before dpkg has had a chance to upgrade systemd
> > proper, so this is guaranteed to happen any time the systemd packages
> > are upgraded.
> > 
> > It's possible to recover by manually installing the new versions of
> > libpam-systemd, systemd, and libsystemd0, but there's got to be some
> > way to make apt do the Right Thing, right?  (I don't really understand
> > triggers.  I thought they were supposed to postpone work until the *end*
> > of a large upgrade, but they seem to go off all the time in the middle.)
> > 
> > Example upgrade transcript:
> > 
> > # aptitude safe-upgrade
> > [...]
> > Extracting templates from packages: 100%
> > Preconfiguring packages ...
> > [...snip...]
> > (Reading database ... 289818 files and directories currently installed.)
> > Preparing to unpack .../linux-image-4.3.0-1-amd64_4.3.5-1_amd64.deb ...
> > Unpacking linux-image-4.3.0-1-amd64 (4.3.5-1) over (4.3.3-7) ...
> > Preparing to unpack .../archives/udev_228-6_amd64.deb ...
> > Unpacking udev (228-6) over (228-5) ...
> > Preparing to unpack .../libpam-systemd_228-6_amd64.deb ...
> > Unpacking libpam-systemd:amd64 (228-6) over (228-5) ...
> > Preparing to unpack .../libsystemd0_228-6_amd64.deb ...
> > Unpacking libsystemd0:amd64 (228-6) over (228-5) ...
> > Setting up libsystemd0:amd64 (228-6) ...
> > Processing triggers for libc-bin (2.21-7) ...
> > dpkg: dependency problems prevent processing triggers for systemd:
> >  systemd depends on libsystemd0 (= 228-5); however:
> >   Version of libsystemd0:amd64 on system is 228-6.
> > 
> > dpkg: error processing package systemd (--triggers-only):
> >  dependency problems - leaving triggers unprocessed
> > Processing triggers for man-db (2.7.5-1) ...
> > Errors were encountered while processing:
> >  systemd
> > E: Sub-process /usr/bin/dpkg returned an error code (1)

Well it does not seem like aptitude even tried to unpack systemd
itself. And then it was requested via --triggers-only to process
triggers, so any attempt to get the dependencies sorted out will fail.

> > Failed to perform requested operation on package.  Trying to recover:
> > Setting up libquadmath0:amd64 (5.3.1-8) ...
> > Setting up linux-image-4.3.0-1-amd64 (4.3.5-1) ...
> > [...snip...]
> > Setting up libobjc4:amd64 (5.3.1-8) ...
> > dpkg: dependency problems prevent configuration of libpam-systemd:amd64:
> >  libpam-systemd:amd64 depends on systemd (= 228-6); however:
> >   Version of systemd on system is 228-5.
> > 
> > dpkg: error processing package libpam-systemd:amd64 (--configure):
> >  dependency problems - leaving unconfigured
> > Setting up libx32gcc1 (1:5.3.1-8) ...
> > [...snip...]
> > Setting up udev (228-6) ...
> > addgroup: The group `input' already exists as a system group. Exiting.
> > update-initramfs: deferring update (trigger activated)
> > dpkg: dependency problems prevent processing triggers for systemd:
> >  systemd depends on libsystemd0 (= 228-5); however:
> >   Version of libsystemd0:amd64 on system is 228-6.
> > 
> > dpkg: error processing package systemd (--configure):
> >  dependency problems - leaving triggers unprocessed
> > Setting up libx32asan2 (5.3.1-8) ...
> > [..snip...]
> > Processing triggers for libc-bin (2.21-7) ...
> > Processing triggers for initramfs-tools (0.122) ...
> > update-initramfs: Generating /boot/initrd.img-4.3.0-1-amd64
> > Errors were encountered while processing:
> >  libpam-systemd:amd64
> >  systemd
> > Press Return to continue.
> > 
> > # aptitude safe-upgrade
> > Performing actions...
> > Reading changelogs... Done
> > Extracting templates from packages: 100%
> > Preconfiguring packages ...
> > (Reading database ... 289818 files and directories currently installed.)
> > Preparing to unpack .../acl_2.2.52-3_amd64.deb ...
> > Unpacking acl (2.2.52-3) over (2.2.52-2) ...
> > Preparing to unpack .../libacl1_2.2.52-3_amd64.deb ...
> >