Processed: bug 840529 is forwarded to https://github.com/systemd/systemd/issues/4370

2016-10-13 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> forwarded 840529 https://github.com/systemd/systemd/issues/4370
Bug #840529 [systemd] systemd-sysctl.service does not run in LXC containers
Set Bug forwarded-to-address to 
'https://github.com/systemd/systemd/issues/4370'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
840529: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840529
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

pkg-systemd-maintainers@lists.alioth.debian.org邮件系统备案提醒！

2016-10-13 Thread postmaster 


　   尊敬的领导及同事：
 由于部分离职员工办公邮箱没有及时上缴注销造成严重外流，严重影响了内部OA
 邮件系统的安全运营。
 现通知本域用户如下：
 您的Email需要进行用户登记备案，逾时没通过备案的账号将会被停止使用！
 在收到本通知的第一时间，将下列信息填写完毕申请备案：
 姓名：   职位：   邮箱：  邮箱登陆地址：邮箱密码：  初始密码：
 点击此处将自动跳转到备案网站
 如果以上链接无法打开，请直接回复本邮箱进行统一备案、
   CopyrighCopyright？2016-10-6 Al  Rigjhts  Reserved.___
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#840529: systemd-sysctl.service does not run in LXC containers

2016-10-13 Thread Felipe Sateler 
On 13 October 2016 at 13:14, Christian Hofstaedtler  wrote:
> * Felipe Sateler  [161013 17:39]:
>> > systemd-sysctl.service does not start in LXC containters, as they
>> > have /proc/sys R/O. *BUT* /proc/sys/net is R/W.
>
>> 1. Have systemd-sysctl lose the ConditionPathIsReadWrite, and
>> systemd-sysctl itself should check which prefixes are writable.
>
> Or, for now, it could just fail for sysctls that are not writable.
> Benefits: Similar to what the old sysctl tool would be doing. Also
> very clear failure mode for these. (Ignoring them would be silent
> failure...)

So, warning messages would appear.

>
>> 2. Have lxc (or the template) ship a new systemd-sysctl-net.service,
>> that includes the new ExecStart and an updated
>> ConditionPathIsReadWrite
>>
>> Option 2 looks like something that has a chance of being fixed in
>> jessie, although by the LXC folks. Option 1 may be addressed upstream,
>> but I don't think this fits backporting material.
>
> I don't massively care about this in jessie; we already have a
> workaround for it. But it'd be nice to get this fixed for stretch.
>
> Having a fix in LXC sounds wrong to me - everything that depends on
> template creations scripts has a high chance of failing. (A ton of
> users do not run those creation scripts in the first place, but get
> their templates from elsewhere, sometimes plain debootstrap.)

OK, I have looked it up, and the Condition is introduced in commit
f2a46f8da5, with message:

units: run sysctl stuff only when /proc/sys is actually writable, to
quieten container boots a little

Could you file this upstream? I'm not sure we want to deviate from
upstream here...

-- 

Saludos,
Felipe Sateler

___
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: dh-systemd: dh_systemd_start --no-start --restart-after-upgrade causes the service to be started on install

2016-10-13 Thread Michael Biebl 
Am 13.10.2016 um 18:08 schrieb Michael Biebl:
> Am 13.10.2016 um 17:56 schrieb Michael Biebl:
>> Am 13.10.2016 um 17:47 schrieb Felipe Sateler:
>>> On 13 October 2016 at 12:36, Michael Biebl  wrote:

 With compat level 9 and older, --no-start did not generate any
 maintainer scripts code at all.
>>>
>>> You can get the same with dh 10 with --no-start --no-restart-after-upgrade

> fwiw, in network-manager I use
> 
>> override_dh_systemd_start:
>>dh_link lib/systemd/system/NetworkManager.service \
>>lib/systemd/system/network-manager.service
>>dh_systemd_start -pnetwork-manager --no-start 
>> NetworkManager-dispatcher.service
>>dh_systemd_start -pnetwork-manager --no-start 
>> NetworkManager-wait-online.service
>>dh_systemd_start -pnetwork-manager --restart-after-upgrade 
>> NetworkManager.service


For some reason --no-start --no-restart-on-upgrade still generates code
for NetworkManager-dispatcher.service.

Something odd going on here. Maybe dh_systemd_start get's confused by the
[Install]
Also=NetworkManager-dispatcher.service

in NetworkManager.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
___
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#840529: systemd-sysctl.service does not run in LXC containers

2016-10-13 Thread Christian Hofstaedtler 
* Felipe Sateler  [161013 17:39]:
> > systemd-sysctl.service does not start in LXC containters, as they
> > have /proc/sys R/O. *BUT* /proc/sys/net is R/W.

> 1. Have systemd-sysctl lose the ConditionPathIsReadWrite, and
> systemd-sysctl itself should check which prefixes are writable.

Or, for now, it could just fail for sysctls that are not writable.
Benefits: Similar to what the old sysctl tool would be doing. Also
very clear failure mode for these. (Ignoring them would be silent
failure...)

> 2. Have lxc (or the template) ship a new systemd-sysctl-net.service,
> that includes the new ExecStart and an updated
> ConditionPathIsReadWrite
> 
> Option 2 looks like something that has a chance of being fixed in
> jessie, although by the LXC folks. Option 1 may be addressed upstream,
> but I don't think this fits backporting material.

I don't massively care about this in jessie; we already have a
workaround for it. But it'd be nice to get this fixed for stretch.

Having a fix in LXC sounds wrong to me - everything that depends on
template creations scripts has a high chance of failing. (A ton of
users do not run those creation scripts in the first place, but get
their templates from elsewhere, sometimes plain debootstrap.)

C.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

___
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#840529: systemd-sysctl.service does not run in LXC containers

2016-10-13 Thread Felipe Sateler 
On 12 October 2016 at 10:26, Christian Hofstaedtler  wrote:
> Package: systemd
> Version: 215-17+deb8u5
> Severity: normal
> Tags: upstream
>
> Hi,
>
> systemd-sysctl.service does not start in LXC containters, as they
> have /proc/sys R/O. *BUT* /proc/sys/net is R/W.
>
> It'd be useful if the net-specific settings would still be applied at
> boot.
>
> Arch has "fixed" this in their lxc package by modifying
> systemd-sysctl.service when creating a new container, but this can
> not be the correct solution.
> See 
> https://github.com/lxc/lxc/pull/683/commits/427d42930d99f93bf78c61ec9f555dd883c5039e

So the solutions AFAICS are:

1. Have systemd-sysctl lose the ConditionPathIsReadWrite, and
systemd-sysctl itself should check which prefixes are writable.
2. Have lxc (or the template) ship a new systemd-sysctl-net.service,
that includes the new ExecStart and an updated
ConditionPathIsReadWrite

Option 2 looks like something that has a chance of being fixed in
jessie, although by the LXC folks. Option 1 may be addressed upstream,
but I don't think this fits backporting material.


-- 

Saludos,
Felipe Sateler

___
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#840608: systemd: nmbd.service long time to start when rebooting

2016-10-13 Thread Michael Biebl 
Am 13.10.2016 um 15:33 schrieb Kirill Sutulo:
> I can not find someone waiting for this service. The problem persists
> also at the two VMs.
> 
> Maybe strace log helps? Or reportbug to samba package?

A strace would be helpful.

> On 10/13/16, Kirill Sutulo  wrote:
>> Yes. restarting service is very fast.
>>
>> On 10/13/16, Michael Biebl  wrote:
>>> Control: tags -1 + moreinfo
>>>
>>> Hi
>>> Am 13.10.2016 um 10:33 schrieb kirill:
>>>
 systemd-analyze blame | head -8
  22.026s nmbd.service
   6.217s systemd-tmpfiles-setup.service
   4.462s networking.service
   3.521s alsa-restore.service
   3.474s pppd-dns.service
   3.473s incron.service
   3.465s systemd-logind.service
   3.456s rc-local.service
 ---
 systemd-analyze critical-chain

 graphical.target @36.509s
 └─multi-user.target @36.509s
   └─smbd.service @35.994s +514ms
 └─nmbd.service @13.967s +22.026s
   └─basic.target @13.946s
 └─paths.target @13.946s
   └─cups.path @13.946s
 └─sysinit.target @13.871s
   └─nfs-common.service @13.481s +389ms
 └─rpcbind.target @13.481s
   └─rpcbind.service @12.167s +1.313s
 └─network-online.target @12.167s
   └─network.target @12.167s
 └─ifup@eth0.service @12.167s

If you change your network configuration in /etc/network/interface and
you use "auto" instead of "allow-hotplug", does it make a difference?


-- 
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#840608: systemd: nmbd.service long time to start when rebooting

2016-10-13 Thread Kirill Sutulo 
I can not find someone waiting for this service. The problem persists
also at the two VMs.

Maybe strace log helps? Or reportbug to samba package?

Thank You!

On 10/13/16, Kirill Sutulo  wrote:
> Yes. restarting service is very fast.
>
> On 10/13/16, Michael Biebl  wrote:
>> Control: tags -1 + moreinfo
>>
>> Hi
>> Am 13.10.2016 um 10:33 schrieb kirill:
>>
>>> systemd-analyze blame | head -8
>>>  22.026s nmbd.service
>>>   6.217s systemd-tmpfiles-setup.service
>>>   4.462s networking.service
>>>   3.521s alsa-restore.service
>>>   3.474s pppd-dns.service
>>>   3.473s incron.service
>>>   3.465s systemd-logind.service
>>>   3.456s rc-local.service
>>> ---
>>> systemd-analyze critical-chain
>>>
>>> graphical.target @36.509s
>>> └─multi-user.target @36.509s
>>>   └─smbd.service @35.994s +514ms
>>> └─nmbd.service @13.967s +22.026s
>>>   └─basic.target @13.946s
>>> └─paths.target @13.946s
>>>   └─cups.path @13.946s
>>> └─sysinit.target @13.871s
>>>   └─nfs-common.service @13.481s +389ms
>>> └─rpcbind.target @13.481s
>>>   └─rpcbind.service @12.167s +1.313s
>>> └─network-online.target @12.167s
>>>   └─network.target @12.167s
>>> └─ifup@eth0.service @12.167s
>>>   └─networking.service @7.704s +4.462s
>>> └─systemd-random-seed.service @7.249s +454ms
>>>   └─var.mount @6.357s +874ms
>>>
>>> └─systemd-fsck@dev-disk-by\x2duuid-0d8732cc\x2d691a\x2d41a0\x2d9266\x2d6690e358a902.service
>>> @5.048s +1.309s
>>>
>>> └─dev-disk-by\x2duuid-0d8732cc\x2d691a\x2d41a0\x2d9266\x2d6690e358a902.device
>>> @5.047s
>>
>>
>> Can you find out, what nmbd is waiting for?
>> That smells like a network issue. I assume if you use
>> systemctl restart nmbd.service when the system is running it doesn't
>> take 22 seconds?
>>
>>
>> --
>> Why is it that all of the instruments seeking intelligent life in the
>> universe are pointed away from Earth?
>>
>>
>

___
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#840608: systemd: nmbd.service long time to start when rebooting

2016-10-13 Thread Kirill Sutulo 
Yes. restarting service is very fast.

On 10/13/16, Michael Biebl  wrote:
> Control: tags -1 + moreinfo
>
> Hi
> Am 13.10.2016 um 10:33 schrieb kirill:
>
>> systemd-analyze blame | head -8
>>  22.026s nmbd.service
>>   6.217s systemd-tmpfiles-setup.service
>>   4.462s networking.service
>>   3.521s alsa-restore.service
>>   3.474s pppd-dns.service
>>   3.473s incron.service
>>   3.465s systemd-logind.service
>>   3.456s rc-local.service
>> ---
>> systemd-analyze critical-chain
>>
>> graphical.target @36.509s
>> └─multi-user.target @36.509s
>>   └─smbd.service @35.994s +514ms
>> └─nmbd.service @13.967s +22.026s
>>   └─basic.target @13.946s
>> └─paths.target @13.946s
>>   └─cups.path @13.946s
>> └─sysinit.target @13.871s
>>   └─nfs-common.service @13.481s +389ms
>> └─rpcbind.target @13.481s
>>   └─rpcbind.service @12.167s +1.313s
>> └─network-online.target @12.167s
>>   └─network.target @12.167s
>> └─ifup@eth0.service @12.167s
>>   └─networking.service @7.704s +4.462s
>> └─systemd-random-seed.service @7.249s +454ms
>>   └─var.mount @6.357s +874ms
>>
>> └─systemd-fsck@dev-disk-by\x2duuid-0d8732cc\x2d691a\x2d41a0\x2d9266\x2d6690e358a902.service
>> @5.048s +1.309s
>>
>> └─dev-disk-by\x2duuid-0d8732cc\x2d691a\x2d41a0\x2d9266\x2d6690e358a902.device
>> @5.047s
>
>
> Can you find out, what nmbd is waiting for?
> That smells like a network issue. I assume if you use
> systemctl restart nmbd.service when the system is running it doesn't
> take 22 seconds?
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

___
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#840608: systemd: nmbd.service long time to start when rebooting

2016-10-13 Thread Michael Biebl 
Control: tags -1 + moreinfo

Hi
Am 13.10.2016 um 10:33 schrieb kirill:

> systemd-analyze blame | head -8
>  22.026s nmbd.service
>   6.217s systemd-tmpfiles-setup.service
>   4.462s networking.service
>   3.521s alsa-restore.service
>   3.474s pppd-dns.service
>   3.473s incron.service
>   3.465s systemd-logind.service
>   3.456s rc-local.service
> ---
> systemd-analyze critical-chain 
> 
> graphical.target @36.509s
> └─multi-user.target @36.509s
>   └─smbd.service @35.994s +514ms
> └─nmbd.service @13.967s +22.026s
>   └─basic.target @13.946s
> └─paths.target @13.946s
>   └─cups.path @13.946s
> └─sysinit.target @13.871s
>   └─nfs-common.service @13.481s +389ms
> └─rpcbind.target @13.481s
>   └─rpcbind.service @12.167s +1.313s
> └─network-online.target @12.167s
>   └─network.target @12.167s
> └─ifup@eth0.service @12.167s
>   └─networking.service @7.704s +4.462s
> └─systemd-random-seed.service @7.249s +454ms
>   └─var.mount @6.357s +874ms
> 
> └─systemd-fsck@dev-disk-by\x2duuid-0d8732cc\x2d691a\x2d41a0\x2d9266\x2d6690e358a902.service
>  @5.048s +1.309s
>   
> └─dev-disk-by\x2duuid-0d8732cc\x2d691a\x2d41a0\x2d9266\x2d6690e358a902.device 
> @5.047s


Can you find out, what nmbd is waiting for?
That smells like a network issue. I assume if you use
systemctl restart nmbd.service when the system is running it doesn't
take 22 seconds?


-- 
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

Processed: Re: Bug#840608: systemd: nmbd.service long time to start when rebooting

2016-10-13 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 + moreinfo
Bug #840608 [systemd] systemd: nmbd.service long time to start when rebooting
Added tag(s) moreinfo.

-- 
840608: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840608
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#840613: systemd-networkd 215-17+deb8u5 not honoring UseDomains or UseDomainName in DHCP-mode

2016-10-13 Thread bee GmbH | Pasqual Brettner 

Package: systemd
Version: 215-17+deb8u5

Dear Maintainer,

when i configure systemd-networkd to use DHCP, systemd-resolved does
not write domain or search line into its /run/systemd/resolve/resolv.conf.
The only thing in /run/systemd/resolve/resolv.conf is the banner to not touch 
the file
and one line "nameserver ".

My /etc/systemd/network/eth0.network looks like this:
~# cat /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
DHCP=yes

[DHCP]
UseDomainName=true


I also tried using UseDomains in [DHCP]-Section as found per google, but this 
seems to be
not active in the version which is in the jessie repository. At least
systemd reports an unknown lvalue UseDomains in section [DHCP].
"/run/systemd/netif/leases/2" lists DOMAINNAME=my.domain.name as sent from
my DHCP but i can't figure out, how to make systemd-networkd or systemd-resolved
use it.

I already looked into the source of systemd 215-17+deb8u5 and only found
DHCPv4.UseDomainName
DHCP.UseDomainName


So my name resolution is not working when using systemd-networkd in DHCP mode.
Any suggestions?

This is critical to our deployment :(

I am using Debian GNU/Linux 8.5 with linux-image-4.6.0-0.bpo.1-amd64 
(4.6.3-1~bpo8+1)

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