Bug#804832: systemd-networkd fails to configure IPv4 Bridge Network

[Ritesh Raj Sarraf]

On Sat, 2015-11-14 at 15:18 +0530, Ritesh Raj Sarraf wrote:
> That said, it still does not work. And the odd part is, networking is
> only broken for IPv4.

From within the container, this reporting from networkctl is
interesting.


It states:

root@deb-template:~# networkctl status
●  State: routable
 Address: 172.16.221.159 on host0
  169.254.190.70 on host0
  fe80::c48a:3cff:feae:252 on host0
 Gateway: 172.16.20.1 on host0
root@deb-template:~# networkctl status -a
● 1: lo
   Link File: n/a
Network File: n/a
Type: loopback
   State: carrier (unmanaged)
 MTU: 65536
 Address: 127.0.0.1
  ::1

● 2: host0
   Link File: n/a
Network File: /lib/systemd/network/80-container-host0.network
Type: ether
   State: routable (configured)
  HW Address: c6:8a:3c:ae:02:52
 MTU: 1500
 Address: 172.16.221.159
  169.254.190.70
  fe80::c48a:3cff:feae:252
 Gateway: 172.16.20.1
root@deb-template:~# ping 172.16.20.1
PING 172.16.20.1 (172.16.20.1) 56(84) bytes of data.
^C
--- 172.16.20.1 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms

root@deb-template:~#


I am not sure how it determines the "routable" status. The default
gateway is 172.16.20.1, which is not pingable.

 
-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
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#804832: systemd-networkd fails to configure IPv4 Bridge Network

[Ritesh Raj Sarraf]

Hello Felipe,


On Thu, 2015-11-12 at 10:02 -0300, Felipe Sateler wrote:
> rrs@chutzpah:~$ cat /etc/systemd/network/localBridge.network
> > [Match]
> > Name=sysbr0
> > 
> > [Network]
> > DHCPServer=yes
> > IPForward=yes
> 
> I believe this is the problem. Because we do not enable iptables
> support in networkd, then it cannot set this flag.
> 

I am not sure on how this works in systemd-networkd, but from the
manpage, it states that this switch is important. And that it is
important irrespective of the standard means through which we've all
been enabling IP Forwarding in Linux so far.

As I mentioned in the bug report, my intent is to replace my legacy
setup with systemd-networkd. So the current bridge setup (lxcbr0)
already has all the routing/forwarding setup in place. In fact, while
exploring systemd-n, I adapted the setup to also include sysbr0.

That said, it still does not work. And the odd part is, networking is
only broken for IPv4.


> I'd love to have iptables support enabled, but upstream wants to
> switch to nftables at some point. Switch costs are lower if there was
> never any support as there is nothing we can break.
> 
> However, I think networkd should emit a warning if a directive is not
> acted upon due to configure switches.
> 
> You could try enabling ip forwarding manually on the sysbr0 interface
> to see if that works.
> 

It is enabled in /proc for the host kernel already.

rrs@chutzpah:~$ cat /proc/sys/net/ipv4/conf/sysbr0/forwarding 
1
15:10 ♒♒♒   ☺    


> > Address=172.16.20.1
> > 12:12 ♒♒♒   ☺
> > 
> > 
> > In the container, the network does get an IPv4 DHCP address. But it
> > does not
> > work. Interestingly the IPv6 network is working fine.
> > 
> > rrs@chutzpah:~$ ssh fe80::c48a:3cff:feae:252%5
> > rrs@fe80::c48a:3cff:feae:252%5's password:
> > 
> > The programs included with the Debian GNU/Linux system are free
> > software;
> > the exact distribution terms for each program are described in the
> > individual files in /usr/share/doc/*/copyright.
> > 
> > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> > permitted by applicable law.
> > Last login: Thu Nov 12 11:58:37 2015 from
> > fe80::b8c4:8aff:fe59:e054%host0
> > 

Given that the interface does get a DHCP lease, I am inclined to think
it may be a systemd bug, or a Debian specific change.

That was the reason why I thought of filing it with us first.

What do you guys think? Should I take it up with Lennart ?


> > I think this is a systemd specific problem. I think there are some
> > bug
> > reports related to similar symptoms. But before filing upstream, I
> > wanted to check with you guys first.
> 
> So, I think there are two bugs. One downstream (iptables support is
> disabled), and one upstream (networkd should complain loudly when
> ipforwarding/masquerading is set and iptables support is not
> enabled).
> 

We should still file the bug report as a Feature Request. iptables will
stay for some time. It would be good to have nftables by default, but
assuming that iptables is obsolete, is not going to happen any time
soon.

I think upstream had a similar view about /var/lib/machines/, where in
they chose btrfs only. Which led to users with ext4, with almost no
functionality. Please see: https://github.com/systemd/systemd/issues/13
08 for details. It is confirmed as a feature request.


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
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#804832: systemd-networkd fails to configure IPv4 Bridge Network

[Ritesh Raj Sarraf]

On Thu, 2015-11-12 at 10:02 -0300, Felipe Sateler wrote:
> I believe this is the problem. Because we do not enable iptables
> support in networkd, then it cannot set this flag.
> 
> I'd love to have iptables support enabled, but upstream wants to
> switch to nftables at some point. Switch costs are lower if there was
> never any support as there is nothing we can break.
> 
> However, I think networkd should emit a warning if a directive is not
> acted upon due to configure switches.
> 
> You could try enabling ip forwarding manually on the sysbr0 interface
> to see if that works.

I think this part, to an extent is taken care of. There were reports
upstream about it. And the messaging has been tuned accordingly.

root@deb-template:~# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service;
enabled; vendor preset: enabled)
   Active: active (running) since Sat 2015-11-14 15:28:29 IST; 38s ago
 Docs: man:systemd-networkd.service(8)
 Main PID: 281 (systemd-network)
   Status: "Processing requests..."
   CGroup: /machine.slice/systemd-nspawn@digikam.service/system.slice/s
ystemd-networkd.service
   └─281 /lib/systemd/systemd-networkd

Nov 14 15:28:28 deb-template systemd[1]: Stopped Network Service.
Nov 14 15:28:28 deb-template systemd[1]: Starting Network Service...
Nov 14 15:28:29 deb-template systemd-networkd[281]: host0: Cannot
configure IPv4 forwarding for interface host0: Read-only file system
Nov 14 15:28:29 deb-template systemd-networkd[281]: Enumeration
completed
Nov 14 15:28:29 deb-template systemd[1]: Started Network Service.
Nov 14 15:28:29 deb-template systemd-networkd[281]: host0: DHCPv4
address 172.16.221.159/16 via 172.16.20.1
Nov 14 15:28:35 deb-template systemd-networkd[281]: host0: Configured


The "cannot configure IPv4." is now a warning message.

https://github.com/systemd/systemd/pull/495/files


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
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#803013: systemd should not destroy application created cgroups

[paul . szabo]

Dear Julian,

Thank you for the various pointers.

> You set Delegate=yes for the unit ...

That does not seem available yet in jessie.

> The kernel cgroups implementation moved or is moving to a
> single-writer, single-hierarchy implementation ...

It does not seem to have moved yet in jessie.

> ... user space daemon arbiter. systemd implements such an arbiter.

It should permit nominating some other arbiter, and does not seem to
have any plans to do that.

> While the kernel probably still allows for multiple hierarchies in
> order to not break the user space interface, they should not be used
> anymore.

Systemd has not yet implemented the cgrules functionality I require.

> [Delegate=yes] is a mid-term workaround, and will be dropped ...

OK.

---

What should I use now for cgrules, and what in the future?

Why is the conflict between the systemd and cgroup-tools packages not
explicit in Debian packaging?

---

About the patch I proposed. It seems wrong to pass empty strings. The
code contains assert(pto) etc to protect against NULL pointers, seems
an oversight to not have assert(strlen(pto)) also. My patch handles the
case of empty strings (though does not go deep enough to find their
origin). Would not my patch make systemd more robust?

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

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

Привет

[Дакало1978]

___
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#804832: systemd-networkd fails to configure IPv4 Bridge Network

[Ritesh Raj Sarraf]

On Sat, 2015-11-14 at 15:27 +0530, Ritesh Raj Sarraf wrote:
> 
> I am not sure how it determines the "routable" status. The default
> gateway is 172.16.20.1, which is not pingable.

The same setup, now bound to the traditional bridge, is working.

root@deb-template:~# networkctl status
●  State: routable
 Address: 172.16.10.174 on host0
  169.254.190.70 on host0
  fe80::c48a:3cff:feae:252 on host0
 Gateway: 172.16.10.1 on host0
 DNS: 172.16.10.1
root@deb-template:~# apt-get update
Get:1 http://ftp.debian.org unstable InRelease [256 kB]
Get:2 http://ftp.debian.org experimental InRelease [187 kB]
Get:3 http://ftp.debian.org unstable/main amd64 Packages/DiffIndex
[7,876 B]
Get:4 http://ftp.debian.org unstable/contrib amd64 Packages/DiffIndex
[7,681 B]
Get:5 http://ftp.debian.org unstable/non-free amd64 Packages/DiffIndex
[6,025 B]
Get:6 http://ftp.debian.org unstable/contrib Translation-en/DiffIndex
[2,023 B]
Get:7 http://ftp.debian.org unstable/main Translation-en/DiffIndex
[7,876 B]
Get:8 http://ftp.debian.org unstable/non-free Translation-en/DiffIndex
[3,403 B]
Get:9 http://ftp.debian.org experimental/main amd64 Packages/DiffIndex
[7,819 B]
Get:10 http://ftp.debian.org experimental/contrib amd64
Packages/DiffIndex [1,195 B]
Get:11 http://ftp.debian.org experimental/non-free amd64
Packages/DiffIndex [1,195 B]
Get:12 http://ftp.debian.org experimental/contrib Translation-
en/DiffIndex [919 B]
Get:13 http://ftp.debian.org experimental/main Translation-en/DiffIndex 
[7,819 B]



-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



signature.asc
Description: This is a digitally signed message part
___
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: systemd shutdown problems if ulatencyd is installed

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 ulatencyd
Bug #755373 [systemd] systemd 208-6 conflicts with ulatencyd
Bug #755512 [systemd] systemd-sysv: Can not normal /sbin/shutdown (even as root)
Bug #756044 [systemd] systemd: On system power,halt,reboot fail to 
reboot,poweroff my system
Bug #756307 [systemd] systemd: Systemd  fail to start(mount) stop(umount)  Unit 
boot.mount
Bug #756375 [systemd] systemd-sysv: Can not normal shutdown with ulatencyd
Bug reassigned from package 'systemd' to 'ulatencyd'.
Bug reassigned from package 'systemd' to 'ulatencyd'.
Bug reassigned from package 'systemd' to 'ulatencyd'.
Bug reassigned from package 'systemd' to 'ulatencyd'.
Bug reassigned from package 'systemd' to 'ulatencyd'.
No longer marked as found in versions systemd/208-6.
No longer marked as found in versions systemd/208-6.
No longer marked as found in versions systemd/208-7, systemd/215-8, and 
systemd/208-6.
No longer marked as found in versions systemd/208-6.
No longer marked as found in versions systemd/208-6.
Ignoring request to alter fixed versions of bug #755373 to the same values 
previously set
Ignoring request to alter fixed versions of bug #755512 to the same values 
previously set
Ignoring request to alter fixed versions of bug #756044 to the same values 
previously set
Ignoring request to alter fixed versions of bug #756307 to the same values 
previously set
Ignoring request to alter fixed versions of bug #756375 to the same values 
previously set

-- 
755373: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755373
755512: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755512
756044: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756044
756307: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756307
756375: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756375
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#755373: systemd shutdown problems if ulatencyd is installed

[Michael Biebl]

Control: reassign -1 ulatencyd


I'm going to re-assign this to ulatencyd.
@ulatencyd maintainer: please check, if this issue is still valid and if
so, please make ulatency please nice when being running under systemd.
If ulatencyd can't be fixed to run under systemd, please add a Conflicts
to your package.

Thanks,
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
___
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#570821: marked as done (udev won't create new device node for hotplugged SATA device)

[Debian Bug Tracking System]

Your message dated Sun, 15 Nov 2015 04:50:35 +0100
with message-id <5648010b.9060...@debian.org>
and subject line Re: udev won't create new device node for hotplugged SATA 
device
has caused the Debian Bug report #570821,
regarding udev won't create new device node for hotplugged SATA device
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.)


-- 
570821: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570821
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: udev
Version: 0.125-7+lenny3
Severity: important


I hot added a new drive to my system.  It shows up in /proc/scsi/scsi and 
in /var/log/messages:

ivan@wavetail:~$ cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: ATA  Model: Hitachi HDP72502 Rev: GM2O
  Type:   Direct-AccessANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA  Model: WDC WD2500JD-00K Rev: 08.0
  Type:   Direct-AccessANSI  SCSI revision: 05
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA  Model: WDC WD1001FALS-0 Rev: 05.0
  Type:   Direct-AccessANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: ATA  Model: ST31000528AS Rev: CC38
  Type:   Direct-AccessANSI  SCSI revision: 05

ivan@wavetail:~# grep sdd /var/log/messages

Feb 21 09:27:41 wavetail kernel: [7160292.659982] sd 1:0:1:0: [sdd] Attached 
SCSI disk
Feb 21 10:04:23 wavetail kernel: [7163058.848883] sd 1:0:1:0: [sdd] 1953525168 
512-byte hardware sectors (1000205 MB)
Feb 21 10:04:23 wavetail kernel: [7163058.857335] sd 1:0:1:0: [sdd] Write 
Protect is off
Feb 21 10:04:23 wavetail kernel: [7163058.872882] sd 1:0:1:0: [sdd] Write 
cache: enabled, read cache: enabled, doesn't support DPO or FUA


udev did not create a /dev/sdd (or any /dev/sd*) file for this device.

/etc/init.d/udev restart does not correct the situation.


wavetail:/home/ivan# ls /dev/sd? 
/dev/sda  /dev/sdb  /dev/sdc
wavetail:/home/ivan# /etc/init.d/udev restart
Stopping the hotplug events dispatcher: udevd.
Starting the hotplug events dispatcher: udevd.
wavetail:/home/ivan# ls /dev/sd?
/dev/sda  /dev/sdb  /dev/sdc


The udev documentation is woefully inadequate here.  It should
indicate clearly what the user should do to add (or retry adding) a hotswap
device, and what debugging information can be gathered if this is
unsucessful.


-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 64
-rw-r--r-- 1 root root 3801 2009-08-26 03:27 50-udev.rules
-rw-r--r-- 1 root root 1601 2009-08-26 03:27 60-persistent-input.rules
-rw-r--r-- 1 root root 4873 2009-08-26 03:27 60-persistent-storage.rules
-rw-r--r-- 1 root root 1488 2009-08-26 03:27 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root  523 2009-04-15 14:14 60-persistent-v4l.rules
-rw-r--r-- 1 root root  991 2009-02-05 10:54 65_mdadm.vol_id.rules
-rw-r--r-- 1 root root  672 2009-04-03 00:36 70-persistent-net.rules
-rw-r--r-- 1 root root  452 2009-04-15 14:14 75-cd-aliases-generator.rules
-rw-r--r-- 1 root root 4427 2009-08-26 03:27 75-persistent-net-generator.rules
-rw-r--r-- 1 root root 2507 2009-08-26 03:27 80-drivers.rules
-rw-r--r-- 1 root root 4559 2009-08-26 03:27 91-permissions.rules
-rw-r--r-- 1 root root  593 2009-04-15 14:14 95-late.rules
-rw-r--r-- 1 root root  806 2008-12-09 02:24 z60_libvpb0.vtcore.rules

-- /sys/:
/sys/block/md0/dev
/sys/block/md1/dev
/sys/block/ram0/dev
/sys/block/ram10/dev
/sys/block/ram11/dev
/sys/block/ram12/dev
/sys/block/ram13/dev
/sys/block/ram14/dev
/sys/block/ram15/dev
/sys/block/ram1/dev
/sys/block/ram2/dev
/sys/block/ram3/dev
/sys/block/ram4/dev
/sys/block/ram5/dev
/sys/block/ram6/dev
/sys/block/ram7/dev
/sys/block/ram8/dev
/sys/block/ram9/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/block/sda/sda3/dev
/sys/block/sdb/dev
/sys/block/sdb/sdb1/dev
/sys/block/sdb/sdb2/dev
/sys/block/sdc/dev
/sys/block/sdc/sdc1/dev
/sys/block/sdc/sdc2/dev
/sys/block/sdd/dev
/sys/block/vroot0/dev
/sys/block/vroot1/dev
/sys/block/vroot2/dev
/sys/block/vroot3/dev
/sys/block/vroot4/dev
/sys/block/vroot5/dev
/sys/block/vroot6/dev
/sys/block/vroot7/dev
/sys/class/bsg/0:0:0:0/dev
/sys/class/bsg/0:0:1:0/dev
/sys/class/bsg/1:0:0:0/dev
/sys/class/bsg/1:0:1:0/dev
/sys/class/i2c-dev/i2c-0/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input0/mouse0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/input3/event3/dev
/sys/class/input/input4/event4/dev
/sys/class/input/mice/dev

Bug#791633: marked as done (Can't anything bad be detected when given gibberish?)

[Debian Bug Tracking System]

Your message dated Sun, 15 Nov 2015 04:20:32 +0100
with message-id <5647fa00.9050...@debian.org>
and subject line Re: Can't anything bad be detected when given gibberish?
has caused the Debian Bug report #791633,
regarding Can't anything bad be detected when given gibberish?
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.)


-- 
791633: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791633
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 221-1
Severity: wishlist
File: /bin/systemctl

Can't anything bad be detected when given e.g.,

# systemctl disable .servicez ; echo $?
0
--- End Message ---
--- Begin Message ---
Version: 227-1

On Tue, 07 Jul 2015 08:45:59 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson
 wrote:
> Package: systemd
> Version: 221-1
> Severity: wishlist
> File: /bin/systemctl
> 
> Can't anything bad be detected when given e.g.,
> 
> # systemctl disable .servicez ; echo $?
> 0


# systemctl disable .servicez ; echo $?
Failed to execute operation: No such file or directory
1


-- 
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
--- End Message ---
___
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#800521: marked as done (systemd: sys-kernel-config.mount not functional)

[Debian Bug Tracking System]

Your message dated Sun, 15 Nov 2015 04:16:52 +0100
with message-id <5647f924.7070...@debian.org>
and subject line Re: Bug#800521: systemd: sys-kernel-config.mount not functional
has caused the Debian Bug report #800521,
regarding systemd: sys-kernel-config.mount not functional
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.)


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

Hi,

On stock jessie systems sys-kernel-config.mount is not functional,
because /sys/kernel/config does not exist before the configfs module
is loaded, thus ConditionPathExists fails on system boot.  RedHat
solved this by building configfs into the kernel, see
https://bugzilla.redhat.com/show_bug.cgi?id=767432.

A possible workaround:

# echo configfs >/etc/modules-load.d/configfs

The issue was exhibited by the DLM service, which has

[Unit]
Requires=sys-kernel-config.mount
After=sys-kernel-config.mount

[Service]
ExecStartPre=/sbin/modprobe dlm

and the dlm module depends on the configfs module, but pulls it in too
late.  What's more, sys-kernel-config.mount does not fail, just becomes
a no-op when pulled in by dlm.service, confusing things further.

I'd be interested to learn how you intend to fix this, because it
affects the DLM packaging work.
-- 
Thanks,
Feri.
--- End Message ---
--- Begin Message ---
Control: reassign -1
Am 30.09.2015 um 16:37 schrieb Michael Biebl:

> Or, the dlm packages ships a modules-load.d snippet in
> /usr/lib/modules-load.d where it loads the configfs mdoule, since it's
> the dlm package which apparently needs configfs, not systemd itself.
> 
> I would also recommend to move the dlm module loading out of the service
> file via ExecStartPre into a module-load.d snippet.

I think this is the correct solution for this problem. So I'm going to
close this bug report.
I would have re-assigned it, but I didn't now the name of the dlm package.

Regards,
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
--- End Message ---
___
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#787758: 'Failed at step NAMESPACE spawning'when using ReadOnlyDirectories in multi-instance service file

[Michael Biebl]

Am 28.10.2015 um 01:02 schrieb Teddy Hogeborn:
> tags 787758 +patch +fixed-upstream
> stop
> 
> I think this is an instance of Red Hat Bug #1184016, here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1184016
> 
> A pair of upstream patches is given in comment #33 by Michal Schmidt:
> 
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=2230852bd9755e1b7bfd1260082471f559b0a005
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=a0827e2b123010c46cfe4f03eebba57d92f9efc4

nusenu, can you test if those two patches fix your issue?


-- 
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#805133: systemd disables swap too early during shutdown

[Ron]

Package: systemd
Version: 215-17+deb8u2
Severity: important

Hi,

On a normal shutdown or reboot, systemd disables swap before stopping
any other processes.  I see something like this:

 Nov 15 14:50:53 systemd[1]: Started Synchronise Hardware Clock to System Clock.
 Nov 15 14:50:53 systemd[1]: Deactivating swap /dev/disk/by-uuid/bffdb4e8-...
 Nov 15 14:50:53 systemd[1]: Deactivating swap /dev/disk/by-uuid/bffdb4e8-...
 Nov 15 14:50:53 systemd[1]: Deactivating swap /dev/disk/by-uuid/bffdb4e8-...
 Nov 15 14:50:53 systemd[1]: Stopping system-ifup.slice.
 Nov 15 14:50:53 systemd[1]: Removed slice system-ifup.slice.
 Nov 15 14:50:53 systemd[1]: Stopping 

Which is fairly undesirable, because processes wanting to do a clean
shutdown may need to allocate memory, and they are now competing for
it with the thundering herd of all the processes that have just been
signalled to shutdown simultaneously.

I noticed this because it was in fact causing postgres to OOM on a test
system as it tried to checkpoint itself while doing an orderly shutdown.

I'm tempted to call this 'grave', because the potential for data loss is
about the equivalent of just yanking the power cord out of the wall for
every shutdown - and in the case of postgres on this system it indeed
means that the WAL segment files are not properly archived before the
system is shutdown - which would be real data loss if anything tried to
restore from them before this system was restarted again.

This really should delay disabling swap until about the last thing it
does before actually halting - and it should probably only disable it
once, since the repeating of that 3 times seems like a bug in its
handling of this too.

  Cheers,
  Ron

___
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#804056: marked as done (Systemd)

[Debian Bug Tracking System]

Your message dated Sun, 15 Nov 2015 04:36:16 +0100
with message-id <5647fdb0.6030...@debian.org>
and subject line Re: Bug#804056: Re: Bug#804056: Systemd
has caused the Debian Bug report #804056,
regarding Systemd
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.)


-- 
804056: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804056
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: jessie 8.2
Severity: critical
Date: 30 Oct 2015

After upgrade from wheezy 7.9 to jessie 8.2 *server* boot in single ro mode. 
(Squeeze to Wheezy: OK)
No network services. 
No remote login.
No signs of problems on monitor:
  - sysvinit leave a couple of diagnostic messages on screen (anyone can read 
if server is ill)
  - systemd after upgrade - zero messages (server is OK but do not work -> it's 
like Microsoft)

My solution:
  A. Back to wheezy.
  B. In file /etc/fstab: bad UUID's for root file system. (UUID changed to 
/dev/sda2)
  - after reboot - problem with /etc/init.d/iptables - don't load firewall.

Upgrade to jessie: suspended.
--- End Message ---
--- Begin Message ---
Am 12.11.2015 um 22:43 schrieb Michael Biebl:
> Control: severity -1 important
> 
> Since we didn't get any further feedback, I'm downgrading to important
> for now
> 
> Am 05.11.2015 um 13:41 schrieb Felipe Sateler:
>> (Please keep the bug on CC)
>>
>> On 5 November 2015 at 08:10, mila_s  wrote:
>>> Great Thankx!
>>>
>>> I am not registered user.
>>> My 8 servers are running for several years. (migrated from Novell)
>>> The oldest firewall works for 9 years.
>>>
>>>
>>> W dniu 2015-11-04 13:45:51 użytkownik Felipe Sateler  
>>> napisał:
 Control: tags -1 moreinfo

 On 4 November 2015 at 08:15,   wrote:
> Package: systemd
> Version: jessie 8.2
> Severity: critical
> Date: 30 Oct 2015
>
> After upgrade from wheezy 7.9 to jessie 8.2 *server* boot in single ro 
> mode. (Squeeze to Wheezy: OK)
> No network services.
> No remote login.
> No signs of problems on monitor:
>   - sysvinit leave a couple of diagnostic messages on screen (anyone can 
> read if server is ill)
>   - systemd after upgrade - zero messages (server is OK but do not work 
> -> it's like Microsoft)

 The journal (inspect with `journalctl -b`) should have more information.

>
> My solution:
>   A. Back to wheezy.
>   B. In file /etc/fstab: bad UUID's for root file system. (UUID changed 
> to /dev/sda2)

> 
> Is suspect that this broken fstab configuration was the root cause for
> the unsuccessful boot. Nonetheless it would be helpful if you can
> confirm that the system boots now.
> 
> If not, to get more verbose debug messages, you can add
> "systemd.log_level=debug systemd.log_target=kmsg" to the kernel command
> line. I would also suggest that you add "systemd.debug-shell" to the
> kernel command line. This gives you a debug shell on tty9, which you can
> switch to, to inspect the system.
> 
> An output of systemctl status, systemctl list-jobs and journalctl -alb
> would be helpful.

I'm closing this bug report. With the provided information it's unclear
what the actual problem is and there is no way to further pursue this.

Please also file separate bug reports for separate issues in the future,
so they can be tracked and dealt with individually.
Having multiple issues in one bug report results in a mess.

Regards,
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
--- End Message ---
___
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#804910: systemd: Invisible fsck, looked like a hanging system

[Michael Biebl]

Am 14.11.2015 um 13:23 schrieb Manuel Bilderbeek:
> Package: systemd
> Version: 227-2
> Followup-For: Bug #804910
> 
> Hi,
> 
> Strangely enough, today it happened again:
> 
> [4.582220] input: HDA Intel Line Out Side as 
> /devices/pci:00/:00:1b.
> 0/sound/card0/input17
> [4.582280] input: HDA Intel Front Headphone as 
> /devices/pci:00/:00:1
> b.0/sound/card0/input18
> [  576.473983] EXT4-fs (sda6): warning: maximal mount count reached, running 
> e2f
> sck is recommended
> [  576.476387] EXT4-fs (sda6): mounted filesystem with ordered data mode. 
> Opts: 
> (null)
> 
> This is what I saw on the screen for these 472 seconds:
> 
> http://imgur.com/UnXFeC2
> 

Please keep in mind, that fsck for / and /usr is run in the initramfs
nowadays and systemd is not yet involved.
Can you boot and removing "quiet" from the kernel command line.
This should give you more log messages from systemd.

-- 
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#804910: systemd: Invisible fsck, looked like a hanging system

[Manuel Bilderbeek]

Hi,

On 14-11-15 14:09, Michael Biebl wrote:

And alternative could be, to attach the output of systemd-analyze and
"systemd-analyze blame" when such a long fsck happens.


I thought I had already done that, but here it is again in full.

$ systemd-analyze
Startup finished in 3.802s (kernel) + 9min 50.031s (userspace) = 9min 
53.833s


and blame:

9min 32.488s systemd-fsck@dev-sda1.service
9min 31.695s systemd-fsck@dev-sda6.service
 16.290s rc-local.service
  1.528s apache2.service
  1.065s nmbd.service
  1.024s samba-ad-dc.service
   649ms shorewall.service
   544ms media-olddisk6.mount
   331ms dev-sdg1.device
   325ms ModemManager.service
   271ms systemd-localed.service
   252ms NetworkManager.service
   201ms systemd-hostnamed.service
   175ms smbd.service
   171ms accounts-daemon.service
   168ms home-manuel-photos.mount
   149ms home-manuel-Documents.mount
   116ms systemd-timesyncd.service
   116ms home-manuel-Pictures.mount
   109ms udisks2.service
   107ms systemd-modules-load.service
98ms exim4.service
81ms iio-sensor-proxy.service
80ms console-setup.service
79ms keyboard-setup.service
68ms systemd-udevd.service
65ms polkitd.service
65ms rsyslog.service
64ms timidity.service
62ms alsa-restore.service
55ms minissdpd.service
53ms systemd-udev-trigger.service
47ms home-manuel-Music.mount
39ms networking.service
38ms wpa_supplicant.service
36ms home-manuel-Videos.mount
35ms systemd-journald.service
35ms packagekit.service
33ms irqbalance.service
31ms systemd-logind.service
30ms avahi-daemon.service
29ms systemd-tmpfiles-setup-dev.service
27ms media-olddisk1.mount
25ms user@1000.service
23ms kbd.service
21ms systemd-setup-dgram-qlen.service
21ms home-manuel-msx\x2dsoft.mount
20ms user@116.service
20ms speech-dispatcher.service
16ms pppd-dns.service
15ms systemd-user-sessions.service
15ms dev-hugepages.mount
15ms dev-mqueue.mount
14ms gdomap.service
13ms sys-kernel-debug.mount
12ms gdm.service
12ms upower.service
10ms systemd-tmpfiles-setup.service
10ms colord.service
 9ms 
dev-disk-by\x2duuid-0a3f3e1b\x2d1141\x2d4033\x2db619\x2dec2f6d6

 5ms rtkit-daemon.service
 5ms systemd-random-seed.service
 5ms systemd-journal-flush.service
 5ms systemd-update-utmp.service
 4ms home-manuel-docs.mount
 4ms systemd-tmpfiles-clean.service
 4ms kmod-static-nodes.service
 4ms systemd-remount-fs.service
 3ms systemd-sysctl.service
 3ms systemd-update-utmp-runlevel.service

See my first bug report where I already included the top of the blame 
output.
My conclusion was that it was in systemd, so that's why I filed to bug 
against systemd. But I might be wrong :) Your opinion, please! :)


--
Kind regards,

Manuel

___
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#804910: systemd: Invisible fsck, looked like a hanging system

[Michael Biebl]

Am 14.11.2015 um 13:54 schrieb Manuel Bilderbeek:
> Hi,
> 
> On 14-11-15 13:49, Michael Biebl wrote:
>> Please keep in mind, that fsck for / and /usr is run in the initramfs
>> nowadays and systemd is not yet involved.
>> Can you boot and removing "quiet" from the kernel command line.
>> This should give you more log messages from systemd.
> 
> OK, I'll try that.
> 
> If this is the cause, then please reassign the bug to the proper package.

We don't know yet if the time is spent in the initramfs or systemd.
That's why I asked for removing the quiet flag. This will give you an
indication when systemd starts.
And alternative could be, to attach the output of systemd-analyze and
"systemd-analyze blame" when such a long fsck happens.


-- 
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#804910: systemd: Invisible fsck, looked like a hanging system

[Manuel Bilderbeek]

Hi,

On 14-11-15 13:49, Michael Biebl wrote:

Please keep in mind, that fsck for / and /usr is run in the initramfs
nowadays and systemd is not yet involved.
Can you boot and removing "quiet" from the kernel command line.
This should give you more log messages from systemd.


OK, I'll try that.

If this is the cause, then please reassign the bug to the proper package.

These kernel options were the defaults so the point is still valid: you 
don't have a clue what's going on as you get no feedback. This should 
not be the case in a default Debian install, IMHO.
So, IMHO: either fsck progress info is NOT something that should be 
suppressed in 'quiet' mode, or mode should not be 'quiet'.


--
Kind regards,

Manuel

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

Report from systemd.conf 2015

[Michael Biebl]

Hi everybody!

Last week I was at the inaugural systemd.conf which took place in Berlin
from November 5th-7th [1]. The first two days were devoted to talks and
presentations, the third (and last) day for hacking and discussion.
You can find pictures [2] and videos [3] & slides [4] for the talks.
Lennart posted a summary as well on his blog [5].

A couple of DDs were present, like Simon McVittie, Marco d'Itri or
W. Martin Borgert. While there were quite a few talks about "containery"
stuff unsurprisingly, I think there was also a lot of interest in what
(classic) distros are doing with systemd and what problems they are facing.

On the second day, I gave a talk about systemd in Debian [6] which I
think was well received. I would like to use the opportunity here to
thank Martin Pitt, who helped prepare the talk.
I talked about the history of the systemd package in Debian, what
challenges we faced during the transition, the concerns and issues we
have today and what QA/CI we use nowadays. This sparked a lively
discussion afterwards.

Especially the CI stuff was interesting to a lot of people. E.g. I was
approached by Lennart, who wants to know more about the performance
stats as he'd like to see the autopkgtests integrated in the upstream
github workflow.
There were also the maintainers of OpenSUSE and RHEL, who also run
automated tests and were interested how autopkgtest works and if there
was a chance for collaboration. The RHEL guys use beakerlib [7] for
their tests. Beakerlib is open source, the tests themselves IIRC are not
freely available (yet). So I'm not sure yet how we can proceed from here
and if maybe some of our tests could be made available directly upstream
(in case they are distro-agnostic enough).

There was also quite a bit of interest in detecting performance
regressions. Something we currently don't do at all.
I'd like to mention David Strauss' interesting talk [8] here, where he
goes into details about what performance limits they hit with systemctl
daemon-reload.

If you are interested in QA, we, and especially Martin, would be
delighted to see you getting involved and improve our test-suite even
further.

Another topic I raised during the talk, was the constant growth of the
systemd project and how to keep the footprint down for minimal
installations by splitting up the package.
I suggested that distros might coordinate on that issue, and this
already resulted in a lively discussion on the upstream mailing list [9].

I was also approached from the nice people working on Cockpit [10],
which is a fancy, web-based UI to administer your server.
They are really interested in having Debian as one of their supported
distros. We were able to get cockpit up and running on Saturday, and
Dominik, one of the cockpit developers, already blogged about the
results [11].
During the week I started to toy around a bit with cockpit and turning
it into a proper package. The results are on Alioth [12], but they are
by no means finished and there is still quite of work to do.
I probably won't maintain cockpit in Debian, so it would be really
awesome if someone would pick that up, and maybe use my git repo as
starting point.
We lack a good UI for systemd, and cockpit really looks promising in
that regard.

Finally, I'd like to thank Lennart, who invited me to systemd.conf and
made it possible that I could come there.

That's all for now. If you have further questions or would like to work
on some of the topics above, please don't hesitate and get in touch with us.

Regards,
Michael



[1] https://systemd.events/
[2] https://plus.google.com/u/0/events/cilbcdfrpbk12h2qe8o18fn7m04
[3] https://www.youtube.com/channel/UCvq_RgZp3kljp9X8Io9Z1DA
[4]
https://drive.google.com/folderview?id=0B-UWEwsUY5PJZXQ2emdsVXJ4OTA=drive_web
[5] http://0pointer.net/blog/systemdconf-2015-summary.html
[6] https://www.youtube.com/watch?v=6F1mrT5qSWI
[7] https://fedorahosted.org/beakerlib/
[8] https://www.youtube.com/watch?v=wVk-NWtiIZY
[9]
http://lists.freedesktop.org/archives/systemd-devel/2015-November/034917.html
[10] http://cockpit-project.org/
[11] http://dominik.perpeet.eu/cockpit-on-debian-8-2
[12] https://anonscm.debian.org/cgit/collab-maint/cockpit.git
-- 
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