Bug#801563: But..

[Сергей Процеров]

However, if I set timeout=2min, then I get just the same behavior 
(lagging emergency mode and system does not boot). Seems like there is 
some other timeout between 1min and 2min, and when systemd-cryptsetup 
reaches this timeout, systemd goes mad.


___
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#801563: (no subject)

[Jayson Willson]

Yes, I confirm. With timeout=1min everything goes fine, but with 
timeout=2min the situation I have described in the beginning happens 
again. I've heard about 1.30min systemd timeout for all units. Could it 
be because of this timeout?


--
Yours sincerely, Jayson Willson

___
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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

[Stephan Sürken]

Hi Martin,

On Fr, 2015-10-23 at 17:10 +0200, Martin Pitt wrote:
(..)
> > 227-2, sid: Fails, retval 6:
> >  # root? systemctl restart non-existing.service
> >  Failed to restart non-existing.service: Unit non-existing.service failed 
> > to load: No such file or directory.
> >  # root? systemctl restart non-existing.service
> >  Failed to restart non-existing.service: Unit non-existing.service failed 
> > to load: No such file or directory.
> 
> That looks right -- systemctl is supposed to fail for a nonexisting
> script. I don't even consider that a bug, but a fix.

hmm, sorry, seems I did a cut-and-paste error here; the last two lines
should have been

 root@manwe:~# systemctl restart wicd.service
 Failed to restart wicd.service: Unit wicd.service failed to load: No such file 
or directory.

So yes, for a non-existing script, that's (changed behaviour) but
correct.

For the example wicd service however, it should ignore the call like
before, afaiu.

(...)

> Starting/stopping services in a schroot has never been defined
> behaviour, as in general you can't do that. chroots should have a
> policy-rc.d (see /usr/share/doc/sysv-rc/README.policy-rc.d.gz) which
> disables service starting/stopping from package maintainer scripts.

Ahh, ok. Will have a look at that.

> Also, package maintainer scripts certainly shouldn't call invoke-rc.d
> on a nonexisting service?

Well, the "nonexisting" example should only serve to simply demonstrate
that systemd actually _has_ changed behaviour. I am concerned about
actual packages failing to install or remove in a plain chroot.

Hth!

S

___
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#788050: systemd-fsck : Check disks at each reboot

[Axel Ludszuweit]

Dear maintainer,

according to the suggestion from message #65 I have increased the 
timeout to 30min.
But fsck still ends with error 13 checking big partitions. Manually fsck 
ends succeesfully.

It seems to be the same behaviour described in message #70.




___
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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

[Stephan Suerken]

Package: systemd
Version: 227-2
Severity: normal

Dear Maintainers,

with 227-2 (not found in 226-2), systemctl behaves differently
in chroots for (at least) services that only provide a sysv init
script, breaking package install or removal:

226-2, jessie: Ignored, retval 0:
 # root? systemctl restart non-existing.service
 Running in chroot, ignoring request.
 # root? systemctl restart wicd.service
 Running in chroot, ignoring request.

227-2, sid: Fails, retval 6:
 # root? systemctl restart non-existing.service
 Failed to restart non-existing.service: Unit non-existing.service failed to 
load: No such file or directory.
 # root? systemctl restart non-existing.service
 Failed to restart non-existing.service: Unit non-existing.service failed to 
load: No such file or directory.

As systemctl is also run implicitely via invoke.rc.d on postinst
etc., this actually breaks package installation/removal on such
systems (one current example is the wicd package).

Fwiw, calling systemctl as /sbin/runlevel still works fine:

# root? /sbin/runlevel
Running in chroot, ignoring request.

Hth!

S

-- Package-specific info:

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.10-2+b1
ii  libaudit1   1:2.4.4-4
ii  libblkid1   2.27-3
ii  libc6   2.19-22
ii  libcap2 1:2.24-12
ii  libcap2-bin 1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.4-3
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27-3
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 227-2
ii  mount   2.27-3
ii  sysv-rc 2.88dsf-59.2
ii  udev227-2
ii  util-linux  2.27-3

Versions of packages systemd recommends:
ii  dbus1.10.0-3
ii  libpam-systemd  227-2

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

-- no debconf information

___
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#801215: systemd: Re-booting results in systemd "Timed out waiting for device dev-mapper-..."

[Sandro Tosi]

we are seeing the exact same behavior on one of our system - is there
anything we can do to help debug what's going on?

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

___
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: Re: Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #802780 [systemd] systemd: systemctl 227 fails in chroots (instead of 
ignoring)
Severity set to 'important' from 'normal'
> tags -1 confirmed
Bug #802780 [systemd] systemd: systemctl 227 fails in chroots (instead of 
ignoring)
Added tag(s) confirmed.

-- 
802780: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802780
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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

[Michael Biebl]

Control: severity -1 important
Control: tags -1 confirmed

Am 23.10.2015 um 15:32 schrieb Stephan Suerken:
> Package: systemd
> Version: 227-2
> Severity: normal
> 
> Dear Maintainers,
> 
> with 227-2 (not found in 226-2), systemctl behaves differently
> in chroots for (at least) services that only provide a sysv init
> script, breaking package install or removal:
> 
> 226-2, jessie: Ignored, retval 0:
>  # root? systemctl restart non-existing.service
>  Running in chroot, ignoring request.
>  # root? systemctl restart wicd.service
>  Running in chroot, ignoring request.
> 
> 227-2, sid: Fails, retval 6:
>  # root? systemctl restart non-existing.service
>  Failed to restart non-existing.service: Unit non-existing.service failed to 
> load: No such file or directory.
>  # root? systemctl restart non-existing.service
>  Failed to restart non-existing.service: Unit non-existing.service failed to 
> load: No such file or directory.
> 
> As systemctl is also run implicitely via invoke.rc.d on postinst
> etc., this actually breaks package installation/removal on such
> systems (one current example is the wicd package).
> 
> Fwiw, calling systemctl as /sbin/runlevel still works fine:
> 
> # root? /sbin/runlevel
> Running in chroot, ignoring request.

I can confirm this behaviour. Bumped the severity to important, but I'm
inclined to make it RC. Martin?


-- 
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
___
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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

[Michael Biebl]

Am 23.10.2015 um 17:10 schrieb Martin Pitt:
> Hello Stephan,
> 
> Stephan Suerken [2015-10-23 13:32 +]:
>> with 227-2 (not found in 226-2), systemctl behaves differently
>> in chroots for (at least) services that only provide a sysv init
>> script, breaking package install or removal:
> 
>> 226-2, jessie: Ignored, retval 0:
>>  # root? systemctl restart non-existing.service
>>  Running in chroot, ignoring request.
>>  # root? systemctl restart wicd.service
>>  Running in chroot, ignoring request.
>>
>> 227-2, sid: Fails, retval 6:
>>  # root? systemctl restart non-existing.service
>>  Failed to restart non-existing.service: Unit non-existing.service failed to 
>> load: No such file or directory.
>>  # root? systemctl restart non-existing.service
>>  Failed to restart non-existing.service: Unit non-existing.service failed to 
>> load: No such file or directory.
> 
> That looks right -- systemctl is supposed to fail for a nonexisting
> script. I don't even consider that a bug, but a fix.

Well, but it also fails for real services now:

v227
# systemctl status systemd-timesyncd.service
Failed to connect to bus: No such file or directory
# echo $?
1

v215 (jessie)
# systemctl status systemd-timesyncd.service
Running in chroot, ignoring request.
# echo $?
0

-- 
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
___
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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

[Martin Pitt]

Hello Stephan,

Stephan Suerken [2015-10-23 13:32 +]:
> with 227-2 (not found in 226-2), systemctl behaves differently
> in chroots for (at least) services that only provide a sysv init
> script, breaking package install or removal:

> 226-2, jessie: Ignored, retval 0:
>  # root? systemctl restart non-existing.service
>  Running in chroot, ignoring request.
>  # root? systemctl restart wicd.service
>  Running in chroot, ignoring request.
> 
> 227-2, sid: Fails, retval 6:
>  # root? systemctl restart non-existing.service
>  Failed to restart non-existing.service: Unit non-existing.service failed to 
> load: No such file or directory.
>  # root? systemctl restart non-existing.service
>  Failed to restart non-existing.service: Unit non-existing.service failed to 
> load: No such file or directory.

That looks right -- systemctl is supposed to fail for a nonexisting
script. I don't even consider that a bug, but a fix.

> As systemctl is also run implicitely via invoke.rc.d on postinst
> etc., this actually breaks package installation/removal on such
> systems (one current example is the wicd package).

Starting/stopping services in a schroot has never been defined
behaviour, as in general you can't do that. chroots should have a
policy-rc.d (see /usr/share/doc/sysv-rc/README.policy-rc.d.gz) which
disables service starting/stopping from package maintainer scripts.

mk-sbuild, pbuilder, and related utilities create such a policy-rc.d
by default.

Also, package maintainer scripts certainly shouldn't call invoke-rc.d
on a nonexisting service?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

___
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#801737: udev: A better trace

[Jean-Philippe MENGUAL]

Package: udev
Version: 227-2
Followup-For: Bug #801737

Dear Maintainer,

Hi,

As the bug happens with packagekit, consolekit, modemmanage!, virtualbox,
it's often related to services. I tried a simple one, modemmanager, to analyze.
Here's what renders:
strace deb-systemd-invoke try-restart ModemManager.service

(it's the last command dpkg tries in its postinst script).
http://sprunge.us/CaGX


The bug seems related to sysctl, systemd or so on.

Here's another strace, out of script command. Just the last line changes:
http://sprunge.us/UGJE

Note when I try sysctl start, unmask, stop, the service, seems to enable.

Hope it helps. Thanks for your help as my tree becomes... not clean.

Regards,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages udev depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.57
ii  dpkg   1.18.3
ii  libacl12.2.52-2
ii  libblkid1  2.27-3
ii  libc6  2.19-22
ii  libkmod2   21-1
ii  libselinux12.3-2+b1
ii  libudev1   227-2
ii  lsb-base   9.20150917
ii  procps 2:3.3.10-2
ii  util-linux 2.27-3

udev recommends no packages.

udev suggests no packages.

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:
P: /devices/LNXSYSTM:00
E: DEVPATH=/devices/LNXSYSTM:00
E: MODALIAS=acpi:LNXSYSTM:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/INT340E:00
E: DEVPATH=/devices/LNXSYSTM:00/INT340E:00
E: ID_VENDOR_FROM_DATABASE=Interphase Corporation
E: MODALIAS=acpi:INT340E:PNP0C02:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=8310208

P: /devices/LNXSYSTM:00/LNXCPU:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:01
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:02
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:03
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:04
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:04
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:05
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:05
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:06
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:06
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXCPU:07
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:07
E: MODALIAS=acpi:LNXCPU:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXPWRBN:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input10
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input10
E: EV=3
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PRODUCT=19/0/1/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=9119437

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input10/event6
N: input/event6
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event6
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input10/event6
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: MAJOR=13
E: MINOR=70
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=9140957
E: XKBLAYOUT=fr
E: XKBMODEL=pc105
E: XKBVARIANT=latin9

P: /devices/LNXSYSTM:00/LNXSYBUS:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: MODALIAS=acpi:LNXSYBUS:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00
E: DRIVER=ac
E: MODALIAS=acpi:ACPI0003:
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC
E: POWER_SUPPLY_NAME=AC
E: POWER_SUPPLY_ONLINE=1
E: SUBSYSTEM=power_supply

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
E: 

Bug#801563: Seems like I have managed to solve the problem

[Jayson Willson]

I have added "timeout=1" to the fourth row of crypttab, and now systemd 
falls to emergency mode correctly.


--
Yours sincerely, Jayson Willson

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