[Touch-packages] [Bug 1564451] Re: User processes are counted towards systemd limit for sshd processes (add libpam-systemd to openssh-server)

2017-06-13 Thread Dr. Jens Rosenboom 
This seems to have been solved by
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1561658,
which could be considered a duplicate.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1564451

Title:
  User processes are counted towards systemd limit for sshd processes
  (add libpam-systemd to openssh-server)

Status in systemd:
  New
Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  When running Xenial, user processes are counted towards the limit for
  the ssh.service, with a limit of 512. So if I login as a normal user
  via ssh and start 512 processes, nobody will be able to login any more
  and even all other users currently logged in will not be able to start
  any new tasks. I'm not certain whether this behaviour is by design,
  but to me it looks like a critical DOS possibility, so tagging as
  security bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1564451/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

2017-01-24 Thread Dr. Jens Rosenboom 
I've tried to reproduce this on a yakkety cloud instance as well as with
lxc for some time, but sadly with no success. So I'm not sure whether
this is still present in yakkety at all.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1591411

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

Status in D-Bus:
  Unknown
Status in systemd:
  Unknown
Status in dbus package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Xenial:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in dbus source package in Yakkety:
  Fix Committed
Status in systemd source package in Yakkety:
  Invalid

Bug description:
  [Impact]

  The bug affects multiple users and introduces an user visible delay
  (~25 seconds) on SSH connections after a large number of sessions have
  been processed. This has a serious impact on big systems and servers
  running our software.

  The currently proposed fix is actually a safe workaround for the bug
  as proposed by the dbus upstream. The workaround makes uid 0 immune to
  the pending_fd_timeout limit that kicks in and causes the original
  issue.

  [Test Case]

  lxc launch ubuntu:x test
  lxc exec test -- login -f ubuntu
  ssh-import-id 

  Then ran a script as follows (passing in ubuntu@):

  while [ 1 ]; do
  (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
  done

  Then checking the log file if there are any ssh sessions that are
  taking 25+ seconds to complete.

  Multiple instances of the same script can be used at the same time.

  [Regression Potential]

  The fix has a rather low regression potential as the workaround is a
  very small change only affecting one particular case - handling of uid
  0. The fix has been tested by multiple users and has been around in
  zesty for a while, with multiple people involved in reviewing the
  change. It's also a change that has been proposed by upstream.

  [Original Description]

  I noticed on a system that accepts large numbers of SSH connections
  that after awhile, SSH sessions were taking ~25 seconds to complete.

  Looking in /var/log/auth.log, systemd-logind starts failing with the
  following:

  Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for 
user ubuntu by (uid=0)
  Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu.
  Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: 
Transport endpoint is not connected
  Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create 
session: Message recipient disconnected from message bus without replying

  I reproduced this in an LXD container by doing something like:

  lxc launch ubuntu:x test
  lxc exec test -- login -f ubuntu
  ssh-import-id 

  Then ran a script as follows (passing in ubuntu@):

  while [ 1 ]; do
  (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log
  done

  In my case, after 1052 logins, the 1053rd and thereafter were taking
  25+ seconds to complete. Here are some snippets from the log file:

  $ cat log | grep 0m0 | wc -l
  1052

  $ cat log | grep 0m25 | wc -l
  4

  $ tail -5 log
  real  0m0.222s
  real  0m25.232s
  real  0m25.235s
  real  0m25.236s
  real  0m25.239s

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu5
  ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  Date: Sat Jun 11 00:09:34 2016
  MachineType: Notebook W230SS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /lib/systemd/system/rc-local.service → 
/lib/systemd/system/rc-local.service.d/debian.conf
   [EXTENDED]   /lib/systemd/system/systemd-timesyncd.service → 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

   2 overridden configuration files found.
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 04/15/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 4.6.5
  dmi.board.asset.tag: Tag 12345
  dmi.board.name: W230SS
  dmi.board.vendor: Notebook
  dmi.board.version: Not Applicable
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 9
  dmi.chassis.vendor: Notebook
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/15/2014:svnNotebook:pnW230SS:pvrNotApplicable:rvnNotebook:rnW230SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A:
  dmi.product.name: W230SS
  dmi.product.version: Not Applicable
  dmi.sys.vendor: Notebook

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1591411

[Touch-packages] [Bug 1565804] Re: ifup of vlan interfaces failing during networking start - RTNETLINK answers: File exists

2016-10-04 Thread Dr. Jens Rosenboom 
*** This bug is a duplicate of bug 1224007 ***
https://bugs.launchpad.net/bugs/1224007

** This bug has been marked a duplicate of bug 1224007
   mtu not always set properly on bond/vlan interface

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1565804

Title:
  ifup of vlan interfaces failing during networking start - RTNETLINK
  answers: File exists

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  /e/n/i:

  auto lo
  iface lo inet loopback
  dns-nameservers 10.245.168.2
  dns-search dellstack
  auto eth0
  iface eth0 inet static
  gateway 10.245.168.1
  address 10.245.168.17/21
  dns-nameservers 10.245.168.2
  mtu 1500

  auto eth1
  iface eth1 inet manual
  mtu 1500

  auto eth1.2667
  iface eth1.2667 inet static
  address 10.245.184.20/24
  vlan-raw-device eth1
  mtu 9000
  vlan_id 2667

  output from networking startup:

  ● networking.service - Raise network interfaces
 Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor 
preset: enabled)
Drop-In: /run/systemd/generator/networking.service.d
 └─50-insserv.conf-$network.conf
 Active: failed (Result: exit-code) since Mon 2016-04-04 12:14:26 UTC; 1h 
33min ago
   Docs: man:interfaces(5)
Process: 1255 ExecStart=/sbin/ifup -a --read-environment (code=exited, 
status=1/FAILURE)
Process: 868 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle 
(code=exited, 
   Main PID: 1255 (code=exited, status=1/FAILURE)

  Apr 04 12:14:25 reflecting-attraction systemd[1]: Starting Raise network 
interfaces...
  Apr 04 12:14:26 reflecting-attraction ifup[1255]: Set name-type for VLAN 
subsystem. Should be visible in /proc/net/vlan/config
  Apr 04 12:14:26 reflecting-attraction ifup[1255]: RTNETLINK answers: File 
exists
  Apr 04 12:14:26 reflecting-attraction ifup[1255]: Failed to bring up 
eth1.2667.
  Apr 04 12:14:26 reflecting-attraction systemd[1]: networking.service: Main 
process exited, code=exited, status=1/FAILURE
  Apr 04 12:14:26 reflecting-attraction systemd[1]: Failed to start Raise 
network interfaces.
  Apr 04 12:14:26 reflecting-attraction systemd[1]: networking.service: Unit 
entered failed state.
  Apr 04 12:14:26 reflecting-attraction systemd[1]: networking.service: Failed 
with result 'exit-code'.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ifupdown 0.8.10ubuntu1
  ProcVersionSignature: User Name 4.4.0-16.32-generic 4.4.6
  Uname: Linux 4.4.0-16-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Mon Apr  4 13:42:48 2016
  SourcePackage: ifupdown
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1565804/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1630191] Re: MTU settings not always applied after reboot

2016-10-04 Thread Dr. Jens Rosenboom 
*** This bug is a duplicate of bug 1224007 ***
https://bugs.launchpad.net/bugs/1224007

** This bug has been marked a duplicate of bug 1224007
   mtu not always set properly on bond/vlan interface

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1630191

Title:
  MTU settings not always applied after reboot

Status in ifupdown package in Ubuntu:
  New

Bug description:
  On a node with two 10G interfaces, we configure a bond interface from
  these two interfaces and then a vlan interface on top of it. The MTU
  of these interfaces shall be set to be 1550 instead of the default
  1500, so we have these settings in /etc/network/interfaces.d:

  root@controller-node13:~# cat /etc/network/interfaces.d/xge0
  auto xge0
  iface xge0 inet manual
bond-master xiondata

  
  root@controller-node13:~# cat /etc/network/interfaces.d/xge1
  auto xge1
  iface xge1 inet manual
bond-master xiondata

  
  root@controller-node13:~# cat /etc/network/interfaces.d/xiondata
  auto xiondata
  iface xiondata inet manual
bond-slaves xge0 xge1
bond-miimon 100
bond-lacp-rate 1
bond-mode 4
mtu 1550

  
  root@controller-node13:~# cat /etc/network/interfaces.d/xiondata.200
  auto xiondata.200
  iface xiondata.200 inet static
address 10.80.1.13/24
vlan_raw_device xiondata
mtu 1550

  After a reboot, the correct MTU is applied to the vlan interface only
  50% of the time, on the other attempts, it stays at 1500, leading to
  broken connectivity. If I restart the interfaces manually, by doing
  "ifdown xiondata; ifup -a" the MTU settings seem to be applied
  correctly every time.

  root@controller-node13:~# apt policy ifupdown
  ifupdown:
Installed: 0.8.10ubuntu1
Candidate: 0.8.10ubuntu1
Version table:
   *** 0.8.10ubuntu1 500
  500 http://eu.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ifupdown 0.8.10ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
  Uname: Linux 4.4.0-38-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Tue Oct  4 09:44:40 2016
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: ifupdown
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1630191/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1630191] [NEW] MTU settings not always applied after reboot

2016-10-04 Thread Dr. Jens Rosenboom 
Public bug reported:

On a node with two 10G interfaces, we configure a bond interface from
these two interfaces and then a vlan interface on top of it. The MTU of
these interfaces shall be set to be 1550 instead of the default 1500, so
we have these settings in /etc/network/interfaces.d:

root@controller-node13:~# cat /etc/network/interfaces.d/xge0
auto xge0
iface xge0 inet manual
  bond-master xiondata


root@controller-node13:~# cat /etc/network/interfaces.d/xge1
auto xge1
iface xge1 inet manual
  bond-master xiondata


root@controller-node13:~# cat /etc/network/interfaces.d/xiondata
auto xiondata
iface xiondata inet manual
  bond-slaves xge0 xge1
  bond-miimon 100
  bond-lacp-rate 1
  bond-mode 4
  mtu 1550


root@controller-node13:~# cat /etc/network/interfaces.d/xiondata.200
auto xiondata.200
iface xiondata.200 inet static
  address 10.80.1.13/24
  vlan_raw_device xiondata
  mtu 1550

After a reboot, the correct MTU is applied to the vlan interface only
50% of the time, on the other attempts, it stays at 1500, leading to
broken connectivity. If I restart the interfaces manually, by doing
"ifdown xiondata; ifup -a" the MTU settings seem to be applied correctly
every time.

root@controller-node13:~# apt policy ifupdown
ifupdown:
  Installed: 0.8.10ubuntu1
  Candidate: 0.8.10ubuntu1
  Version table:
 *** 0.8.10ubuntu1 500
500 http://eu.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ifupdown 0.8.10ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
Uname: Linux 4.4.0-38-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
Date: Tue Oct  4 09:44:40 2016
ProcEnviron:
 LANGUAGE=en_US:
 TERM=screen
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: ifupdown
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: ifupdown (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug third-party-packages xenial

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1630191

Title:
  MTU settings not always applied after reboot

Status in ifupdown package in Ubuntu:
  New

Bug description:
  On a node with two 10G interfaces, we configure a bond interface from
  these two interfaces and then a vlan interface on top of it. The MTU
  of these interfaces shall be set to be 1550 instead of the default
  1500, so we have these settings in /etc/network/interfaces.d:

  root@controller-node13:~# cat /etc/network/interfaces.d/xge0
  auto xge0
  iface xge0 inet manual
bond-master xiondata

  
  root@controller-node13:~# cat /etc/network/interfaces.d/xge1
  auto xge1
  iface xge1 inet manual
bond-master xiondata

  
  root@controller-node13:~# cat /etc/network/interfaces.d/xiondata
  auto xiondata
  iface xiondata inet manual
bond-slaves xge0 xge1
bond-miimon 100
bond-lacp-rate 1
bond-mode 4
mtu 1550

  
  root@controller-node13:~# cat /etc/network/interfaces.d/xiondata.200
  auto xiondata.200
  iface xiondata.200 inet static
address 10.80.1.13/24
vlan_raw_device xiondata
mtu 1550

  After a reboot, the correct MTU is applied to the vlan interface only
  50% of the time, on the other attempts, it stays at 1500, leading to
  broken connectivity. If I restart the interfaces manually, by doing
  "ifdown xiondata; ifup -a" the MTU settings seem to be applied
  correctly every time.

  root@controller-node13:~# apt policy ifupdown
  ifupdown:
Installed: 0.8.10ubuntu1
Candidate: 0.8.10ubuntu1
Version table:
   *** 0.8.10ubuntu1 500
  500 http://eu.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ifupdown 0.8.10ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
  Uname: Linux 4.4.0-38-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  Date: Tue Oct  4 09:44:40 2016
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: ifupdown
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1630191/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1578141] Re: Predictable interface names partially broken with igb driver

2016-05-17 Thread Dr. Jens Rosenboom 
@Martin: Fixing the installed system is easy, the bad case happens when
the installer sets up the system with "rename2" as the first interface,
making access via console necessary in order to recover.

root@compute-node37:~# SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_id 
/sys/class/net/eno1
calling: test-builtin
=== trie on-disk ===
tool version:  229
file size: 6841778 bytes
header size 80 bytes
strings1755242 bytes
nodes  5086456 bytes
Load module index
timestamp of '/etc/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Parsed configuration file /lib/systemd/network/90-mac-for-usb.link
Created link configuration context.
ID_NET_NAME_MAC=enx002590d8975a
ID_OUI_FROM_DATABASE=Super Micro Computer, Inc.
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_PATH=enp7s0f0
Unload module index
Unloaded link configuration context.
root@compute-node37:~# SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_id 
/sys/class/net/rename3  

  
calling: test-builtin
=== trie on-disk ===
tool version:  229
file size: 6841778 bytes
header size 80 bytes
strings1755242 bytes
nodes  5086456 bytes
Load module index
timestamp of '/etc/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib/systemd/network/99-default.link
Parsed configuration file /lib/systemd/network/90-mac-for-usb.link
Created link configuration context.
ID_NET_NAME_MAC=enx002590d8975b
ID_OUI_FROM_DATABASE=Super Micro Computer, Inc.
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_PATH=enp7s0f1
Unload module index
Unloaded link configuration context.

Also note that the whole renaming process seems to come from an Ubuntu
specific patch in Revert-udev-network-device-renaming-immediately-
give.patch, IIUC plain systemd would fail the renaming process and end
up with either (eno1, eth1) or (eth0, eno1) as interface tuples.

If there was a way to get rid of the race condition and make sure that
the system always ends up with the same tuple, that would already be a
large step forward.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1578141

Title:
  Predictable interface names partially broken with igb driver

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  Note: I'm not sure whether this is really a kernel bug or something
  within systemd/udev, please advise how to further debug.

  On a system with two GE ports, instead of getting named eno1 and eno2,
  I am getting eno1 and renameN. Where N starts at 3 and increases by 2
  on every iteration of doing "rmmod igb;modprobe igb". The
  corresponding lines in dmesg look like this:

  [2.748429] igb :07:00.0: added PHC on eth0
  [2.748431] igb :07:00.0: Intel(R) Gigabit Ethernet Network Connection
  [2.748433] igb :07:00.0: eth0: (PCIe:5.0Gb/s:Width x4) 
00:25:90:d7:60:8e
  [2.748505] igb :07:00.0: eth0: PBA No: 106100-000
  [2.748506] igb :07:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
  [2.802555] igb :07:00.1: added PHC on eth1
  [2.802557] igb :07:00.1: Intel(R) Gigabit Ethernet Network Connection
  [2.802559] igb :07:00.1: eth1: (PCIe:5.0Gb/s:Width x4) 
00:25:90:d7:60:8f
  [2.802631] igb :07:00.1: eth1: PBA No: 106100-000
  [2.802632] igb :07:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
  [2.803618] igb :07:00.0 eno1: renamed from eth0
  [2.833208] igb :07:00.1 rename3: renamed from eth1

  What is even worse: Sometimes the naming changes and the second
  interface ends up as eno1 while the first interface is named renameN
  with an even N. The bad thing about this version is that when it
  happens while the installer is running, the installer will setup
  "rename2" as the primary network interface, which works fine for the
  installation itself, but after installation is finished and the first
  boot of the installed system happens, that interface will be gone,
  leaving the system without network connectivity.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-21-generic 4.4.0-21.37
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 May  4 09:48 seq
   crw-rw 1 root audio 116, 33 May  4 09:48 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  Au

[Touch-packages] [Bug 1578141] Re: Predictable interface names partially broken with igb driver

2016-05-17 Thread Dr. Jens Rosenboom 
Looking further, it seems that the BIOS is providing broken information,
see this snippet from dmidecode output:

Handle 0x007E, DMI type 41, 11 bytes
Onboard Device
Reference Designation:  Onboard Intel Ethernet 1
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: :07:00.0

Handle 0x007F, DMI type 41, 11 bytes
Onboard Device
Reference Designation:  Onboard Intel Ethernet 2
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: :07:00.1

and as a result we get ID_NET_NAME_ONBOARD=eno1 for both devices. So
udev tries to rename both interfaces to eno1, only one succeeds, the
other one fails due to a name collision. Would be nice to implement a
workaround for these broken BIOS data.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1578141

Title:
  Predictable interface names partially broken with igb driver

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  Note: I'm not sure whether this is really a kernel bug or something
  within systemd/udev, please advise how to further debug.

  On a system with two GE ports, instead of getting named eno1 and eno2,
  I am getting eno1 and renameN. Where N starts at 3 and increases by 2
  on every iteration of doing "rmmod igb;modprobe igb". The
  corresponding lines in dmesg look like this:

  [2.748429] igb :07:00.0: added PHC on eth0
  [2.748431] igb :07:00.0: Intel(R) Gigabit Ethernet Network Connection
  [2.748433] igb :07:00.0: eth0: (PCIe:5.0Gb/s:Width x4) 
00:25:90:d7:60:8e
  [2.748505] igb :07:00.0: eth0: PBA No: 106100-000
  [2.748506] igb :07:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
  [2.802555] igb :07:00.1: added PHC on eth1
  [2.802557] igb :07:00.1: Intel(R) Gigabit Ethernet Network Connection
  [2.802559] igb :07:00.1: eth1: (PCIe:5.0Gb/s:Width x4) 
00:25:90:d7:60:8f
  [2.802631] igb :07:00.1: eth1: PBA No: 106100-000
  [2.802632] igb :07:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
  [2.803618] igb :07:00.0 eno1: renamed from eth0
  [2.833208] igb :07:00.1 rename3: renamed from eth1

  What is even worse: Sometimes the naming changes and the second
  interface ends up as eno1 while the first interface is named renameN
  with an even N. The bad thing about this version is that when it
  happens while the installer is running, the installer will setup
  "rename2" as the primary network interface, which works fine for the
  installation itself, but after installation is finished and the first
  boot of the installed system happens, that interface will be gone,
  leaving the system without network connectivity.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-21-generic 4.4.0-21.37
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 May  4 09:48 seq
   crw-rw 1 root audio 116, 33 May  4 09:48 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  Date: Wed May  4 10:00:39 2016
  HibernationDevice: RESUME=/dev/mapper/compute--node37--vg-swap
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Supermicro X9DRT-HF+
  PciMultimedia:
   
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US
   SHELL=/bin/bash
  ProcFB: 0 VESA VGA
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-21-generic 
root=/dev/mapper/compute--node37--vg-root ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-21-generic N/A
   linux-backports-modules-4.4.0-21-generic  N/A
   linux-firmware1.157
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/21/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 3.0c
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: X9DRT-HF+
  dmi.board.vendor: Supermicro
  dmi.board.version: 0123456789
  dmi.chassis.asset.tag:

[Touch-packages] [Bug 1578141] Re: Predictable interface names partially broken with igb driver

2016-05-06 Thread Dr. Jens Rosenboom 
We have seen the issue only when deploying Xenial, installations running
Precise or Trusty do not seem to be affected.

Running with 4.6.0-040600rc6-generic has shown the same behaviour.

After doing the rmmod/modprobe cycle, I have now found the attached set
of messages in the output of "journalctl -x", so this seems to confirm
my suspicion of some bad interaction between kernel and systemd going
on.

** Attachment added: "Output of "journalctl -x" when doing "rmmod igb;sleep 
3;modprobe igb""
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1578141/+attachment/4657073/+files/journal.txt

** Tags added: kernel-bug-exists-upstream

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1578141

Title:
  Predictable interface names partially broken with igb driver

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  Note: I'm not sure whether this is really a kernel bug or something
  within systemd/udev, please advise how to further debug.

  On a system with two GE ports, instead of getting named eno1 and eno2,
  I am getting eno1 and renameN. Where N starts at 3 and increases by 2
  on every iteration of doing "rmmod igb;modprobe igb". The
  corresponding lines in dmesg look like this:

  [2.748429] igb :07:00.0: added PHC on eth0
  [2.748431] igb :07:00.0: Intel(R) Gigabit Ethernet Network Connection
  [2.748433] igb :07:00.0: eth0: (PCIe:5.0Gb/s:Width x4) 
00:25:90:d7:60:8e
  [2.748505] igb :07:00.0: eth0: PBA No: 106100-000
  [2.748506] igb :07:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
  [2.802555] igb :07:00.1: added PHC on eth1
  [2.802557] igb :07:00.1: Intel(R) Gigabit Ethernet Network Connection
  [2.802559] igb :07:00.1: eth1: (PCIe:5.0Gb/s:Width x4) 
00:25:90:d7:60:8f
  [2.802631] igb :07:00.1: eth1: PBA No: 106100-000
  [2.802632] igb :07:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx 
queue(s)
  [2.803618] igb :07:00.0 eno1: renamed from eth0
  [2.833208] igb :07:00.1 rename3: renamed from eth1

  What is even worse: Sometimes the naming changes and the second
  interface ends up as eno1 while the first interface is named renameN
  with an even N. The bad thing about this version is that when it
  happens while the installer is running, the installer will setup
  "rename2" as the primary network interface, which works fine for the
  installation itself, but after installation is finished and the first
  boot of the installed system happens, that interface will be gone,
  leaving the system without network connectivity.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-21-generic 4.4.0-21.37
  ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
  Uname: Linux 4.4.0-21-generic x86_64
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 May  4 09:48 seq
   crw-rw 1 root audio 116, 33 May  4 09:48 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.1-0ubuntu2
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  Date: Wed May  4 10:00:39 2016
  HibernationDevice: RESUME=/dev/mapper/compute--node37--vg-swap
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Supermicro X9DRT-HF+
  PciMultimedia:
   
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US
   SHELL=/bin/bash
  ProcFB: 0 VESA VGA
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-21-generic 
root=/dev/mapper/compute--node37--vg-root ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-21-generic N/A
   linux-backports-modules-4.4.0-21-generic  N/A
   linux-firmware1.157
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/21/2014
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 3.0c
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: X9DRT-HF+
  dmi.board.vendor: Supermicro
  dmi.board.version: 0123456789
  dmi.chassis.asset.ta

[Touch-packages] [Bug 1564922] Re: Warning messages during package installation

2016-04-12 Thread Dr. Jens Rosenboom 
** Description changed:

- This log is from installing the pre-release packages, but I got the same
- warnings when installing 10.0.5 earlier:
+ When having a custom /usr/sbin/policy-rc.d, there are various warnings
+ during installation, like:
  
  Preparing to unpack 
.../ceph_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  Unpacking ceph (10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201) over 
(10.0.5-0ubuntu1) ...
  Preparing to unpack 
.../ceph-common_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  
- Not sure whether this is a bug in deb-systemd-invoke really.
+ The issue seems to be that deb-systemd-invoke is called with the
+ systemd-type service name, while /usr/sbin/policy-rc.d expects the "old"
+ service name as parameter, e.g. "ceph-mon.service" vs "ceph-mon".

** Description changed:

  When having a custom /usr/sbin/policy-rc.d, there are various warnings
  during installation, like:
  
  Preparing to unpack 
.../ceph_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  Unpacking ceph (10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201) over 
(10.0.5-0ubuntu1) ...
  Preparing to unpack 
.../ceph-common_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  
  The issue seems to be that deb-systemd-invoke is called with the
  systemd-type service name, while /usr/sbin/policy-rc.d expects the "old"
- service name as parameter, e.g. "ceph-mon.service" vs "ceph-mon".
+ service name as parameter, e.g. "ceph-mon.service" vs "ceph-mon":
+ 
+ root@controller-node11:~# /usr/sbin/policy-rc.d ceph-mon start
+ root@controller-node11:~# echo $?
+ 104
+ root@controller-node11:~# /usr/sbin/policy-rc.d ceph-mon.service start
+ root@controller-node11:~# echo $?
+ 100

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1564922

Title:
  Warning messages during package installation

Status in ceph package in Ubuntu:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New

Bug description:
  When having a custom /usr/sbin/policy-rc.d, there are various warnings
  during installation, like:

  Preparing to unpack 
.../ceph_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  Unpacking ceph (10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201) over 
(10.0.5-0ubuntu1) ...
  Preparing to unpack 
.../ceph-common_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.

  The issue seems to be that deb-systemd-invoke is called with the
  systemd-type service name, while /usr/sbin/policy-rc.d expects the
  "old" service name as parameter, e.g. "ceph-mon.service" vs "ceph-
  mon":

  root@controller-node11:~# /usr/sbin/policy-rc.d ceph-mon start
  root@controller-node11:~# echo $?
  104
  root@controller-node11:~# /usr/sbin/policy-rc.d ceph-mon.service start
  root@controller-node11:~# echo $?
  100

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1564922/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1564922] Re: Warning messages during package installation

2016-04-12 Thread Dr. Jens Rosenboom 
I'm now seeing the warnings also in the postinst for dmeventd, so
probably deb-systemd-invoke should be fixed as being the common
denominator.

** Also affects: init-system-helpers (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: ceph (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to init-system-helpers in
Ubuntu.
https://bugs.launchpad.net/bugs/1564922

Title:
  Warning messages during package installation

Status in ceph package in Ubuntu:
  Invalid
Status in init-system-helpers package in Ubuntu:
  New

Bug description:
  This log is from installing the pre-release packages, but I got the
  same warnings when installing 10.0.5 earlier:

  Preparing to unpack 
.../ceph_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.
  Unpacking ceph (10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201) over 
(10.0.5-0ubuntu1) ...
  Preparing to unpack 
.../ceph-common_10.1.0.dfsg-0ubuntu1~ubuntu16.04.1~ppa201603311201_amd64.deb ...
  deb-systemd-invoke only supports /usr/sbin/policy-rc.d return code 101 and 
104!
  Got return code 100, ignoring.

  Not sure whether this is a bug in deb-systemd-invoke really.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1564922/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1564451] Re: User processes are counted towards systemd limit for sshd processes

2016-04-01 Thread Dr. Jens Rosenboom 
Thanks to some help in #systemd I could find the cause: On the affected
systems libpam-systemd was not installed. So maybe it would make sensu
to turn this into a stronger dependency than "recommended", at least in
combination with openssh-server.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1564451

Title:
  User processes are counted towards systemd limit for sshd processes

Status in systemd:
  New
Status in openssh package in Ubuntu:
  New

Bug description:
  When running Xenial, user processes are counted towards the limit for
  the ssh.service, with a limit of 512. So if I login as a normal user
  via ssh and start 512 processes, nobody will be able to login any more
  and even all other users currently logged in will not be able to start
  any new tasks. I'm not certain whether this behaviour is by design,
  but to me it looks like a critical DOS possibility, so tagging as
  security bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1564451/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1564451] Re: User processes are counted towards systemd limit for sshd processes

2016-04-01 Thread Dr. Jens Rosenboom 
Hmm, on a cloud instance this looks different, even when logged in
multiple time, the output only shows the master process:

# systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Fri 2016-04-01 06:00:11 UTC; 1h 44min ago
 Main PID: 971 (sshd)
Tasks: 1 (limit: 512)
   Memory: 5.3M
  CPU: 169ms
   CGroup: /system.slice/ssh.service
   └─971 /usr/sbin/sshd -D

Package versions are identical in both systems:

root@jr-xeni1:~# apt-cache policy systemd
systemd:
  Installed: 229-3ubuntu1
  Candidate: 229-3ubuntu1
  Version table:
 *** 229-3ubuntu1 500
500 http://nova.clouds.archive.ubuntu.com/ubuntu xenial/main amd64 
Packages
100 /var/lib/dpkg/status
root@jr-xeni1:~# apt-cache policy openssh-server
openssh-server:
  Installed: 1:7.2p2-2
  Candidate: 1:7.2p2-2
  Version table:
 *** 1:7.2p2-2 500
500 http://nova.clouds.archive.ubuntu.com/ubuntu xenial/main amd64 
Packages
100 /var/lib/dpkg/status

So I'm wondering what else could be causing the different behaviour
here.


** Also affects: systemd
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1564451

Title:
  User processes are counted towards systemd limit for sshd processes

Status in systemd:
  New
Status in openssh package in Ubuntu:
  New

Bug description:
  When running Xenial, user processes are counted towards the limit for
  the ssh.service, with a limit of 512. So if I login as a normal user
  via ssh and start 512 processes, nobody will be able to login any more
  and even all other users currently logged in will not be able to start
  any new tasks. I'm not certain whether this behaviour is by design,
  but to me it looks like a critical DOS possibility, so tagging as
  security bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1564451/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1564451] Re: User processes are counted towards systemd limit for sshd processes

2016-03-31 Thread Dr. Jens Rosenboom 
Do your sleep processes show up in the output of "systemctl status
ssh.service" in the CGroup section? For me they do (sample with just one
process backgrounded):

# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Fri 2016-04-01 05:53:59 UTC; 1min 1s ago
 Main PID: 2928 (sshd)
Tasks: 10 (limit: 512)
   CGroup: /system.slice/ssh.service
   ├─2928 /usr/sbin/sshd -D
   ├─4966 sshd: jrosenboom [priv
   ├─5087 sshd: jrosenboom@pts/
   ├─5127 -bash
   ├─5208 sudo -i
   ├─5213 sudo -i
   ├─5214 -bash
   ├─6386 sleep 100
   ├─6403 systemctl status ssh.service
   └─6404 pager

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1564451

Title:
  User processes are counted towards systemd limit for sshd processes

Status in openssh package in Ubuntu:
  New

Bug description:
  When running Xenial, user processes are counted towards the limit for
  the ssh.service, with a limit of 512. So if I login as a normal user
  via ssh and start 512 processes, nobody will be able to login any more
  and even all other users currently logged in will not be able to start
  any new tasks. I'm not certain whether this behaviour is by design,
  but to me it looks like a critical DOS possibility, so tagging as
  security bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1564451/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1521613] Re: Default route not installed but received in dhcp offer

2015-12-02 Thread Dr. Jens Rosenboom 
This is the expected behaviour if your DHCP server also specifies a
classless static route, see RFC 3442:

If the DHCP server returns both a Classless Static Routes option and a
Router option, the DHCP client MUST ignore the Router option.

** Changed in: isc-dhcp (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1521613

Title:
  Default route not installed but received in dhcp offer

Status in isc-dhcp package in Ubuntu:
  Invalid

Bug description:
  Hi,

  I am booting the ubuntu cloud image for wily (from 27-Nov-2015 22:04) in an 
openstack enviroment. The system comes up,
  gets an IP via DHCP, but no default route is being installed. A verification 
with dhcpdump shows that open 3, routers contains 1 entry.

  Attached are screenshots from an ifup and from the dhcpdump, if any
  further input is required please let me know.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: isc-dhcp-client 4.3.1-5ubuntu3
  ProcVersionSignature: Ubuntu 4.2.0-18.22-generic 4.2.3
  Uname: Linux 4.2.0-18-generic x86_64
  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
  Date: Tue Dec  1 12:44:14 2015
  DhclientLeases:
   
  Ec2AMI: ami-0009
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  Ec2Kernel: None
  Ec2Ramdisk: None
  ExecutablePath: /sbin/dhclient
  ProcAttrCurrent: /sbin/dhclient (enforce)
  ProcEnviron: PATH=(custom, no user)
  SourcePackage: isc-dhcp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1521613/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1447807] Re: systemctl enable shows error on enabling a SysV service

2015-05-06 Thread Dr. Jens Rosenboom 
Tested and confirmed working, thanks again.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447807

Title:
  systemctl enable shows error on enabling a SysV service

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Vivid:
  In Progress
Status in systemd source package in Wily:
  Fix Committed

Bug description:
  SRU TEST CASE:
  --
  Trying to enable a SysV init service which does not have a corresponding 
systemd unit results in an error:

  # systemctl enable pulseaudio
  Synchronizing state for pulseaudio.service with sysvinit using update-rc.d...
  Executing /usr/sbin/update-rc.d pulseaudio defaults
  Executing /usr/sbin/update-rc.d pulseaudio enable
  Failed to execute operation: No such file or directory

  /etc/init.d/pulseaudio actually does get enabled (check
  /etc/rc*/*pulse*), but the command fails with code 1 and you get that
  error message. With the fix the command succeeds.

  SRU Regression potential
  
  Low, the modes for "sysv script + systemd unit" as well as "systemd unit 
only" already have automatic tests, and now this scenario ("sysv script only") 
has a test too. In the worst case this has the potential of completely breaking 
systemctl enable/disable, which can be worked around with changing symlinks 
manually, and isn't breaking the boot.

  
  Version details:

  Description:  Ubuntu 15.04
  Release:  15.04

  systemd:
    Installed: 219-7ubuntu3
    Candidate: 219-7ubuntu3
    Version table:
   *** 219-7ubuntu3 0
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ vivid/main amd64 
Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447807/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1447807] Re: systemctl enable fails to enable a SysV service

2015-05-06 Thread Dr. Jens Rosenboom 
Thanks for the fast fix, is there already a package built from the patch
somewhere that I could test?

Also you might want to amend the title of the bug, as enabling the
service is in fact performed properly, systemctl just throws an error in
the end when it should simply terminate successfully instead.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447807

Title:
  systemctl enable fails to enable a SysV service

Status in systemd package in Ubuntu:
  Fix Committed
Status in systemd source package in Vivid:
  In Progress
Status in systemd source package in Wily:
  Fix Committed

Bug description:
  SRU TEST CASE:
  --
  Trying to enable a SysV init service which does not have a corresponding 
systemd unit results in an error:

  # systemctl enable pulseaudio
  Synchronizing state for pulseaudio.service with sysvinit using update-rc.d...
  Executing /usr/sbin/update-rc.d pulseaudio defaults
  Executing /usr/sbin/update-rc.d pulseaudio enable
  Failed to execute operation: No such file or directory

  /etc/init.d/pulseaudio actually does get enabled (check
  /etc/rc*/*pulse*), but the command fails with code 1 and you get that
  error message. With the fix the command succeeds.

  SRU Regression potential
  
  Low, the modes for "sysv script + systemd unit" as well as "systemd unit 
only" already have automatic tests, and now this scenario ("sysv script only") 
has a test too. In the worst case this has the potential of completely breaking 
systemctl enable/disable, which can be worked around with changing symlinks 
manually, and isn't breaking the boot.

  
  Version details:

  Description:  Ubuntu 15.04
  Release:  15.04

  systemd:
    Installed: 219-7ubuntu3
    Candidate: 219-7ubuntu3
    Version table:
   *** 219-7ubuntu3 0
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ vivid/main amd64 
Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447807/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1447807] Re: systemctl enable fails to enable a SysV service

2015-05-05 Thread Dr. Jens Rosenboom 
Looking at the source code a bit, I see that in
systemctl.c:enable_sysv_units there is a comment that it should
reshuffle the args array, but it seems it never does that? So
strv_isempty(names) in enable_unit never matches, causing the call to
systemd which is failing, because there is no unit file.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447807

Title:
  systemctl enable fails to enable a SysV service

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Trying to enable a SysV init service results in an error:

  # systemctl enable sysstat
  Synchronizing state for sysstat.service with sysvinit using update-rc.d...
  Executing /usr/sbin/update-rc.d sysstat defaults
  Executing /usr/sbin/update-rc.d sysstat enable
  Failed to execute operation: No such file or directory

  I expected the service to be enabled.

  Version details:

  Description:  Ubuntu 15.04
  Release:  15.04

  systemd:
Installed: 219-7ubuntu3
Candidate: 219-7ubuntu3
Version table:
   *** 219-7ubuntu3 0
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ vivid/main amd64 
Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447807/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1451743] Re: systemctl enable ntp fails with an error

2015-05-05 Thread Dr. Jens Rosenboom 
*** This bug is a duplicate of bug 1447807 ***
https://bugs.launchpad.net/bugs/1447807

** This bug has been marked a duplicate of bug 1447807
   systemctl enable fails to enable a SysV service

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1451743

Title:
  systemctl enable ntp fails with an error

Status in ntp package in Ubuntu:
  New

Bug description:
  root@node10:~# systemctl enable ntp   


   
  Synchronizing state for ntp.service with sysvinit using update-rc.d...
  Executing /usr/sbin/update-rc.d ntp defaults
  Executing /usr/sbin/update-rc.d ntp enable
  Failed to execute operation: No such file or directory
  root@node10:~#

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: ntp 1:4.2.6.p5+dfsg-3ubuntu6
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  Date: Tue May  5 09:24:06 2015
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apparmor.d.usr.sbin.ntpd: [modified]
  modified.conffile..etc.ntp.conf: [modified]
  mtime.conffile..etc.apparmor.d.usr.sbin.ntpd: 2015-05-05T08:45:35.134023
  mtime.conffile..etc.ntp.conf: 2015-05-05T08:45:35.170023

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1451743/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1447807] Re: systemctl enable fails to enable a SysV service

2015-05-05 Thread Dr. Jens Rosenboom 
I wouldn't agree that this is purely cosmetical, as it breaks things
like Chef automation: https://github.com/gmiranda23/ntp/issues/105

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1447807

Title:
  systemctl enable fails to enable a SysV service

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Trying to enable a SysV init service results in an error:

  # systemctl enable sysstat
  Synchronizing state for sysstat.service with sysvinit using update-rc.d...
  Executing /usr/sbin/update-rc.d sysstat defaults
  Executing /usr/sbin/update-rc.d sysstat enable
  Failed to execute operation: No such file or directory

  I expected the service to be enabled.

  Version details:

  Description:  Ubuntu 15.04
  Release:  15.04

  systemd:
Installed: 219-7ubuntu3
Candidate: 219-7ubuntu3
Version table:
   *** 219-7ubuntu3 0
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ vivid/main amd64 
Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447807/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1451797] Re: rc.local should require network-online.target

2015-05-05 Thread Dr. Jens Rosenboom 
While I agree that this may never have been guaranteed, it has been
working with all previous init systems. For me, the implied policy of
using rc.local is: Run after all other init stuff has finished.

For example, https://github.com/puppetlabs/razor-server uses modifying
rc.local in order to trigger some post installation actions to happen
once the node has rebooted after being installed. This works pretty well
with Precise and Trusty and also seems to be fine with most other
distros.

Also, having a server with no network connectivity ever will also not be
very useful. This is certainly different for desktop systems, but then,
why would you have the

After=network.target

at all?

** Changed in: systemd (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1451797

Title:
  rc.local should require network-online.target

Status in systemd package in Ubuntu:
  New

Bug description:
  The current definition in `/lib/systemd/system/rc-local.service` uses
  `After=network.target`, which is pretty useless, as `network.target`
  according to
  http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ only
  has relevance during shutdown, which never happens for rc.local.

  The result is that tasks in rc.local may get started before the
  network is properly setup, which may cause them to fail, as this is a
  significant change from the old SysV init behaviour.

  The solution would be to change the dependency to

  Wants=network-online.target
  After=network-online.target

  see also the notes in
  http://www.freedesktop.org/software/systemd/man/systemd.special.html
  for that.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu4 [modified: lib/systemd/system/rc-local.service]
  ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
  Uname: Linux 3.19.0-16-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  Date: Tue May  5 11:40:42 2015
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Supermicro X9DRT
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-16-generic 
root=/dev/mapper/hostname--vg-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/04/2012
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.0c
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: X9DRT
  dmi.board.vendor: Supermicro
  dmi.board.version: 1.21
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: Supermicro
  dmi.chassis.version: 0123456789
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.0c:bd05/04/2012:svnSupermicro:pnX9DRT:pvr0123456789:rvnSupermicro:rnX9DRT:rvr1.21:cvnSupermicro:ct3:cvr0123456789:
  dmi.product.name: X9DRT
  dmi.product.version: 0123456789
  dmi.sys.vendor: Supermicro

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451797/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1451797] [NEW] rc.local should require network-online.target

2015-05-05 Thread Dr. Jens Rosenboom 
Public bug reported:

The current definition in `/lib/systemd/system/rc-local.service` uses
`After=network.target`, which is pretty useless, as `network.target`
according to
http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ only has
relevance during shutdown, which never happens for rc.local.

The result is that tasks in rc.local may get started before the network
is properly setup, which may cause them to fail, as this is a
significant change from the old SysV init behaviour.

The solution would be to change the dependency to

Wants=network-online.target
After=network-online.target

see also the notes in
http://www.freedesktop.org/software/systemd/man/systemd.special.html for
that.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-7ubuntu4 [modified: lib/systemd/system/rc-local.service]
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
Date: Tue May  5 11:40:42 2015
Lsusb:
 Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Supermicro X9DRT
ProcEnviron:
 LANGUAGE=en_US:
 TERM=screen
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-16-generic 
root=/dev/mapper/hostname--vg-root ro quiet splash vt.handoff=7
SourcePackage: systemd
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/04/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.0c
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X9DRT
dmi.board.vendor: Supermicro
dmi.board.version: 1.21
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 0123456789
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr1.0c:bd05/04/2012:svnSupermicro:pnX9DRT:pvr0123456789:rvnSupermicro:rnX9DRT:rvr1.21:cvnSupermicro:ct3:cvr0123456789:
dmi.product.name: X9DRT
dmi.product.version: 0123456789
dmi.sys.vendor: Supermicro

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug systemd-boot vivid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1451797

Title:
  rc.local should require network-online.target

Status in systemd package in Ubuntu:
  New

Bug description:
  The current definition in `/lib/systemd/system/rc-local.service` uses
  `After=network.target`, which is pretty useless, as `network.target`
  according to
  http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ only
  has relevance during shutdown, which never happens for rc.local.

  The result is that tasks in rc.local may get started before the
  network is properly setup, which may cause them to fail, as this is a
  significant change from the old SysV init behaviour.

  The solution would be to change the dependency to

  Wants=network-online.target
  After=network-online.target

  see also the notes in
  http://www.freedesktop.org/software/systemd/man/systemd.special.html
  for that.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: systemd 219-7ubuntu4 [modified: lib/systemd/system/rc-local.service]
  ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
  Uname: Linux 3.19.0-16-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  Date: Tue May  5 11:40:42 2015
  Lsusb:
   Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
   Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Supermicro X9DRT
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-16-generic 
root=/dev/mapper/hostname--vg-root ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/04/2012
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 1.0c
  dmi.board.asset.tag: To be filled by O.E.M.
  dmi.board.name: X9DRT
  dmi.board.vendor: Supermicro
  dmi.board.version: 1.21
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: Supermicro
  dmi.chassis.version: 0123456789
  dmi.modalias:

[Touch-packages] [Bug 1451743] [NEW] systemctl enable ntp fails with an error

2015-05-05 Thread Dr. Jens Rosenboom 
Public bug reported:

root@node10:~# systemctl enable ntp 


 
Synchronizing state for ntp.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d ntp defaults
Executing /usr/sbin/update-rc.d ntp enable
Failed to execute operation: No such file or directory
root@node10:~#

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: ntp 1:4.2.6.p5+dfsg-3ubuntu6
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
Date: Tue May  5 09:24:06 2015
ProcEnviron:
 LANGUAGE=en_US:
 TERM=screen
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ntp
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.apparmor.d.usr.sbin.ntpd: [modified]
modified.conffile..etc.ntp.conf: [modified]
mtime.conffile..etc.apparmor.d.usr.sbin.ntpd: 2015-05-05T08:45:35.134023
mtime.conffile..etc.ntp.conf: 2015-05-05T08:45:35.170023

** Affects: ntp (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug systemd-boot vivid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1451743

Title:
  systemctl enable ntp fails with an error

Status in ntp package in Ubuntu:
  New

Bug description:
  root@node10:~# systemctl enable ntp   


   
  Synchronizing state for ntp.service with sysvinit using update-rc.d...
  Executing /usr/sbin/update-rc.d ntp defaults
  Executing /usr/sbin/update-rc.d ntp enable
  Failed to execute operation: No such file or directory
  root@node10:~#

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: ntp 1:4.2.6.p5+dfsg-3ubuntu6
  ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
  Uname: Linux 3.19.0-15-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1
  Architecture: amd64
  Date: Tue May  5 09:24:06 2015
  ProcEnviron:
   LANGUAGE=en_US:
   TERM=screen
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.apparmor.d.usr.sbin.ntpd: [modified]
  modified.conffile..etc.ntp.conf: [modified]
  mtime.conffile..etc.apparmor.d.usr.sbin.ntpd: 2015-05-05T08:45:35.134023
  mtime.conffile..etc.ntp.conf: 2015-05-05T08:45:35.170023

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1451743/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp