Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?
On 04/18/2015 05:29 AM, Matt Hoosier wrote: On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez crrodrig...@opensuse.org mailto:crrodrig...@opensuse.org wrote: Did you watch this presentation ? https://www.youtube.com/watch?v=RFVlbaDqll8 what part of systemd is taking 1.5 seconds to start, on what CPU and how much of RAM does the board has ? Thanks, I hadn't found that presentation before. My board is essentially a Panda ES, with gigabytes of RAM. A small point of clarification: when I say that systemd takes 1.5 seconds, I'm referring to the time that elapses between the moment that /lib/systemd/systemd is exec'ed and the time that the first unit is shown in the 'systemd-analyze plot'. I haven't done an internal profile on the systemd binary to see what might be happening during that window yet. Does it spend significant time in loading modules from kmod-setup.c maybe? Maybe adding 'debug' to your kernel command line gives you a hint. Could you say a word more about the sys_accept4() and /sys/fs/cgroup issue? Was its only symptom that it caused systemd to run slower? That was a udev issue which should not affect you anymore with recent kernel versions (note the presentation is from 2011). It certainly has nothing to do with the effect you're seeing. Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] resolved: Assertion 'n 0' failed
Hello! Sometimes I'm seeing messages like this: [ 5780.379921] systemd-resolved[685]: Assertion 'n 0' failed at /var/tmp/portage/sys-apps/systemd-219- r2/work/systemd-219/src/resolve/resolved-dns-answer.c:28, function dns_answer_new(). Aborting. [ 5780.621865] systemd-resolved[7396]: Assertion 'n 0' failed at /var/tmp/portage/sys-apps/systemd-219- r2/work/systemd-219/src/resolve/resolved-dns-answer.c:28, function dns_answer_new(). Aborting. Looks like the process is aborted and restarted right after this (the PID changes) but the problem persists for a short duration. Then, everything is fine again. I didn't see problems in my desktop, tho. But I believe, if the DNS resolver gets timeouts (since it is using UDP) it will retry anyway. My configuration is nothing special, DHCP, DNS, and IPv6 advertisement provided by my router: $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp4s0 ether routableconfigured 3 sit0 sitoff unmanaged 3 links listed. $ networkctl status enp4s0 ● 2: enp4s0 Link File: /usr/lib64/systemd/network/99-default.link Network File: /etc/systemd/network/80-dhcp.network Type: ether State: routable (configured) Path: pci-:04:00.0 Driver: r8169 Vendor: Realtek Semiconductor Co., Ltd. Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (Motherboard (one of many)) HW Address: 00:25:22:xx:xx:xx (ASRock Incorporation) MTU: 1500 Address: 192.168.4.45 2002:::x::: 2002:::x:::: fe80::::: Gateway: 192.168.4.254 (Cisco-Linksys, LLC) fe80::::: (Cisco-Linksys, LLC) DNS: 192.168.4.254 Domain: sol.local $ cat /etc/systemd/network/80-dhcp.network [Match] Name=en* [Network] DHCP=yes [DHCP] UseDomains=true -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with intermediate target
Hello, Why does systemd start this service before /var is mounted, though the service should be executed after remote-fs.target, and remote-fs.target comes after local-fs.target? Because remote-fs.target is not part of initial transaction. And why is this different in my intermediate.target than in multi-user.target, though intermediate.target defines exactly the same requirements, orders and conflicts as multi-user.target? Because systemd allows to declare extra dependencies that are not directly part of unit definition. E.g. remote-fs.target has WantedBy=multi-user.target. It is *not* dependencies listed in unit configuration of multi-user.target that make it start remote-fs.target. When initial target is multi-user.target all those reverse dependencies (for lack of better word) are pulled in and are part of initial transaction. With another unit as initial target they are skipped. Ah, I understand, that makes it clear. The auto-generated pident.service file only defines that the service should be executed after remote-fs.target, but it does not require it, and because no other service or target wants or requires remote-fs.target before pidentd.service starts, the filesystems are not yet mounted at that point. But then, I think that the way how systemd translates LSB init scripts should be changed. This is the LSB part of /etc/init.d/pidentd: ### BEGIN INIT INFO # Provides: pidentd-run-dir # Required-Start:$remote_fs # Required-Stop: $remote_fs # Default-Start: S # Default-Stop: # Short-Description: setup for pidentd # Description: create /var/run/ident for pidentd ### END INIT INFO As you can see, it defines remote-fs in Required-Start, not in Should-Start. In my opinion, this should result in an additional Requires=remote-fs.target in pidentd.service. Regards Christoph ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Problem with intermediate target
В Thu, 16 Apr 2015 17:10:57 +0200 Christoph Pleger christoph.ple...@cs.tu-dortmund.de пишет: Hello, I wrote: Sounds like you want to create intermediate.target, change default.target to point at it, boot all the way up to intermediate.target, and at that point isolate or start multi-user.target. I chose that solution, because from all possible solutions for the desired boot order, it seems to be the one which is closest to my idea. After setting intermediate.target as default target and defining a service belonging to intermediate.target that switches to graphical.target, I discovered the following (which does not happen when graphical.target is the default target): With the package pidentd installed, which does not bring a .service file, but only an init script that wants to create a directory /var/run/identd, at boot time some error messages appear on the screen that /var is not writable. Obviously, /var is not mounted yet when the script is executed. After booting, this is the content of/run/systemd/generator.late/pidentd.service: # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/pidentd Description=LSB: setup for pidentd DefaultDependencies=no Before=sysinit.target After=remote-fs.target [Service] Type=forking Restart=no TimeoutSec=0 IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SysVStartPriority=19 ExecStart=/etc/init.d/pidentd start ExecStop=/etc/init.d/pidentd stop Why does systemd start this service before /var is mounted, though the service should be executed after remote-fs.target, and remote-fs.target comes after local-fs.target? Because remote-fs.target is not part of initial transaction. And why is this different in my intermediate.target than in multi-user.target, though intermediate.target defines exactly the same requirements, orders and conflicts as multi-user.target? Because systemd allows to declare extra dependencies that are not directly part of unit definition. E.g. remote-fs.target has WantedBy=multi-user.target. It is *not* dependencies listed in unit configuration of multi-user.target that make it start remote-fs.target. When initial target is multi-user.target all those reverse dependencies (for lack of better word) are pulled in and are part of initial transaction. With another unit as initial target they are skipped. More strange, when booting is completed, the directory /var/run/identd exists. It seems that the init script is called a second time ... May be. systemctl -p WantedBy -p RequiredBy pidentd.service would answer it. And no, I do not think it is systemd feature :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] controlling serial console using a token
Yes it's a kernel command line arg, it is board specific token introduced to control the serial console. if defined serial console should not be enabled. we have this in place for other system initializing system - sytemV , where depending On Fri, Apr 17, 2015 at 4:24 PM, Lennart Poettering lenn...@poettering.net javascript:_e(%7B%7D,'cvml','lenn...@poettering.net'); wrote: On Fri, 17.04.15 15:54, Praveen kumar R (praveenrgo...@gmail.com javascript:_e(%7B%7D,'cvml','praveenrgo...@gmail.com');) wrote: I have a token passed on by command line argument on which I need to decide to start the serial On which command line? Kernel command line? What kind of token? console or not. I plan to tweak the getty*ttyS0.service and add the script which validates the token and starts the console. Is this the right approach or is there any better way of handling it ?? To get a login getty on the serial port its sufficient to add console=ttyS0... to the kernel cmdline. systemd automatically starts a serial getty automatically on the first terminal the kernel console is pointing to. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] rules: Enable runtime power management on built-in USB Bluetooth controllers
From: Matthew Garrett mj...@coreos.com
If a Bluetooth controller is built into the machine, it should be safe to
enable runtime power management on it. Let's do so.
---
Makefile.am | 3 ++-
rules/90-usb-bluetooth-pm.rules | 8
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 rules/90-usb-bluetooth-pm.rules
diff --git a/Makefile.am b/Makefile.am
index 40cf101..8463a54 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3754,7 +3754,8 @@ dist_udevrules_DATA += \
rules/78-sound-card.rules \
rules/80-net-setup-link.rules \
rules/90-hda-controller-pm.rules \
- rules/90-hda-codec-pm.rules
+ rules/90-hda-codec-pm.rules \
+ rules/90-usb-bluetooth-pm.rules
nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-usb-bluetooth-pm.rules b/rules/90-usb-bluetooth-pm.rules
new file mode 100644
index 000..ea535f0
--- /dev/null
+++ b/rules/90-usb-bluetooth-pm.rules
@@ -0,0 +1,8 @@
+# USB devices that are internal to the machine should also be safe to
autosuspend
+
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{removable}==removable, GOTO=usb_bluetooth_pm_end
+ACTION==add, SUBSYSTEM==usb, SUBSYSTEMS==usb,
ATTR{removable}==unknown, GOTO=usb_bluetooth_pm_end
+
+ACTION==add, SUBSYSTEM==usb, ATTR{bDeviceClass}==e0,
ATTR{bDeviceSubClass}==01, ATTR{bDeviceProtocol}==01,
TEST==power/control, ATTR{power/control}=auto
+
+LABEL=usb_bluetooth_pm_end
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] rules: Enable runtime device power management on a subset of HDA codecs
From: Matthew Garrett mj...@coreos.com
4.1 ports HDA codec power management to the standard runtime PM framework,
which means we have per-codec control over whether it's enabled or not.
We've traditionally left this disabled because on some codecs enabling it
causes popping noises on power transitions, but now we can whitelist on a
per-codec basis. This patch simply enables it for the Broadwell HDMI codec
with the aim that we can add more based on user feedback.
---
Makefile.am | 3 ++-
rules/90-hda-codec-pm.rules | 4
2 files changed, 6 insertions(+), 1 deletion(-)
create mode 100644 rules/90-hda-codec-pm.rules
diff --git a/Makefile.am b/Makefile.am
index d23c428..40cf101 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3753,7 +3753,8 @@ dist_udevrules_DATA += \
rules/75-net-description.rules \
rules/78-sound-card.rules \
rules/80-net-setup-link.rules \
- rules/90-hda-controller-pm.rules
+ rules/90-hda-controller-pm.rules \
+ rules/90-hda-codec-pm.rules
nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-hda-codec-pm.rules b/rules/90-hda-codec-pm.rules
new file mode 100644
index 000..e0c55e1
--- /dev/null
+++ b/rules/90-hda-codec-pm.rules
@@ -0,0 +1,4 @@
+# Enable autosuspend for some HDA codecs
+
+ACTION==add, SUBSYSTEM==hdaudio, ATTR{chip_name}==Broadwell HDMI,
ATTR{power/control}=auto
+
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Enable runtime power management on more hardware
Modern hardware is very sensitive to peripheral power management state. While the kernel supports runtime PM on a lot of hardware, it's mostly disabled by default due to the risk of it breaking a subset of devices. Let's turn it on on devices where we have reasonable confidence in it working, with the aim of extending this to more devices as we receive user feedback. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
From: Matthew Garrett mj...@coreos.com
PCI power management seems to work fine on Intel HDA controllers, so let's
turn that on. We can expand this to other vendors based on user feedback.
---
Makefile.am | 3 ++-
rules/90-hda-controller-pm.rules | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
create mode 100644 rules/90-hda-controller-pm.rules
diff --git a/Makefile.am b/Makefile.am
index 68d8252..d23c428 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3752,7 +3752,8 @@ dist_udevrules_DATA += \
rules/70-touchpad.rules \
rules/75-net-description.rules \
rules/78-sound-card.rules \
- rules/80-net-setup-link.rules
+ rules/80-net-setup-link.rules \
+ rules/90-hda-controller-pm.rules
nodist_udevrules_DATA += \
rules/99-systemd.rules
diff --git a/rules/90-hda-controller-pm.rules b/rules/90-hda-controller-pm.rules
new file mode 100644
index 000..2f915be
--- /dev/null
+++ b/rules/90-hda-controller-pm.rules
@@ -0,0 +1,3 @@
+# Enable autosuspend for some HDA interfaces
+
+ACTION==add, SUBSYSTEM==pci, ATTR{class}==0x040300,
ATTR{vendor}==0x8086, ATTR{power/control}=auto
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
On Sat, Apr 18, 2015 at 6:11 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
From: Matthew Garrett mj...@coreos.com
PCI power management seems to work fine on Intel HDA controllers, so let's
turn that on. We can expand this to other vendors based on user feedback.
+ACTION==add, SUBSYSTEM==pci, ATTR{class}==0x040300,
ATTR{vendor}==0x8086, ATTR{power/control}=auto
It looks like an unconditional static assignment.
Why should udev carry this? We generally do not want to do things like
that. Udev can help if there is conditional policy or complex
cross-subsystem knowledge is needed, but this looks just like a job
for the kernel and not userspace.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
(Resending from the correct address) On Sat, Apr 18, 2015 at 07:51:26PM +0200, Kay Sievers wrote: It looks like an unconditional static assignment. Why should udev carry this? We generally do not want to do things like that. Udev can help if there is conditional policy or complex cross-subsystem knowledge is needed, but this looks just like a job for the kernel and not userspace. 1) having this in udev makes it easier for users to alter the configuration - the kernel can then afford to be conservative until we enable power management, rather than potentially breaking the device the moment pm is enabled without any ability to recover it. 2) this config is currently static, but the appropriate policy may turn out to be more complicated in some scenarios (interactions between devices and their upstream bridges, for instance, or USB Bluetooth controllers that are on-die with a PCI wifi controller without having a common exposed bus topology yet still having pm interactions). Splitting this between udev and the kernel makes it more difficult to determine the source of the policy and debug it. 3) we already have examples of this in udev, so people already expect to find it here. -- Matthew Garrett | mj...@srcf.ucam.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] udev: Allow detection of udevadm settle timeout
When udevadm settle times out, it exits with exit code 1. This make it
impossible for users to detect a timeout and handle real errors. Now we
use exit code 3 on timeouts.
---
src/udev/udevadm-settle.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 2c84ada..114951c 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -29,6 +29,8 @@
#include udev.h
#include util.h
+#define EXIT_TIMEOUT 3
+
static void help(void) {
printf(%s settle OPTIONS\n\n
Wait for pending udev events.\n\n
@@ -142,8 +144,10 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
break;
}
-if (timeout 0 now(CLOCK_MONOTONIC) = deadline)
+if (timeout 0 now(CLOCK_MONOTONIC) = deadline) {
+rc = EXIT_TIMEOUT;
break;
+}
/* wake up when queue is empty */
if (poll(pfd, 1, MSEC_PER_SEC) 0 pfd[0].revents POLLIN)
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] udev: Fix ping timeout when settle timeout is 0
When running udevadm settle --timeout=0, the ping always times out, and
udevadm will return 0 without checking the queue state.
Since zero timeout is considered as unlimited timeout, we use now
unlimited ping timeout.
---
src/udev/udevadm-settle.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 2c84ada..424 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -107,7 +107,9 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
uctrl = udev_ctrl_new(udev);
if (uctrl != NULL) {
-if (udev_ctrl_send_ping(uctrl, timeout) 0) {
+int ping_timeout = timeout 0 ? (int)timeout : -1;
+
+if (udev_ctrl_send_ping(uctrl, ping_timeout) 0) {
log_debug(no connection to daemon);
udev_ctrl_unref(uctrl);
return EXIT_SUCCESS;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 1/2] udev: settle should return immediately when timeout is 0
udevadm manual says:
A value of 0 will check if the queue is empty and always return
immediately.
However, currently we ignore the deadline if the value is 0, and wait
without any limit.
Zero timeout behaved according to the documentation until commit
ead7c62ab7 (udevadm: settle - kill alarm()). Looking at this patch, it
seems that the behavior change was unintended.
This patch restores the documented behavior.
---
src/udev/udevadm-settle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 2c84ada..437c794 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -142,7 +142,7 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
break;
}
-if (timeout 0 now(CLOCK_MONOTONIC) = deadline)
+if (now(CLOCK_MONOTONIC) = deadline)
break;
/* wake up when queue is empty */
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 2/2] udev: Skip ping if timeout is 0
When running udevadm settle --timeout=0, udev_ctrl_send_ping always
times out, and settle returns 0 without checking the queue.
Now we skip ping in this case, and return the queue state.
---
src/udev/udevadm-settle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 437c794..614768f 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -102,7 +102,7 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
deadline = now(CLOCK_MONOTONIC) + timeout * USEC_PER_SEC;
/* guarantee that the udev daemon isn't pre-processing */
-if (getuid() == 0) {
+if (timeout 0 getuid() == 0) {
struct udev_ctrl *uctrl;
uctrl = udev_ctrl_new(udev);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
