from:"Paul Menzel"

[systemd-devel] Docker, Supervisor and systemd

2014-02-20 Thread Paul Menzel

Dear systemd folks,


Docker, “an open-source project to easily create lightweight, portable,
self-sufficient containers from any application”, [1] mostly recommends
to use Supervisor [2] to control the processes to be run in the
container, like starting and restarting them and logging the output.
Actually all things systemd also does to my knowledge. Supervisor also
needs a configuration file for each process, which it should start.

Has somebody experiences to use systemd for that? Or is there a reason
why systemd should not be used for that?


Thanks,

Paul


[1] https://www.docker.io/
[2] http://supervisord.org/


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Starting CUPS very late on a desktop and non-server system

2014-02-20 Thread Paul Menzel

Dear systemd folks,


after Debian’s CTTE chose systemd as the default init system for the
next Debian release, I installed it on one of the systems.

Looking at the output `systemd-analyze plot`, I noticed that CUPS takes
700 ms to start and as this is a desktop system where not a lot is
printed and when, then only after the user has logged in, I wonder how
that can be dealt with systemd. Like starting it only after user login?
Or is that something which is not nicely doable because CUPS runs as a
system daemon?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting CUPS very late on a desktop and non-server system

2014-02-25 Thread Paul Menzel

Dear Michael,


thank you for your answer.


Am Freitag, den 21.02.2014, 00:21 +0100 schrieb Michael Biebl:
 This might be of interest to you:
 http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-February/001433.html
 
 So, the cups maintainer is already looking into this. It has to be
 said CUPS is not the most trivial wrt proper systemd support.

Indeed, that addresses my question. Updating to CUPS package 1.7.1-6,
which includes these changes, `systemd-analyze plot` suggests that
`cups-browsed.service` now only takes 33 ms.

The whole user space supposedly takes around 1.5 s, which I hope will
improve even further in the future. Though the “experienced” time,
meaning until GDM’s login screen was there, was around five seconds.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] src/util.h: include `stdarg.h`

2011-05-02 Thread Paul Menzel

Am Montag, den 02.05.2011, 19:26 +0200 schrieb Lennart Poettering:
 On Mon, 02.05.11 18:33, Paul Menzel (paulepan...@users.sourceforge.net) wrote:
 
  Date: Mon, 2 May 2011 14:13:08 +0200
  
  Otherwise using uClibc compilation (OpenEmbedded [1] with
  `minimal-uclibc` for `MACHINE = beagleboard`) fails with the
  following error message.
 
  --- a/src/util.h
  +++ b/src/util.h
  @@ -25,6 +25,7 @@
   #include inttypes.h
   #include time.h
   #include sys/time.h
  +#include stdarg.h
   #include stdbool.h
   #include stdlib.h
   #include stdio.h
 
 Hmm, this should be enough to include in util.c, not util.h, right?
 
 Normally I'd say that it is uclibc's job to ensure compat with
 glibc. But in this case I think it actually makes sense to include this,
 because we do use va_xxx and friends in util.c.
 
 Can you rework and test the patch if you include this in util.c rather
 then util.h? I'd be willing to merge such a patch then.

I tried adding it just to `util.c` and it did not fix the problem.
Unfortunately I do not know what uClibc expects. I only know using
EGLIBC and the same tool chain does not show this problem.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] src/util.h: include `stdarg.h`

2011-05-09 Thread Paul Menzel

Am Dienstag, den 03.05.2011, 00:39 +0200 schrieb Kay Sievers:
 On Tue, May 3, 2011 at 00:20, Paul Menzel wrote:
  Am Montag, den 02.05.2011, 19:26 +0200 schrieb Lennart Poettering:
  Hmm, this should be enough to include in util.c, not util.h, right?
 
  I tried adding it just to `util.c` and it did not fix the problem.
  Unfortunately I do not know what uClibc expects. I only know using
  EGLIBC and the same tool chain does not show this problem.
 
 Guess we need it util.h as the prototypes use it:
   void status_vprintf(const char *format, va_list ap);
 and it's not type that the compiler could guess.

Sounds reasonable. Lennart, could you please commit the patch.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] user space boot time 1s (was: Parallel startup with sockets and without killing the machine?)

2011-05-09 Thread Paul Menzel

Am Montag, den 09.05.2011, 20:04 +0200 schrieb Lennart Poettering:

[…]

 We can now boot a reasonably complete GNOME userspace in less than
 1s.

Is there a demo image for that? What are the hardware specs?

Will you be on the LinuxTag? coreboot will be demoing systems, e. g.,
Lenovo X60/T60, where hardware initialization is also done in less than
one second [1]. Maybe we could demo a system with less than two seconds
from button push to a GNOME system? That would be good publicity.

[…]


Thanks,

Paul


[1] http://www.coreboot.org/pipermail/coreboot/2011-May/064913.html


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user space boot time 1s

2011-05-09 Thread Paul Menzel

Am Montag, den 09.05.2011, 22:17 +0200 schrieb Lennart Poettering:
 On Mon, 09.05.11 21:29, Paul Menzel (paulepan...@users.sourceforge.net) wrote:
 
  Am Montag, den 09.05.2011, 20:04 +0200 schrieb Lennart Poettering:
  
  […]
  
   We can now boot a reasonably complete GNOME userspace in less than
   1s.
  
  Is there a demo image for that? What are the hardware specs?
 
 No image. Measured on Kay's X300 (a few years old) with SSD, a few weeks
 ago. It's a OpenSUSE with a number of fixes and cleanups.

Well, maybe Kay still has that image and can share it or even plug in
his SSD.

 Note that these results are fluctuating. i.e. you won't get the exact
 same results on each boot. Also: by bringing up userspace I was simply
 referring to the time systemd spends doing that. What the services still
 do is ignored by this value. it's just that systemd goes idle, and its
 queues are empty and fully dispatched.

Understood.

  Will you be on the LinuxTag? coreboot will be demoing systems, e. g.,
  Lenovo X60/T60, where hardware initialization is also done in less than
  one second [1]. Maybe we could demo a system with less than two seconds
  from button push to a GNOME system? That would be good publicity.
 
 I'll be at LinuxTag, I live in Berlin.

I heard rumors about that. ;-)

 But quite frankly I won't have the time to do spend time on that, sorry.

Surely you will come by for a few minutes to see with your own eyes what
you hear from all the visitors about that awesome user experience at the
coreboot booth. ;-) We want to take a picture with you and get a short
comment for a press release of one of the main systemd developers saying
how awesome coreboot is (you can mention systemd of course). ;-)


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] minimal-uclibc: systemd fails with `src/manager.c:257:42: error: 'EPOLL_CLOEXEC' undeclared (first use in this function)`

2011-05-10 Thread Paul Menzel

Dear OE folks,


task compile of `systemd_git.bb` fails with the following error message
using `minimal-uclibc` for `MACHINE = beagleboard`. Using `minimal`,
i. e. EGLIBC, works.

[…]
|   CC src/libsystemd_core_la-manager.lo
| src/manager.c: In function 'manager_new':
| src/manager.c:257:9: warning: implicit declaration of function 
'epoll_create1' [-Wimplicit-function-declaration]
| src/manager.c:257:42: error: 'EPOLL_CLOEXEC' undeclared (first use in 
this function)
| src/manager.c:257:42: note: each undeclared identifier is reported 
only once for each function it appears in
| src/manager.c: In function 'manager_process_notify_fd':
| src/manager.c:1956:25: warning: cast increases required alignment of 
target type [-Wcast-align]
[…]

`manager.c` includes

#include sys/epoll.h
#include fcntl.h

which I read should contain that definition. But looking at `fcntl.h` I
could not find it. I then looked in


./minimal-uclibc-dev/sysroots/armv7a-oe-linux-uclibceabi/usr/include/sys/epoll.h

where it is defined for EGLIBC but not for uClibc. I also found the
patch for uClibc [1] but there `EPOLL_CLOEXEC` is enclosed in `#if 0`.

I am no uClibc expert, but do you know if uClibc will provide
`EPOLL_CLOEXEC` in the near future? How should systemd fix that?

Please find attached a patch updating systemd to a newer including a
commit fixing another problem with systemd and uClibc.


Thanks,

Paul


[1] http://lists.uclibc.org/pipermail/uclibc-cvs/2011-March/028879.html
From a135d73cfc7f4c0eb8da344d5bf0d49668ffdbf9 Mon Sep 17 00:00:00 2001
From: Paul Menzel paulepan...@users.sourceforge.net
Date: Tue, 10 May 2011 09:19:02 +0200
Subject: [PATCH] systemd: bump srcrev
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

• better uClibc support [1], but still fails in `src/manager.c`
• Ȧngström support merged upstream [2]

Still needs native docbook-xsl which is not available in OE.

[1] http://cgit.freedesktop.org/systemd/commit/?id=ec2002f84928c0b5921a961cb2b8637563f29daa
[2] http://cgit.freedesktop.org/systemd/commit/?id=1bd8b8184ee3bc7fc023d6d6dfb2ca99fb6612f3

Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
 .../systemd-v26/0003-Angstrom-support.patch|  165 
 recipes/systemd/systemd_git.bb |3 +-
 2 files changed, 1 insertions(+), 167 deletions(-)
 delete mode 100644 recipes/systemd/systemd-v26/0003-Angstrom-support.patch

diff --git a/recipes/systemd/systemd-v26/0003-Angstrom-support.patch b/recipes/systemd/systemd-v26/0003-Angstrom-support.patch
deleted file mode 100644
index c75cee4..000
--- a/recipes/systemd/systemd-v26/0003-Angstrom-support.patch
+++ /dev/null
@@ -1,165 +0,0 @@
-From 0fa5b59c5f484c80453e9d3201b87e4253f8bec3 Mon Sep 17 00:00:00 2001
-From: Koen Kooi k...@dominion.thruhere.net
-Date: Thu, 5 May 2011 17:15:41 +0200
-Subject: [PATCH 3/3] Angstrom support
-
-This commit consists of the initial work to include Angstrom as a ported
-distribution for systemd.
-
-Angstrom tries to follow the debian way as much as possible, but deviates
-where it doesn't make sense for 'embedded'.
-
-Signed-off-by: Koen Kooi k...@dominion.thruhere.net

- Makefile.am|7 +++
- configure.ac   |7 +++
- src/locale-setup.c |2 +-
- src/service.c  |   10 +-
- src/util.c |   12 
- 5 files changed, 32 insertions(+), 6 deletions(-)
-
-diff --git a/Makefile.am b/Makefile.am
-index 49d2ee8..f3f7818 100644
 a/Makefile.am
-+++ b/Makefile.am
-@@ -96,6 +96,12 @@ AM_CPPFLAGS += \
- 	-DKBD_SETFONT=\/bin/setfont\ \
- 	-DDEFAULT_FONT=\LatArCyrHeb-16\
- else
-+if TARGET_ANGSTROM
-+AM_CPPFLAGS += \
-+	-DKBD_LOADKEYS=\/usr/bin/loadkeys\ \
-+	-DKBD_SETFONT=\/usr/bin/setfont\ \
-+	-DDEFAULT_FONT=\LatArCyrHeb-16\
-+else
- AM_CPPFLAGS += \
- 	-DKBD_LOADKEYS=\/bin/loadkeys\ \
- 	-DKBD_SETFONT=\/bin/setfont\ \
-@@ -105,6 +111,7 @@ endif
- endif
- endif
- endif
-+endif
- 
- rootbin_PROGRAMS = \
- 	systemd \
-diff --git a/configure.ac b/configure.ac
-index dcd4b9d..b5b7ac3 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -295,6 +295,7 @@ if test z$with_distro = z; then
- test -f /etc/altlinux-release  with_distro=altlinux
- test -f /etc/mandriva-release  with_distro=mandriva
- test -f /etc/meego-release  with_distro=meego
-+test -f /etc/angstrom-version  with_distro=angstrom
- if test x`lsb_release -is 2/dev/null` = xUbuntu; then
- with_distro=ubuntu
- fi
-@@ -375,6 +376,11 @@ case $with_distro in
- AC_DEFINE(TARGET_MEEGO, [], [Target is MeeGo])
- M4_DISTRO_FLAG=-DTARGET_MEEGO=1
- 		;;
-+angstrom)
-+SYSTEM_SYSVRCND_PATH=/etc
-+AC_DEFINE(TARGET_ANGSTROM, [], [Target is Ångström

Re: [systemd-devel] minimal-uclibc: systemd fails with `src/manager.c:257:42: error: 'EPOLL_CLOEXEC' undeclared (first use in this function)`

2011-05-10 Thread Paul Menzel

Dear systemd folks,


I am sorry for this message. I first wanted it to send to systemd-devel
but decided to send it to openembedded-devel instead and forgot to
update the address. If you have any insight though it is most welcome.


Thanks,

PAul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add the most common consoles that MeeGo needs

2011-07-01 Thread Paul Menzel

Dear Chris,


please just post plain text messages (and no HTML) to lists [1].

Am Freitag, den 01.07.2011, 09:19 -0700 schrieb Chris Ferron:
 MeeGo will use several consoles depending on the hardware adaptations.
 This patch adds the most common to the serial-getty unit Install section 
 so when systemd is built for MeeGo as its distribution, you get the most 
 common Aliased for installation by the user.

Why don’t you use that as a commit message?

  From c50559ea74069061401c8a218d73d515d7b9cd09 Mon Sep 17 00:00:00 2001
 From: Chris Ferron chris.e.fer...@linux.intel.com
 Date: Fri, 1 Jul 2011 08:54:37 -0700
 Subject: [PATCH] Add the most common consoles that MeeGo as a distribution
   will need.

Please turn of line breaks when pasting stuff. You can also use `git
send-email` to send patches.

 ---
   units/serial-getty@.service.m4 |9 +
   1 files changed, 9 insertions(+), 0 deletions(-)
 
 diff --git a/units/serial-getty@.service.m4 b/units/serial-getty@.service.m4
 index 082290c..aea47be 100644
 --- a/units/serial-getty@.service.m4
 +++ b/units/serial-getty@.service.m4
 @@ -9,6 +9,9 @@
   Description=Serial Getty on %I
   BindTo=dev-%i.device
   After=dev-%i.device systemd-user-sessions.service 
 plymouth-quit-wait.service
 +m4_ifdef(`TARGET_MEEGO',
 +After=dev-%i.device systemd-user-sessions.service
 +)m4_dnl
   m4_ifdef(`TARGET_FEDORA',
   After=rc-local.service
   )m4_dnl
 @@ -44,3 +47,9 @@ KillMode=process
   # Some login implementations ignore SIGTERM, so we send SIGHUP
   # instead, to ensure that login terminates cleanly.
   KillSignal=SIGHUP
 +
 +m4_ifdef(`TARGET_MEEGO',
 +[Install]
 +Alias=sysinit.target.wants/serial-getty@ttyS0.service 
 sysinit.target.wants/serial-getty@ttyS1.service 
 sysinit.target.wants/serial-getty@tty01.service 
 sysinit.target.wants/serial-getty@ttyO2.service
 +)m4_dnl
 +

Unnecessary line at the end?

Are such customization wanted upstream or are there other ways to
implement that? I would imagine this becomes very complex if every
distribution starts adding such things.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC][PATCH v2] analyze: draw kernel and initrd boot time as well

2011-09-26 Thread Paul Menzel

Am Montag, den 26.09.2011, 14:34 +0200 schrieb Kay Sievers:
 On Sun, Sep 25, 2011 at 20:41, Koen Kooi k...@dominion.thruhere.net wrote:
  Sample output without initrd: 
  http://dominion.thruhere.net/koen/angstrom/systemd/omap4430-panda-201109221422.svg
 
  Signed-off-by: Koen Kooi k...@dominion.thruhere.net
  ---
 
  Second attempt at this, please check the logic in this patch, a quick test 
  on F15 looks OK, but I'd like more datapoints from initrd users.
 
 Looks a bit wrong. The initramfs bar should end when systemd starts,
 and the overall length should not exceed systemd's finish time.
 
 Mangled your patch a bit. Added a 3rd userspace bar, made them all
 grey. Renamed initrd to initramfs, because initramdisks do not exist
 since many years.
 
 Output is here:
   http://people.freedesktop.org/~kay/f16.svg
 
 Please check.

Does the grey userspace bar have to end as the last of the processes(?)
below. I am not sure if it is an illusion, but it does not look like
that.

The 4 s mark would be nice to have.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD

2012-05-22 Thread Paul Menzel

Dear systemd folks,


hopefully it is alright to report my findings here. If you have any
suggestions to improve the startup time, please do not hesitate to tell
me. ;-)

Hardware

• ASRock E350M1 with dual core 1.6 GHz Fusion CPU [1]
• Crucial m4 SSD connected via SATA-3-cable [2]
• one Ext4 partition

Software

• default Debian Sid/unstable installed using `grml-debootstrap` and
Grml live system
• `aptitude purge mdadm lvm2`
• `aptitude install systemd` (version 44-1)
• `linux-image-3.2.0-2-amd64` (version 3.2.17-1)

Results
===
1. Passing `init=/bin/systemd` to the Linux kernel command line the GDM
3 login screen showed up noticeably faster.

2. GDM 3 did not list the available users though, which had to be
entered manually. After logging out again users are displayed fine.

3. Systemd says start up took 7.5 seconds.

$ systemd-analyze
Startup finished in 4077ms (kernel) + 3390ms (userspace) =
7468ms

4. All units take less than a second to start.

$ systemd-analyze blame
   948ms avahi-daemon.service
   729ms postfix.service
   656ms rsyslog.service
   632ms systemd-logind.service
   559ms console-kit-log-system-start.service
   523ms bootlogs.service
   520ms chrony.service
   467ms udev.service
   451ms rc.local.service
   436ms loadcpufreq.service
   427ms keymap.service
   424ms ssh.service
   396ms cron.service
   388ms dev-mqueue.mount
   367ms systemd-modules-load.service
   360ms sys-kernel-debug.mount
   340ms udev-trigger.service
   327ms systemd-sysctl.service
   324ms dev-hugepages.mount
   296ms sys-kernel-security.mount
   281ms network-manager.service
   279ms saned.service
   279ms systemd-user-sessions.service
   277ms gdm3.service
   264ms media.mount
   247ms systemd-remount-api-vfs.service
   215ms pppd-dns.service
   211ms resolvconf.service
   199ms systemd-tmpfiles-setup.service
   195ms screen-cleanup.service
   191ms kbd.service
   159ms networking.service
   151ms console-setup.service
   147ms pulseaudio.service
   143ms cpufrequtils.service
91ms hdparm.service
91ms mountoverflowtmp.service
88ms keyboard-setup.service
87ms sysfsutils.service
87ms debian-fixup.service
59ms remount-rootfs.service
59ms colord-sane.service
56ms console-kit-daemon.service
48ms colord.service
44ms polkitd.service
31ms accounts-daemon.service
26ms upower.service
22ms udisks.service
19ms boot-efi.mount
13ms rtkit-daemon.service

5. Also I experience the sudo issue [3].

Conclusions
===
1. I should follow the optimization suggestions in the systemd Wiki [4].

2. Improving loading time of the Linux kernel should be my priority
right now. With four seconds it take more than half of the total Debian
startup time. I would not have expected that.

I guess I need to use `bootchart` to check if the long time is due to
the slow 1.6 GHz dual Fusion CPU or if the storage is not set up
correctly.

3. It will be interesting if GNOME 3.4 will speed up things too as
mentioned in the Wiki [4]. Currently `gnome-shell` 3.2.2.1-4+b1 is
installed.


Thank you very much for this promising piece of software,

Paul


[1] http://www.asrock.com/mb/overview.asp?Model=E350M1
[2] http://www.crucial.com/store/partspecs.aspx?imodule=CT256M4SSD2
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667470
[4] http://freedesktop.org/wiki/Software/systemd/Optimizations


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] OT: Races with GDM3 and accountsservice

2012-05-23 Thread Paul Menzel

Am Dienstag, den 22.05.2012, 23:48 +0200 schrieb Paul Menzel:
 Am Dienstag, den 22.05.2012, 18:41 +0200 schrieb Michael Biebl:
  2012/5/22 Paul Menzel paulepan...@users.sourceforge.net:
   2. GDM 3 did not list the available users though, which had to be
   entered manually. After logging out again users are displayed fine.
  
  The user list is populated via accountsservice.
  A D-Bus activated system service. accounts-daemon.service shows up in
  your list above. So I'm wondering if there is genuine bug / race in
  the way gdm interacts with accountsdaemon.
 
 It looks like a race. The next two system starts the user list was
 correctly populated and now it is not populated again.

After the third boot it worked too, but after the fourth it failed
again.

I do not know where to look for causes for this problem. I just found
the following.

# less /var/log/gdm3/\:0-greeter.log
gnome-session[951]: WARNING: Failed to start app: Unable to start 
application: Kindprozess »gnome-power-manager« konnte nicht ausgeführt werden 
(Datei oder Verzeichnis nicht gefunden)
Gtk-Message: Failed to load module atk-bridge
gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook
gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook
gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook
gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook
gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook
gdm-simple-greeter[1138]: Gtk-WARNING: 
/tmp/buildd/gtk+3.0-3.4.2/./gtk/gtkwidget.c:7117: widget not within a GtkWindow
gdm-simple-greeter[1138]: Gtk-CRITICAL: 
gtk_widget_get_preferred_height_for_width: assertion `width = 0' failed
gdm-simple-greeter[1138]: Gtk-CRITICAL: 
gtk_widget_get_preferred_height_for_width: assertion `width = 0' failed
gdm-simple-greeter[1138]: Gtk-WARNING: gtk_widget_size_allocate(): 
attempt to allocate widget with width -47 and height -47
Warnung der Fensterverwaltung:Buggy client sent a _NET_ACTIVE_WINDOW 
message with a timestamp of 0 for 0x107 (Anmeldefen)
Warnung der Fensterverwaltung:meta_window_activate called by a pager 
with a 0 timestamp; the pager needs to be fixed.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] man/systemctl.xml: Add missing space for »stopcommand«

2012-05-24 Thread Paul Menzel

Date: Thu, 24 May 2012 22:20:39 +0200

---
I do not know if that has been fixed already.

$ git remote update
Fetching origin
fatal: The remote end hung up unexpectedly
error: Could not fetch origin

with `url = git://anongit.freedesktop.org/systemd`.

 man/systemctl.xml |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/systemctl.xml b/man/systemctl.xml
index 2ea6fe9..9c9d2fe 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -697,7 +697,7 @@
 command does not implicitly stop the
 units that is being disabled. If this
 is desired an additional
-commandstop/commandcommand should
+commandstop/command command should
 be executed afterwards./para
 
 paraThis command will print the
-- 
1.7.10


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] man/systemctl.xml: Add missing space for »stopcommand«

2012-05-29 Thread Paul Menzel

Am Donnerstag, den 24.05.2012, 22:29 +0200 schrieb Paul Menzel:
 Date: Thu, 24 May 2012 22:20:39 +0200
 
 ---
 I do not know if that has been fixed already.
 
 $ git remote update
 Fetching origin
 fatal: The remote end hung up unexpectedly
 error: Could not fetch origin
 
 with `url = git://anongit.freedesktop.org/systemd`.

It was updated to `git://anongit.freedesktop.org/systemd/systemd` I
guess.

  man/systemctl.xml |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/man/systemctl.xml b/man/systemctl.xml
 index 2ea6fe9..9c9d2fe 100644
 --- a/man/systemctl.xml
 +++ b/man/systemctl.xml
 @@ -697,7 +697,7 @@
  command does not implicitly stop the
  units that is being disabled. If this
  is desired an additional
 -commandstop/commandcommand should
 +commandstop/command command should
  be executed afterwards./para
  
  paraThis command will print the

This patch was not committed yet. Hopefully Lennart or Kay can push it.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd prevents pulseaudio from shutting down

2012-06-03 Thread Paul Menzel

Dear Robert,


Am Sonntag, den 03.06.2012, 11:35 +0200 schrieb Robert Buhren:

 i'm using ecryptfs to encrypt my home directory and pam_mount to 
 have it automatically
 mounted/unmounted at login/logout. The unmounting never worked and i 
 discoverd that a pulseaudio process of my user was keept running 
 although my user was already logged out. This process had some files 
 opened  in ~./pulse which is why i think my home dir is not unmounted.
 The only client that was accessing my pulseaudio process was the module 
 systemd-login.c
 
 [pulseaudio] main.c: 1 client(s) logged in.
 [pulseaudio] main.c: index: 0
 [pulseaudio] main.c: driver: module-systemd-login.c
 [pulseaudio] main.c: owner module: 19
 [pulseaudio] main.c: properties:
 [pulseaudio] main.c: application.name = Login Session 2
 [pulseaudio] main.c: systemd-login.session = 2
 
 I already tried using KillUserProcesses=yes in logind.conf,to to 
 have systemd kill all user process on logout, but it didn't help.
 
 So is it true that systemd keeps my pusleaudio alive? If so how can i 
 avoid that? And is this behavior intended?

I will not be able to help you, but you can give more information. What
distribution do you use? What version of Linux, PulseAudio, systemd?
Maybe even attach the PulseAudio’s unit file for reference.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Different bootchart versions (was: systemd-udevd: excessive I/O usage)

2012-06-05 Thread Paul Menzel

Dear Auke,


Am Montag, den 04.06.2012, 13:02 -0700 schrieb Kok, Auke-jan H:
 On Mon, Jun 4, 2012 at 12:49 PM, Peeters Simon peeters.si...@gmail.com 
 wrote:

  while trying to optimize my bootup i noted that i could not squeeze it
  under 17seconds userspace
 
  Looking at the bootchart revealed that this is mainly due to
  systemd-udevd consuming 60% of my bootup I/O.
  This means i lose 12 seconds of bootup just to one process.
 
 can you post the bootchart SVG file?
 
 I'm assuming you're using this version of bootchart:
 
 http://foo-projects.org/~sofar/bootchart/bootchart-1.18.tar.gz

looking at Debian there are two packages.

$ LANG=C aptitude show bootchart bootchart2
Package: bootchart   
State: installed
Automatically installed: yes
Version: 0.10~svn407-3.3
Priority: optional
Section: admin
Maintainer: J??rg Sommer jo...@alea.gnuu.de
Architecture: all
Uncompressed Size: 135 k
Depends: psmisc, lsb-base (= 3.0-6)
Recommends: bootchart-view, acct
Description: Boot process performance analyser
 Bootchart is a tool for performance analysis and visualization of the 
GNU/Linux boot process. Resource utilization and process information
 are collected during the boot process and are later rendered in a PNG, 
SVG or EPS encoded chart. 
 
 You can render the data with bootchart-view or at 
http://www.bootchart.org/download.html
Homepage: http://www.bootchart.org/

Package: bootchart2
New: yes
State: not installed
Version: 0.14.2-1
Priority: optional
Section: utils
Maintainer: David Paleino da...@debian.org
Architecture: i386
Uncompressed Size: 126 k
Depends: libc6 (= 2.4)
Recommends: pybootchartgui
Conflicts: bootchart
Description: boot process performance analyser
 bootchart2 is a boot process performance analyser: a tool that lets 
you collect and analyse data from your boot process. bootchart2 origins
 from bootchart, and has some advantages over it: 
 
 * more detailed kernel charting: uses the taskstats interface, instead 
of /proc/*/stat 
 * the data collector has been rewritten to make it faster 
   
 After the boot, you can view the logged data with a 
separately-provided GUI.
Homepage: http://github.com/mmeeks/bootchart

Could you clarify the relation between the version you meantioned [1]
and bootchart2 maintained by Michael Meeks [1]? That would be awesome.

[…]


Thanks,

Paul


[1] http://foo-projects.org/~sofar/bootchart/
[2] http://github.com/mmeeks/bootchart


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unit file for motd (message of the day) (was: Trying systemd with Debian Sid/unstable on ASRock E350M1 with Crucial m4 SSD)

2012-06-10 Thread Paul Menzel

Dear systemd folks,


Am Dienstag, den 22.05.2012, 11:06 +0200 schrieb Paul Menzel:

[…]

 4. All units take less than a second to start.
 
 $ systemd-analyze blame
948ms avahi-daemon.service
729ms postfix.service
656ms rsyslog.service
632ms systemd-logind.service
559ms console-kit-log-system-start.service
523ms bootlogs.service

[…]

in Debian the init.d script bootlogs was split up and a separate init.d
script `motd` was created [1].

sysvinit (2.88dsf-24) experimental; urgency=low

  [ Roger Leigh ]
  * initscripts:
- Don't generate or touch /etc/motd.  Instead, the dynamic part of
  /etc/motd is created as /run/motd.dynamic, leaving /etc/motd
  entirely under the control of the system administrator.  If
  /etc/motd is a symlink to /run/motd, /etc/motd.tail is moved
  back to /etc/motd.  Closes: #353229, #624391, #668307.  /etc/motd
  is not removed if initscripts is purged, since it's not owned by
  initscripts.
- By default, /run/motd is just the output of uname, preserving the
  existing behaviour.  However, should the administrator wish to
  include dynamic information in the motd, they may write scripts
  to update /run/motd.dynamic as they please.  Closes: #437176.
- motd generation is split from bootlogs into a separate motd
  init script.
- bootlogs init script has been removed; current logging daemons
  handle this themselves, making this script redundant.
- tmpfs mounts are never cleaned by bootclean.sh.  Cleaning /run
  can lead to nonfunctional input when Xorg starts.  Closes: 
#669949.
  * sysvinit-utils:
- Suggest rather than Recommend bootlogd.

`systemd-analyze blame` shows that the init.d script `motd` still takes
quite a lot of time.

   363ms motd.service

There is not much going on in that script.

#!/bin/sh
### BEGIN INIT INFO
# Provides:  motd
# Required-Start:hostname $local_fs
# Required-Stop:
# Should-Start:
# Default-Start: 1 2 3 4 5
# Default-Stop:
# Short-Description: Create dynamic part of /etc/motd
# Description:   /etc/motd is user-editable and static.  This script
#creates the initial dynamic part, by default the
#output of uname, and stores it in 
/var/run/motd.dynamic.
#Both parts are output by pam_motd.
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin
. /lib/init/vars.sh

do_start () {
# Update motd
uname -snrvm  /var/run/motd.dynamic
}

do_status () {
if [ -f /var/run/motd.dynamic ] ; then
return 0
else
return 4
fi
}

case $1 in
  start|)
do_start
;;
  restart|reload|force-reload)
echo Error: argument '$1' not supported 2
exit 3
;;
  stop)
# No-op
;;
  status)
do_status
exit $?
;;
  *)
echo Usage: bootlogs [start|stop|status] 2
exit 3
;;
esac

:

So is systemd’s conversion of that init.d script to a unit file take so
long? Can someone point me to a unit/service file for motd so that I can
compare it? Unfortunately I could not find one on the net when searching
for »fedora systemd motd service file«.

[…]


Thanks,

Paul


[1] 
http://packages.debian.org/changelogs/pool/main/s/sysvinit/sysvinit_2.88dsf-27/changelog#version2.88dsf-24
[2] http://wiki.gentoo.org/wiki/Systemd


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] OT: Races with GDM3 and accountsservice

2012-06-10 Thread Paul Menzel

Am Mittwoch, den 23.05.2012, 22:54 +0200 schrieb Paul Menzel:
 Am Dienstag, den 22.05.2012, 23:48 +0200 schrieb Paul Menzel:
  Am Dienstag, den 22.05.2012, 18:41 +0200 schrieb Michael Biebl:
   2012/5/22 Paul Menzel:
2. GDM 3 did not list the available users though, which had to be
entered manually. After logging out again users are displayed fine.
   
   The user list is populated via accountsservice.
   A D-Bus activated system service. accounts-daemon.service shows up in
   your list above. So I'm wondering if there is genuine bug / race in
   the way gdm interacts with accountsdaemon.
  
  It looks like a race. The next two system starts the user list was
  correctly populated and now it is not populated again.
 
 After the third boot it worked too, but after the fourth it failed
 again.
 
 I do not know where to look for causes for this problem. I just found
 the following.
 
 # less /var/log/gdm3/\:0-greeter.log
 gnome-session[951]: WARNING: Failed to start app: Unable to start 
 application: Kindprozess »gnome-power-manager« konnte nicht ausgeführt werden 
 (Datei oder Verzeichnis nicht gefunden)
 Gtk-Message: Failed to load module atk-bridge
 gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for 
 notebook
 gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for 
 notebook
 gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for 
 notebook
 gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for 
 notebook
 gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for 
 notebook
 gdm-simple-greeter[1138]: Gtk-WARNING: 
 /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtkwidget.c:7117: widget not within a 
 GtkWindow
 gdm-simple-greeter[1138]: Gtk-CRITICAL: 
 gtk_widget_get_preferred_height_for_width: assertion `width = 0' failed
 gdm-simple-greeter[1138]: Gtk-CRITICAL: 
 gtk_widget_get_preferred_height_for_width: assertion `width = 0' failed
 gdm-simple-greeter[1138]: Gtk-WARNING: gtk_widget_size_allocate(): 
 attempt to allocate widget with width -47 and height -47
 Warnung der Fensterverwaltung:Buggy client sent a _NET_ACTIVE_WINDOW 
 message with a timestamp of 0 for 0x107 (Anmeldefen)
 Warnung der Fensterverwaltung:meta_window_activate called by a pager 
 with a 0 timestamp; the pager needs to be fixed.

I reported that problem in GNOME’s Bugzilla as #677476 but it was closed
right away because the version of GDM is too old.


Thanks,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=677476
[Bug 677476] New: Races with GDM3 and accountsservice


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] `systemd-analyze blame` shows unit file although `systemctl list-units-files` shows it as disabled

2012-06-10 Thread Paul Menzel

Dear systemd folks,


I do not understand why a disabled unit file is listed in
`systemd-analyze blame`.

$ systemctl list-unit-files
[…]
accounts-daemon.servicedisabled
[…]
$ systemd-analyze blame
[…]
35ms accounts-daemon.service
[…]

Could you enlighten me what is going on? Reading `man systemctl` and
`man systemd` I still could not figure this out.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] create-log-files.sh: script to collect benchmark data

2012-06-13 Thread Paul Menzel

Date: Fri, 8 Jun 2012 10:55:20 +0200

./create-log-files.sh disable-postfix

One of the goal of systemd is to decrease boot time. As written in the
Wiki [1] to draw correct conclusions benchmarks have to be run. This
script collects some data which is useful to compare different settings.

[1] http://freedesktop.org/wiki/Software/systemd/Optimizations
---
I hope others can contribute their scripts and programs so that
developers and users can benchmark their setup.

 scripts/create-log-files.sh |8 
 1 file changed, 8 insertions(+)
 create mode 100755 scripts/create-log-files.sh

diff --git a/scripts/create-log-files.sh b/scripts/create-log-files.sh
new file mode 100755
index 000..2fee015
--- /dev/null
+++ b/scripts/create-log-files.sh
@@ -0,0 +1,8 @@
+#!/bin/bash
+
+NOW=$(date +%Y%m%d-%H%M%S)
+TEXT=$NOW--$1
+systemd-analyze  systemd-analyze.$TEXT
+systemd-analyze blame  systemd-analyze-blame.$TEXT
+systemd-analyze plot  systemd-analyze-plot.$TEXT
+systemctl list-unit-files  systemctl-list-unit-files.$TEXT
-- 
1.7.10.4



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd unit files for Debian based systems

2012-06-16 Thread Paul Menzel

Dear systemd folks,


do you know of a repository or location where I can get systemd unit
files for Debian based systems? I found Lennart’s `systemd-units`
directory [1] but it does not contain units for programs.

The best way would be of course that units would be included by upstream
but this does not seem to be the case yet.

At least I could not find those for openssh-server [2], GDM 3 [3],
console-common [4] and cpufrequtils [5].

Also distribution independent files seem to be difficult since
configuration files are located at different places as is the case for
cpufrequtils. Arch Linux has the following service file [6].

$ more /etc/systemd/system/cpufreq.service
[Unit]
Description=CPU frequency scaling daemon

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/cpufreq
ExecStart=/usr/bin/cpufreq-set -r -g $governor -d $min_freq -u $max_freq

[Install]
WantedBy=multi-user.target

For example in Debian such files are put under
`/etc/default/cpufrequtils`.


Thanks,

Paul


[1] http://0pointer.de/public/systemd-units/
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676830
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677107
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677314
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677600
[6] https://wiki.archlinux.org/index.php/Systemd/Services#cpufreq


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit files for Debian based systems

2012-06-18 Thread Paul Menzel

Dear Lennart,


thank you for you reply.


Am Montag, den 18.06.2012, 17:48 +0200 schrieb Lennart Poettering:
 On Sat, 16.06.12 10:39, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

  do you know of a repository or location where I can get systemd unit
  files for Debian based systems? I found Lennart’s `systemd-units`
  directory [1] but it does not contain units for programs.
 
 Those files should probably not be used, they are kinda out-of-date. I
 have removed these files now from the web server, to avoid
 confusion. (ok, i renamed them to /systemd-units.out-of-date/, so that
 they can be used as reference but little else)

If my assumptions that systemd unit files should be distribution
independent than a central place at freedesktop.org to collect these
unit files would be great. Then everybody could try these and improve
them while trying to get these upstream.

  The best way would be of course that units would be included by upstream
  but this does not seem to be the case yet.
  
  At least I could not find those for openssh-server [2],

Do you know of a service file for openssh-server?

  GDM 3 [3], console-common [4] and cpufrequtils [5].

 GDM should not be too hard, and will do this eventually myself if nobody
 beats me to it. The reason why I haven't done this yet is that Fedora
 currently uses prefdm for starting the DMs and we need to get rid of
 that in all packages at the same time.

Understood. Thank you for doing that.

 What would console-common do that systemd-vconsole doesn't do anyway?

I have no clue. I just looked at the output of `systemd-analyze blame`
and reported my findings.

`console-common` [6] contains `/etc/init.d/keymap.sh` to set the keymap.

#!/bin/sh
### BEGIN INIT INFO
# Provides: keymap
# Required-Start:   mountdevsubfs
# Required-Stop:
# Default-Start:S
# Default-Stop:
# X-Interactive:true
# Short-Description:Set keymap
# Description:  Set the Console keymap
### END INIT INFO

# If setupcon is present, then we've been superseded by console-setup.
if type setupcon /dev/null 21; then
exit 0
fi

. /lib/lsb/init-functions

#
# Load the keymaps *as soon as possible*
#

# Don't fail on error
CONSOLE_TYPE=`fgconsole 2/dev/null` || CONSOLE_TYPE=unknown

# Don't fail on serial consoles

QUIT=0
# fail silently if loadkeys not present (yet).
command -v loadkeys /dev/null 21 || QUIT=1

CONFDIR=/etc/console
CONFFILEROOT=boottime
EXT=kmap
CONFFILE=${CONFDIR}/${CONFFILEROOT}.${EXT}.gz

reset_kernel()
{
# On Mac PPC machines, we may need to set kernel vars first
# We need to mount /proc to do that; not optimal, as its going 
to 
# be mounted in S10checkroot, but we need it set up before 
sulogin
# may be run in checkroot, which will need the keyboard to log 
in...
[ -x /sbin/sysctl ] || return
[ -r /etc/sysctl.conf ] || return
grep -v '^\#' /etc/sysctl.conf | grep -q keycodes 
if [ $? = 0 ] ; then
grep keycodes /etc/sysctl.conf | grep -v ^# | while read 
d ; do
/sbin/sysctl -w $d 2 /dev/null || true
done
fi
}

unicode_start_stop()
{
# Switch unicode mode by checking the locale.
# This will be needed before loading the keymap.
[ -x /usr/bin/unicode_start ] || [ -x /bin/unicode_start ] ||  
return
[ -x /usr/bin/unicode_stop ] || [ -x /bin/unicode_stop ] || 
return

ENV_FILE=
[ -r /etc/environment ]  ENV_FILE=/etc/environment
[ -r /etc/default/locale ]  ENV_FILE=/etc/default/locale 
[ $ENV_FILE ]  CHARMAP=$(set -a  . $ENV_FILE  locale 
charmap)
if [ $CHARMAP = UTF-8 ]; then
unicode_start 2 /dev/null || true
else
unicode_stop 2 /dev/null || true
fi
}

if [ ! $QUIT = '1' ] ; then

  case $1 in
  start | restart | force-reload | reload)
  
# Set kernel variables if required
reset_kernel

# First mount /proc if necessary...and if it is there (#392798)
unmount_proc=no
if [ -d /proc ]; then
if [ ! -x /proc/$$ ]; then
unmount_proc=yes  
mount -n /proc
fi

Re: [systemd-devel] cpufrequtils considered useless (was: systemd unit files for Debian based systems)

2012-06-19 Thread Paul Menzel

Am Dienstag, den 19.06.2012, 10:03 +0200 schrieb Lennart Poettering:
 On Mon, 18.06.12 21:56, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

Dear Lennart,


[…]

   What is cpufrequitls for? Why would anybody fiddle with that? ondemand
   is the only CPU scheduler that makes sense, so what is this about? Also,
   you can change the CPU scheduler via simple sysfs writes, right? So why
   would you use a tool like cpufreq for this? tmpfiles should be
   entirely sufficient?
   
   cpufreq stuff really appears to be sugar for 
   -Oit-feels-so-much-faster-now freaks...
  
  In Debian it is a recommendation of the package `gnome-applets`.
  
  $ LANG=C aptitude why cpufrequtils
  i   gnome Dependsgnome-applets (= 2.91)
  i A gnome-applets Recommends cpufrequtils
  
  I guess it is useful to have an abstraction layer because directories
  and files under `/sys` might change.
 
 Nah, really, cpufrequtils should just go away. People should use the
 kernel APIs right away.

alright looking into why `cpufrequtils` is installed on my system I now
know the reasons. The frequency(?) modules are not loaded automatically
and therefore the init.d script shipped by `cpufrequtils` is needed.

$ zless /usr/share/doc/gnome-applets/changelog.Debian.gz
[…]
gnome-applets (2.24.2-1) experimental; urgency=low

  * es.po: updated Spanish translation from Francisco Javier Cuadrado. 
Closes: #502236.
  * Recommend cpufrequtils. Closes: #448833.

The mentioned Debian bug reports #448833 [8] and #509827 [9] contain the
discussion.

Without the appropriate modules loaded – in my case `powernow_k8` – no
power saving features of the CPU are available.

$ find /sys -iname '*cpufreq*'
/sys/devices/system/cpu/cpufreq
$ ls -l /sys/devices/system/cpu/cpufreq/
insgesamt 0
$ sudo modprobe powernow_k8
$ ls -l /sys/devices/system/cpu/cpufreq/
insgesamt 0
drwxr-xr-x 2 root root 0 Jun 19 11:18 ondemand

So how is this supposed to work out of the box?


Thanks,

Paul


[8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448833
[9] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509827


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] cpufrequtils considered useless

2012-06-19 Thread Paul Menzel

Am Dienstag, den 19.06.2012, 11:48 +0200 schrieb Lennart Poettering:
 On Tue, 19.06.12 11:42, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

Dear Lennart,


I guess it is useful to have an abstraction layer because directories
and files under `/sys` might change.
   
   Nah, really, cpufrequtils should just go away. People should use the
   kernel APIs right away.
  
  alright looking into why `cpufrequtils` is installed on my system I now
  know the reasons. The frequency(?) modules are not loaded automatically
  and therefore the init.d script shipped by `cpufrequtils` is needed.
 
 This is a not the case anymore for kernels 3.3 and up anymore. CPU
 feature modules are now loaded automatically based on the CPUID data.

great news! So what should distributions having decided to use Linux 3.2
for their next stable release do?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unit file for motd (message of the day)

2012-06-19 Thread Paul Menzel

Am Dienstag, den 19.06.2012, 20:04 +0200 schrieb Lennart Poettering:
 On Sun, 10.06.12 14:40, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

Dear Lennart,

[ Roger Leigh ]
* initscripts:
  - Don't generate or touch /etc/motd.  Instead, the dynamic part 
  of
/etc/motd is created as /run/motd.dynamic, leaving /etc/motd
entirely under the control of the system administrator.  If
/etc/motd is a symlink to /run/motd, /etc/motd.tail is moved
back to /etc/motd.  Closes: #353229, #624391, #668307.  
  /etc/motd
is not removed if initscripts is purged, since it's not owned 
  by
initscripts.
  - By default, /run/motd is just the output of uname, preserving 
  the
existing behaviour.  However, should the administrator wish to
include dynamic information in the motd, they may write 
  scripts
to update /run/motd.dynamic as they please.  Closes: #437176.
 
 Yikes, baroque.
 
  So is systemd’s conversion of that init.d script to a unit file take so
  long? Can someone point me to a unit/service file for motd so that I can
  compare it? Unfortunately I could not find one on the net when searching
  for »fedora systemd motd service file«.
 
 Honestly I always found that this mangling of motd in Debian is
 quite confused. /etc should be considered read-only. Always writing
 to the root fs just because you boot the machine is a really bad idea.

Reading this changelog entry and the init.d script, I could not find
anything that is written dynamically to `/etc` and just to `/run`.

$ ls -al /etc/motd*
lrwxrwxrwx 1 root root  13 Apr  3  2008 /etc/motd - /var/run/motd
-rw-r--r-- 1 root root 286 Apr  3  2008 /etc/motd.tail
$ more /etc/motd*
::
/etc/motd
::
Linux debian-sid 3.2.0-2-686-pae #1 SMP Mon Jun 11 18:27:04 UTC 2012 
i686

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.
::
/etc/motd.tail
::

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.

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd and hdparm

2012-06-22 Thread Paul Menzel

Dear systemd folks, dear Mark (upstream), dear Stephen (Debian),


before going further about this what is your recommended way to deal
with hdparm setting up options for block devices?

Arch Linux does not seem to ship any init.d scripts/service files for
hdparm [1][2] and Fedora does not either [3].

The Debian package of hdparm [4] ships an init.d script [5] which reads
values from a config file and tunes the devices appropriately, which I
all attached from version 9.39-1.

Besides that drives should be set up „optimally“ in the first place by
the Linux kernel, how should users be able to set up there drives?


Thanks,

Paul


[1] https://github.com/falconindy/systemd-arch-units/tree/master/service
[2] https://projects.archlinux.org/svntogit/packages.git/tree/hdparm
[3] http://pkgs.fedoraproject.org/gitweb/?p=hdparm.git;a=tree
[4] http://packages.debian.org/sid/hdparm
[5] http://packages.debian.org/sid/amd64/hdparm/filelist
# To set the same options for a block of harddisks, do so with something
# like the following example options:
# harddisks=/dev/hda /dev/hdb
# hdparm_opts=-d1 -X66
# This is run before the configuration in hdparm.conf.  Do not use 
# this arrangement if you need modules loaded for your hard disks,
# or need udev to create the nodes, or have some other local quirk
# These are better addressed with the options in /etc/hdparm.conf
#
# harddisks=
# hdparm_opts=

# By default, hdparm will refuse to set harddisk options on any drive
# if the system has software RAID running, and one or more disk arrays
# are in the process of resynchronisation.
# With this variable set to 'yes', /etc/init.d/hdparm will suspend the
# RAID resynchronisation process before setting harddisk options, and
# will resume it after setting is done.
RAID_WORKAROUND=no


hdparm
Description: application/shellscript
## This is the default configuration for hdparm for Debian.  It is a 
## rather simple script, so please follow the following guidelines :)
## Any line that begins with a comment is ignored - add as many as you 
## like.  Note that an in-line comment is not supported.  If a line 
## consists of whitespace only (tabs, spaces, carriage return), it will be
## ignored, so you can space control fields as you like.  ANYTHING ELSE
## IS PARSED!!  This means that lines with stray characters or lines that 
## use non # comment characters will be interpreted by the initscript.  
## This has probably minor, but potentially serious, side effects for your 
## hard drives, so please follow the guidelines.  Patches to improve 
## flexibilty welcome.  Please read /usr/share/doc/hdparm/README.Debian for 
## notes about known issues, especially if you have an MD array.
##
## Note that if the init script causes boot problems, you can pass 'nohdparm' 
## on the kernel command line, and the script will not be run.
##
## Uncommenting the options below will cause them to be added to the DEFAULT
## string which is prepended to options listed in the blocks below.
##
## If an option is listed twice, the second instance replaces the first.
##
## /sbin/hdparm is not run unless a block of the form:
##  DEV {
## option
## option
## ...
##  }
## exists.  This blocks will cause /sbin/hdparm OPTIONS DEV to be run.
## Where OPTIONS is the concatenation of all options previously defined
## outside of a block and all options defined with in the block.

# -q be quiet
quiet 
# -a sector count for filesystem read-ahead
#read_ahead_sect = 12
# -A disable/enable the IDE drive's read-lookahead feature
#lookahead = on
# -b bus state
#bus = on
# -B apm setting
#apm = 255
# -B apm setting when on battery
#apm_battery = 127
# -c enable (E)IDE 32-bit I/O support - can be any of 0,1,3
#io32_support = 1
# -d disable/enable the using_dma flag for this drive
#dma = off
# -D enable/disable the on-drive defect management
#defect_mana = off
# -E cdrom speed
#cd_speed = 16
# -k disable/enable the keep_settings_over_reset flag for this drive
#keep_settings_over_reset = off
# -K disable/enable the drive's keep_features_over_reset flag
#keep_features_over_reset = on
# -m sector count for multiple sector I/O
#mult_sect_io = 32
# -P maximum sector count for the drive's internal prefetch mechanism
#prefetch_sect = 12
# -r read-only flag for device
#read_only = off
# -s Turn on/off power on in standby mode
# poweron_standby = off
# -S standby (spindown) timeout for the drive
#spindown_time = 24
# -u interrupt-unmask flag for the drive
#interrupt_unmask = on
# -W Disable/enable the IDE drive's write-caching feature
#write_cache = off
# -X IDE transfer mode for newer (E)IDE/ATA2 drives
#transfer_mode = 34
# -y force to immediately enter the standby mode
#standby
# -Y force to immediately enter the sleep mode
#sleep
# -Z Disable the power-saving function of certain Seagate drives
#disable_seagate
# -M Set the acoustic management properties of a drive
#acoustic_management
# -p Set the chipset PIO mode
# chipset_pio_mode
# --security-freeze

[systemd-devel] Upstream service file for NTP daemon chrony

2012-06-22 Thread Paul Menzel

Dear systemd folks,


Fedora ships systemd service files for chrony [1][2].

• chrony-wait.service:

   1 [Unit]
   2 Description=Wait for chrony to synchronize system clock
   3 After=chronyd.service
   4 Requires=chronyd.service
   5 Before=time-sync.target
   6 Wants=time-sync.target
   7 
   8 [Service]
   9 Type=oneshot
  10 # Wait up to ~10 minutes for chronyd to synchronize and the remaining
  11 # clock correction to be less than 0.1 seconds
  12 ExecStart=/usr/bin/chronyc waitsync 60 0.1
  13 RemainAfterExit=yes
  14 
  15 [Install]
  16 WantedBy=multi-user.target

• chronyd.service:

   1 [Unit]
   2 Description=NTP client/server
   3 After=syslog.target ntpdate.service
   4 Conflicts=ntpd.service
   5 BindTo=systemd-timedated-ntp.target
   6 
   7 [Service]
   8 Type=forking
   9 EnvironmentFile=-/etc/sysconfig/chronyd
  10 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey
  11 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS
  12 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers
  13 
  14 [Install]
  15 WantedBy=multi-user.target

Do these look good enough to get upstream? `systemd-arch-units` refused
a pull request [3].


Thanks,

Paul


[1] 
http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chrony-wait.service;h=3958160098eae926aaf7136d7b5b8bab42a6aa35;hb=HEAD
[2] 
http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chronyd.service;h=167332e37511f19019aabc32f82a47ef80656cd5;hb=HEAD
[3] https://github.com/falconindy/systemd-arch-units/issues/98


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] GDM service file (was: systemd unit files for Debian based systems)

2012-06-22 Thread Paul Menzel

Am Montag, den 18.06.2012, 21:56 +0200 schrieb Paul Menzel:

 Am Montag, den 18.06.2012, 17:48 +0200 schrieb Lennart Poettering:
  On Sat, 16.06.12 10:39, Paul Menzel wrote:

Dear systemd folks,


[… also asking for service file for GDM … ]

  GDM should not be too hard, and will do this eventually myself if nobody
  beats me to it. The reason why I haven't done this yet is that Fedora
  currently uses prefdm for starting the DMs and we need to get rid of
  that in all packages at the same time.
 
 Understood. Thank you for doing that.

just as a follow up for those interested there is a service file for GDM
in the systemd-arch-units repository [7].

systemd-arch-units$ more service/gdm.service 
[Unit]
Description=Gnome Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/sbin/gdm -nodaemon

[Install]
WantedBy=graphical.target

This does not yet seem to be included in Arch Linux upstream [8]. Any
comments on that? In Debian the name of the GDM3 binary is `gdm3` and
not `gdm`.

debian-system:~$ ls /usr/sbin/gdm*
/usr/sbin/gdm3

[…]


Thanks,

Paul


[7] 
https://github.com/falconindy/systemd-arch-units/blob/master/service/gdm.service
[8] https://projects.archlinux.org/svntogit/packages.git/tree/gdm/trunk


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] GDM service file for Debian (was: systemd unit files for Debian based systems)

2012-06-23 Thread Paul Menzel

Am Freitag, den 22.06.2012, 15:35 +0100 schrieb Léo Gillot-Lamure:
 Simple suggestion : GDM takes a name on the bus, so you can reliably
 know when the service has finished to start. The service file used in
 Gentoo adds a line BusName=org.gnome.DisplayManager in the [Service]
 section to achieve that.

Thanks. Gentoo’s service file looks like this [1]

1   [Unit]
2   Description=GNOME Display Manager
3   After=systemd-user-sessions.service
4   
5   [Service]
6   ExecStart=/usr/bin/gdm --nodaemon
7   Type=dbus
8   BusName=org.gnome.DisplayManager
9   
10  [Install]
11  WantedBy=graphical.target

and here again Arch Linux’ for comparison.

$ more service/gdm.service 
[Unit]
Description=Gnome Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/sbin/gdm -nodaemon

[Install]
WantedBy=graphical.target

So Lennart, which one would you prefer?

Adapting the path to `/usr/sbin/gdm3` in Gentoo’s one and saving it
under `/lib/systemd/service/gdm3.service` it works under Debian after
`sudo systemctl enable gdm3.service`.

Although reading Jordi’s post [2],

As we get many questions regarding the status of GDM in Debian,
let's add a short note on this. Packaging GDM, at least in its
current upstream form, is not a matter of unpacking a new
tarball and editing debian/changelog. When Joss works on a new
major version, the amount of tweaking to break away from stuff
that works on other distros but is not so simple in Debian is
outstanding (see, for example, the current unfinished work for
GDM 3.2 in our SVN repo). In our case, to handle our GDM
defaults, we even need changes to the underlying configuration
system, dconf. This evidently takes some effort to do, and
unfortunately our GDM expert has had little time for Debian
lately, but we're confident we'll end up with a GDM in wheezy
that is on par with Debian standards.

and looking at Debian’s GDM init.d script [2]

1   #! /bin/sh
2   ### BEGIN INIT INFO
3   # Provides:  gdm3
4   # Should-Start:  console-screen dbus network-manager
5   # Required-Start:$local_fs $remote_fs
6   # Required-Stop: $local_fs $remote_fs
7   # Default-Start: 2 3 4 5
8   # Default-Stop:  0 1 6
9   # Short-Description: GNOME Display Manager
10  # Description:   Debian init script for the GNOME Display Manager
11  ### END INIT INFO
12  #
13  # Author:   Ryan Murray rmur...@debian.org
14  #
15  set -e
16  
17  PATH=/sbin:/bin:/usr/sbin:/usr/bin
18  DAEMON=/usr/sbin/gdm3
19  
20  test -x $DAEMON || exit 0
21  
22  if [ -r /etc/default/locale ]; then
23. /etc/default/locale
24export LANG LANGUAGE
25  fi
26  
27  . /lib/lsb/init-functions
28  
29  # To start gdm even if it is not the default display manager, change
30  # HEED_DEFAULT_DISPLAY_MANAGER to false.
31  HEED_DEFAULT_DISPLAY_MANAGER=true
32  DEFAULT_DISPLAY_MANAGER_FILE=/etc/X11/default-display-manager
33  
34  gen_config() {
35# GSettings configuration uses dconf update to generate a gdm profile
36if [ -d /var/lib/gdm3 ]; then
37  needed=no
38  if [ -f /var/lib/gdm3/dconf/db/gdm ]; then
39for f in \
40/usr/share/gdm/dconf /usr/share/gdm/dconf/*-settings \
41/usr/share/gdm/dconf/locks /usr/share/gdm/dconf/locks/*-locks 
\
42/etc/gdm3/greeter.gsettings; do
43  if [ $f -nt /var/lib/gdm3/dconf/db/gdm ]; then
44needed=yes
45break
46  fi
47done
48  else
49needed=yes
50  fi
51  if [ $needed = yes ]; then
52rm -rf /var/lib/gdm3/dconf
53mkdir -p /var/lib/gdm3/dconf/profile 
/var/lib/gdm3/dconf/db/gdm.d/locks
54ln -s /usr/share/gdm/dconf-profile /var/lib/gdm3/dconf/profile/gdm
55ln -s /usr/share/gdm/dconf/*-settings 
/var/lib/gdm3/dconf/db/gdm.d/
56ln -s /usr/share/gdm/dconf/locks/*-locks 
/var/lib/gdm3/dconf/db/gdm.d/locks/
57# The configuration file in /etc uses org.gnome.blah gsettings 
syntax.
58# Convert it to org/gnome/blah dconf syntax.
59awk '/\[.*\]/ { gsub(\\.,/); } ! /^#/ { print;}' \
60  /etc/gdm3/greeter.gsettings  
/var/lib/gdm3/dconf/db/gdm.d/90-debian-settings
61dconf update /var/lib/gdm3/dconf/db 2 /dev/null
62  fi
63fi
64  }
65  
66  case $1 in
67start)
68  CONFIGURED_DAEMON=$(basename $(cat 
$DEFAULT_DISPLAY_MANAGER_FILE 2 /dev/null))
69  if grep -wqs text /proc/cmdline; then
70  log_warning_msg Not starting GNOME Display Manager; found 
'text' in kernel commandline.

Re: [systemd-devel] cpufrequtils considered useless

2012-06-23 Thread Paul Menzel

Am Dienstag, den 19.06.2012, 12:10 +0200 schrieb Kay Sievers:
 On Tue, Jun 19, 2012 at 12:04 PM, Paul Menzel wrote:
  Am Dienstag, den 19.06.2012, 11:48 +0200 schrieb Lennart Poettering:
  On Tue, 19.06.12 11:42, Paul Menzel wrote:
 
 I guess it is useful to have an abstraction layer because directories
 and files under `/sys` might change.
   
Nah, really, cpufrequtils should just go away. People should use the
kernel APIs right away.
  
   alright looking into why `cpufrequtils` is installed on my system I now
   know the reasons. The frequency(?) modules are not loaded automatically
   and therefore the init.d script shipped by `cpufrequtils` is needed.
 
  This is a not the case anymore for kernels 3.3 and up anymore. CPU
  feature modules are now loaded automatically based on the CPUID data.
 
  great news! So what should distributions having decided to use Linux 3.2
  for their next stable release do?
 
 Update their kernel. :)

Or backport that feature [1][2]. Ben Hutchings rules and I thank him for
doing all that great work on the Linux kernel side! Thanks Ben!

 Or do whatever they used to do in the past and bet it works, like it
 did most of the time. The problem is pretty much solved from systemd's
 point of view, so there will be no effort from this side.

[…]

So now Debian Wheezy users on x86 do not need cpufrequtils anymore to
load the correct module.


Thanks,

Paul


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664813
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678116


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How do I disable old init.d scripts?

2012-06-25 Thread Paul Menzel

Dear systemd folks,


how can I disable init.d scripts which systemd loads for compatibility
reasons?

$ ls /etc/init.d/motd  (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
   543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] `systemd-analyze blame`indicates GDM3 takes longer to start with service file than with init.d script

2012-06-25 Thread Paul Menzel

Dear systemd folks,


after a system start I save the output of `systemd-anlyze blame`.

With Debian Sid/unstable, GDM 3.4.1 and the shipped init.d script on
average it took about 120 ms. For example:

124ms gdm3.service

Adding the following service file

$ more /lib/systemd/system/gdm3.service[Unit]
Description=GNOME Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/sbin/gdm3 --nodaemon
Type=dbus
BusName=org.gnome.DisplayManager

[Install]
WantedBy=graphical.target

I now get 190 ms on average, for example:

188ms gdm3.service

Can you think of a reason for that? It should at least not take more
time, should not it?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How do I disable old init.d scripts?

2012-06-25 Thread Paul Menzel

Am Montag, den 25.06.2012, 15:38 +0200 schrieb Lennart Poettering:
 On Mon, 25.06.12 15:25, Paul Menzel wrote:

[…]

  how can I disable init.d scripts which systemd loads for compatibility
  reasons?
  
  $ ls /etc/init.d/motd  (or any other init.d script)
  /etc/init.d/motd
  $ systemd-analyze blame | grep motd
 543ms motd.service
  $ sudo systemctl disable motd.service
  Failed to issue method call: No such file or directory
 
 On Fedora we defer to chkconfig automatically for sysv services.

Looking at the code

$ git grep -i chkconfig

this seems to happen for the following distributions.

#if defined (HAVE_SYSV_COMPAT)  (defined(TARGET_FEDORA) || 
defined(TARGET_MANDRIVA) || defined(TARGET_SUSE) || defined(TARGET_MEEGO) || 
defined(TARGET_ALTLINUX) || defined(TARGET_MAGEIA))

 This hookup is currently missing for Debian, but I'd be willing to merge a
 patch for that.

If I am not mistaken, Debian uses `update-rc.d` for that purpose.

Does someone know if it is feasible to just change the one variable (and
options) containing the path to the utilities and reuse the error
handling or will that not work?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] man/bootup.xml: Fix grammar by adding missing verb »is«

2012-06-25 Thread Paul Menzel

Date: Mon, 25 Jun 2012 23:00:38 +0200

---
 man/bootup.xml |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/bootup.xml b/man/bootup.xml
index 69f9a27..e29c1a0 100644
--- a/man/bootup.xml
+++ b/man/bootup.xml
@@ -73,7 +73,7 @@
 storage technologies backing them), and then
 (optionally) jumps back into the initrd code which
 unmounts/detaches the root file system and the storage
-it resides on. As last step the system powered down./para
+it resides on. As last step the system is powered down./para
 
 paraAdditional information about the system boot
 process may be found in
-- 
1.7.10.4



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd numbers for Debian Sid/unstable system

2012-06-28 Thread Paul Menzel

Am Donnerstag, den 28.06.2012, 07:54 +0200 schrieb Tollef Fog Heen:
 ]] Lennart Poettering 
 
  On Wed, 27.06.12 21:59, Tollef Fog Heen (tfh...@err.no) wrote:

   ]] Lennart Poettering 
   
Hmm, the other distributions have an #ifdef TARGET_FOOBAR section in
vconsole-setup for that. Debian currently doesn't. I'd be willing to add
a patch that parses the old DEbian configuration files, to implement the
fallback.
   
   We use the X11 keyboard definitions.  Are you sure you want to
   completely reimplement console-setup? :-)
  
  Ah, hmm. I heard of that. Can you explain how precisely that works? Do
  you actually use the same keybaord definitions, i.e. have converted them
  to console definitions? Or do you just share the same naming namespace?
 
 console-setup reads the xkb definitions and downsamples them to
 something the console can understand.  IIRC, it doesn't work for the
 most complex keymaps and the cases where you have multiple keymaps
 defined which you can switch between, but it works well in the simple
 case of one language.  (IIRC, this is due to kernel limitations in how
 many keys can be defined and such.  Also, I don't think the kernel
 understands Compose.)
 
  Any docs available for this?
 
 There might be some in
 http://ftp.debian.org/debian/pool/main/c/console-setup/console-setup_1.78.tar.gz

You can also clone the Git repository.

$ debcheckout -d console-setup
typegit
url git://git.debian.org/d-i/console-setup.git
top-bases   
topgit  no


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cryptsetup: add keyfile-offset= support

2012-06-29 Thread Paul Menzel

Dear Tom,


Am Freitag, den 29.06.2012, 13:40 +0200 schrieb Tom Gundersen:
 This is useful if your keyfile is a block device, and you want to
 use a specific part of it, such as an area between the MBR and the
 first partition.
 
 This feature is documented in the Arch wiki[0], and has been supported
 by the Arch initscripts, so would be nice to get this into systemd.

please document that libcryptsetup ≥ 1.4.2 is needed in the commit
message.

 [0]:
 https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition

Please no line break here.

 ---
  configure.ac|  2 +-
  man/crypttab.xml| 13 +
  src/cryptsetup/cryptsetup.c | 11 ++-
  3 files changed, 24 insertions(+), 2 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index e0a2526..e1876cc 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -333,7 +333,7 @@ AC_SUBST(AUDIT_LIBS)
  have_libcryptsetup=no
  AC_ARG_ENABLE(libcryptsetup, AS_HELP_STRING([--disable-libcryptsetup], 
 [disable libcryptsetup tools]))
  if test x$enable_libcryptsetup != xno; then
 -PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup ],
 +PKG_CHECK_MODULES(LIBCRYPTSETUP, [ libcryptsetup = 1.4.2 ],
  [AC_DEFINE(HAVE_LIBCRYPTSETUP, 1, [Define if libcryptsetup 
 is available]) have_libcryptsetup=yes], have_libcryptsetup=no)
  if test x$have_libcryptsetup = xno -a x$enable_libcryptsetup = 
 xyes; then
  AC_MSG_ERROR([*** libcryptsetup support requested but 
 libraries not found])
 diff --git a/man/crypttab.xml b/man/crypttab.xml
 index f3bde71..e54f78c 100644
 --- a/man/crypttab.xml
 +++ b/man/crypttab.xml
 @@ -131,6 +131,19 @@
  
 
  varlistentry
 +
 termvarnamekeyfile-offset=/varname/term

Wrong indentation?

 +
 + listitemparaSpecifies the number
 +of bytes to skip at the start of
 +the keyfile; see
 +
 citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
 +for possible values and the default
 +value of this
 +option. /para/listitem

No space after full stop and merge with line before?

 +/varlistentry
 +
 +
 +varlistentry
  termvarnamehash=/varname/term
  
  listitemparaSpecifies the hash to
 diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
 index b26fcca..f570724 100644
 --- a/src/cryptsetup/cryptsetup.c
 +++ b/src/cryptsetup/cryptsetup.c
 @@ -37,6 +37,7 @@
  static const char *opt_type = NULL; /* LUKS1 or PLAIN */
  static char *opt_cipher = NULL;
  static unsigned opt_key_size = 0;
 +static unsigned opt_keyfile_offset = 0;
  static char *opt_hash = NULL;
  static unsigned opt_tries = 0;
  static bool opt_readonly = false;
 @@ -79,6 +80,13 @@ static int parse_one_option(const char *option) {
  return 0;
  }
  
 +} else if (startswith(option, keyfile-offset=)) {
 +
 +if (safe_atou(option+15, opt_keyfile_offset)  0) {
 +log_error(keyfile-offset= parse failure, 
 ignoring.);
 +return 0;
 +}
 +
  } else if (startswith(option, hash=)) {
  char *t;
  
 @@ -462,7 +470,8 @@ int main(int argc, char *argv[]) {
   argv[3]);
  
  if (key_file)
 -k = crypt_activate_by_keyfile(cd, argv[2], 
 CRYPT_ANY_SLOT, key_file, keyfile_size, flags);
 +k = crypt_activate_by_keyfile_offset(cd, 
 argv[2], CRYPT_ANY_SLOT, key_file, keyfile_size,
 +opt_keyfile_offset, flags);
  else {
  char **p;

Otherwise this looks good.

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

2012-06-29 Thread Paul Menzel

Dear systemd folks,


I got some private (I do not know why) replies regarding this service
files giving me some hints.


Am Freitag, den 22.06.2012, 11:57 +0200 schrieb Paul Menzel:

 Fedora ships systemd service files for chrony [1][2].
 
 • chrony-wait.service:
 
1 [Unit]
2 Description=Wait for chrony to synchronize system clock
3 After=chronyd.service
4 Requires=chronyd.service
5 Before=time-sync.target
6 Wants=time-sync.target
7 
8 [Service]
9 Type=oneshot
   10 # Wait up to ~10 minutes for chronyd to synchronize and the remaining
   11 # clock correction to be less than 0.1 seconds
   12 ExecStart=/usr/bin/chronyc waitsync 60 0.1
   13 RemainAfterExit=yes
   14 
   15 [Install]
   16 WantedBy=multi-user.target
 
 • chronyd.service:
 
1 [Unit]
2 Description=NTP client/server
3 After=syslog.target ntpdate.service
4 Conflicts=ntpd.service
5 BindTo=systemd-timedated-ntp.target
6 
7 [Service]
8 Type=forking
9 EnvironmentFile=-/etc/sysconfig/chronyd
   10 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey
   11 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS
   12 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers
   13 
   14 [Install]
   15 WantedBy=multi-user.target
 
 Do these look good enough to get upstream? `systemd-arch-units` refused
 a pull request [3].

It was pointed out that the service files above are very Fedora
specific. Mantas pointed out that Arch Linux now ships unit files
directly [4]

[Unit]
Description=Chrony Network Time Daemon

[Service]
Type=forking
ExecStart=/usr/sbin/chronyd
PIDFile=/var/run/chronyd.pid

[Install]
WantedBy=multi-user.target

and therefore the pull request above was rejected. Furthermore David had
some great ideas whose result is quite similar to the service file in
Arch Linux.

[Unit]
Description=Chrony Network Time Daemon
After=nss-lockup.target syslog.target

[Service]
ExecStart=/usr/sbin/chronyd -n

[Install]
WantedBy=multi-user.target

David suggested that a separate system user could be used for this
daemon too and systemd should do this.

But it looks like that Arch Linux or Debian assume `chronyd` is run as
`root` and do not set up devices or certain files for time setting to be
used by a different user than root.

Additionally `After=nss-lockup.target` should be set, so that the NTP
daemon actually finds a NTP server.

And lastly, in the directory `units/` of the systemd source tree
contains `time-sync.target` and the Fedora services use that too. But
reading the manual of systemd.special, my take on this is this is just a
compatibility file and should not be used in a systemd service file.

So does the last service file look reasonable and should be used for
upstream inclusion?


Thanks,

Paul


 [1] 
 http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chrony-wait.service;h=3958160098eae926aaf7136d7b5b8bab42a6aa35;hb=HEAD
 [2] 
 http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chronyd.service;h=167332e37511f19019aabc32f82a47ef80656cd5;hb=HEAD
 [3] https://github.com/falconindy/systemd-arch-units/issues/98
[4] 
https://projects.archlinux.org/svntogit/community.git/tree/trunk/service?h=packages/chrony


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd numbers for Debian Sid/unstable system

2012-06-30 Thread Paul Menzel

Am Mittwoch, den 27.06.2012, 12:35 +0200 schrieb Lennart Poettering:
 On Wed, 27.06.12 12:18, Paul Menzel wrote:

[…]

 540ms chrony.service
 515ms rc.local.service
 
 The rc-local generator should be smart enough to pull this in only if it
 exists. It's a really slow service and most likely just a NOP anyway.

Right. The default file `/etc/rc.local` just contains `exit 0`. So I
masked that service file.

$ sudo systemctl mask rc.local.service

 509ms vdr.service
 487ms sysfsutils.service
 
 What is this? This stuff sounds like something that can just go away...

I was surprised too. It looks like this was installed by
`grml-debootstrap` and I removed it using the following command.

$ sudo aptitude purge --purge-unused sysfsutils

[…]

 191ms screen-cleanup.service
 
 Something for tmpfiles?

I have to look into that.

 167ms systemd-tmpfiles-setup.service
 147ms pulseaudio.service
 
 Hmm, as a system service? Meh..

Well, no. Debian still ships an init.d script which reads
`/etc/default/pulseaudio` and there system mode is disabled by default.
So I masked this one too.

$ sudo systemctl mask pulseaudio.service

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

2012-07-01 Thread Paul Menzel

Dear systemd folks,


Am Samstag, den 30.06.2012, 01:00 +0200 schrieb Paul Menzel:

 Am Freitag, den 22.06.2012, 11:57 +0200 schrieb Paul Menzel:
 
  Fedora ships systemd service files for chrony [1][2].
  
  • chrony-wait.service:
  
 1 [Unit]
 2 Description=Wait for chrony to synchronize system clock
 3 After=chronyd.service
 4 Requires=chronyd.service
 5 Before=time-sync.target
 6 Wants=time-sync.target
 7 
 8 [Service]
 9 Type=oneshot
10 # Wait up to ~10 minutes for chronyd to synchronize and the remaining
11 # clock correction to be less than 0.1 seconds
12 ExecStart=/usr/bin/chronyc waitsync 60 0.1
13 RemainAfterExit=yes
14 
15 [Install]
16 WantedBy=multi-user.target
  
  • chronyd.service:
  
 1 [Unit]
 2 Description=NTP client/server
 3 After=syslog.target ntpdate.service
 4 Conflicts=ntpd.service
 5 BindTo=systemd-timedated-ntp.target
 6 
 7 [Service]
 8 Type=forking
 9 EnvironmentFile=-/etc/sysconfig/chronyd
10 ExecStartPre=/usr/libexec/chrony-helper generate-commandkey
11 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS
12 ExecStartPost=/usr/libexec/chrony-helper add-dhclient-servers
13 
14 [Install]
15 WantedBy=multi-user.target
  
  Do these look good enough to get upstream? `systemd-arch-units` refused
  a pull request [3].
 
 It was pointed out that the service files above are very Fedora
 specific. Mantas pointed out that Arch Linux now ships unit files
 directly [4]
 
 [Unit]
 Description=Chrony Network Time Daemon
 
 [Service]
 Type=forking
 ExecStart=/usr/sbin/chronyd
 PIDFile=/var/run/chronyd.pid
 
 [Install]
 WantedBy=multi-user.target
 
 and therefore the pull request above was rejected. Furthermore David had
 some great ideas whose result is quite similar to the service file in
 Arch Linux.
 
 [Unit]
 Description=Chrony Network Time Daemon
 After=nss-lockup.target syslog.target
 
 [Service]
 ExecStart=/usr/sbin/chronyd -n
 
 [Install]
 WantedBy=multi-user.target
 
 David suggested that a separate system user could be used for this
 daemon too and systemd should do this.
 
 But it looks like that Arch Linux or Debian assume `chronyd` is run as
 `root` and do not set up devices or certain files for time setting to be
 used by a different user than root.
 
 Additionally `After=nss-lockup.target` should be set, so that the NTP
 daemon actually finds a NTP server.
 
 And lastly, in the directory `units/` of the systemd source tree
 contains `time-sync.target` and the Fedora services use that too. But
 reading the manual of systemd.special, my take on this is this is just a
 compatibility file and should not be used in a systemd service file.
 
 So does the last service file look reasonable and should be used for
 upstream inclusion?

Another problem, upstream cannot decide and each distribution has to, is
that when chronyd starts it starts as offline. I have not found a way to
start the daemon as online.

Therefore normally some kind of init.d script is run to read the
password from `/etc/chrony/chrony.keys` (in Debian) and to execute the
client `chronyc` and passes the command online to put the NTP server
sources online [5].

I do not know how Arch Linux is doing this, but in their Wiki suggests
to put some scripts under `/etc/NetworkManager/dispatcher.d/`
NetworkManager can execute when an interface goes up or down [6].

Under Debian NetworkManager ships a compatibility script to run scripts
`/etc/network/if-{up,down}.d/` and I successfully put some scripts in
there to put chrony online or offline.

But these are some problems I see that upstreaming unit files which all
distributions can use will be difficult.


Thanks,

Paul


  [1] 
  http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chrony-wait.service;h=3958160098eae926aaf7136d7b5b8bab42a6aa35;hb=HEAD
  [2] 
  http://pkgs.fedoraproject.org/gitweb/?p=chrony.git;a=blob;f=chronyd.service;h=167332e37511f19019aabc32f82a47ef80656cd5;hb=HEAD
  [3] https://github.com/falconindy/systemd-arch-units/issues/98
 [4] 
 https://projects.archlinux.org/svntogit/community.git/tree/trunk/service?h=packages/chrony
[5] http://chrony.tuxfamily.org/manual.html#Usage-reference
[6] 
https://wiki.archlinux.org/index.php/Chrony#Using_NetworkManager_to_let_chronyd_go_online


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

2012-07-02 Thread Paul Menzel

Am Montag, den 02.07.2012, 13:04 -0700 schrieb David Strauss:
 On Fri, Jun 29, 2012 at 4:00 PM, Paul Menzel wrote:
  Additionally `After=nss-lockup.target` should be set, so that the NTP

Ah, nice typo I got here: s/lockup/lookup/.

  daemon actually finds a NTP server.
 
 Also, is this necessary? Can't chronyd just fail to sync NTP until it
 works? There's value to an NTP daemon running even if it lacks
 upstream sync sources for a while.

Which? But it might be true.

 I'm also generally skeptical of After= without a corresponding
 Requires= entry because it only affects the ordering if the other unit
 is already present in the working set of services then being started.

I did not get that. The manuals are waiting for me.

 If something's required to happen before a unit, you need both.

Understood.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstream service file for NTP daemon chrony

2012-07-02 Thread Paul Menzel

Am Dienstag, den 03.07.2012, 00:55 +0200 schrieb Kay Sievers:
 On Tue, Jul 3, 2012 at 12:44 AM, Paul Menzel wrote:
  I'm also generally skeptical of After= without a corresponding
  Requires= entry because it only affects the ordering if the other unit
  is already present in the working set of services then being started.
 
  I did not get that. The manuals are waiting for me.
 
  If something's required to happen before a unit, you need both.
 
  Understood.
 
 $ man systemd.unit
 
 Before=, After=
 Configures ordering dependencies between units. If a unit foo.service
 contains a setting Before=bar.service and both units are being
 started, bar.service's start-up is delayed until foo.service is
 started up.

So »started up« does not mean is started up and finished with execution?

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core/main.c: only reopen /dev/console if we switch-root to a custom init

2012-07-12 Thread Paul Menzel

Dear Harald,


thank you for the patch.


Am Donnerstag, den 12.07.2012, 08:43 +0200 schrieb har...@redhat.com:
 From: Harald Hoyer har...@redhat.com

What happens otherwise? Is there an error message?

 ---
  src/core/main.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/core/main.c b/src/core/main.c
 index 6f6b565..a7172c1 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -1672,9 +1672,6 @@ finish:
   * rebooted while we do that */
  watchdog_close(true);
  
 -/* Reopen the console */
 -make_console_stdio();
 -
  if (switch_root_dir) {
  r = switch_root(switch_root_dir);
  if (r  0)
 @@ -1711,6 +1708,9 @@ finish:
  execv(args[0], (char* const*) args);
  }
  
 +/* Reopen the console */
 +make_console_stdio();
 +
  /* Try the fallback, if there is any, without any
   * serialization. We pass the original argv[] and
   * envp[]. (Well, modulo the ordering changes due to


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] LUKS passphrase asked twice when using plain device names

2014-09-23 Thread Paul Menzel

Dear systemd and dracut folks,


with Debian Sid/unstable, using plain device names like `/dev/sda1` in
`/etc/fstab` and `/etc/crypttab` the LUKS passphrase has to be entered
twice. Once it asked by dracut and once by systemd. I did not yet try
with UUIDs and ask first if that is an error?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fix spell

2014-12-30 Thread Paul Menzel

Dear Susant,


Am Dienstag, den 30.12.2014, 13:35 +0530 schrieb Susant Sahani:

thank you for the patch.

Could you please fix the summary line? For example use

man: Fix three typos

or

man: Fix spelling

as that also shows that the manual pages are touched.

`git commit --amend` let’s you update the commit message.

 ---
  man/sd_event_add_child.xml  | 2 +-
  man/sd_event_add_signal.xml | 2 +-
  man/systemctl.xml   | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd: Program terminated with signal SIGFPE, Arithmetic exception.

2014-12-30 Thread Paul Menzel

Dear systemd folks,


using Debian Sid/unstable with systemd 215-8, I still have problems that
there are time-outs between systemd and D-Bus, even with the current
D-Bus 1.8.12 [1]. Experiencing this again, where
`systemd-logind.service` was not started, I was able to log in on tty1
but in the end I was unable to run any `sudo systemctl` commands as they
timed out. I also was unable to reboot or halt the system.

Somewhere in that situation systemd also crashed with an arithmetic
exception; logged as `Caught FPE` in `/var/log/syslog`.

I created ticket #87349 in the Freedesktop.org Bugzilla bug tracker [2].
The backtrace is pasted in the original upstream bug report and in this
message at the end.


Thanks,

Paul


[1] https://bugs.freedesktop.org/show_bug.cgi?id=87424
Time-out problems during boot with systemd
[2] https://bugs.freedesktop.org/show_bug.cgi?id=87349

-- Package-specific info:

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-4
ii  libc6   2.19-13
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-4
ii  libgcrypt20 1.6.2-4+b1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-8
ii  mount   2.25.2-4
ii  sysv-rc 2.88dsf-58
ii  udev215-8
ii  util-linux  2.25.2-4

Versions of packages systemd recommends:
ii  dbus1.8.12-3
ii  libpam-systemd  215-8

Versions of packages systemd suggests:
pn  systemd-ui  none

-- no debconf information

-- Backtrace
Thread 1 (Thread 0xb73417c0 (LWP 3020)):
#0  0xb7650d3c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7603bb6 in raise (sig=8) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = optimized out
resultvar = optimized out
pid = optimized out
#2  0xb7686e6b in crash.lto_priv.235 (sig=8) at ../src/core/main.c:158
rl = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615}
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 repeats 32 times}}, sa_flags = 0, 
  sa_restorer = 0x0}
pid = optimized out
__func__ = crash
__PRETTY_FUNCTION__ = crash
#3  signal handler called
No symbol table info available.
#4  0xb772fcdf in manager_print_jobs_in_progress (m=0xb79c6bd0) at 
../src/core/manager.c:170
job_of_n = 0x0
j = optimized out
counter = 0
cylon = 
|\000\000\000\060ᶷ\000\000\000\000\001\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\001\000\000
time = 
\002\000\000\000\003\000\000\000\005\000\000\000\001\000\000\000\002\000\000\000\003\000\000\000\004\000\000\000\005\000\000\000\000M\362\261\v\000\000\000\210P\245\267\071Hk\267h:{\267\005\000\000\000\v\000\000\000\210P\245\267
limit = no limit, '\000' repeats 55 times
x = optimized out
i = 0x0
cylon_pos = optimized out
#5  manager_dispatch_jobs_in_progress (source=0xb7b64fe8, usec=432972905, 
userdata=0xb79c6bd0) at ../src/core/manager.c:1846
m = 0xb79c6bd0
r = optimized out
next = optimized out
__PRETTY_FUNCTION__ = manager_dispatch_jobs_in_progress
#6  0xb76a157d in source_dispatch (s=0xb7b64fe8) at 
../src/libsystemd/sd-event/sd-event.c:2024
r = optimized out
__PRETTY_FUNCTION__ = source_dispatch
__func__ = source_dispatch
#7  0xb76a6b94 in sd_event_run (e=optimized out, timeout=optimized out) at 
../src/libsystemd/sd-event/sd-event.c:2314
ev_queue = optimized out
ev_queue_max = optimized out
p = optimized out
r = optimized out
i = optimized out
m = 1
timedout = false
__PRETTY_FUNCTION__ = sd_event_run
#8  0xb7731f13 in manager_loop (m=0xb79c6bd0) at ../src/core/manager.c:1912
wait_usec = 18446744073709551615
rl = {interval = 100, begin = 432639580, burst = 5, num = 26074}
__PRETTY_FUNCTION__ = manager_loop
__func__ = manager_loop
#9  0xb7685062 in main (argc=1, argv=0xbfe55314) at ../src/core/main.c:1743
m = optimized out
---Type return to continue, or q return to quit---
r = optimized out
retval = 1
before_startup = optimized out
after_startup = optimized out
timespan =  
!4\267@\373d\267\234u_\267\070tE\267\364^_\267\001\000\000\000\000\000\000\000 
\364e\267\210Q\345\277\000\060g\267dO\345\277 \372d\267

Re: [systemd-devel] Small fixes to accelerometer

2014-12-30 Thread Paul Menzel

Dear Robert,


thank you for your patch. You should tag patches with [PATCH] in the
subject. Your MUA (mail client) Claws Mail can probably even import the
mbox file `git format-patch -1` creates, which you attached.


Am Dienstag, den 30.12.2014, 09:23 +0100 schrieb Robert Milasan:
 From 7aaa2c1b6b6a6d0ef391610e932d6eff010dea41 Mon Sep 17 00:00:00 2001
 From: Robert Milasan rmila...@suse.com
 Date: Tue, 30 Dec 2014 09:20:42 +0100
 Subject: [PATCH] accelerometer: drop unused -x option, display short options
  too.

As you can see from the line break in the summary, it is too long, which
in this case stems from the fact, that you have one commit for two
issues. It’s good measure to send one patch for one problem.

Could you please submit two patches instead? `git add -p` helps here.
Please ask if you need help splitting the commit up.

 ---
  src/udev/accelerometer/accelerometer.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/udev/accelerometer/accelerometer.c 
 b/src/udev/accelerometer/accelerometer.c
 index dd4b7dc..9c13d97 100644
 --- a/src/udev/accelerometer/accelerometer.c
 +++ b/src/udev/accelerometer/accelerometer.c
 @@ -198,8 +198,8 @@ static void test_orientation(struct udev *udev,
  static void help(void)
  {
  printf(Usage: accelerometer [options] device path\n
 - --debug debug to stderr\n
 - --help  print this help text\n\n);
 + -d,--debug debug to stderr\n
 + -h,--help  print this help text\n\n);

Should there be a space after the `,`? Do the descriptions still align
well.

  }
  
  int main (int argc, char** argv)
 @@ -229,7 +229,7 @@ int main (int argc, char** argv)
  while (1) {
  int option;
  
 -option = getopt_long(argc, argv, dxh, options, NULL);
 +option = getopt_long(argc, argv, dh, options, NULL);

Good find!

  if (option == -1)
  break;


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] accelerometer: display short options too

2014-12-30 Thread Paul Menzel

Am Dienstag, den 30.12.2014, 18:58 +0100 schrieb Robert Milasan:
 ---
  src/udev/accelerometer/accelerometer.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

Awesome! Thank you for splitting these up and submitting a v2!

 diff --git a/src/udev/accelerometer/accelerometer.c
 b/src/udev/accelerometer/accelerometer.c index 23d6f78..9c13d97 100644
 --- a/src/udev/accelerometer/accelerometer.c
 +++ b/src/udev/accelerometer/accelerometer.c
 @@ -198,8 +198,8 @@ static void test_orientation(struct udev *udev,
  static void help(void)
  {
  printf(Usage: accelerometer [options] device path\n
 - --debug debug to stderr\n
 - --help  print this help text\n\n);
 + -d,--debug debug to stderr\n
 + -h,--help  print this help text\n\n);

1. I still wonder if the description is aligned after this patch is
applied.
2. A space after the comma, `-d, --debug` would be helpful in my
opinion.

  }
  
  int main (int argc, char** argv)


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd: Program terminated with signal SIGFPE, Arithmetic exception.

2015-01-05 Thread Paul Menzel

Am Montag, den 05.01.2015, 17:57 +0100 schrieb Lennart Poettering:
 On Tue, 30.12.14 16:51, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

  using Debian Sid/unstable with systemd 215-8, I still have problems that
  there are time-outs between systemd and D-Bus, even with the current
  D-Bus 1.8.12 [1]. Experiencing this again, where
  `systemd-logind.service` was not started, I was able to log in on tty1
  but in the end I was unable to run any `sudo systemctl` commands as they
  timed out. I also was unable to reboot or halt the system.
  
  Somewhere in that situation systemd also crashed with an arithmetic
  exception; logged as `Caught FPE` in `/var/log/syslog`.
  
  I created ticket #87349 in the Freedesktop.org Bugzilla bug tracker [2].
  The backtrace is pasted in the original upstream bug report and in this
  message at the end.
 
 Is there any known, easy way to reproduce the issue?

Sorry, I do not know of one and I was not able to reproduce it another
time.

 Is it possible that something in your boot causes the systemd
 configuration to be reloaded?

Sorry, I do not know. Any idea, how I can check that?

 I now made some changes to git
 (9c3349e23b14db27e7ba45f82cf647899c563ea9) that add an explicit
 assert() around the line where the devision by zero happens. Most
 likely the counting of running jobs got confused, hence I reworked
 that code too. Not sure if it fixes the issue, but I can't test this,
 since I have no idea how to trigger it...
 
 Anyway, would be good if you could check current git, to see if things
 are better for you...

Thank you. Do you think it would be good for distributions to backport
it?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Analyzing and debugging userspace services (with e. g. Valgrind)

2015-04-02 Thread Paul Menzel

Dear systemd folks,


does systemd provide an option to debug userspace services with, for
example, the instrumentation framework Valgrind [1] to find memory leaks
or analyze the memory usage in more detail?

If it does not, should such a feature be added? Would it be useful, to
just have a switch or option `Valgrind=true` or something like it? It’d
also be nice to just have a global switch `systemd.valgrind=1` and
systemd will run each service under Valgrind. Problems lie as always in
the details, like if and how suppression files should be passed.

Or should just the unit/service file be edited?


Thanks,

Paul


[1] http://valgrind.org


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

2015-04-02 Thread Paul Menzel

Dear systemd folks,


some network cards with certain cables and devices take up to five
seconds so that the link is up [1].

$ sudo journalctl -u systemd-networkd
-- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 2015-03-22 
08:39:39 CET. --
Mär 20 17:39:31 myhostname systemd-networkd[245]: lo  : 
gained carrier
Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0: 
link configured
Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0: 
gained carrier

This is annoying if the system is up, but you cannot log into a server
because the NIC is so slow configuring the link.

The Linux kernel module developers from the e1000-devel mailing list
suggested the following [2]:

 Both sides either need to be forced or both sides need to be auto-neg.
 Otherwise the auto-negotiation process will usually detect link (the
 physical signal) but fail to find duplex (since one side is not
 talking) and default to the lowest common denominator, e.g. half
 duplex.  So, you could try forcing speed, it may look right on your
 end but if you have no visibility to the other end it could be running
 at half duplex.

 You may be able to speed up the auto negotiation process by
 exclusively advertising 1000 Mbps Full Duplex.

 # ethtool -s ethX advertise 0x20

In the IRC channel #syst...@irc.freenode.net somebody told me to look
into systemd’s network link configuration (`man systemd.link`).

Reading the manual page, it’s not clear to me, if auto-negotiation is
going to be disabled, if the following is set.

BitsPerSecond=1G
Duplex=Full

Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
could I set that up?


Thanks,

Paul


[1] http://sourceforge.net/p/e1000/mailman/message/33623906/
[2] http://sourceforge.net/p/e1000/mailman/message/33635403/


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

2015-05-02 Thread Paul Menzel

Dear poma,


Thank you for the reply with a test and sorry for my late reply. I was
unfortunately unable to test this on the server, as there was no
maintenance window yet. It’s still on my todo list though.

Am Donnerstag, den 09.04.2015, 00:28 +0200 schrieb poma:
 On 08.04.2015 23:05, Lennart Poettering wrote:
  On Wed, 08.04.15 22:13, Paul Menzel wrote:
  
  Wouldn't it suffice to unplug the ethernet cable, then use ethtool to
  turn this on, then replug it, and measuring the time until networkd
  notices the link beat is back?
 
  It would. But this is a rented Hetzner server and I have no access to
  the data center. Do you have another idea. Please keep in mind that I
  also only have remote access using that NIC. ;-)
  
  Then, I figure a udev rule should do. Something like this (untested:)
  
  ACTION==add, SUBSYSTEM==net, KERNEL!=lo, RUN+=/usr/bin/ethtool $name 
  ...
  
  Replace the ... of course with the ethool options you need.
  
  This would then be run immediately when the device appears. If this
  makes a measurable difference, then let us know.

 /etc/udev/rules.d/10-speed1G-enp1s6.rules
 ACTION==add, SUBSYSTEM==net, RUN+=/usr/sbin/ethtool -s enp1s6 advertise 
 0x20
 
 :03 systemd[1]: Starting Network Service...
 :05 systemd-networkd[1612]: enp1s6  : link configured
 :05 systemd-networkd[1612]: enp1s6  : gained carrier
 :06 systemd-networkd[1612]: enp1s6  : lost carrier
 :09 systemd-networkd[1612]: enp1s6  : gained carrier
 
 ~~~
 
 /etc/udev/rules.d/10-speed1G-enp1s6.rules-
 
 :15 systemd[1]: Starting Network Service...
 :17 systemd-networkd[1633]: enp1s6  : link configured
 :17 systemd-networkd[1633]: enp1s6  : gained carrier

So in your case, `gained carrier` is indeed shown earlier saving two
seconds. The next message probably indicates a problem with the driver.

Poma, what Linux kernel do you use?

Lennart, is poma’s test sufficient to show that integrating an
`advertise` command(?) into systemd-networkd would be useful?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

2015-04-06 Thread Paul Menzel

Am Freitag, den 03.04.2015, 16:47 +0200 schrieb Lennart Poettering:
 On Thu, 02.04.15 13:11, Paul Menzel wrote:

  some network cards with certain cables and devices take up to five
  seconds so that the link is up [1].
  
  $ sudo journalctl -u systemd-networkd
  -- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 2015-03-22 
  08:39:39 CET. --
  Mär 20 17:39:31 myhostname systemd-networkd[245]: lo  : 
  gained carrier
  Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0: 
  link configured
  Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0: 
  gained carrier
  
  This is annoying if the system is up, but you cannot log into a server
  because the NIC is so slow configuring the link.
  
  The Linux kernel module developers from the e1000-devel mailing list
  suggested the following [2]:
  
   Both sides either need to be forced or both sides need to be auto-neg.
   Otherwise the auto-negotiation process will usually detect link (the
   physical signal) but fail to find duplex (since one side is not
   talking) and default to the lowest common denominator, e.g. half
   duplex.  So, you could try forcing speed, it may look right on your
   end but if you have no visibility to the other end it could be running
   at half duplex.
  
   You may be able to speed up the auto negotiation process by
   exclusively advertising 1000 Mbps Full Duplex.
  
   # ethtool -s ethX advertise 0x20
  
  In the IRC channel #syst...@irc.freenode.net somebody told me to look
  into systemd’s network link configuration (`man systemd.link`).
  
  Reading the manual page, it’s not clear to me, if auto-negotiation is
  going to be disabled, if the following is set.
  
  BitsPerSecond=1G
  Duplex=Full
  
  Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
  could I set that up?
 
 BitsPerSecond= and Duplex= are equivalent to ethtool speed and
 ethtool duplex. 
 
 We currently have no setting in .link files that was equivalent to
 ethtool advertise. Maybe we could add that, Tom?
 
 Paul, are you sure that this will really cut 5s from the configuration
 time? Did you try this?

I am not sure and didn’t try this, as I do not know where to integrate
that `ethtool -s eth0 advertise …` call. In udev or `systemd-networkd`?

If somebody could help me, how I can test this, I’ll report my findings
back.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Read and publish firmware time stamps and boot time (was: bootloader time on a non-EFI bootloader)

2015-04-06 Thread Paul Menzel

[CC’ing coreboot, GRUB, SeaBIOS, Syslinux project and Linux kernel]

Am Montag, den 16.03.2015, 11:38 +0100 schrieb Kay Sievers:
On Mon, Mar 16, 2015 at 11:29 AM, Umut Tezduyar Lindskog wrote:
I would like to pass the time it was spent in bootloader to systemd.
Is there a kernel command line to pass this information on non EFI
bootloader? Or is there an another way?

No, there isn't anything I know of.

The kernel boot protocol should probably be extended to accept a block
of values to be passed from the loader to the OS, and be exported
somewhere by the kernel itself to userspace.

Overloading the kernel command line with that does not sound like the
right approach. We should not support anything like that from systemd.

Could that approach please be discussed with all firmware, payload and
firmware projects? For example, coreboot (and the depthcharge payload
used on Chromebooks and Chromeboxes) already store the time stamps in
its CBMEM, which can be read with the utility `cbmem` with `cbmem -t`
[1] or with GRUB’s `coreboot_boottime` command.

10 entries total:

10:start of ramstage 9
30:device enumeration441 (432)
40:device configuration 95,357 (94,915)
50:device enable 99,275 (3,918)
60:device initialization 109,246 (9,971)
70:device setup done 181,906 (72,659)
75:cbmem post182,274 (368)
80:write tables 182,276 (2)
90:load payload 183,873 (1,597)
99:selfboot jump 283,779 (99,905)

GRUB also has a `boottime` command outputting times like how long a
module needed to load.

One approach would be, that the Linux kernel has drivers to read the
different implementations on how to store the boot time and then exports
those to userspace.

The other approach, and probably more feasible one, is that all firmware
projects use the same standard/specification.

What is actually needed? Are pairs of

project, stage name, time in milliseconds since start of program

where each project gets assigned a unique ID. Do you need more data?

Thanks,

Paul

[1]
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=util/cbmem/cbmem.c;h=4314d3077f2f657190d9afd63234d9621c59eb91;hb=HEAD

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

2015-04-08 Thread Paul Menzel

Am Dienstag, den 07.04.2015, 18:37 +0200 schrieb Lennart Poettering:
 On Mon, 06.04.15 22:16, Paul Menzel wrote:
 
  Am Freitag, den 03.04.2015, 16:47 +0200 schrieb Lennart Poettering:
   On Thu, 02.04.15 13:11, Paul Menzel wrote:
  
some network cards with certain cables and devices take up to five
seconds so that the link is up [1].

$ sudo journalctl -u systemd-networkd
-- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 
2015-03-22 08:39:39 CET. --
Mär 20 17:39:31 myhostname systemd-networkd[245]: lo
  : gained carrier
Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0  
  : link configured
Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0  
  : gained carrier

This is annoying if the system is up, but you cannot log into a server
because the NIC is so slow configuring the link.

The Linux kernel module developers from the e1000-devel mailing list
suggested the following [2]:

 Both sides either need to be forced or both sides need to be auto-neg.
 Otherwise the auto-negotiation process will usually detect link (the
 physical signal) but fail to find duplex (since one side is not
 talking) and default to the lowest common denominator, e.g. half
 duplex.  So, you could try forcing speed, it may look right on your
 end but if you have no visibility to the other end it could be running
 at half duplex.

 You may be able to speed up the auto negotiation process by
 exclusively advertising 1000 Mbps Full Duplex.

 # ethtool -s ethX advertise 0x20

In the IRC channel #syst...@irc.freenode.net somebody told me to look
into systemd’s network link configuration (`man systemd.link`).

Reading the manual page, it’s not clear to me, if auto-negotiation is
going to be disabled, if the following is set.

BitsPerSecond=1G
Duplex=Full

Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
could I set that up?
   
   BitsPerSecond= and Duplex= are equivalent to ethtool speed and
   ethtool duplex. 
   
   We currently have no setting in .link files that was equivalent to
   ethtool advertise. Maybe we could add that, Tom?
   
   Paul, are you sure that this will really cut 5s from the configuration
   time? Did you try this?
  
  I am not sure and didn’t try this, as I do not know where to integrate
  that `ethtool -s eth0 advertise …` call. In udev or `systemd-networkd`?
  
  If somebody could help me, how I can test this, I’ll report my findings
  back.
 
 Wouldn't it suffice to unplug the ethernet cable, then use ethtool to
 turn this on, then replug it, and measuring the time until networkd
 notices the link beat is back?

It would. But this is a rented Hetzner server and I have no access to
the data center. Do you have another idea. Please keep in mind that I
also only have remote access using that NIC. ;-)


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd as Docker process manager (was: Docker, Supervisor and systemd)

2015-07-19 Thread Paul Menzel

Dear Lennart,


a late thank you for your reply!


Am Freitag, den 21.02.2014, 19:39 +0100 schrieb Lennart Poettering:
 On Thu, 20.02.14 23:25, Paul Menzel wrote:
  
  Docker, “an open-source project to easily create lightweight, 
  portable, self-sufficient containers from any application”, [1] 
  mostly recommends to use Supervisor [2] to control the processes to 
  be run in the container, like starting and restarting them and 
  logging the output.
  Actually all things systemd also does to my knowledge. Supervisor 
  also needs a configuration file for each process, which it should 
  start.
  
  Has somebody experiences to use systemd for that? Or is there a 
  reason why systemd should not be used for that?
 
 systemd should work fine for that. I figure systemd is not yet
 everywhere hence they suggest an option you can install everywhere...
 
 I had a look at the configuration file language of supervisord. THere
 appears to be nothing interesting we couldn't do already. I mean, 
 there are certain differences, for example they have an XMLRPC API, 
 while ours is via D-Bus, but other than that I don't see much... They 
 have some fcgi hookup, but I don't grok that, and I figure we already 
 can do kinda the same with socket activation, but dunno...

Finally, I looked into this topic again to use systemd as the process
manager for a Docker container. I found Dan Walsh’s great post *Running
systemd within a docker container*, written two month after my message
to the systemd-devel list, talking about some bugs and other issues,
where most of them are solved now with at least Docker 1.6, so systemd
can be used without much problems as the process manager.

To my knowledge there are two issue left. I enumerate these below and
add two more general questions.

1. The capability `SYS_ADMIN` has to be given(?) to the Docker
container.

--cap-add SYS_ADMIN

Otherwise things like `systemctl` do not work and fail with the message
that D-Bus is not available.

Reading the manual page *capabilities* (`man 7 capabilities` [1]) shows
quite an excessive list.

   CAP_SYS_ADMIN
  * Perform a range of system administration operations
including: quotactl(2), mount(2), umount(2), swapon(2),
setdomainname(2);
  * perform privileged syslog(2) operations (since Linux 2.6.37,
CAP_SYSLOG should be used to permit such operations);
  * perform VM86_REQUEST_IRQ vm86(2) command;
  * perform IPC_SET and IPC_RMID operations on arbitrary System
V IPC objects;
  * override RLIMIT_NPROC resource limit;
  * perform operations on trusted and security Extended
Attributes (see xattr(7));
  * use lookup_dcookie(2);
  * use ioprio_set(2) to assign IOPRIO_CLASS_RT and (before
Linux 2.6.25) IOPRIO_CLASS_IDLE I/O scheduling classes;
  * forge PID when passing socket credentials via UNIX domain
sockets;
  * exceed /proc/sys/fs/file-max, the system-wide limit on the
number of open files, in system calls that open files (e.g.,
accept(2), execve(2), open(2), pipe(2));
  * employ CLONE_* flags that create new namespaces with
clone(2) and unshare(2) (but, since Linux 3.8, creating user
namespaces does not require any capability);
  * call perf_event_open(2);
  * access privileged perf event information;
  * call setns(2) (requires CAP_SYS_ADMIN in the target
namespace);
  * call fanotify_init(2);
  * perform KEYCTL_CHOWN and KEYCTL_SETPERM keyctl(2)
operations;
  * perform madvise(2) MADV_HWPOISON operation;
  * employ the TIOCSTI ioctl(2) to insert characters into the
input queue of a terminal other than the caller's
controlling terminal;
  * employ the obsolete nfsservctl(2) system call;
  * employ the obsolete bdflush(2) system call;
  * perform various privileged block-device ioctl(2) operations;
  * perform various privileged filesystem ioctl(2) operations;
  * perform administrative operations on many device drivers.

So a container with that capability won’t be that contained anymore.

Do you know of a way to run systemd within the container without adding
the capability SYS_ADMIN?

2. systemd-docker [4][7]

Quoting the systemd-docker README.md [4]:

 Why I wrote this?

 The full context is in Docker Issue #6791 [5] and this mailing list
 thread [6]. The short of it is that systemd does not actually
 supervise the Docker container but instead the Docker client. This
 makes systemd incapable of reliably managing Docker containers
 without hitting a bunch of really odd situations.

Is it planned to solve this in systemd somehow

[systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

2016-06-18 Thread Paul Menzel

Dear systemd folks,


the setup is as follows.

Nginx is used as the Web server, which communicates with a Ruby on
Rails application over a socket. Puma [1] is used as the application
server.

Nginx and Puma are managed by systemd service files.

If a new version of the application is installed, the goal is that
there is no downtime. That means, until the application with the new
code isn’t ready yet to serve requests, the old application still
answers them, that means, not only are no requests lost, but during
restart the visitor does not need to wait any longer than normally.

In this case, JRuby is used, which means that application start, `sudo
systemctl start web-application.service` takes more than 30 seconds.

So, `sudo systemctl restart web-application.service` is not enough as
Puma takes some time to be started. (The socket activation described in
the Puma systemd documentation [2] only takes care, that no requests
are lost. The visitor still has to wait.)

Is that possible by just using systemd, or is a load balancer like
HAProxy or a special NGINX configuration and service file templates
needed?

My current thinking would be, that a service file template for the Puma
application server is used. The new code is then started in parallel,
and if it’s done, it “takes over the socket”. (No idea if NGINX would
need to be restarted.) Then the old version of the code is stopped. (I
don’t know how to model that last step/dependency.)

What drawbacks does the above method have? Is it implementable?

How do you manage such a setup?


Thanks,

Paul


[1] http://puma.io/
[2] https://github.com/puma/puma/blob/master/docs/systemd.md

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Depending on services from a service unit template

2016-06-27 Thread Paul Menzel

Dear systemd folks,


having a template for a service unit like `example@.service`, and
starting several services from it, is there a way, to let another
service unit require all services started from that template?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Depending on services from a service unit template

2016-06-30 Thread Paul Menzel

Dear Michael, dear Andrei,

Thank you for replying.

Am Montag, den 27.06.2016, 15:37 +0200 schrieb Michael Biebl:
> 2016-06-27 13:49 GMT+02:00 Andrei Borzenkov <arvidj...@gmail.com>:
> > On Mon, Jun 27, 2016 at 9:25 AM, Paul Menzel wrote:

> > > having a template for a service unit like `example@.service`, and
> > > starting several services from it, is there a way, to let another
> > > service unit require all services started from that template?
> > 
> > I do not think it is possible. In other direction it may work with
> > some workaround (i.e. make every instance of template be required
> > by specific services).
> 
> PartOf= in the template service might be what you are looking for.

From the manual page systemd.unit:

>    PartOf=
>    Configures dependencies similar to Requires=, but limited
> to stopping and restarting of units. When systemd stops or restarts
> the units listed here, the action is propagated to this unit. Note
> that this is a one-way dependency — changes to this unit do not
> affect the listed units.

So, it could indeed be what I am looking for. In my use case, it
doesn’t feel right yet though.

There are several instances of a Web application started from
example@.service. In front of it is the proxy HAProxy.

So in my reading, saying that the Web application instances is a *part
of* HAProxy, doesn’t totally feel/sound right to me.

Also, asking for `Requires=` was, that HAProxy seems to check the
configured backends to run, and refuses to start if they don’t. That’s
why, all the Web applications are required before the HAProxy start-up.

If I am not mistaken, `PartOf=` does not solve that problem.

Do you have another suggestion?

Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Strange output of `systemd-analyze critical-chain`

2016-11-15 Thread Paul Menzel

Dear systemd folks,


I am using systemd 232-3 from Debian sid/unstable.

```
$ systemd --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDNar systemd 
folks,
```

On the underpowered ASRock E350M1, startup is quite slow.

The output of `systemd-analyze blame` also looks quite strange.

```
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @3min 6.269s
└─acct.service @6min 32.163s +55ms
  └─basic.target @1min 29.644s
    └─paths.target @1min 29.639s
  └─cups.path @1min 29.634s
    └─sysinit.target @1min 29.554s
  └─systemd-timesyncd.service @1min 29.275s +263ms
    └─systemd-tmpfiles-setup.service @1min 28.575s +620ms
  └─systemd-journal-flush.service @13.493s +1min 15.054s
    └─var.mount @12.408s +1.057s
  └─systemd-fsck@dev-map\x2dvar.service @12.377s +17ms
    └─dev-mapper-speicher\x2dvar.device @12.205s
```

It jumps from 1:30 to 6:32 minutes but the difference is shown as 55
ms.

As written, the systemd is quite underpowered. Might that be the
reason?

Here is the output of `systemd-analyze blame`.

```
5min 39.610s apt-daily.service
1min 21.012s tor@default.service
1min 15.054s systemd-journal-flush.service
 1min 9.497s NetworkManager-wait-online.service
 53.514s libvirt-guests.service
 20.218s libvirtd.service
 16.227s timidity.service
 15.682s accounts-daemon.service
 12.913s NetworkManager.service
 12.889s vdr.service
 11.915s apache2.service
 11.143s ModemManager.service
 10.434s dev-mapper-speicher\x2dusr.device
 10.349s lirc.service
  9.904s dev-mapper-speicher\x2droot.device
  8.397s irqbalance.service
  7.531s exim4.service
  7.164s srv-bilder.mount
  6.602s tor.service
  6.568s lm-sensors.service
  6.542s klogd.service
  6.539s restorecond.service
  6.518s rsyslog.service
  6.509s pppd-dns.service
  6.241s minissdpd.service
  5.343s colord.service
  4.982s ebtables.service
  4.702s kdump-tools.service
  4.631s polkit.service
  4.620s rc-local.service
  3.853s srv-filme.mount
  3.302s binfmt-support.service
  3.235s networking.service
  3.157s lvm2-monitor.service
  3.063s ssh.service
  2.732s keyboard-setup.service
  2.281s boot.mount
  2.151s systemd-tmpfiles-setup-dev.service
  1.915s gdm.service
  1.857s systemd-tmpfiles-clean.service
  1.788s console-setup.service
  1.687s dev-mapper-speicher\x2dswap.swap
  1.681s systemd-cryptsetup@md1_crypt.service
  1.603s home.mount
  1.270s iio-sensor-proxy.service
  1.258s systemd-sysctl.service
  1.063s systemd-random-seed.service
  1.058s systemd-udevd.service
  1.057s var.mount
  1.049s speech-dispatcher.service
  1.031s udhcpd.service
[…]
```

Do you know what is going on?


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Short way to show messages of executable and unit with `journalctl`

2017-04-14 Thread Paul Menzel

Dear systemd folks,


Is there a shorter way than below to show all messages of an executable
and a unit?

```
$ journalctl _COMM=sudo + _SYSTEMD_UNIT=NetworkManager.service
```

I would be happy about a command, that involves `-u` so that I don’t
have to type the suffix `.service`.


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFH] How to analyze long load time of `systemd-timesyncd`?

2017-04-19 Thread Paul Menzel

Dear systemd folks,


I am trying to figure out why `systemd-timesyncd` takes quite some
time, that means over 100 ms, to start up on several systems [1]. This
is also reproducible with systemd 232 from Debian Sid/unstable.

After adding `log_info()` statements to the source code, as told in
#syst...@irc.freenode.net, it looks like the time is spend before the
`main()` is called. Is the flow documented somewhere? Who prints
`Starting Network Time Synchronization...`, and then what happens?

It’d be awesome if you could help me, how to further debug this issue.

```
$ journalctl -u systemd-timesyncd -o short-monotonic -b
-- Logs begin at Tue 2016-09-13 14:51:22 CEST, end at Tue 2017-04-18 16:14:36 
CEST. --
[7.694166] mysystem systemd[1]: Starting Network Time Synchronization...
[8.942021] mysystem systemd-timesyncd[311]: After log_set_target
[8.942021] mysystem systemd-timesyncd[311]: After log_set_facility
[8.942805] mysystem systemd-timesyncd[311]: After log_parse_environment
[8.943063] mysystem systemd-timesyncd[311]: After log_open
[8.943271] mysystem systemd-timesyncd[311]: After get_user_creds
[8.943465] mysystem systemd-timesyncd[311]: load_clock_timestamp: before 
open /systemd/clock
[9.103315] mysystem systemd-timesyncd[311]: load_clock_timestamp: after 
open /systemd/clock
[9.103493] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after fstat
[9.103642] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
before timespec_load
[9.103790] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after timespec_load
[9.103933] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
before fchmod
[9.104097] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after fchmod
[9.104238] mysystem systemd-timesyncd[311]: load_clock_timestamp: in if, 
after fchown
[9.104377] mysystem systemd-timesyncd[311]: load_clock_timestamp: before 
now(CLOCK_REALTIME)
[9.104522] mysystem systemd-timesyncd[311]: load_clock_timestamp: after 
now(CLOCK_REALTIME)
[9.104661] mysystem systemd-timesyncd[311]: load_clock_timestamp: before 
return
[9.104801] mysystem systemd-timesyncd[311]: After load_clock_timestamp
[9.104944] mysystem systemd-timesyncd[311]: After drop_privileges
[9.105086] mysystem systemd-timesyncd[311]: After manager_new
[9.298678] mysystem systemd-timesyncd[311]: After manager_parse_config_file
[9.298894] mysystem systemd-timesyncd[311]: Before sd_notify
[9.299048] mysystem systemd[1]: Started Network Time Synchronization.
```


Thanks,

Paul


[1] https://github.com/systemd/systemd/issues/5024

signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to set `InitRDTimestampMonotonic` from console?

2018-07-03 Thread Paul Menzel


Dear systemd folks,


Debian uses a shell script as `/init` in initrd, and I like to extend 
that, to set the time stamps for the initrd execution.


`systemd-analyze` built from `src/analyze/analyze.c` uses D-Bus to get 
the time stamp to display that.


```
   bus_get_uint64_property(bus,
"/org/freedesktop/systemd1",
"org.freedesktop.systemd1.Manager",
"InitRDTimestampMonotonic",
_time) < 0
```

In `src/core/manager.c` the value is set like below.

```
if 
(dual_timestamp_is_set(>timestamps[MANAGER_TIMESTAMP_INITRD])) {


/* The initrd case on bare-metal*/
kernel_usec = 
m->timestamps[MANAGER_TIMESTAMP_INITRD].monotonic - 
m->timestamps[MANAGER_TIMESTAMP_KERNEL].monotonic;
initrd_usec = 
m->timestamps[MANAGER_TIMESTAMP_USERSPACE].monotonic - 
m->timestamps[MANAGER_TIMESTAMP_INITRD].monotonic;


log_struct(LOG_INFO,
   "MESSAGE_ID=" 
SD_MESSAGE_STARTUP_FINISHED_STR,

   "KERNEL_USEC="USEC_FMT, kernel_usec,
   "INITRD_USEC="USEC_FMT, initrd_usec,
   "USERSPACE_USEC="USEC_FMT, 
userspace_usec,
   LOG_MESSAGE("Startup finished in 
%s%s (kernel) + %s (initrd) + %s (userspace) = %s.",

   buf,
   format_timespan(kernel, 
sizeof(kernel), kernel_usec, USEC_PER_MSEC),
   format_timespan(initrd, 
sizeof(initrd), initrd_usec, USEC_PER_MSEC),


format_timespan(userspace, sizeof(userspace), userspace_usec, 
USEC_PER_MSEC),
   format_timespan(sum, 
sizeof(sum), total_usec, USEC_PER_MSEC)));

```




Is it possible to set that value from a shell script? If yes, could you 
please tell me how?



Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Best practices for full disk encryption with dm-crypt/LUKS

2018-02-19 Thread Paul Menzel


Dear Andrei,


Thank you for your reply.


Am 20.02.2018 um 05:41 schrieb Andrei Borzenkov:

20.02.2018 01:16, Paul Menzel пишет:



Having a system with UEFI, what is the state of the art to use full disk
encryption? I read the article in the Arch Linux wiki [1], and it still
using GRUB. There is an blog post from 2016 using systemd-boot [2].


If your kernel or initrd are located on encrypted filesystem you need
bootloader that can read them.


And can systemd-boot read it?


If there was a way without LVM, I’d prefer that.


It has always been possible, the question is to which extent individual
distributions made it easy to setup. openSUSE Tumbleweed/Leap 15
installer finally offers native encryption of plain partition without LVM.


That’s great news. To my knowledge, the Debian Installer (Debian 9 
(stretch)) isn’t able to do it.



Are there new programs or features in the systemd ecosystem making the
setup easy?


I'd say it is more initramfs implementation question - initramfs is
responsible for actually mounting your root.


What are the options? Initramfs and Dracut, right?


Kind regards,

Paul



[1] https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
[2] 
https://blog.urbanslug.com/posts/2016-09-11-dm-crypt-systemd-boot-and-efi-on-archlinux.html

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Hints for upgrading systemd on a running system

2018-02-20 Thread Paul Menzel


Dear Lennart and others,


Thank you for your prompt replies.


Am 20.02.2018 um 23:12 schrieb Lennart Poettering:

On Di, 20.02.18 20:00, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:



We finally are going to upgrade from a very old systemd version 27 from 2011
to the current systemd v237. (Historical reasons.)

Anyway, I already was told about `systemctl daemon-reexec`, and we got it
working.


While we try to ensure that live upgrades of PID 1 like that work
quite well, this is generally tested only for small steps. Jumping 6
years ahead in one go is not something people typically test.


Indeed, but it seems to work. During the upgrade you have to make sure, 
that both versions are installed in parallel when doing `systemctl 
daemon-reexec`, so the old systemd still finds it dependencies/libraries 
and can terminate properly. Then the old version can be removed.



After that, looking at the output of `systemctl`, there are many units from
the old version, which were removed in the meantime.

```
$ systemctl --state=not-found
   UNIT LOAD  ACTIVE   SUB DESCRIPTION
● dev-hugepages.automount  not-found active   waiting
dev-hugepages.automount
● dev-mqueue.automount not-found active   waiting
dev-mqueue.automount
● sys-kernel-debug.automount   not-found active   waiting
sys-kernel-debug.automount
● sys-kernel-security.automountnot-found active   waiting
sys-kernel-security.automount
● auditd.service   not-found inactive dead
auditd.service
● console-kit-log-system-start.service not-found active   exited
console-kit-log-system-start.service
● display-manager.service  not-found inactive dead
display-manager.service
● hwclock-load.service not-found active   exited
hwclock-load.service
● plymouth-quit-wait.service   not-found inactive dead
plymouth-quit-wait.service
● plymouth-start.service   not-found inactive dead
plymouth-start.service
● remount-rootfs.service   not-found active   exited
remount-rootfs.service
● syslog.service   not-found inactive dead
syslog.service
● systemd-kmsg-syslogd.service not-found active   running
systemd-kmsg-syslogd.service
● systemd-remount-api-vfs.service  not-found active   exited
systemd-remount-api-vfs.service
● systemd-sysusers.service not-found inactive dead
systemd-sysusers.service
● udev-retry.service   not-found active   exited
udev-retry.service
● udev-settle.service  not-found active   exited
udev-settle.service
● systemd-logger.socketnot-found active   listening
systemd-logger.socket
● systemd-shutdownd.socket not-found active   listening
systemd-shutdownd.socket
● cryptsetup.targetnot-found active   active
cryptsetup.target
● syslog.targetnot-found active   active
syslog.target


My recommendation: simply reboot. That should clean up everything
properly.

Note that PID 1 itself is probably pretty Ok with such a massive
update in one step, but the unit files have been rearranged quite a
bit since then. Downstream distributions generally expect you to
reboot even between single-step distro updates, but this becomes much
more of a necessity if you jump even further.


But if reboot wouldn’t be an option, is there a way to get rid of 
not-found services?



Note that systemd upstream currently requires kernel 3.13 at least
which was released in 2014. Hence, if you update from a 2011 system
you have to reboot anyway, already to update the kernel...


We already run later Linux Kernels, so that is not a problem. But thank 
you for mentioning it.



Do I need to stop those manually beforehand, or is there another way to
clean up?

Is the recommended update procedure documented somewhere?


Usually distributions document that invididually as systemd is just
one component of many that make up the distribution.


Understood.


Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Hints for upgrading systemd on a running system

2018-02-20 Thread Paul Menzel


Dear systemd folks,


We finally are going to upgrade from a very old systemd version 27 from 
2011 to the current systemd v237. (Historical reasons.)


Anyway, I already was told about `systemctl daemon-reexec`, and we got 
it working.


After that, looking at the output of `systemctl`, there are many units 
from the old version, which were removed in the meantime.


```
$ systemctl --state=not-found
  UNIT LOAD  ACTIVE   SUB 
DESCRIPTION
● dev-hugepages.automount  not-found active   waiting 
dev-hugepages.automount
● dev-mqueue.automount not-found active   waiting 
dev-mqueue.automount
● sys-kernel-debug.automount   not-found active   waiting 
sys-kernel-debug.automount
● sys-kernel-security.automountnot-found active   waiting 
sys-kernel-security.automount
● auditd.service   not-found inactive dead 
auditd.service
● console-kit-log-system-start.service not-found active   exited 
console-kit-log-system-start.service
● display-manager.service  not-found inactive dead 
display-manager.service
● hwclock-load.service not-found active   exited 
hwclock-load.service
● plymouth-quit-wait.service   not-found inactive dead 
plymouth-quit-wait.service
● plymouth-start.service   not-found inactive dead 
plymouth-start.service
● remount-rootfs.service   not-found active   exited 
remount-rootfs.service
● syslog.service   not-found inactive dead 
syslog.service
● systemd-kmsg-syslogd.service not-found active   running 
systemd-kmsg-syslogd.service
● systemd-remount-api-vfs.service  not-found active   exited 
systemd-remount-api-vfs.service
● systemd-sysusers.service not-found inactive dead 
systemd-sysusers.service
● udev-retry.service   not-found active   exited 
udev-retry.service
● udev-settle.service  not-found active   exited 
udev-settle.service
● systemd-logger.socketnot-found active   listening 
systemd-logger.socket
● systemd-shutdownd.socket not-found active   listening 
systemd-shutdownd.socket
● cryptsetup.targetnot-found active   active 
cryptsetup.target
● syslog.targetnot-found active   active 
syslog.target


LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB= The low-level unit activation state, values depend on unit type.

21 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
```

Do I need to stop those manually beforehand, or is there another way to 
clean up?


Is the recommended update procedure documented somewhere?


Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Best practices for full disk encryption with dm-crypt/LUKS

2018-02-19 Thread Paul Menzel


Dear systemd folks,


Having a system with UEFI, what is the state of the art to use full disk 
encryption? I read the article in the Arch Linux wiki [1], and it still 
using GRUB. There is an blog post from 2016 using systemd-boot [2].


If there was a way without LVM, I’d prefer that.

Are there new programs or features in the systemd ecosystem making the 
setup easy?



Kind regards,

Paul


[1] 
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
[2] 
https://blog.urbanslug.com/posts/2016-09-11-dm-crypt-systemd-boot-and-efi-on-archlinux.html

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to profile units with perf? (was: logind: How to process enumerate buttons in parallel?)

2018-07-18 Thread Paul Menzel

Dear systemd folks,

On 07/16/18 11:26, Lennart Poettering wrote:
> On Mo, 16.07.18 10:25, Paul Menzel wrote:

[…]

>> Do you have suggestions how to do that with systemd-logind?
> 
> People tend to use "perf" for things like this these days.

Thank you, that’s what I wanted to use, but I am not really sure how
to do it with systemd units?

I failed by adapting the systemd-logind Exec line, as the permissions
for the perf counters(?) are not there.

Then I tried to add a perf service unit doing

/usr/sbin/perf_4.17 record -o /dev/shm/perf.data sleep 10

and order it before sysinit.target but that did not contain anything
useful.

Kind regads,

Paul

smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] logind: How to process enumerate buttons in parallel?

2018-07-16 Thread Paul Menzel

Dear Lennart,


Thank you for your response.


On 07/13/18 17:12, Lennart Poettering wrote:
> On Do, 12.07.18 16:51, Paul Menzel wrote:

>> Trying to decrease the start-up time, I noticed that `systemd-logind`
>> probes devices in serial(?) (instead of parallel).
>>
>> From `manager_enumerate_buttons(Manager *m)` in `src/login/logind.c`:
>>
>> ```
>> udev_list_entry_foreach(item, first) {
>> _cleanup_(udev_device_unrefp) struct udev_device *d = NULL;
>> int k;
>>
>> d = udev_device_new_from_syspath(m->udev, 
>> udev_list_entry_get_name(item));
>> if (!d)
>> return -ENOMEM;
>>
>> k = manager_process_button_device(m, d);
>> if (k < 0)
>> r = k;
>> }
>> ```
>>
>> The macro is defined as below:
>>
>> ```
>> /**
>>  * udev_list_entry_foreach:
>>  * @list_entry: entry to store the current position
>>  * @first_entry: first entry to start with
>>  *
>>  * Helper to iterate over all entries of a list.
>>  */
>> #define udev_list_entry_foreach(list_entry, first_entry) \
>> for (list_entry = first_entry; \
>>  list_entry != NULL; \
>>  list_entry = udev_list_entry_get_next(list_entry))
>> ```
>>
>> Is there a way to do that in parallel?
> 
> systemd components are generally single threaded. Probing input
> devices from systemd is unlikely to be a performance problem. I mean,
> we don't process 10K devices here, but usually not more than 25 or
> so... Also the code isn't really CPU or IO bound here, it just does a
> few open() and ioctl() calls mostly.

By the way, below are the timings from the journal.

```
$ journalctl -o short-precise -u systemd-logind.service -b
-- Logs begin at Sat 2017-12-16 23:28:06 CET, end at Mon 2018-07-16 08:23:11 
CEST. --
Jul 16 08:22:54.006190 kodi systemd[1]: Starting Login Service...
Jul 16 08:22:54.103445 kodi systemd-logind[169]: New seat seat0.
Jul 16 08:22:54.163713 kodi systemd[1]: Started Login Service.
Jul 16 08:22:54.312955 kodi systemd-logind[169]: Watching system buttons on 
/dev/input/event1 (Power Button)
Jul 16 08:22:54.514965 kodi systemd-logind[169]: Watching system buttons on 
/dev/input/event0 (Power Button)
Jul 16 08:22:54.781082 kodi systemd-logind[169]: Watching system buttons on 
/dev/input/event2 (AT Translated Set 2 keyboard)
```

> Before spending time on optimizing anything like this: did you did
> profiling on this, that shows clearly that this is performance
> relevant at all?

Do you have suggestions how to do that with systemd-logind?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to set `InitRDTimestampMonotonic` from console?

2018-07-04 Thread Paul Menzel


Dear Dimitri,


Am 04.07.2018 um 12:24 schrieb Dimitri John Ledkov:


On 4 July 2018 at 10:22, Lennart Poettering  wrote:

On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:


Dear systemd folks,


Debian uses a shell script as `/init` in initrd, and I like to extend that,
to set the time stamps for the initrd execution.


This is part of the data that is serialized during the transition from
the systemd instance in the initrd to the systemd instance on the
host. The serialization is internal to systemd, and this is unlikely
to change, as it contains numerous bits of information that are
fragile and sensitive as the serialization really contains the full
service manager state with all its units and so on.


Is it possible to set that value from a shell script? If yes, could you
please tell me how?


It's not, and quite frankly I am not enthusiastic about the idea to
make this configurable...


At one point, I was considering to serialize just enough data to add
these in the initramfs-tools (and/or systemd) as Debian specific
patches to start supporting these measurements.
And have a distro patch in systemd to read these measurements from a
separately serialized file on boot-up.


Yeah, that wolud be good to have. Do you know, if there are feature 
requests for these already?



Also, there are bootloader measurements, that I think we do not
receive either from grub.


With Ubuntu 18.04 on a TUXEDO Book BU1406 with Ubuntu 18.04, UEFI 
firmware and GRUB, I get the output below.



Startup finished in 5.793s (firmware) + 3.339s (loader) + 7.002s (kernel) + 
8.107s (userspace) = 24.242s



Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] logind: How to process enumerate buttons in parallel?

2018-07-12 Thread Paul Menzel

Dear systemd folks,


Trying to decrease the start-up time, I noticed that `systemd-logind`
probes devices in serial(?) (instead of parallel).

From `manager_enumerate_buttons(Manager *m)` in `src/login/logind.c`:

```
udev_list_entry_foreach(item, first) {
_cleanup_(udev_device_unrefp) struct udev_device *d = NULL;
int k;

d = udev_device_new_from_syspath(m->udev, 
udev_list_entry_get_name(item));
if (!d)
return -ENOMEM;

k = manager_process_button_device(m, d);
if (k < 0)
r = k;
}
```

The macro is defined as below:

```
/**
 * udev_list_entry_foreach:
 * @list_entry: entry to store the current position
 * @first_entry: first entry to start with
 *
 * Helper to iterate over all entries of a list.
 */
#define udev_list_entry_foreach(list_entry, first_entry) \
for (list_entry = first_entry; \
 list_entry != NULL; \
 list_entry = udev_list_entry_get_next(list_entry))
```

Is there a way to do that in parallel?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to reduce time to between Linux’ `run_init_process()` and systemd banner?

2018-07-13 Thread Paul Menzel


Dear systemd folks,


Trying to decrease the boot time, I got rid of the initrd. Now, there
is a noticeable delay between Linux `run_init_process()` and the first
systemd message.

I added an output line to the Linux function.

```
static int run_init_process(const char *init_filename)
{
argv_init[0] = init_filename;

pr_info("Run %s as init process\n", init_filename);
return do_execve(getname_kernel(init_filename),
(const char __user *const __user *)argv_init,
(const char __user *const __user *)envp_init);
}
```

Here you see the result on a system (ASRock E350M1) with an SDD
(spinning).

```
[0.287632] Run /sbin/init as init process
[0.547261] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
-PCRE2 default-hierarchy=hybrid)

```

The systemd binary is only 2.3 MB in size, so I do not think that
this is the loading time.

$ ls -lh /lib/systemd/systemd
-rwxr-xr-x 2 root root 2.3M Mar 12 13:44 /lib/systemd/systemd

Is there a way, to get a message from systemd as early as possible
to see where the time is spent?

`log_execution_mode(_boot)` is not at the beginning in
`main()` in `src/core/main.c`. I guess the “console” needs to be
set up first?

Any help is appreciated.


Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to reduce time to between Linux’ `run_init_process()` and systemd banner?

2018-07-13 Thread Paul Menzel


Dear systemd folks,


I forgot to attach the logs.


Am 13.07.2018 um 20:20 schrieb Paul Menzel:


Trying to decrease the boot time, I got rid of the initrd. Now, there
is a noticeable delay between Linux `run_init_process()` and the first
systemd message.

I added an output line to the Linux function.

```
static int run_init_process(const char *init_filename)
{
     argv_init[0] = init_filename;

     pr_info("Run %s as init process\n", init_filename);
     return do_execve(getname_kernel(init_filename),
     (const char __user *const __user *)argv_init,
     (const char __user *const __user *)envp_init);
}
```

Here you see the result on a system (ASRock E350M1) with an SDD
(spinning).

```
[    0.287632] Run /sbin/init as init process
[    0.547261] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
-PCRE2 default-hierarchy=hybrid)

```

The systemd binary is only 2.3 MB in size, so I do not think that
this is the loading time.

     $ ls -lh /lib/systemd/systemd
     -rwxr-xr-x 2 root root 2.3M Mar 12 13:44 /lib/systemd/systemd

Is there a way, to get a message from systemd as early as possible
to see where the time is spent?

`log_execution_mode(_boot)` is not at the beginning in
`main()` in `src/core/main.c`. I guess the “console” needs to be
set up first?

Any help is appreciated.



Kind regards,

Paul
[0.00] Linux version 4.18.0-rc4-00097-g33ec366fda95 (root@f2fc51708d66) 
(gcc version 7.3.0 (Debian 7.3.0-24)) #96 SMP Fri Jul 13 15:26:28 UTC 2018
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] type 16
[0.00] BIOS-e820: [mem 0x1000-0x0009] usable
[0.00] BIOS-e820: [mem 0x000c-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xc7d3bfff] usable
[0.00] BIOS-e820: [mem 0xc7d3c000-0xc7ff] type 16
[0.00] BIOS-e820: [mem 0xc800-0xdfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00011eff] usable
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0xc7d3c max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-back
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFC0 mask FFFC0 write-protect
[0.00]   1 base 0C000 mask FF800 write-back
[0.00]   2 base 08000 mask FC000 write-back
[0.00]   3 base 0 mask F8000 write-back
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00011f00 aka 4592M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] Scanning 1 areas for low memory corruption
[0.00] initial memory mapped: [mem 0x-0x0fff]
[0.00] Base memory trampoline at [(ptrval)] 9b000 size 16384
[0.00] BRK [0x0fc61000, 0x0fc61fff] PGTABLE
[0.00] log_buf_len: 33554432 bytes
[0.00] early log buf free: 259860(99%)
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F0800 24 (v02 CORE  )
[0.00] ACPI: XSDT 0xC7D4D0E0 6C (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: FACP 0xC7D4F850 F4 (v04 CORE   COREBOOT 
 CORE )
[0.00] ACPI: DSDT 0xC7D4D280 0025C7 (v02 ASROCK COREBOOT 
00010001 INTL 20180629)
[0.00] ACPI: FACS 0xC7D4D240 40
[0.00] ACPI: FACS 0xC7D4D240 40
[0.00] ACPI: SSDT 0xC7D4F950 8A (v02 CORE   COREBOOT 
002A CORE 002A)
[0.00] ACPI: TCPA 0xC7D4F9E0 32 (v02 CORE   COREBOOT 
 CORE )
[0.00] ACPI: APIC 0xC7D4FA20 5C (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: HEST 0xC7D4FA80 28 (v01 CORE   COREBOOT 
 CORE )
[0.00] ACPI: SSDT 0xC7D4FAB0 00168E (v02 AMDALIB 
0001 MSFT 0400)
[0.00] ACPI: SSDT 0xC7D51140 0003DE (v01 AMDPOWERNOW 
0001 AMD  0001)
[0.0

[systemd-devel] Changed ordering of systemd-resolved.service

2018-04-13 Thread Paul Menzel


Dear Dimitri, dear systemd folks,


In commit 1f158013 (resolved.service: set DefaultDependencies=no) the 
ordering of systemd-resolved.service was changed. (How do I find the 
merge request to find possible discussion? Also the commit message 
description is too specific in my opinion, as it doesn’t give a clue 
that more is changed.)



commit 1f1580139ed48dd308a6a2470baf037ae1ed6aab
Author: Dimitri John Ledkov 
AuthorDate: Mon Dec 11 18:27:49 2017 +
Commit: Lennart Poettering 
CommitDate: Thu Jan 11 12:40:44 2018 +0100

resolved.service: set DefaultDependencies=no

On systems that only use resolved for name resolution, there are usecases that

require resolved to be started before sysinit target, such that network name
resolution is available before network-online/sysinit targets. For example,
cloud-init for some datasources hooks into the boot process ahead of sysinit
target and may need network name resolution at that point already.

systemd-resolved already starts pretty early in the process, thus starting it

slightly earlier should not have negative side effects.

However, this depends on resolved ability to connect to system DBus once that

is up.

diff --git a/units/systemd-resolved.service.in 
b/units/systemd-resolved.service.in
index 8059aa7b6..c4c7f1fee 100644
--- a/units/systemd-resolved.service.in
+++ b/units/systemd-resolved.service.in
@@ -13,8 +13,10 @@ Documentation=man:systemd-resolved.service(8)
 Documentation=https://www.freedesktop.org/wiki/Software/systemd/resolved
 
Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
 
Documentation=https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
-After=systemd-networkd.service network.target
-Before=network-online.target nss-lookup.target
+DefaultDependencies=no
+After=systemd-sysusers.service systemd-networkd.service
+Before=network.target nss-lookup.target shutdown.target
+Conflicts=shutdown.target
 Wants=nss-lookup.target
 
 [Service]


I like starting systemd-resolved earlier, but unfortunately ordering it 
before `network.target` adds a delay on systems wanting to start as fast 
as possible. But why did you change it from `network-online.target` to 
`network.target`? I’d say `network-online.target` is more correct.


For my use case of a fast system start-up, this change delays it by at 
least 100 ms, as now it takes longer to reach the end of the network target.



   network.target
   This unit is supposed to indicate when network functionality is
   available, but it is only very weakly defined what that is supposed
   to mean, with one exception: at shutdown, a unit that is ordered
   after network.target will be stopped before the network — to
   whatever level it might be set up then — is shut down. It is hence
   useful when writing service files that require network access on
   shutdown, which should order themselves after this target, but not
   pull it in. Also see Running Services After the Network is up[1]
   for more information. Also see network-online.target described
   above.

   systemd automatically adds dependencies of type After= for this
   target unit to all SysV init script service units with an LSB
   header referring to the "$network" facility.



   network-online.target
   Units that strictly require a configured network connection should
   pull in network-online.target (via a Wants= type dependency) and
   order themselves after it. This target unit is intended to pull in
   a service that delays further execution until the network is
   sufficiently set up. What precisely this requires is left to the
   implementation of the network managing service.

   Note the distinction between this unit and network.target. This
   unit is an active unit (i.e. pulled in by the consumer rather than
   the provider of this functionality) and pulls in a service which
   possibly adds substantial delays to further execution. In contrast,
   network.target is a passive unit (i.e. pulled in by the provider of
   the functionality, rather than the consumer) that usually does not
   delay execution much. Usually, network.target is part of the boot
   of most systems, while network-online.target is not, except when at
   least one unit requires it. Also see Running Services After the
   Network is up[1] for more information.

   All mount units for remote network file systems automatically pull
   in this unit, and order themselves after it. Note that networking
   daemons that simply provide functionality to other hosts generally
   do not need to pull this in.

   Note that

Re: [systemd-devel] Changed ordering of systemd-resolved.service

2018-04-16 Thread Paul Menzel

Dear Dimitri,

On 04/16/18 18:51, Dimitri John Ledkov wrote:

On 16 April 2018 at 14:25, Paul Menzel wrote:

On 04/16/18 12:47, Dimitri John Ledkov wrote:

On 13 April 2018 at 16:40, Paul Menzel wrote:

In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
ordering of systemd-resolved.service was changed. (How do I find the
merge
request to find possible discussion? Also the commit message description
is
too specific in my opinion, as it doesn’t give a clue that more is
changed.)

https://github.com/systemd/systemd/pull/7609

Thank you, no idea, why I didn’t find it with `git log --oneline --graph`.
Hmm, looks like, Lennart directly put that commit in master without merging
the pull request.

I like starting systemd-resolved earlier, but unfortunately ordering it
before `network.target` adds a delay on systems wanting to start as fast
as
possible. But why did you change it from `network-online.target` to
`network.target`? I’d say `network-online.target` is more correct.

For my use case of a fast system start-up, this change delays it by at
least
100 ms, as now it takes longer to reach the end of the network target.

cloud-init initializes networking configuration by fetching,
potentially, remote sources to customize an instance on first boot.
Specifically it may dhcp any interface, to reach a metadata source,
download the real networking configuration, reconfigure networking to
match the final networking details (all interfaces / public ip
addresses / etc), and proceed to complete networking.target and
network-online.target.

This means that resolved is required earlier in the boot cycle. Before
networking.target.

Just to be sure, you mean *network.target*, right?

Thank you for specifying the requirement. I agree, that it should be started
as early as possible, but I disagree with the rest.

There are things that expect network to be up in
"network-online.target", which by some is implied to mean DNS
resolution too, unfortunately.

Sorry for being ignorant, but could you please be specific, what these
things are. If these units have that requirement order them after
`network-online.target`.

If your systems have problems with it, they have wrong dependencies,
don’t
they? Also, they should probably be able to deal with the situation, that
DNS does not work, as that can happen during operation.

So, I’d really like to rework that ordering change.

Reworking that change will break certain public cloud providers
unfortunately because of public clouds metadata providers being odd.

Note, we cannot use dbus activation in this case as dbus-daemon is not
up yet, and systemd-resolve command line client also does not work at
this point.

If you want to make it an optional dependency that early, maybe it
will be possible to convert systemd-resolved to be socket activated on
tcp/udp?

Alternatively, as a system integrator, you may want to change these
dependencies in your distro, especially if you do not configure
resolved _stub resolver_ as the default provider of /etc/resolv.conf
or for example to do not use the recommended default stub-provider
over 127.0.0.53 and instead use the nss module over dbus.

The above dependencies are correct and recommend, for the default
setup of /etc/resolv.conf pointing at the stub-resolv.conf as
generated by resolved at runtime.

Specifically, the dependencies as is are "too-early" if one uses the
last two modes of the /etc/resolv.conf handling as described in the
man page -
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf

First, I think, the terminology of *early* leads to misunderstandings. For
you it includes ordering with `Before=`, for me it’s just about `After=`
statements.

It's actually both. Cloud-init is a cross-distribution tool, and it
injects itself at multiple points during boot. It pre-empts networking
target, is between networking & network-online, and after
network-online target.

Without this upstream change, cloud-init was not able to pre-empt
network.target, was resulting in a dependency cycle, and systems
resulted booting degraded (due to dependency cycle resolved by
shooting arbitrary unit in the head), in a default upstream systemd
configuration.

Anyway, regressing the user experience for everyone only because it’s

Can you please explain what has degraded? starting systemd-resolved
before or after network*.target shouldn't make any difference in wall
clock time to reach multi-user.target. And in my boot testing, I did
not see any boot regressions.

Just look, what is ordered after the network target.

1. units/rc-local.service.in:After=network.target
2. units/systemd-user-sessions.service.in:After=remote-fs.target
nss-user-lookup.target network.target

Both are needed for the login screen.

Or are you explicitly measuring time to network.target, separate from
time to network-online.target, and separate from reaching the default
target?

Re: [systemd-devel] Changed ordering of systemd-resolved.service

2018-04-16 Thread Paul Menzel

Dear Dimitri,

Thank you for your quick response.

On 04/16/18 12:47, Dimitri John Ledkov wrote:

On 13 April 2018 at 16:40, Paul Menzel wrote:

In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
ordering of systemd-resolved.service was changed. (How do I find the merge
request to find possible discussion? Also the commit message description is
too specific in my opinion, as it doesn’t give a clue that more is changed.)

https://github.com/systemd/systemd/pull/7609

Thank you, no idea, why I didn’t find it with `git log --oneline
--graph`. Hmm, looks like, Lennart directly put that commit in master
without merging the pull request.

I like starting systemd-resolved earlier, but unfortunately ordering it
before `network.target` adds a delay on systems wanting to start as fast as
possible. But why did you change it from `network-online.target` to
`network.target`? I’d say `network-online.target` is more correct.

For my use case of a fast system start-up, this change delays it by at least
100 ms, as now it takes longer to reach the end of the network target.

This means that resolved is required earlier in the boot cycle. Before
networking.target.

Just to be sure, you mean *network.target*, right?

Thank you for specifying the requirement. I agree, that it should be
started as early as possible, but I disagree with the rest.

There are things that expect network to be up in
"network-online.target", which by some is implied to mean DNS
resolution too, unfortunately.

Sorry for being ignorant, but could you please be specific, what these
things are. If these units have that requirement order them after
`network-online.target`.

If your systems have problems with it, they have wrong dependencies, don’t
they? Also, they should probably be able to deal with the situation, that
DNS does not work, as that can happen during operation.

So, I’d really like to rework that ordering change.

Reworking that change will break certain public cloud providers
unfortunately because of public clouds metadata providers being odd.

Note, we cannot use dbus activation in this case as dbus-daemon is not
up yet, and systemd-resolve command line client also does not work at
this point.

If you want to make it an optional dependency that early, maybe it
will be possible to convert systemd-resolved to be socket activated on
tcp/udp?

The above dependencies are correct and recommend, for the default
setup of /etc/resolv.conf pointing at the stub-resolv.conf as
generated by resolved at runtime.

First, I think, the terminology of *early* leads to misunderstandings.
For you it includes ordering with `Before=`, for me it’s just about
`After=` statements.

Anyway, regressing the user experience for everyone only because it’s
required for cloud-init is not right in my opinion. As you pointed out,
the system integrator can adapt certain things, and in my opinion, I
throw the ball back to you, and kindly ask you, to adapt systemd locally
so it works with your use-case or let’s come up with a better solution.

Maybe a new target is needed, where you can order your services after,
as ordering them after systemd-resolved.service is too specific.

I submitted a merge/pull request to change the ordering [1].

Kind regards,

Paul

[1] https://github.com/systemd/systemd/pull/8731

smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix strerror_r segfault on non-glibc systems

2018-03-29 Thread Paul Menzel


Dear Ioan-Adrian,


Thank you for your patch (from the future `Date: Thu, 29 Mar 2018
14:41:30 +0300`).

I believe systemd moved the development to GitHub [1] and only accepts 
merge/pull requests [1].



Please see our Contribution Guidelines for more information about
filing GitHub Issues and posting GitHub Pull Requests.



Kind regards,

Paul


[1] https://github.com/systemd/systemd/



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to debug why a unit is started when?

2018-03-16 Thread Paul Menzel


Dear systemd folks,


I am trying to get the GDM login screen started earlier on a Dell XPS 13 
9370 with Debian Sid/unstable system with systemd 238. Currently, after 
selecting the Linux kernel in GRUB it’s only displayed after roughly 
eight to ten seconds while Linux takes around two seconds [1].


Using systemd-bootchart I see that GDM is started quite late [1], and I 
wondering if there is an option to find out why.


GDM’s service unit [2] has the “dependencies” below.

After=rc-local.service plymouth-start.service 
systemd-user-sessions.service


Is there a debug option, where systemd says, why a certain unit is 
started? For example, reached target X and therefore starting Y.



Kind regards,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=794336
[2] https://git.gnome.org/browse/gdm/tree/data/gdm.service.in



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to debug why a unit is started when?

2018-03-19 Thread Paul Menzel


Dear Colin,


On 03/19/2018 07:31 AM, Colin Guthrie wrote:

Paul Menzel wrote on 17/03/18 17:50:



On 03/16/2018 05:04 PM, Andrei Borzenkov wrote:

16.03.2018 18:49, Paul Menzel пишет:



I am trying to get the GDM login screen started earlier on a Dell XPS 13
9370 with Debian Sid/unstable system with systemd 238. Currently, after
selecting the Linux kernel in GRUB it’s only displayed after roughly
eight to ten seconds while Linux takes around two seconds [1].

Using systemd-bootchart I see that GDM is started quite late [1], and I
wondering if there is an option to find out why.

GDM’s service unit [2] has the “dependencies” below.

  After=rc-local.service plymouth-start.service
systemd-user-sessions.service

Is there a debug option, where systemd says, why a certain unit is
started? For example, reached target X and therefore starting Y.


systemctl --after (--recursive) --list-dependencies gdm.service

may be the first step. Or use systemd-analyze chart to see full picture
of what was started when.


I didn’t know about `systemd-analyze plot`. Please find the SVG file
attached.

Looking at the log messages, I kind of think it’s related to the
NetworkManager, but I do not see the dependency. Is it
`rc-local.service`? It seems to depend on the `network.target`.


I didn't look too hard at the data, but from experience,
systemd-user-sessions often has to start after the network is online as
user accounts may be defined in e.g. LDAP etc.

This is the likely chain you need to break and configure accordingly.

e.g. if you have no network filesystems (defined without noauto or
nofail) and no LDAP/NIS users etc., then you may not need
networkmanager-wait-online.service and if you disable this, things might
go a lot faster.

Be careful however, as some old network-listening services may still
need this dodgy delay service to function properly.
Thank you for pointing this out. I actually knew this from the past, but 
forgot about it. I didn’t look further into it though, as I had removed 
the `After=` line (including `systemd-user-sessions.service`). I changed 
more things too though by deinstalling the package *ifupdown*.


```
$ systemctl cat gdm
# /lib/systemd/system/gdm.service
[Unit]
Description=GNOME Display Manager

# replaces the getty
Conflicts=getty@tty1.service
After=getty@tty1.service

# replaces plymouth-quit since it quits plymouth on its own

# Needs all the dependencies of the services it's replacing
# pulled from getty@.service and plymouth-quit.service
# (except for plymouth-quit-wait.service since it waits until
# plymouth is quit, which we do)

# GDM takes responsibility for stopping plymouth, so if it fails
# for any reason, make sure plymouth still stops
OnFailure=plymouth-quit.service

[Service]
ExecStartPre=/usr/share/gdm/generate-config
ExecStart=/usr/sbin/gdm3
KillMode=mixed
Restart=always
RestartSec=1s
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
StandardOutput=syslog
StandardError=inherit
EnvironmentFile=-/etc/default/locale
ExecReload=/usr/share/gdm/generate-config
ExecReload=/bin/kill -SIGHUP $MAINPID
```

But `sudo systemctl disable NetworkManager-wait-online.service` indeed 
changed something, and the GDM service is now started at the same time 
as NetworkManager.


Unfortunately, the GDM session worker is only started after 1.6 seconds 
according to the chart – the updated chart is attached. That is a likely 
a GDM problem though.



```
[…]
Mar 19 10:14:30.440112 xps139370 systemd[1]: Starting GNOME Display Manager...
[…]
Mar 19 10:14:30.475575 xps139370 systemd[1]: Started GNOME Display Manager.
Mar 19 10:14:30.475764 xps139370 gdm3[523]: Successfully connected to D-Bus
[…]
Mar 19 10:14:32.022907 xps139370 gdm3[523]: GdmLocalDisplayFactory: Adding 
display on seat seat0
Mar 19 10:14:32.023006 xps139370 gdm3[523]: GdmDisplay: id: (null)
Mar 19 10:14:32.023011 xps139370 gdm3[523]: GdmDisplay: seat id: (null)
Mar 19 10:14:32.023014 xps139370 gdm3[523]: GdmDisplay: session class: greeter
Mar 19 10:14:32.023017 xps139370 gdm3[523]: GdmDisplay: initial: no
Mar 19 10:14:32.023019 xps139370 gdm3[523]: GdmDisplay: allow timed login: yes
Mar 19 10:14:32.023022 xps139370 gdm3[523]: GdmDisplay: local: yes
Mar 19 10:14:32.023109 xps139370 gdm3[523]: GdmDisplay: session type: wayland
Mar 19 10:14:32.023113 xps139370 gdm3[523]: GdmDisplay: seat id: seat0
Mar 19 10:14:32.023117 xps139370 gdm3[523]: GdmDisplay: initial: yes
Mar 19 10:14:32.023121 xps139370 gdm3[523]: GdmDisplayStore: Adding display 
/org/gnome/DisplayManager/Displays/94611499688528 to store
Mar 19 10:14:32.023234 xps139370 gdm3[523]: GdmDisplay: Managing display: 
/org/gnome/DisplayManager/Displays/94611499688528
Mar 19 10:14:32.023236 xps139370 gdm3[523]: GdmDisplay: Preparing display: 
/org/gnome/DisplayManager/Displays/94611499688528
Mar 19 10:14:32.024422 xps139370 kernel: ath10k_pci :02:00.0: Unknown 
eventid: 118809
Mar 19 10:14:32.025099 xps139370 gdm3[523]: GdmDisplay: Checking kernel command 
buffer

Re: [systemd-devel] How to debug why a unit is started when?

2018-03-17 Thread Paul Menzel


Dear Tomasz,


On 03/16/2018 04:56 PM, Tomasz Torcz ️ wrote:

On Fri, Mar 16, 2018 at 04:49:28PM +0100, Paul Menzel wrote:



I am trying to get the GDM login screen started earlier on a Dell XPS 13
9370 with Debian Sid/unstable system with systemd 238. Currently, after
selecting the Linux kernel in GRUB it’s only displayed after roughly eight
to ten seconds while Linux takes around two seconds [1].

Using systemd-bootchart I see that GDM is started quite late [1], and I
wondering if there is an option to find out why.


   Not a direct answer to your question, but you can use systemd-bootchart
to get graphical timeline of how long did it take to start different
units.  Then you will have to find box for GDM and see which other
boxes ended at the moment GDM started.


Thank you for your reply, but as written, I tried that, and uploaded the 
chart to the GDM bug report. Unfortunately, I didn’t see any connection, 
that means, no box ended.



Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to debug stop job running into time-out?

2018-10-24 Thread Paul Menzel

Dear systemd folks,


With Debian Sid/unstable (systemd 239) and GDM 3.30.1, sometimes
powering off the system, it takes two minutes and the message
below is shown on the screen.

> A stop job is running for User Manager for UID 1000 (1min 3s / 1 min 59s)

What ways are there to debug this issue. The problem is, it’s
not always reproducible.

Is there a key combination for dumping the necessary information?
Like what process(?) cannot be stopped?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Run OpenVPN unprivileged as systemd user service

2018-11-01 Thread Paul Menzel

Dear systemd folks,


Our users sometimes need to access the internal network of another
organization, but unfortunately SSH access is blocked, and it’s only possible
over OpenVPN. With that, they could use their browser and SSH to access the
internal network.

Due to security reasons, we do not want to allow OpenVPN on our systems, and
wonder, if systemd user service would enable us to run OpenVPN unprivileged for
a user, so that the user has no chance of disturbing other users.

OpenVPN provides systemd units [1].

Do you think, it’d be easily possible, that the OpenVPN sets up the connection
in a separate network name space, and the user can enter that name space and
start SSH and a browser from there?

If yes, do you have any hints before I start to dig into that?


Kind regards,

Paul


[1]: https://github.com/OpenVPN/openvpn/blob/master/distro/systemd/
[Unit]
Description=OpenVPN tunnel for %I
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/client
ExecStart=/usr/local/sbin/openvpn --suppress-timestamps --nobind --config 
%i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_RAW CAP_SETGID 
CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process

[Install]
WantedBy=multi-user.target
[Unit]
Description=OpenVPN service for %I
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/server
ExecStart=/usr/local/sbin/openvpn --status %t/openvpn-server/status-%i.log 
--status-version 2 --suppress-timestamps --config %i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE 
CAP_AUDIT_WRITE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process
RestartSec=5s
Restart=on-failure

[Install]
WantedBy=multi-user.target


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mailing List List-Id Header

2018-10-30 Thread Paul Menzel

Dear Esben,


On 10/30/18 16:17, Esben Stien wrote:
> Is there supposed to be a List-Id in the headers of email that comes from
> this mailing list?
> 
> I don't see any. Any other headers you use?

I see all the headers. For example, from your message (Ctrl + u in Thunderbird):

```
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: systemd Development Mailing List 
List-Unsubscribe: 
, 
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
 
```


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Collect logs over serial

2019-01-31 Thread Paul Menzel

Dear systemd/udev folks,


Having a large pool of (different) systems, we hit Linux kernel
panics several times in a year. To better debug those, we want
to make use of the serial ports still present on today’s
systems.

Unfortunately, the serial ports on the back plane, we’d like to
use, are numbered differently. Can you recommend best practices
how to detect where that port is on a system?

Currently, we only do it for port ttyS1, by adding
`console=ttyS1,115200n8` to the Linux kernel command line *on
all systems*, and using the attached script and service unit
template and the server the serial cable is connected to.

```
[Unit]
Description=TTY logger

[Service]
ExecStart=/usr/libexec/serial-log %I
Type=simple
UtmpIdentifier=%I

[Install]
WantedBy=basic.target
```

```
devnam="$1"

while true; do
until /usr/bin/stty -F "/dev/$devnam" 115200 -echo 2>/dev/null; do
sleep 60
done
until cat "/dev/$devnam" >> /var/log/$devnam.log 2>&1;do
sleep 1
done
done
```

Polling the device every 60 seconds is not very elegant, and we
also would like to avoid having to configure each device
manually, where the serial port is.

Does udev/systemd/… have some features solving this more in a
better way?


Kind regards,

Paul
[Unit]
Description=TTY logger

[Service]
ExecStart=/usr/libexec/serial-log %I
Type=simple
UtmpIdentifier=%I

[Install]
WantedBy=basic.target
#! /bin/bash

(($#==1)) || { echo "usage: $0 device-name" >&2; exit 1; }

devnam="$1"

while true; do
until /usr/bin/stty -F "/dev/$devnam" 115200 -echo 2>/dev/null; do
sleep 60
done
until cat "/dev/$devnam" >> /var/log/$devnam.log 2>&1;do
sleep 1
done
done


smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-devel listed as support confuses users (was: connection failure)

2019-07-02 Thread Paul Menzel

Dear systemd folks,


On 7/2/19 3:44 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 02, 2019 at 03:39:04PM +0200, ABDUL MAJITH wrote:

>> I am trying to use the Docker in GNS3, when I try to launch it show the
>> error as follows,
>>
>> -- The start-up result is done.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request
>> repeated too quickly.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with
>> result 'exit-code'.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker
>> Application Container Engine.
>> -- Subject: Unit docker.service has failed
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit docker.service has failed.
>> -- 
>> -- The result is failed.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with
>> result 'service-start-limit-hit'.
>> Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache...
>> -- Subject: Unit dnf-makecache.service has begun start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has begun starting up.
>> Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching disabled.
>> Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache.
>> -- Subject: Unit dnf-makecache.service has finished start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has finished starting up.
>> -- 
>> -- The start-up result is done.
>> ...skipping...
>> -- 
>> -- The start-up result is done.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Start request
>> repeated too quickly.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.service: Failed with
>> result 'exit-code'.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: Failed to start Docker
>> Application Container Engine.
>> -- Subject: Unit docker.service has failed
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit docker.service has failed.
>> -- 
>> -- The result is failed.
>> Jul 02 15:21:55 reccon.irisa.fr systemd[1]: docker.socket: Failed with
>> result 'service-start-limit-hit'.
>> Jul 02 15:24:06 reccon.irisa.fr systemd[1]: Starting dnf makecache...
>> -- Subject: Unit dnf-makecache.service has begun start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has begun starting up.
>> Jul 02 15:24:07 reccon.irisa.fr dnf[18029]: Metadata timer caching disabled.
>> Jul 02 15:24:07 reccon.irisa.fr systemd[1]: Started dnf makecache.
>> -- Subject: Unit dnf-makecache.service has finished start-up
>> -- Defined-By: systemd
>> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> -- 
>> -- Unit dnf-makecache.service has finished starting up.
>> -- 
>> -- The start-up result is done.
>>
>> How to rectify this failure to start the docker application
> 
> This is a problem with docker. Nothing to do with the systemd-devel list.
> Please ask in a forum appropriate for docker issues.

Reading the output above, I can see, why the people contact this mailing
list.

The output has the systemd-devel list listed as support all over the
place.


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Reduce loading time (size) of init program (systemd)

2019-09-16 Thread Paul Menzel

Dear systemd folks,


In his talk *Linux kernel fastboot on the way* at this years Linux
Plumbers Conference [1][2], Feng Tang (CCed) has the notes below on
the slide for userspace/systemd.

> • Systemd is ~1.5MB - the loading time for emmc is 100ms> • Can we use a 
> small lightweight “init” program, which starts
>   target programs in parallel and readahead to preload libraries
>   and executables?

Are you already aware of these issues? If yes, have you ideas or
suggestions how to solve this? Maybe something to discuss at this
weeks All System Go! 2019.


Kind regards,

Paul


[1]: https://linuxplumbersconf.org/event/4/contributions/281/
[2]: 
https://linuxplumbersconf.org/event/4/contributions/281/attachments/216/617/LPC_2019_kernel_fastboot_on_the_way.pdf



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How-to for systemd user timers instead of cron/crontab?

2019-10-17 Thread Paul Menzel

Dear systemd folks,


I couldn’t find a simple documentation for “normal” users how
to use systemd timers instead of cron/crontab? The Arch Wiki
has a page [1], but I am afraid it’s still too complicated
for our users.


Kind regards,

Paul


[1]: https://wiki.archlinux.org/index.php/Systemd/Timers



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How to apply for partition type GUID for Linux /boot?

2019-11-27 Thread Paul Menzel

Dear systemd folks,


A partition type GUID [1] for the partition to be mounted under `/boot`
when started with Linux would be nice. For example, there is already one
for FreeBSD /boot [2].

As you seem to have requested one for the freedesktop.org shared boot
loader partition already, could you please share the application process
for such a partition type GUID?


Kind regards,

Paul


[1]: https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
[2]: 
https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to apply for partition type GUID for Linux /boot?

2019-11-28 Thread Paul Menzel

Dear Arseny,


On 2019-11-28 15:10, Arseny Maslennikov wrote:
> On Wed, Nov 27, 2019 at 01:13:52PM +0100, Lennart Poettering wrote:
>> On Mi, 27.11.19 12:43, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) 
>> wrote:
>>
>>> Dear systemd folks,
>>>
>>> A partition type GUID [1] for the partition to be mounted under `/boot`
>>> when started with Linux would be nice. For example, there is already one
>>> for FreeBSD /boot [2].
>>>
>>> As you seem to have requested one for the freedesktop.org shared boot
>>> loader partition already, could you please share the application process
>>> for such a partition type GUID?
>>
>> The great thing about UUIDs are that they are an unmanaged
>> namespace. Anyone can pick one, as long they generate them properly
>> (which today means pulling from a good /dev/urandom).
>>
>> Hence there's no requesting or registration, you just pick one,
>> that's it.
>>
>> I don't know what you expect /boot to be. In the systemd context we
>> defined the "extended boot loader partition", which is a place you can
>> place kernels and stuff, if you don't want to use the EFI ESP for
>> that, and sd-boot and our userspace tools look in it too. It's
>> automatically discovered and mounted to /boot if it exists, by
>> systemd-gpt-auto-generator.
>>
>> This extended boot loader partition as GPT type UUID
>> bc13c2ff-59e6-4262-a352-b275fd6f7172 and that's documented in the
>> systemd-gpt-auto-generator(8) man page.
> 
> The spec at freedesktop.org[1], (naturally) being the first Google hit
> for "discoverable partitions spec" and also being referred to from a lot
> of places all over the community[2][3][4][5][6], has no mention of the
> extended boot loader partition.
> I did not find it at systemd.io (which is, AFAIK, generated from the
> source).
> Is the page unmaintained? If it is: was it moved? are there any
> official, maintained pages for the spec visible and citable on the web?

Isn’t it [7]?

> Otherwise, if the OS is installed on a disk with GPT disk label, and
> if the ESP partition already exists but is too small, a new suitably
> sized (let’s say 500MB) partition with GPT type GUID of
> bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should
> be used as $BOOT.

Do you mean the term is missing there?


Kind regards,

Paul


> [1]https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> 
> [2]https://forum.manjaro.org/t/discoverable-partitions-specification/104505
> [3]https://lists.freedesktop.org/archives/systemd-devel/2014-March/017817.html
> [4]https://en.wikipedia.org/wiki/GUID_Partition_Table
> [5]https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
> [6]https://wiki.archlinux.org/index.php/GPT_fdisk
[7]: https://systemd.io/BOOT_LOADER_SPECIFICATION



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Problems with DNS resolution in German Rail WiFi

2019-10-31 Thread Paul Menzel


Dear systemd folks,


Since over half a year, I am having problems with the German Rail WIFI 
(Deutsche Bahn, WIFIonICE) [1]. I am only having problems with the WIFI 
in the train. The WIFI on the train stations (operated by Deutsche 
Telekom(?)) works fine.


I am able to connect to the WIFI network, but accessing the capture page 
to log in, and after logging in, I am having serious DNS problems in the 
browsers (Mozilla Firefox 70.0 and Google Chromium). I am using Debian 
Sid/unstable.


It looks like that, DNS requests are not answered in time (also 
confirmed by the developer tools in the browser). SSH (and even Mozilla 
Thunderbird) seems to work better. The fellow train travelers do not 
seem to have any problems.


Testing on the console shows:

```
$ time host bahn.de
bahn.de has address 18.185.205.203
bahn.de has address 35.157.56.133
bahn.de has address 35.158.56.207
bahn.de mail is handled by 10 mailgate2.deutschebahn.com.
bahn.de mail is handled by 10 mailgate1.deutschebahn.com.

real0m0,243s
user0m0,021s
sys 0m0,000s
$ systemd-resolve bahn.de
bahn.de: resolve call failed: Die Wartezeit für die Verbindung ist 
abgelaufen

$ time systemd-resolve bahn.de
bahn.de: resolve call failed: DNSSEC validation failed: failed-auxiliary

real0m55,967s
user0m0,006s
sys 0m0,006s
$ time systemd-resolve bahn.de
bahn.de: resolve call failed: Die Wartezeit für die Verbindung ist 
abgelaufen


real2m0,094s
user0m0,005s
sys 0m0,007s
$ time systemd-resolve bahn.de
bahn.de: resolve call failed: Die Wartezeit für die Verbindung ist 
abgelaufen


real2m0,113s
user0m0,014s
sys 0m0,000s
```

How can this be debugged (next time I am using the ICE)? Is this 
systemd-resolved related? If not, who should I bug about it?



Kind regards,

Paul


[1]: https://www.bahn.de/p/view/service/zug/railnet_ice_bahnhof.shtml
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to apply for partition type GUID for Linux /boot?

2019-11-27 Thread Paul Menzel

Dear Lennart,


On 2019-11-27 13:13, Lennart Poettering wrote:
> On Mi, 27.11.19 12:43, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) 
> wrote:

>> A partition type GUID [1] for the partition to be mounted under `/boot`
>> when started with Linux would be nice. For example, there is already one
>> for FreeBSD /boot [2].
>>
>> As you seem to have requested one for the freedesktop.org shared boot
>> loader partition already, could you please share the application process
>> for such a partition type GUID?
> 
> The great thing about UUIDs are that they are an unmanaged
> namespace. Anyone can pick one, as long they generate them properly
> (which today means pulling from a good /dev/urandom).
> 
> Hence there's no requesting or registration, you just pick one,
> that's it.
> 
> I don't know what you expect /boot to be. In the systemd context we
> defined the "extended boot loader partition", which is a place you can
> place kernels and stuff, if you don't want to use the EFI ESP for
> that, and sd-boot and our userspace tools look in it too. It's
> automatically discovered and mounted to /boot if it exists, by
> systemd-gpt-auto-generator.
> 
> This extended boot loader partition as GPT type UUID
> bc13c2ff-59e6-4262-a352-b275fd6f7172 and that's documented in the
> systemd-gpt-auto-generator(8) man page.

Yes, I wanted to use that, but as it was formatted with ext4 the boot
failed [3].

> --
> Lennart Poettering, Berlin

A space is missing after your signature separator [4].


Kind regards,

Paul


[3]: https://github.com/systemd/systemd/issues/14165
[4]: https://de.wikipedia.org/wiki/Signatur_(E-Mails_und_Postings)#Form



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Best practices for starting unit only if network is online

2020-02-05 Thread Paul Menzel


Dear systemd folks,


fwupd ships the service unit `fwupd-refresh.service` with the ordering 
below [1].


After=network.target network-online.target systemd-networkd.service 
NetworkManager.service connman.service


I would have thought ordering after `network-online.target` would be 
enough. Are there best practices for ensuring that the network is working?


(As a sidenote, the service seems to be only activated by a timer [2], 
so network will be up probably.)



Kind regards,

Paul


[1]: 
https://github.com/fwupd/fwupd/blob/4f28afb6e720215a33805f37d1845ec425a45256/data/motd/fwupd-refresh.service.in#L4
[2]: 
https://github.com/fwupd/fwupd/blob/master/data/motd/fwupd-refresh.timer

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Service fails to start with no log messages

2020-01-07 Thread Paul Menzel

Dear Jeffrey,


On 2020-01-07 03:17, Jeffrey Walton wrote:

[…]

> There are absolutely 0 entires about my monitor service:
> 
> $ journalctl -e | grep -i callboot | grep monitor
> $

The switch `-e` implies that by default only 1000 lines are shown.

   -e, --pager-end
   Immediately jump to the end of the journal inside the implied
   pager tool. This implies -n1000 to guarantee that the pager will
   not buffer logs of unbounded size. This may be overridden with an
   explicit -n with some other numeric value, while -nall will
   disable this cap. Note that this option is only supported for the
   less(1) pager.

Does `journalctl -b | grep -i callboot` show something? `-b` only shows log
messages for the current boot.

[…]


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fwd: systemd for petitboot as linux payload (x230)

2020-04-20 Thread Paul Menzel


Dear systemd folks,


Am 20.04.20 um 11:47 schrieb Lennart Poettering:

On Mo, 20.04.20 10:52, Robin C (amisbie...@posteo.net) wrote:



Hi everyone,

I'm curruntly trying to build petitboot for my lenovo x230 (actualy runs
coreboot + tianocore).

I use this tutorial to build it:
https://www.raptorengineering.com/content/kb/1.html

I think it is not up to date, can anyone confirme or not? I'm stuck on the
first part, buildind systemd... I have this errors:

In file included from ../src/basic/errno-list.c:31:0:
./src/basic/errno-from-name.h:143:1: error: conflicting types for ‘lookup_errno’
  lookup_errno (register const char *str, register size_t len)
  ^~~~
../src/basic/errno-list.c:27:33: note: previous declaration of ‘lookup_errno’ 
was here
  static const struct errno_name* lookup_errno(register const char *str,
  ^~~~


gperf changed its output some time back. You need to have a newer
gperf (or if you build an older version of systemd, an older one) to
build systemd.


Maybe the configure script can check the version. I created an issue [1].


Kind regards,

Paul


[1]: https://github.com/systemd/systemd/issues/15492
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

2020-04-02 Thread Paul Menzel


Dear Lennart,


Am 01.04.20 um 17:10 schrieb Lennart Poettering:

On Mi, 01.04.20 14:23, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:


After=device should work. udev announces device after all rules have
been processed.


After= only orders, but this doesn't pull the device unit into the job
queue. To do that, you need to add Wants= on the device unit as well.


Trying this,

 After=dev-dri-card0.device
 Wants=dev-dri-card0.device

the service times out waiting for the device.

 $ journalctl -a
 […]
 Apr 01 14:15:42.672430 kodi systemd[1]: Reached target Multi-User System.
 […]
 Apr 01 14:17:09.805001 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start timed out.
 Apr 01 14:17:09.805839 kodi systemd[1]: Timed out waiting for device 
/dev/dri/card0.
 Apr 01 14:17:09.806464 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start failed with result 'timeout'.
 Apr 01 14:17:09.809847 kodi systemd[1]: Starting Weston, a Wayland 
compositor, as a system service...
 […]
 $ ls -l /dev/dri/card0
 crw-rw 1 root video 226, 0 Apr  1 14:15 /dev/dri/card0


DRM devices are currently not tagged with "systemd", and thus no
.device units are syntesized for them in systemd. Add a udev rule that
matches against them and sets the "systemd" tag and they will appear
in systemd, so that you can order your stuff against it.


That did the trick. In `systemd-analyze critical-chain` the device shows 
up with three seconds. Quite a lot, but unfortunately the Linux drivers 
do not seem to be optimized for speed.


But my problem turned out to be something else. getty@tty1.service and 
Weston on tty1 were apparently conflicting causing the permission denied 
errors, and adding `Conflict=getty@tty1.service` seems to have fixed it.


I created merge/pull request #15307 for adding the tags anyway [1].


Kind regards,

Paul


[1]: https://github.com/systemd/systemd/pull/15307
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

2020-04-01 Thread Paul Menzel


Dear Andrei, dear Lennart,


Thank you very much for your answers.

Am 31.03.20 um 17:09 schrieb Lennart Poettering:

On Do, 19.03.20 20:24, Andrei Borzenkov (arvidj...@gmail.com) wrote:


19.03.2020 19:47, Paul Menzel пишет:



I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.

I amtrying to start a graphical desktop as soon as possible. Currently,
I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a
permission denied error. The Weston service unit is ordered after
`systemd-logind.service`.

Weston now fails to start, because it gets a permission denied error
accessing `/dev/dri/card0` [1][2].

     drmModeSetCrtc(backend->drm.fd, output->crtc_id,
scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);

Right before Weston starts, the permission and ownership are like below.

     $ ls -l /dev/dri:
     insgesamt 0
     crw--- 1 root root 226,   0 Mär 19 17:29 card0
     crw--- 1 root root 226, 128 Mär 19 17:29 renderD128

After udev applied the rules, it looks like below, meaning users in
group `video` are allowed to access the device.

     $ ls -l /dev/dri
     insgesamt 0
     drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
     crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
     crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128

Is there a way to order a service in such a way, that it’s guaranteed
that udev rules to devices were applied?


After=device should work. udev announces device after all rules have
been processed.


After= only orders, but this doesn't pull the device unit into the job
queue. To do that, you need to add Wants= on the device unit as well.


Trying this,

After=dev-dri-card0.device
Wants=dev-dri-card0.device

the service times out waiting for the device.

$ journalctl -a
[…]
Apr 01 14:15:42.672430 kodi systemd[1]: Reached target Multi-User 
System.

[…]
Apr 01 14:17:09.805001 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start timed out.
Apr 01 14:17:09.805839 kodi systemd[1]: Timed out waiting for 
device /dev/dri/card0.
Apr 01 14:17:09.806464 kodi systemd[1]: dev-dri-card0.device: Job 
dev-dri-card0.device/start failed with result 'timeout'.
Apr 01 14:17:09.809847 kodi systemd[1]: Starting Weston, a Wayland 
compositor, as a system service...

[…]
$ ls -l /dev/dri/card0
crw-rw 1 root video 226, 0 Apr  1 14:15 /dev/dri/card0


Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Q: systemctl kill: "Invalid who argument 15862"

2020-05-06 Thread Paul Menzel


Dear Ulrich,


Am 06.05.20 um 11:21 schrieb Ulrich Windl:


I have a question for systemd-228-150.82.1.x86_64 (of SLES12 SP4):
While developing a script for logrotate, I tested this command with the
following result:

# systemctl kill -s HUP --kill-who=15862 iotwatch@LOC1.service
Failed to kill unit iotwatch@LOC1.service: Invalid who argument 15862


[…]


Did I misinterpret the manual page, or what is the problem?

--kill-who=
When used with kill, choose which processes to send a signal to.
Must be one of main, control or all to select whether to kill only
the main process, the control process or all processes of the
unit.


I understand it, that only *main*, *control* or *all* are valid arguments.


Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

2020-03-19 Thread Paul Menzel


Dear systemd folks,


I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.

I amtrying to start a graphical desktop as soon as possible. Currently, 
I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a 
permission denied error. The Weston service unit is ordered after 
`systemd-logind.service`.


Weston now fails to start, because it gets a permission denied error 
accessing `/dev/dri/card0` [1][2].


drmModeSetCrtc(backend->drm.fd, output->crtc_id, 
scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);


Right before Weston starts, the permission and ownership are like below.

$ ls -l /dev/dri:
insgesamt 0
crw--- 1 root root 226,   0 Mär 19 17:29 card0
crw--- 1 root root 226, 128 Mär 19 17:29 renderD128

After udev applied the rules, it looks like below, meaning users in 
group `video` are allowed to access the device.


$ ls -l /dev/dri
insgesamt 0
drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128

Is there a way to order a service in such a way, that it’s guaranteed 
that udev rules to devices were applied?


A small script applying permissions and ownership manually in 
`ExecStartPre=` seems to work around the (graphics) issue.


If it cannot be solved with ordering, what would you suggest?

[1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
[2]: 
https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd packet loss Ubuntu 18.04 (systemd 237)

2020-07-08 Thread Paul Menzel

Dear Luke,


On 2020-07-08 13:10, Luke Alexander wrote:

> I had a look through some of the issues against the systemd github repo but
> could not find any matching - there were a couple which look promising but
> don't completely resolve our issue.
> 
> Our issue is that we have a k8s (1.18, kube-router CNI) cluster comprised
> of a number of Ubuntu 16.04 nodes, we are in the process if upgrading the
> nodes to Ubuntu 18.04 - however after upgrading the first node and adding
> it back to the cluster we observed high packet loss from other cluster
> nodes to the 18.04 node as well as ping error messages when running a
> continuous ping from the 18.04 node to another node in the cluster, eg:
> 
> 64 bytes from 10.8.11.1: icmp_seq=91 ttl=64 time=0.088 ms
> 64 bytes from 10.8.11.1: icmp_seq=92 ttl=64 time=0.076 ms
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
> ping: sendmsg: No buffer space available
> 
> Another observation is that one of our daemonset pods (promtail) could not
> start.
> 
> systemctl --version
> systemd 237
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN
> -PCRE2 default-hierarchy=hybrid
> 
> After many days of troubleshooting various possibilities, changing network
> cable, NIC, a different server, various sysctl values, I eventually tried
> switching from systemd-networkd to NetworkManager as the backend via
> netplan config. After rebooting the server with NetworkManager in place and
> re-adding the node back to the k8s cluster, the packet loss disappeared as
> did the ping errors and the daemonset pod (promtail) also started normally.
> 
> I would like to use Ubuntu's default of systemd-networkd to handle our
> NIC/route config - but cannot until I've figured out what in
> systemd-networkd is breaking.
> 
> Any help is much appreciated on this matter.

Unfortunately, upstream only supports the last two upstream versions of
systemd. Please report the issue to the Ubuntu bug tracker Launchpad [1].
It would probably help to verify, if the issue is still present in the newest
version. So maybe try Ubuntu 20.04 first to see if it’s fixed there.
Otherwise, building systemd yourself in Ubuntu should be doable too.

I am sorry for the unsatisfying answer.


Kind regards,

Paul


[1]: https://bugs.launchpad.net/ubuntu/+source/systemd



smime.p7s
Description: S/MIME Cryptographic Signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)

2020-07-12 Thread Paul Menzel


Dear PGNet,


Am 12.07.20 um 07:54 schrieb PGNet Dev:

On 6/16/20 1:35 AM, Lennart Poettering wrote:

On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote:



IS there a backport of this^^ fix available for v234 that popped
up in the meantime?

If not, as is likely, is there a "safe" workaround for quieting
the fail, and rm'ing the associated boot delay?  Is rm'ing either the
"Also=" or "WantedBy=" a reasonable band-aid?

Or, some other approach?


You could use RequiredForOnline= in the bridge's .network file to mark
it as irrelevant for systemd-network-wait-online.



On my current machine, just upgraded to new OS version (still same
distro -- for the moment) I've,

  networkctl
  IDX LINK TYPE   OPERATIONAL SETUP
1 lo   loopback   carrier unmanaged
2 enp3s0   ether  no-carrier  configuring
3 enp5s0   ether  routableconfigured

infc #3 is active; intfc #2 is unused

I added to each

cd /etc/systemd/network
grep Link -A1 *
  20-enp3s0.network:[Link]
  20-enp3s0.network-RequiredForOnline=no
  --
  20-enp5s0.network:[Link]
  20-enp5s0.network-RequiredForOnline=no

and rebooted.

still, there's a 2min delay on startup

systemd-analyze blame | head
   2min 284ms systemd-networkd-wait-online.service
   5.803s dkms.service
   5.409s rc-local.service
   4.270s mariadb-custom.service
   3.952s after-local.service
   3.647s udisks2.service
   2.985s rpcbind.service
   2.936s mcelog.service
   2.901s ca-certificates.service
   2.878s smartd.service

in dmesg,

  dmesg | grep wait-online -A1 -B1
   [  129.299191] systemd[1]: Started update geoipdb service.
   [  130.961418] systemd-networkd-wait-online[1664]: Event loop failed: 
Connection timed out
   [  130.971019] systemd[1]: systemd-networkd-wait-online.service: Main 
process exited, code=exited, status=1/FAILURE
   [  130.971276] systemd[1]: Failed to start Wait for Network to be Configured.
   [  130.974180] systemd[1]: systemd-networkd-wait-online.service: Unit 
entered failed state.
   [  130.974187] systemd[1]: systemd-networkd-wait-online.service: Failed with 
result 'exit-code'.
   [  130.974266] systemd[1]: Reached target Network is Online.

other than the two interfaces I _do_ have -- and have set

  [Link]
  RequiredForOnline=no

for, what's possibly _still_ causing this delay?

this^ is, as before, with

  rpm -qa | grep ^systemd-2
   systemd-234-lp152.30.1.x86_64

switching back to non-systemd-networkd network stack eliminates any such delay.
not surprising, given the bug -- and certainly not ideal.


If systemd is still the same, your distribution upgrade wasn’t relevant 
to the issue at hand, was it?


The upstream project only supports the latest two versions of systemd, 
which currently are 244 and 245. Please report your issues to openSUSE.



Kind regards,

Paul
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

1 2 >

1 - 100 of 127 matches

Mail list logo