Re: [systemd-devel] [PATCH 3/3] rules: Enable runtime power management on built-in USB Bluetooth controllers
В Sat, 18 Apr 2015 09:11:57 -0700 Matthew Garrett пишет: > From: Matthew Garrett > > 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 > I wonder how long the list will grow. Is not property in hwdb better approach? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Zombie process still exists after stopping gdm.service
В Fri, 17 Apr 2015 14:04:18 -0600 Daniel Drake пишет: > Hi, > > I'm investigating why "systemctl stop gdm; Xorg" usually fails. The > new X process complains that X is still running. > > Here's what I think is happening: > > 1. systemd sends SIGTERM to gdm to stop the service > > 2. gdm exits - it has a simple SIGTERM handler which just quits the > mainloop without doing any cleanup (as far as I can see, it doesn't > make any attempt to kill the child X server) > > 3. X exits because of PR_SET_PDEATHSIG (i.e. it's set to be > automatically killed when the parent goes away). The killed process > enters defunct state and is reparented to PID 1, presumably also > moving it out of the gdm cgroup. > No, it remains in cgroup. Otherwise systemd service management would not be possible at all ... > 4. systemd notes that gdm's cgroup is empty and decides that gdm is > now successfully stopped. > I looked at display-manager.service here and it sets KillMode=process. That is better explanation to your observation. > 5. systemctl returns and now Xorg is launched immediately. Xorg reads > the PID of the old Xorg process from /tmp, and notices that that PID > is still in use (it is still an unreaped zombie) because kill() > doesn't return an error. Xorg aborts thinking that it is already > running. > > 6. Moments later, systemd reaps the zombie. Oops, too late. > > > Does that make sense? > I wonder how it is best to fix this. Is it a bug that systemd decided > that gdm.service had stopped before it had reaped zombie processes > that originally belonged to gdm? > > Is it a gdm bug that killing gdm doesn't make any attempt to reap X > before going away itself? (they chose PR_SET_PDEATHSIG to do something > similar, but maybe we have to argue that it is not quite sufficient) > > Thanks > Daniel > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
В Fri, 17 Apr 2015 16:47:58 + Zbigniew Jędrzejewski-Szmek пишет: > On Mon, Feb 16, 2015 at 04:19:47PM +0100, Christian Seiler wrote: > > Am 2015-02-16 14:16, schrieb Lennart Poettering: > > >On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: > > >>Not quite. While you can use drop-in snippets to amend > > >>orderings/depends, it's (unfortunately) not possible to override > > >>Wants=,Before= etc. > > > > > >There have been discussions to allow masking deps via /dev/null > > >symlinks in .wants/ and .requires/ dirs... I think that'd be a better > > >solution... > > >[...] > > >>Agreed, systemctl edit is much nicer. Unfortunately, as said above, > > >>drop-ins can *not* be used to override all aspects of a native unit > > >>file. So it's not (yet) a complete replacement for insserv > > >>overrides. > > >> > > >>If it would be possible to unset Wants= or After=, just like other > > >>service properties, then things would be different. > > > > > >As mentioned, I'd be happy to take patches to make precisely that > > >work! > > > > Last time I talked about this here, there was a lot of confusion, so > > I didn't pursue it further. But I would really like to get this to > > work, but before I start with a patch, I'd like to explain what I'd > > like to do before working on it, to see if it works for you. > > > > The semantics I'd like to see would be the following: > > > > - anything in /etc named exactly the same as in /usr/lib overrides > >the latter, just as is already the case with units and drop-ins > > > > => allow masking of .wants/ and .requires/ with symlinks to > > /dev/null (I think you were in favor of that) > > > > - additionally, postpone processing of dependencies in unit files > >until the entire unit (and all drop-ins) have been read in > > > > For example, even without a drop-in: > > > > a.service: > > [Unit] > > Wants=b.service > > Wants= > > Wants=c.service > > > > After that, Wants should be set to c.service. Note that this > > should NOT affect dependencies set in other ways, i.e. via > > .wants/ directories or by dependencies of other services, this > > should JUST alter what was specified in the unit itself. > > > > A more complex example to illustrate the latter: > > > > /usr/lib/.../a.service: > > [Unit] > > Wants=b.service > > After=c.service > > > > /usr/lib/.../a.service.wants/d.service -> /usr/lib/.../d.service > > /usr/lib/.../a.service.wants/e.service -> /usr/lib/.../e.service > > > > /usr/lib/.../f.service > > [Unit] > > Before=a.service > > > > /etc/.../a.service.d/dont-depend-on-b.conf: > > [Unit] > > Wants= > > > > /etc/.../a.service.d/not-after-c.conf: > > [Unit] > > After= > > > > /etc/.../a.service.wants/e.service -> /dev/null > > > > In the end, the dependnecies should be: > > > > Wants=d.service > > - b.service gets removed via drop-in > > - e.service gets removed because it's masked > > - but d.service stays, because it was never defined in > > the unit file, so a drop-in doesn't override it, only > > the mask does > > > > After=f.service > > - c.service gets removed via drop-in > > - f.service is not declared in the original unit file but > > rather in f.service as a Before= dependency, so you'd > > have to override that to make this go into effect > > > > The general principle would be: you can drop stuff at the same > > place it's defined. If it's defined as After= in a unit, > > override it in a drop-in for that unit, if it's defined as > > Before= in another unit, override it in a drop-in for the other > > unit, and if it's defined in the filesystem via .wants/ or > > .requires/, you can override it by masking it in the filesystem. > > Only in the end will all remaining dependencies be combined to > > make up the entire list of dependencies for that service. > > > > Would you be agreeable to these semantics? If so, I'll hack up a > > patch. > Seems quite intuitive to me. Would be great to have this implemented. > Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] controlling serial console using a token
В Sat, 18 Apr 2015 19:54:50 +0530 Praveen kumar R пишет: > 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. > Sorry I do not understand this sentence. "define" what? Please give exact example of kernel command line and explain what behavior you expect in this case. > we have this in place for other system initializing system - sytemV , where > depending > > On Fri, Apr 17, 2015 at 4:24 PM, Lennart Poettering > wrote: > > > On Fri, 17.04.15 15:54, Praveen kumar R (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 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
[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 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
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
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 wrote:
> From: Matthew Garrett
>
> 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
[systemd-devel] [PATCH 1/3] rules: Enable runtime device power management on Intel HDA controllers
From: Matthew Garrett
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
[systemd-devel] [PATCH 3/3] rules: Enable runtime power management on built-in USB Bluetooth controllers
From: Matthew Garrett
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
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
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
[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
[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 > wrote: > On Fri, 17.04.15 15:54, Praveen kumar R (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
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 > 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
Re: [systemd-devel] Problem with intermediate target
В Thu, 16 Apr 2015 17:10:57 +0200 "Christoph Pleger" пишет: > 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
