Re: [systemd-devel] Synchronization Between Services at Shutdown
Thanks for the quick reply, Andrei. It sounds like there is indeed a race condition in my code then since there is nothing explicit in my implementation of service A that makes it wait until it has processed the method call from service B before it stops listening for method calls. Did I get that right? On Wed, Apr 1, 2015 at 8:26 PM, Andrei Borzenkov arvidj...@gmail.com wrote: В Wed, 1 Apr 2015 18:22:50 -0700 Kurt von Laven k...@endlessm.com пишет: Hello folks, I am trying to ensure that my system DBus service has time to handle a DBus method call before it shuts down. My DBus service is implemented as a system systemd service; let's call it service A. It runs a single-threaded, synchronous event loop that listens for DBus method calls and handles them appropriately. This event loop also listens for SIGTERM. When SIGTERM is received, service A currently terminates the event loop, performs any necessary writes to disk, and releases its resources. I am assuming that when the system is shut down cleanly, systemd initially sends SIGTERM to systemd services and only sends SIGKILL to abort it abruptly if it takes too long to shut down when asked nicely. I have another system systemd service, call it service B, that runs an event loop listening for SIGTERM. When service B receives a SIGTERM, it makes the aforementioned DBus method call and then flushes the system bus. Service B specifies Requires= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires= Service A and After= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before= Service A. Service A makes no mention of service B in its unit configuration file. Does systemd make any sort of guarantee that service A will get a chance to handle the DBus method call before receiving SIGTERM, or does my code as written have a race condition? systemd will not initiate stopping of A before B has stopped. If it does, this should be considered a bug. So it is up to service B to handle termination correctly. Note that systemd will send SIGKILL after timeout if service has not terminated. -- Kurt von Laven | Endless Mobile | EndlessM.com http://endlessm.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masked services start dependencies in any case
On Mon, 30.03.15 01:46, Jan Engelhardt (jeng...@inai.de) wrote:
Thread originated in
http://lists.opensuse.org/opensuse-factory/2015-03/msg00419.html
On Monday 2015-03-30 01:07, Jan Engelhardt wrote:
On Sunday 2015-03-29 20:24, Stefan Seifert wrote:
Some time in the last month Tumbleweed lost the ability to boot into
runlevel
3 (command line with no X server running) by appending a 3 to the kernel
line
in the grub menu. I guess that's because with systemd there are no numbered
runlevels anymore,
There is a bug… somewhere. !@#$%^
Our basic.target requests klog.service.
Our klog.service has a Requires=default.target defined. This resolves
to, say, graphical.target, *rather than* what's on the command line. And
so, the graphic parts are started *even if* you have 3 on the boot
line.
klog.service itself is masked in our setup, so it won't be started, but
its dependencies *are* in systemd-219. Why, o why? :-{
This did not occur in 210.
What does systemctl status and systemctl show say about the unit
in question?
(And what is klog.service? Sounds really obsolete...)
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] [systemd-219] Journal spamming by umount / high CPU usage
On Sun, 29.03.15 17:12, Kai Krakow (hurikha...@gmail.com) wrote: Hello! I've got a automount point for a daily USB backup job. Due to some instabilities of early USB3 chipsets and early USB3 devices, the mounted device sometimes wents offline and eventually comes back after a while but my backup job is stuck (rsync). I configured rsync to shutdown upon block io timeouts. This in turn makes the systemd automounter think (correctly) that the mount point is no longer in use - but it cannot be unmounted. The problem here is, that it spams the journal with hundreds of messages per minute all day long (or as long as I don't reboot): Hmm? The systemd automount logic so far does not support mount expiration, hence I cannot really parse what you write above? Mär 29 16:49:00 jupiter umount[19547]: umount: /mnt/private/usb-backup: umount fehlgeschlagen: Die Operation ist nicht erlaubt Why does this fail with EPERM? I don't really follow I must admit... 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] parsing audit messages
On Thu, 26.03.15 13:56, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Mar 26, 2015 at 09:42:45AM +0100, Lennart Poettering wrote: On Sun, 15.03.15 03:51, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sun, Mar 15, 2015 at 03:49:07AM +0100, Zbigniew Jędrzejewski-Szmek wrote: Hi, I was looking at some debug logs, and the audit messages are semi-useless in their current undecoded form: mar 14 22:24:02 fedora22 audit[1]: audit-1130 pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-udev-trigger comm=systemd exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=success' mar 14 22:24:05 fedora22 audit: audit-1327 proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D0069707461626C655F7365637572697479 You added code to parse this, and I think we should make use of it and put msg= field as MESSAGE=, and maybe store the original message as _AUDIT= or something. If there's no msg field, like with proctitle, print all fields that are in the message, but using our cescape, and not this hexadecimal form which is unreadable for humans. I think we should also translate type= to names... https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sec-Audit_Record_Types.html Well, we don't translate MESSAGE_ID fields to strings either... Here the mapping is stable, and maintained in one place... I think it's more like dns TYPE field, completely reversible, then MESSAGE_IDs. I think generating a translation table automatically from the headers like we do for input keys should be OK. 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] possible to detect journald rate limiting?
On Mon, 23.03.15 20:09, Chris Morgan (chmor...@gmail.com) wrote: Hello. I have a journal test that fails periodically. When observing the test with journalctl -f in the cases that fail I don't see any journal entries from the journalctl -f. I'm wondering if I'm hitting rate limiting here on F21 (systemd 216). Is there some way to detect at the application that I'm being rate limited? I'm getting 0 back from sd_journal_sendv(). Or some other mechanism to detect? No, delivery to the journal is asynchronous, and there is no client-side rate limiting applied, hence the client side doesn't have any information about rate limiting at all. The server side shows after each applied ratelimiting that it applied some ratelimiting. 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] [PATCH] tmpfiles: don't create subvolumes in chroot
Lennart Poettering lenn...@poettering.net writes: On Wed, 01.04.15 15:45, Jan Synacek (jsyna...@redhat.com) wrote: I am also against this since chrooting is an implementation detail of mock, nothing more, and the fact that mock's recursive deletion logic cannot handle removal of subvolumes is not directly connected to the fact that mock uses chroot. Sorry, but we need to find a different solution for this. Maybe mock should use seccomp to make the subvolume creation ioctls unavailable, or it should be updated to deal with subvolumes properly. I agree that mock should be enhanced to cope with subvolumes, but I also think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... I think that in mock root it doesn't. But that's a special case. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: clean up output a little bit
On Tue, 31.03.15 11:52, Shawn Landden (sh...@churchofgit.com) wrote:
---
src/systemctl/systemctl.c | 51
+++
1 file changed, 51 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 3158a38..bf279f9 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4133,6 +4133,57 @@ static int print_property(const char *name,
sd_bus_message *m, const char *conte
}
break;
+
+case SD_BUS_TYPE_UINT64:
+ /* alternatively we could print these as infinity like
CPUQuotaPerSecUSec */
+if (startswith(name, Limit) ||
+streq(name, CPUShares) ||
+streq(name, StartupCPUShares) ||
+streq(name, BlockIOWeight) ||
+streq(name, StartupBlockIOWeight) ||
+/* confusing that MemoryCurrent could be
UINT64_MAX */
Hmm, what is this about?
+streq(name, MemoryCurrent) ||
+streq(name, MemoryLimit) ||
+
+streq(name, CapabilityBoundingSet)) {
+uint64_t u64;
+
+r = sd_bus_message_read_basic(m, 't', u64);
+if (r 0)
+return bus_log_parse_error(r);
+
+if ((u64 != (uint64_t) - 1) || arg_all)
+printf(%s=%PRIu64\n, name, u64);
+
+return 0;
+
+}
+
+break;
+
+case SD_BUS_TYPE_BOOLEAN:
+
+if (endswith(name, Accounting) ||
+startswith(name, Private) ||
+streq(name, NoNewPrivileges) ||
+streq(name, NonBlocking) ||
+streq(name, CPUSchedulingResetOnFork) ||
+streq(name, Delegate) ||
+streq(name, Transient)) {
+bool b;
+
+r = sd_bus_message_read_basic(m, 'b', b);
+if (r 0)
+return bus_log_parse_error(r);
+
+if ((b == true) || arg_all)
+printf(%s=%s\n, name, yes_no(b));
+
+return 0;
+
+}
+
+break;
No, I really don't like this. I don't want to encode tables with
default values on the client side. First of all these tables can get out of
date, and secondly, the defaults for many of these can actually be
altered via system.conf as mentioned earlier.
In fact, I am tempted to go the other way and drop the suppression of
empty fields, and simply always show all fields.
I'd be willing to add some extra code to bus_print_property() which
displays the special value (uint64_t) -1 as -1 instead of
18446744073709551615. And similar for uint32_t... That should slightly
improve the output already.
Another idea to think about might be to just drop all special
formatting in the show output and instead use the sd-bus string
serialization that busctl introspect shows for all the fields. That
format is shell parsable at least, and somewhat easy to
grok. But I figure we can't really do that, since we claim that
systemctl show is machine parsable, and making major changes to its
formatting should hence not be OK.
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] [PATCH] tmpfiles: don't create subvolumes in chroot
On Wed, 01.04.15 21:04, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/01/2015 02:37 PM, Lennart Poettering wrote: Note that I intend to add more subvolume lines to tmpfiles even. For example, I am pretty sure /home should be created as subvolume if it doesn't exist already, and similar. I'm afraid that will still only work on a single host setup ( laptop/desktop ) and I'm pretty sure if the intent from you is to default to more subvolume creation i'm afraid you will start conflicting with installers on top of everything else as well. Why would this conflict with installers? 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] [PATCH] tmpfiles: don't create subvolumes in chroot
On Thu, 02.04.15 08:59, Jan Synacek (jsyna...@redhat.com) wrote: think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... I think that in mock root it doesn't. But that's a special case. Why not? Subvolumes are fully recursive, hence it doesn't really matter whether they are created on the host or in a chroot environment or a container or whatever else. Lennart -- Lennart Poettering, Red Hat ___ 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)
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] [PATCH 0/5] udev/hwdb: Add support for setting trackpoint properties
Hi All, Testing has shown that the default experience of trackpoints on different model laptops differs quite a lot, from almost unusably fast, to just plain unusably slow on some models. It seems that before libinput people where using the huge amount of configurability Xorg gives them to work around this, this is not a situation which we want to replicate with libinput. Instead the plan is to where necessary add hwdb entries telling libinput apply a constant (linear) acceleration factor to deltas from the trackpoint to normalize the deltas. This patch-set also adds some special handling for IBM/Lenovo trackpoints which also have a sysfs driver setting which allows tweaking the sensitivity and on some models we need to set a specific value to get the best user experience. This patch-set has been tested (together with a matching libinput patch) on 5 different models sofar: Thinkpad X200s, Thinkpad T440s, Dell Latitude D620, Dell Latitude E6400, Dell Latitude E6430. Note the 2 ThinkPad models where specifically chosen as they are known to have a bad ootb trackpoint experience, so unsurprisingly both end up with hwdb entries, see: https://bugzilla.redhat.com/show_bug.cgi?id=1200717 https://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/Trackpoint-quot-too-slow-quot-proglem-of-X1-Carbon-Gen-2/td-p/1603962 Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/5] hwdb: Add entries for the trackpoint on 2 Thinkpads
Lenovo has changed the sensitity of the trackpoint on the x240 / T440s / T540 generation of Thinkpads, making them somewhat unsensitive by default, add a hwdb entry to tweak the sensitivity setting. The ThinkPad X200s is way way too slow by default and unless you push the trackpoint quite hard only sends delta events in the 1-2 range, tweak the sensitivity to make it send a wider range of deltas and apply a const accel factor to make it have a more reasonable speed by default. Signed-off-by: Hans de Goede hdego...@redhat.com --- hwdb/70-trackpoint.hwdb | 14 ++ 1 file changed, 14 insertions(+) diff --git a/hwdb/70-trackpoint.hwdb b/hwdb/70-trackpoint.hwdb index 3dd5100..0017d8b 100644 --- a/hwdb/70-trackpoint.hwdb +++ b/hwdb/70-trackpoint.hwdb @@ -68,3 +68,17 @@ # # Sort by by brand, model + +# +# Lenovo +# + +# Lenovo Thinkpad X200s +trackpoint:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX200s:* + TRACKPOINT_SENSITIVTY=200 + TRACKPOINT_CONST_ACCEL=1.5 + +# Lenovo Thinkpad T440s +trackpoint:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440s:* + TRACKPOINT_SENSITIVTY=200 + TRACKPOINT_CONST_ACCEL=1.0 -- 2.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/5] udev: Add rules and hwdb files for setting trackpoint properties
There is quite a wide spread in the delta events generated by trackpoints,
some generate deltas of 1-2 under normal use, while others generate deltas
from 1-20.
This commit adds a set of rules + a hwdb file which allows specifying a
per model TRACKPOINT_CONST_ACCEL value which can be used by the userspace
input stack to normalize the deltas so that all trackpoints get the same
speed/feeling ootb.
The hwdb matching is modelled after 60-keyboard.rules, rather then after
70-mouse.rules, as trackpoints are typically (but not always) found integrated
into laptops and the keyboard matching rules are a better match to this.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hwdb/70-trackpoint.hwdb | 59 +++
rules/70-mouse.rules | 1 +
rules/70-trackpoint.rules | 16 +
3 files changed, 76 insertions(+)
create mode 100644 hwdb/70-trackpoint.hwdb
create mode 100644 rules/70-trackpoint.rules
diff --git a/hwdb/70-trackpoint.hwdb b/hwdb/70-trackpoint.hwdb
new file mode 100644
index 000..f2f8364
--- /dev/null
+++ b/hwdb/70-trackpoint.hwdb
@@ -0,0 +1,59 @@
+# This file is part of systemd.
+#
+# Trackpoint const-accel configuration, to make different brand / model
+# laptop trackpoints have the same speed / feel, and per model adjustment
+# of the IBM TrackPoint driver's sensitivty setting
+#
+# The lookup keys are composed in:
+# 70-trackpoint.rules
+#
+# Note: The format of the trackpoint: prefix match key is a
+# contract between the rules file and the hardware data, it might
+# change in later revisions to support more or better matches, it
+# is not necessarily expected to be a stable ABI.
+#
+# Supported hardware matches are:
+# - Generic input devices match:
+# trackpoint:input:bvpe-
+#This matches on the kernel modalias of the input-device, mainly:
+# is the bus-id (see /usr/include/linux/input.h BUS_*), , and
+#WWW are the 4-digit hex uppercase vendor, product and version ID and
+#is an arbitrary length input-modalias describing the device capabilities.
+#
+# - Input driver device name and DMI data match:
+# trackpoint:name:input device name:dmi:bvn*:bvr*:bd*:svnvendor:pn*
+#input device name is the name device specified by the driver,
+#vendor is the firmware-provided string from the kernel DMI modalias.
+#
+# To add local entries, create a new file
+# /etc/udev/hwdb.d/71-trackpoint-local.hwdb
+# and add your rules there. To load the new rules execute (as root):
+# udevadm hwdb --update
+# udevadm trigger /dev/input/eventXX
+# where /dev/input/eventXX is the trackpoint in question. If in
+# doubt, simply use /dev/input/event* to reload all input rules.
+#
+# If your changes are generally applicable, open a bug report on
+# http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
+# and include your new rules, a description of the device, and the
+# output of
+# udevadm info /dev/input/eventXX
+# (or /dev/input/event*).
+#
+# Allowed properties are:
+# TRACKPOINT_CONST_ACCEL
+#
+#
+#TRACKPOINT_CONST_ACCEL #
+#
+#
+# Trackpoint const accel settings are specified as
+#TRACKPOINT_CONST_ACCEL=accel
+#
+# Where accel is a floating point number, using a '.' seperator, specifying
+# by how much to multiply deltas generated by the trackpoint to get
+# normalized deltas.
+#
+
+#
+# Sort by by brand, model
diff --git a/rules/70-mouse.rules b/rules/70-mouse.rules
index 3ea743a..c47a1b1 100644
--- a/rules/70-mouse.rules
+++ b/rules/70-mouse.rules
@@ -3,6 +3,7 @@
ACTION==remove, GOTO=mouse_end
KERNEL!=event*, GOTO=mouse_end
ENV{ID_INPUT_MOUSE}==, GOTO=mouse_end
+ENV{ID_INPUT_TRACKPOINT}==1, GOTO=mouse_end
# mouse:subsystem:vvidppid:name:name:*
KERNELS==input*, ENV{ID_BUS}==usb, \
diff --git a/rules/70-trackpoint.rules b/rules/70-trackpoint.rules
new file mode 100644
index 000..8ecbde6
--- /dev/null
+++ b/rules/70-trackpoint.rules
@@ -0,0 +1,16 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION==remove, GOTO=trackpoint_end
+KERNEL!=event*, GOTO=trackpoint_end
+ENV{ID_INPUT_TRACKPOINT}==, GOTO=trackpoint_end
+
+# skip later rules when we find something for this input device
+IMPORT{builtin}=hwdb --subsystem=input --lookup-prefix=trackpoint:, \
+ GOTO=trackpoint_end
+
+# device matching the input device name and the machine's DMI data
+KERNELS==input*, \
+ IMPORT{builtin}=hwdb
'trackpoint:name:$attr{device/name}:$attr{[dmi/id]modalias}', \
+ GOTO=trackpoint_end
+
+LABEL=trackpoint_end
--
2.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/5] udev: Update trackpoint rules to allow setting ibm trackpoint sensitivity
The IBM / Lenovo trackpoints are special, they allow specifying a sensitivity
setting through a ps/2 command, which changes the range of the deltas send when
using the trackpoint. One some models with normal usage one only deltas
of 1 or 2 are send, resulting in there only being 2 mouse cursor movement
speeds, rather then the expected fluid scale.
Changing the sensitivity to a higher level then the bootup default fixes this,
the rule additions in this commit allows specifying a new sensitivity default
through hwdb giving a better ootb experience.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
hwdb/70-trackpoint.hwdb | 11 +++
rules/70-trackpoint.rules | 6 ++
2 files changed, 17 insertions(+)
diff --git a/hwdb/70-trackpoint.hwdb b/hwdb/70-trackpoint.hwdb
index f2f8364..3dd5100 100644
--- a/hwdb/70-trackpoint.hwdb
+++ b/hwdb/70-trackpoint.hwdb
@@ -54,6 +54,17 @@
# by how much to multiply deltas generated by the trackpoint to get
# normalized deltas.
#
+#
+# TRACKPOINT_SENSITIVTY #
+#
+#
+# TPPS/2 IBM TrackPoint driver sensitivity sysfs setting
+#TRACKPOINT_SENSITIVITY=sensitivity
+#
+# Where sensitivity is a number between 0 and 255, note this property
+# only applies to TPPS/2 IBM TrackPoint devices and only works with DMI
+# matches.
+#
#
# Sort by by brand, model
diff --git a/rules/70-trackpoint.rules b/rules/70-trackpoint.rules
index 8ecbde6..1ed234d 100644
--- a/rules/70-trackpoint.rules
+++ b/rules/70-trackpoint.rules
@@ -8,6 +8,12 @@ ENV{ID_INPUT_TRACKPOINT}==, GOTO=trackpoint_end
IMPORT{builtin}=hwdb --subsystem=input --lookup-prefix=trackpoint:, \
GOTO=trackpoint_end
+# Same as below but also sets the TPPS/2 IBM TrackPoint driver sensitivity
+KERNELS==input*, ATTR{device/name}==TPPS/2 IBM TrackPoint, \
+ IMPORT{builtin}=hwdb
'trackpoint:name:$attr{device/name}:$attr{[dmi/id]modalias}', \
+ RUN=/bin/sh -c 'echo -n $env{TRACKPOINT_SENSITIVTY}
/sys$env{DEVPATH}/../../../sensitivity', \
+ GOTO=trackpoint_end
+
# device matching the input device name and the machine's DMI data
KERNELS==input*, \
IMPORT{builtin}=hwdb
'trackpoint:name:$attr{device/name}:$attr{[dmi/id]modalias}', \
--
2.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 5/5] hwdb: Add entries for the trackpoint on 2 Dell Latitudes
The trackpoint of the Dell Latitude E6400 is somewhat slow by default, where as the trackpoint of the Dell Latitude D620 is much too fast by default, set TRACKPOINT_CONST_ACCEL for both of them to adjust for this. Signed-off-by: Hans de Goede hdego...@redhat.com --- hwdb/70-trackpoint.hwdb | 12 1 file changed, 12 insertions(+) diff --git a/hwdb/70-trackpoint.hwdb b/hwdb/70-trackpoint.hwdb index 0017d8b..30c22a3 100644 --- a/hwdb/70-trackpoint.hwdb +++ b/hwdb/70-trackpoint.hwdb @@ -70,6 +70,18 @@ # Sort by by brand, model # +# Dell +# + +# Latitude D620 +trackpoint:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeD620*:pvr* + TRACKPOINT_CONST_ACCEL=0.5 + +# Latitude E6400 +trackpoint:name:*DualPoint Stick:dmi:bvn*:bvr*:bd*:svnDellInc.:pnLatitudeE6400*:pvr* + TRACKPOINT_CONST_ACCEL=1.5 + +# # Lenovo # -- 2.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/5] udev-builtin-input_id: identify trackpoints and accelerometers
The kernel has been setting the INPUT_PROP_POINTING_STICK property bit
on trackpoints for a while now, and this is useful information to have
in various places, so make input_id aware of this and make it set
ID_INPUT_POINTING_STICK on trackpoints.
While adding support for querying properties, also add support for the
recently added INPUT_PROP_ACCELEROMETER property bit.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/udev/udev-builtin-input_id.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c
index 46f1c53..5b1790c 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -33,6 +33,14 @@
#include udev.h
#include util.h
+#ifndef INPUT_PROP_POINTING_STICK
+#define INPUT_PROP_POINTING_STICK 0x05
+#endif
+
+#ifndef INPUT_PROP_ACCELEROMETER
+#define INPUT_PROP_ACCELEROMETER0x06
+#endif
+
/* we must use this kernel-compatible implementation */
#define BITS_PER_LONG (sizeof(unsigned long) * 8)
#define NBITS(x) x)-1)/BITS_PER_LONG)+1)
@@ -131,6 +139,7 @@ static void test_pointers (struct udev_device *dev,
const unsigned long* bitmask_abs,
const unsigned long* bitmask_key,
const unsigned long* bitmask_rel,
+ unsigned long prop,
bool test) {
int is_mouse = 0;
int is_touchpad = 0;
@@ -182,6 +191,10 @@ static void test_pointers (struct udev_device *dev,
udev_builtin_add_property(dev, test, ID_INPUT_MOUSE, 1);
if (is_touchpad)
udev_builtin_add_property(dev, test, ID_INPUT_TOUCHPAD, 1);
+if (prop (1 INPUT_PROP_POINTING_STICK))
+udev_builtin_add_property(dev, test, ID_INPUT_TRACKPOINT,
1);
+if (prop (1 INPUT_PROP_ACCELEROMETER))
+udev_builtin_add_property(dev, test, ID_INPUT_ACCELEROMETER,
1);
}
/* key like devices */
@@ -232,7 +245,8 @@ static int builtin_input_id(struct udev_device *dev, int
argc, char *argv[], boo
unsigned long bitmask_abs[NBITS(ABS_MAX)];
unsigned long bitmask_key[NBITS(KEY_MAX)];
unsigned long bitmask_rel[NBITS(REL_MAX)];
-const char *sysname, *devnode;
+unsigned long prop = 0;
+const char *sysname, *devnode, *prop_str;
/* walk up the parental chain until we find the real input device; the
* argument is very likely a subdevice of this, like eventN */
@@ -248,7 +262,10 @@ static int builtin_input_id(struct udev_device *dev, int
argc, char *argv[], boo
get_cap_mask(dev, pdev, capabilities/abs, bitmask_abs,
sizeof(bitmask_abs), test);
get_cap_mask(dev, pdev, capabilities/rel, bitmask_rel,
sizeof(bitmask_rel), test);
get_cap_mask(dev, pdev, capabilities/key, bitmask_key,
sizeof(bitmask_key), test);
-test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key,
bitmask_rel, test);
+prop_str = udev_device_get_property_value(pdev, PROP);
+if (prop_str)
+ prop = strtoul(prop_str, NULL, 16);
+test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key,
bitmask_rel, prop, test);
test_key(dev, bitmask_ev, bitmask_key, test);
}
--
2.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OnCalendar every X minutes
On Mon, 30.03.15 01:12, Mirco Tischler (mt...@gmx.de) wrote: However there's one difference between these relative triggers and OnCalendar: you can only use Persistent= in combination with OnCalendar. This means that if your timer elapses in 5 minutes and you suspend your machine for an hour or so, after resume it still elapses in 5 minutes. To clarify: Persietent= only matters for full system reboots, it has no effect on suspend/resume cycles. What you are asking for are basically .timer triggers for CLOCK_BOOTTIME rather than CLOCK_MONOTONIC. This is something we could certainly support, hence I added this to th TODO list now. Traditionally CLOCK_BOOTTIME didn't support timerfd(), but that limitation has been lifted on newer kernerls AFAIR, hence we could add this relatively easily. 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] Synchronization Between Services at Shutdown
On Wed, 01.04.15 18:22, Kurt von Laven (k...@endlessm.com) wrote: Hello folks, I am trying to ensure that my system DBus service has time to handle a DBus method call before it shuts down. My DBus service is implemented as a system systemd service; let's call it service A. It runs a single-threaded, synchronous event loop that listens for DBus method calls and handles them appropriately. This event loop also listens for SIGTERM. When SIGTERM is received, service A currently terminates the event loop, performs any necessary writes to disk, and releases its resources. I am assuming that when the system is shut down cleanly, systemd initially sends SIGTERM to systemd services and only sends SIGKILL to abort it abruptly if it takes too long to shut down when asked nicely. I have another system systemd service, call it service B, that runs an event loop listening for SIGTERM. When service B receives a SIGTERM, it makes the aforementioned DBus method call and then flushes the system bus. Service B specifies Requires= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=Service A and After= http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=Service A. Service A makes no mention of service B in its unit configuration file. Does systemd make any sort of guarantee that service A will get a chance to handle the DBus method call before receiving SIGTERM, or does my code as written have a race condition? The general rule in systemd is that the shutdown order is the reverse startup order. If you declare After=foo.service in a service bar.service, then this will hence have two effects: 1) when both are started foo.service is started before bar.service. And 2) when both are stopped bar.service is stopped before foo.service. If you want to ensure that bus communication still works in your shutdown code, you hence need to make sure you place After=dbus.service in your services, so that you are shut down before dbus is. 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] [PATCH v2] Add reboot to EFI support
On Thu, 26.03.15 16:09, Jan Janssen (medhe...@web.de) wrote: Heya, Hmm, so we already support passing special reboot() parameters, and this is done by manipulating a file in /run, without introducing any new targets. To me it appears that boot-into-firmware-setup is something hat should be handled the same way, i.e. as a special parameter for the *normal* poweroff path, instead of introducing a new poweroff path for it. Of course, instead of manipulating /run for this we should directly manipulate the respective EFI variable. I hence think this should be a new switch --firmware-setup or so to systemctl. Of course, that sounds awfully specific and I don't really like too much adding a new switch just for this flag, but it's the least best option I see. The existing boot argument is passed as-is to the kernel, hence giving the argument efi a special meaning would mean once couldn't pass that parameter anymore to the kernel. I would strongly prefer naming the switch something like firmware instead of EFI, since we shouldn't encode the technology here, but the generic term. Also, this should mention that this is about the setup tool of the firmware, since EFI is available all the time, and this is really about the *setup* tool of the firmware... I think ultimately we need to expose this even in GNOME, similar to the way Window exposes this. To cover that we should probably add a bus API to logind in some form to manipulate the EFI var in question, and systemctl reboot --firmware-setup would use that. (And yes, a similar bus API for specifying the generic reboot parameter probably should exist alongside it). Of course the bus API should also support a CanFirmwareSetup() call or so, that reports whether the logic is available at all. Does this make sense? 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] Analyzing and debugging userspace services (with e. g. Valgrind)
On Thu, 02.04.15 11:27, Paul Menzel (paulepan...@users.sourceforge.net) wrote: 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? Yeah, I think this is the best way to go. Use systemctl edit --full foobar.service and prefix it's ExecStart= parameter with an invocation of valgrind. 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] [PATCH] tmpfiles: don't create subvolumes in chroot
Lennart Poettering lenn...@poettering.net writes: On Thu, 02.04.15 08:59, Jan Synacek (jsyna...@redhat.com) wrote: think that systemd shouldn't create them where it doesn't make sense. I don't think that that's achievable with the current logic. Am I missing something? But why do you say when it doesn't make sense? Why do you think this doesn't make sense... I think that in mock root it doesn't. But that's a special case. Why not? Subvolumes are fully recursive, hence it doesn't really matter whether they are created on the host or in a chroot environment or a container or whatever else. Ok, I discussed this with the maintainer of mock and wrote a patch for it to be able to deal with subvolumes. Thanks for the pointers! -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting a unit on resume from suspend/hibernate
On Thu, 2 Apr 2015, Lennart Poettering wrote: On Thu, 02.04.15 18:43, Dimitrios Apostolou (ji...@gmx.net) wrote: Hello list, I'm having trouble to auto-activate a unit on resume, after suspend-to-ram or hibernation. The unit properly stops when suspending (because of Conflicts=sleep.target), but does not restart after resuming. We do not really support that right now. Suspend/hibernate is implemented as a single transaction, and you cannot stop a unit and start it in the same transaction. Thanks, this is a nice explanation, I wish this was documented because there are various hackish ways all over the internet, that might or might not work after much fiddling around. A hackish way to implement this is by using the suspend callout dir /usr/lib/systemd/system-sleep/ (see systemd-suspend.service(8) for details), and enqueue a stop and a start job from there, depending on whether the hook is called before or after the suspend/hibernation. But yeah, this is hackish. So I wanted to avoid that because of dependencies - I need the units to be stopped in proper order, so I thought that these dependencies are better be expressed in the unit file. But I guess it's OK to do systemctl start/stop in the system-sleep scripts, so that will work for me. Usually if one wants to do that one is just working around some problems that are better solved in a different way. Why precisely do you need this feature? I need to properly terminate system accounting, in the same way that it happens when shutting down, so that a relevant record is written. Same when resuming, I need it to be identical to booting the system. Thanks, Dimitris 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] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs
hi, sorry for the delay.
from
http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html:
By default, it will wait for all links it is aware of and which are
managed by systemd-networkd.service(8) to be fully configured or
failed, *and for at least one link to gain a carrier.*.
the import part here is the end of the sentence. without this patch,
systemd-networkd-wait-online will block until all configured
interfaces have carrier.. you can reproduce this by running
systemd-networkd in qemu with two ethernet interfaces, and issue 'info
network' and then 'set_link if down' to simulate no carrier. then
you can run systemd-networkd-wait-online, and observe that it will
block until both interfaces are up, not just one.
nick
On Wed, Mar 25, 2015 at 10:53 PM, Andrei Borzenkov arvidj...@gmail.com wrote:
On Wed, Mar 25, 2015 at 11:49 PM, misch...@offblast.org wrote:
From: mischief misch...@offblast.org
when checking interface status, systemd-networkd-wait-online
will continue to wait if any interface is still configuring or
being processed by udev. this patch allows it to return if any
one interface is degraded/routable, as per the manual.
But current behavior is exactly what manual says: By default, it will
wait for all links it is aware of and which are managed by
systemd-networkd.service(8) to be fully configured or failed. Or do I
miss something?
---
src/network/networkd-wait-online-manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/network/networkd-wait-online-manager.c
b/src/network/networkd-wait-online-manager.c
index 1c997a5..1ac162a 100644
--- a/src/network/networkd-wait-online-manager.c
+++ b/src/network/networkd-wait-online-manager.c
@@ -74,13 +74,13 @@ bool manager_all_configured(Manager *m) {
if (!l-state) {
log_debug(link %s has not yet been processed by
udev,
l-ifname);
-return false;
+continue;
}
if (streq(l-state, configuring)) {
log_debug(link %s is being processed by networkd,
l-ifname);
-return false;
+continue;
}
if (l-operational_state
--
2.0.5
___
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] [PATCH] networkd: fix systemd-networkd-wait-online with multiple NICs
On Thu, Apr 2, 2015 at 3:08 PM, Nick Owens misch...@offblast.org wrote: hi, sorry for the delay. from http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html: By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, *and for at least one link to gain a carrier.*. the import part here is the end of the sentence. without this patch, systemd-networkd-wait-online will block until all configured interfaces have carrier.. you can reproduce this by running systemd-networkd in qemu with two ethernet interfaces, and issue 'info network' and then 'set_link if down' to simulate no carrier. then you can run systemd-networkd-wait-online, and observe that it will block until both interfaces are up, not just one. nick On Wed, Mar 25, 2015 at 10:53 PM, Andrei Borzenkov arvidj...@gmail.com wrote: On Wed, Mar 25, 2015 at 11:49 PM, misch...@offblast.org wrote: From: mischief misch...@offblast.org when checking interface status, systemd-networkd-wait-online will continue to wait if any interface is still configuring or being processed by udev. this patch allows it to return if any one interface is degraded/routable, as per the manual. But current behavior is exactly what manual says: By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed. Or do I miss something? It is worth noting that there may be some issues with tracking interface states in networkd, there appear to be ways to get an interface stuck in a 'configuring' state despite the fact that the interface has no network config and/or has no carrier. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Timers and Service Conditions
Hi, I have a problem with a timer that trigges a service that has a condition set. The timer defines the following properties: [Timer] OnBootSec=1h OnUnitInactiveSec=1h Unit=autobackup@%i.service The service unit set the following condition: ConditionACPower=true When I'm now on AC power the service is never active and, therefor, the inactive timestamp is never set. This causes the timer to be triggered repeatedly which causes a very high system load. I want to keep the timer relative to bootup. So, can I avoid OnCalendar= ? Thanks Merten ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] automount: add expire support
On Thu, 02.04.15 13:55, Mantas Mikulėnas (graw...@gmail.com) wrote: Isn't log_warning_errno(errno, %m) identical to just log_warning(%m)? it's not. the former generates an ERRNO= structured journal field, the latter doesn't. Also see my reply to Tom's review about this. 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] [PATCH 1/5] udev-builtin-input_id: identify trackpoints and accelerometers
On Thu, 02.04.15 11:48, Hans de Goede (hdego...@redhat.com) wrote:
The kernel has been setting the INPUT_PROP_POINTING_STICK property bit
on trackpoints for a while now, and this is useful information to have
in various places, so make input_id aware of this and make it set
ID_INPUT_POINTING_STICK on trackpoints.
While adding support for querying properties, also add support for the
recently added INPUT_PROP_ACCELEROMETER property bit.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/udev/udev-builtin-input_id.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c
b/src/udev/udev-builtin-input_id.c
index 46f1c53..5b1790c 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -33,6 +33,14 @@
#include udev.h
#include util.h
+#ifndef INPUT_PROP_POINTING_STICK
+#define INPUT_PROP_POINTING_STICK 0x05
+#endif
+
+#ifndef INPUT_PROP_ACCELEROMETER
+#define INPUT_PROP_ACCELEROMETER0x06
+#endif
Are these definitions normally defined in input.h? If so, please add
them to missing.h, where we try to centralize definitions of this kind.
/* we must use this kernel-compatible implementation */
#define BITS_PER_LONG (sizeof(unsigned long) * 8)
#define NBITS(x) x)-1)/BITS_PER_LONG)+1)
@@ -131,6 +139,7 @@ static void test_pointers (struct udev_device *dev,
const unsigned long* bitmask_abs,
const unsigned long* bitmask_key,
const unsigned long* bitmask_rel,
+ unsigned long prop,
unsigned long? Is this really necessary? Shouldn't we just use
uint64_t? here?
bool test) {
int is_mouse = 0;
int is_touchpad = 0;
@@ -182,6 +191,10 @@ static void test_pointers (struct udev_device *dev,
udev_builtin_add_property(dev, test, ID_INPUT_MOUSE, 1);
if (is_touchpad)
udev_builtin_add_property(dev, test, ID_INPUT_TOUCHPAD,
1);
+if (prop (1 INPUT_PROP_POINTING_STICK))
+udev_builtin_add_property(dev, test, ID_INPUT_TRACKPOINT,
1);
+if (prop (1 INPUT_PROP_ACCELEROMETER))
+udev_builtin_add_property(dev, test,
ID_INPUT_ACCELEROMETER, 1);
}
/* key like devices */
@@ -232,7 +245,8 @@ static int builtin_input_id(struct udev_device *dev, int
argc, char *argv[], boo
unsigned long bitmask_abs[NBITS(ABS_MAX)];
unsigned long bitmask_key[NBITS(KEY_MAX)];
unsigned long bitmask_rel[NBITS(REL_MAX)];
-const char *sysname, *devnode;
+unsigned long prop = 0;
+const char *sysname, *devnode, *prop_str;
/* walk up the parental chain until we find the real input device;
the
* argument is very likely a subdevice of this, like eventN */
@@ -248,7 +262,10 @@ static int builtin_input_id(struct udev_device *dev, int
argc, char *argv[], boo
get_cap_mask(dev, pdev, capabilities/abs, bitmask_abs,
sizeof(bitmask_abs), test);
get_cap_mask(dev, pdev, capabilities/rel, bitmask_rel,
sizeof(bitmask_rel), test);
get_cap_mask(dev, pdev, capabilities/key, bitmask_key,
sizeof(bitmask_key), test);
-test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key,
bitmask_rel, test);
+prop_str = udev_device_get_property_value(pdev, PROP);
+if (prop_str)
+ prop = strtoul(prop_str, NULL, 16);
Hmm, we try to avoid direct invocations of strtoul() and friends, due
to the annoying error handling... Can't we use safe_atou64() here, or so?
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] [PATCH 1/5] udev-builtin-input_id: identify trackpoints and accelerometers
Hi,
On 02-04-15 12:21, Lennart Poettering wrote:
On Thu, 02.04.15 11:48, Hans de Goede (hdego...@redhat.com) wrote:
The kernel has been setting the INPUT_PROP_POINTING_STICK property bit
on trackpoints for a while now, and this is useful information to have
in various places, so make input_id aware of this and make it set
ID_INPUT_POINTING_STICK on trackpoints.
While adding support for querying properties, also add support for the
recently added INPUT_PROP_ACCELEROMETER property bit.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/udev/udev-builtin-input_id.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c
index 46f1c53..5b1790c 100644
--- a/src/udev/udev-builtin-input_id.c
+++ b/src/udev/udev-builtin-input_id.c
@@ -33,6 +33,14 @@
#include udev.h
#include util.h
+#ifndef INPUT_PROP_POINTING_STICK
+#define INPUT_PROP_POINTING_STICK 0x05
+#endif
+
+#ifndef INPUT_PROP_ACCELEROMETER
+#define INPUT_PROP_ACCELEROMETER0x06
+#endif
Are these definitions normally defined in input.h?
Yes.
If so, please add them to missing.h, where we try to centralize definitions of
this kind.
Ok, will fix for v2.
/* we must use this kernel-compatible implementation */
#define BITS_PER_LONG (sizeof(unsigned long) * 8)
#define NBITS(x) x)-1)/BITS_PER_LONG)+1)
@@ -131,6 +139,7 @@ static void test_pointers (struct udev_device *dev,
const unsigned long* bitmask_abs,
const unsigned long* bitmask_key,
const unsigned long* bitmask_rel,
+ unsigned long prop,
unsigned long? Is this really necessary? Shouldn't we just use
uint64_t? here?
unsigned long matches what is used in the kernel, it is a bit field,
I do not know what type is preferred for bit fields in systemd / udev.
bool test) {
int is_mouse = 0;
int is_touchpad = 0;
@@ -182,6 +191,10 @@ static void test_pointers (struct udev_device *dev,
udev_builtin_add_property(dev, test, ID_INPUT_MOUSE, 1);
if (is_touchpad)
udev_builtin_add_property(dev, test, ID_INPUT_TOUCHPAD,
1);
+if (prop (1 INPUT_PROP_POINTING_STICK))
+udev_builtin_add_property(dev, test, ID_INPUT_TRACKPOINT,
1);
+if (prop (1 INPUT_PROP_ACCELEROMETER))
+udev_builtin_add_property(dev, test, ID_INPUT_ACCELEROMETER,
1);
}
/* key like devices */
@@ -232,7 +245,8 @@ static int builtin_input_id(struct udev_device *dev, int
argc, char *argv[], boo
unsigned long bitmask_abs[NBITS(ABS_MAX)];
unsigned long bitmask_key[NBITS(KEY_MAX)];
unsigned long bitmask_rel[NBITS(REL_MAX)];
-const char *sysname, *devnode;
+unsigned long prop = 0;
+const char *sysname, *devnode, *prop_str;
/* walk up the parental chain until we find the real input device; the
* argument is very likely a subdevice of this, like eventN */
@@ -248,7 +262,10 @@ static int builtin_input_id(struct udev_device *dev, int
argc, char *argv[], boo
get_cap_mask(dev, pdev, capabilities/abs, bitmask_abs,
sizeof(bitmask_abs), test);
get_cap_mask(dev, pdev, capabilities/rel, bitmask_rel,
sizeof(bitmask_rel), test);
get_cap_mask(dev, pdev, capabilities/key, bitmask_key,
sizeof(bitmask_key), test);
-test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key,
bitmask_rel, test);
+prop_str = udev_device_get_property_value(pdev, PROP);
+if (prop_str)
+ prop = strtoul(prop_str, NULL, 16);
Hmm, we try to avoid direct invocations of strtoul() and friends, due
to the annoying error handling... Can't we use safe_atou64() here, or so?
If that can handle hex without a 0x prefix then yes.
Regards,
Hans
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] automount: add expire support
On Thu, Apr 2, 2015 at 1:54 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Sun, 22.03.15 13:36, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
Love this work!
init_autofs_dev_ioctl(param);
param.ioctlfd = ioctl_fd;
-param.timeout.timeout = sec;
+
+/* Convert to seconds, rounding up. */
+param.timeout.timeout = usec / USEC_PER_SEC + (usec %
USEC_PER_SEC 0);
Please use (usec + USEC_PER_SEC - 1) / USEC_PER_SEC.
+int automount_update_mount(Automount *a, MountState old_state,
MountState state)
+{
Please add opening bracket to the function declaration line before, like
for all other
constructs. We differ from kernel coding style in this regard.
@@ -535,6 +585,100 @@ fail:
automount_enter_dead(a, AUTOMOUNT_FAILURE_RESOURCES);
}
+static int automount_start_expire(Automount *a);
+
+struct expire_data {
+int dev_autofs_fd;
+int ioctl_fd;
+};
+
+static inline void cleanup_expire(void *p) {
+struct expire_data *data = *(struct expire_data**)p;
+
+if (!data)
+return;
+
+safe_close(data-dev_autofs_fd);
+safe_close(data-ioctl_fd);
+free(data);
+}
+#define _cleanup_expire_ _cleanup_(cleanup_expire)
No need to define this. We only define this for commonly used
structs. Simply use _cleanup_() directly...
+
+static void *expire_thread(void *p) {
+struct autofs_dev_ioctl param;
+_cleanup_expire_ struct expire_data *data = (struct
expire_data*)p;
+int r;
+
+assert(data-dev_autofs_fd = 0);
+assert(data-ioctl_fd = 0);
+
+init_autofs_dev_ioctl(param);
+param.ioctlfd = data-ioctl_fd;
+
+do {
+r = ioctl(data-dev_autofs_fd, AUTOFS_DEV_IOCTL_EXPIRE,
param);
+} while (r == 0);
+
+if (errno != EAGAIN)
+log_error_errno(errno, failed to expire automount:
%m);
Please uppercase the first word of the message.
Also, given that we don't actually do anything about the failure, i
think we should downgrade this to a warning, and clarify that we
ignore this, by suffixing the message with , ignoring or so... Like so:
log_warning_errno(errno, Failed to expire automount, ignoring:
%m);
Isn't log_warning_errno(errno, %m) identical to just log_warning(%m)?
--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
On Thu, 02.04.15 13:00, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 11:06 GMT+02:00 Lennart Poettering lenn...@poettering.net: If you want to ensure that bus communication still works in your shutdown code, you hence need to make sure you place After=dbus.service in your services, so that you are shut down before dbus is. Type=dbus service currently only get a dependency on dbus.socket (via After=basic.target). Yeah, and rightfully so. I mean, a service really should be able to shutdown if dbus is dead. In fact, it should be able to shutdown in pretty much any situation... 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] Synchronization Between Services at Shutdown
2015-04-02 13:03 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Thu, 02.04.15 13:00, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 11:06 GMT+02:00 Lennart Poettering lenn...@poettering.net: If you want to ensure that bus communication still works in your shutdown code, you hence need to make sure you place After=dbus.service in your services, so that you are shut down before dbus is. Type=dbus service currently only get a dependency on dbus.socket (via After=basic.target). Yeah, and rightfully so. I mean, a service really should be able to shutdown if dbus is dead. In fact, it should be able to shutdown in pretty much any situation... Apparently they don't. There were all sorts of failures caused by dbus being shut down too early. https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612 is one of the related bug reports afair. Since Martin has been working on this, I'll let him comment on this. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/02/2015 08:31 AM, Lennart Poettering wrote: On Wed, 01.04.15 21:04, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/01/2015 02:37 PM, Lennart Poettering wrote: Note that I intend to add more subvolume lines to tmpfiles even. For example, I am pretty sure /home should be created as subvolume if it doesn't exist already, and similar. I'm afraid that will still only work on a single host setup ( laptop/desktop ) and I'm pretty sure if the intent from you is to default to more subvolume creation i'm afraid you will start conflicting with installers on top of everything else as well. Why would this conflict with installers? Beside the obvious point that you on your own accord have started to decide *for* the end user what his intend are based on your own assumption ( which is something the end user decided at install time or later on if he administrates said host ) after install time, last time I checked installers ( as many other tools ) had a hard time themselves dealing properly with subvolumes and support btrfs properly. You thought that /var/lib/machines being a subvolume was the right thing to do and you were wrong, it only works for you on your own host but never in practice for administrators whom are the target audience for that feature. You think that /home should be created as subvolume by default, again wrong not only for the end user who will be scratching their heads wondering where their space went but also for administrators whom have this stored on NAS/SAN with their own specific btrfs policy build on top of storage pools ( if they are using btrfs ) As I said before subvolumes should not be created et all by default just directories which is the sane default from upstream until btrfs has become widespread enough and tools, application and end users have gotten used to it. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedatectl: fix when queried system has differn't timezone
On Mon, 23.03.15 04:44, Shawn Landden (sh...@churchofgit.com) wrote:
Also allow getting time from time(2) when BUS_TRANSPORT_MACHINE.
v2: check for error
---
src/timedate/timedatectl.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9e04f8f..44d329e 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -106,14 +106,21 @@ static void print_status_info(const StatusInfo *i) {
/* Enforce the values of /etc/localtime */
if (getenv(TZ)) {
-fprintf(stderr, Warning: Ignoring the TZ variable. Reading
the system's time zone setting only.\n\n);
+fprintf(stderr, Warning: Ignoring the TZ variable.\n\n);
unsetenv(TZ);
}
+r = setenv(TZ, i-timezone, false);
+if (r 0) {
+log_error_errno(errno, Failed to set TZ environment
variable: %m);
+exit(EXIT_FAILURE);
No! Please never use exit() as a replacement for proper error
handling. In fact, exit() is never OK in our sources really. I have
added a section to CODING_STYLE now to explain this.
+}
+tzset();
+
if (i-time != 0) {
sec = (time_t) (i-time / USEC_PER_SEC);
have_time = true;
-} else if (arg_transport == BUS_TRANSPORT_LOCAL) {
+} else if (IN_SET(arg_transport, BUS_TRANSPORT_REMOTE,
BUS_TRANSPORT_MACHINE)) {
THis makes no sense, the check is reversed, no? Why change this at
all?
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] [PATCH] automount: add expire support
On Sun, 22.03.15 13:36, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
Love this work!
init_autofs_dev_ioctl(param);
param.ioctlfd = ioctl_fd;
-param.timeout.timeout = sec;
+
+/* Convert to seconds, rounding up. */
+param.timeout.timeout = usec / USEC_PER_SEC + (usec % USEC_PER_SEC
0);
Please use (usec + USEC_PER_SEC - 1) / USEC_PER_SEC.
+int automount_update_mount(Automount *a, MountState old_state, MountState
state)
+{
Please add opening bracket to the function declaration line before, like for
all other
constructs. We differ from kernel coding style in this regard.
@@ -535,6 +585,100 @@ fail:
automount_enter_dead(a, AUTOMOUNT_FAILURE_RESOURCES);
}
+static int automount_start_expire(Automount *a);
+
+struct expire_data {
+int dev_autofs_fd;
+int ioctl_fd;
+};
+
+static inline void cleanup_expire(void *p) {
+struct expire_data *data = *(struct expire_data**)p;
+
+if (!data)
+return;
+
+safe_close(data-dev_autofs_fd);
+safe_close(data-ioctl_fd);
+free(data);
+}
+#define _cleanup_expire_ _cleanup_(cleanup_expire)
No need to define this. We only define this for commonly used
structs. Simply use _cleanup_() directly...
+
+static void *expire_thread(void *p) {
+struct autofs_dev_ioctl param;
+_cleanup_expire_ struct expire_data *data = (struct expire_data*)p;
+int r;
+
+assert(data-dev_autofs_fd = 0);
+assert(data-ioctl_fd = 0);
+
+init_autofs_dev_ioctl(param);
+param.ioctlfd = data-ioctl_fd;
+
+do {
+r = ioctl(data-dev_autofs_fd, AUTOFS_DEV_IOCTL_EXPIRE,
param);
+} while (r == 0);
+
+if (errno != EAGAIN)
+log_error_errno(errno, failed to expire automount:
%m);
Please uppercase the first word of the message.
Also, given that we don't actually do anything about the failure, i
think we should downgrade this to a warning, and clarify that we
ignore this, by suffixing the message with , ignoring or so... Like so:
log_warning_errno(errno, Failed to expire automount, ignoring: %m);
+
+return NULL;
+}
+
+static int automount_dispatch_expire(sd_event_source *source, usec_t usec,
void *userdata) {
+Automount *a = AUTOMOUNT(userdata);
+_cleanup_expire_ struct expire_data *data = NULL;
+int r;
+
+assert(a);
+assert(source == a-expire_event_source);
+
+data = malloc0(sizeof(struct expire_data));
Please use new0(struct expire data, 1) for this.
+if (!data)
+return -ENOMEM;
+
+data-ioctl_fd = -1;
+
+data-dev_autofs_fd = dup(UNIT(a)-manager-dev_autofs_fd);
In general I think we should avoid dup(), and also dup2(), and use
fcntl(fd, F_DUPFD_CLOEXEC, 3) instead. First, you want the O_CLOEXEC for
this. Secondly, it's good to avoid the risk the dupped fd becomes 0,
1, 2 in the unlikely case they are closed...
I also updated CODING_STYLE now to clarify this.
+if (data-dev_autofs_fd 0)
+return data-dev_autofs_fd;
You probably want to return -errno here?
+
+if (a-expire_event_source) {
+r = sd_event_source_set_time(a-expire_event_source,
now(CLOCK_MONOTONIC) + 5 * USEC_PER_SEC);
+if (r 0)
+return r;
+
+return sd_event_source_set_enabled(a-expire_event_source,
SD_EVENT_ONESHOT);
+}
+
+return sd_event_add_time(
+UNIT(a)-manager-event,
+a-expire_event_source,
+CLOCK_MONOTONIC,
+now(CLOCK_MONOTONIC) + 5 * USEC_PER_SEC, 0,
+automount_dispatch_expire, a);
+}
Maybe the 5 * USEC_PER_SEC should become a #define somewhere at the
top of the file? Given that this is used more than once it might be
advisable to use the same definition.
+case autofs_ptype_expire_direct:
+log_unit_debug(UNIT(a)-id, Got direct umount request on
%s, a-where);
+
+sd_event_source_set_enabled(a-expire_event_source,
SD_EVENT_OFF);
Maybe cast the result to (void) explicitly, to clarify that we
knowingly ignore the return value.
+
+r = set_ensure_allocated(a-expire_tokens, NULL);
+if (r 0) {
+log_unit_error(UNIT(a)-id, Failed to
allocate token set.);
Sounds like a job for log_oom().
+goto fail;
+}
+
+r = set_put(a-expire_tokens,
UINT_TO_PTR(packet.v5_packet.wait_queue_token));
+if (r 0) {
+log_unit_error_errno(UNIT(a)-id, r, Failed to
remember token: %m);
+goto fail;
+}
+r =
Re: [systemd-devel] Synchronization Between Services at Shutdown
2015-04-02 11:06 GMT+02:00 Lennart Poettering lenn...@poettering.net: If you want to ensure that bus communication still works in your shutdown code, you hence need to make sure you place After=dbus.service in your services, so that you are shut down before dbus is. Type=dbus service currently only get a dependency on dbus.socket (via After=basic.target). Incidentally, pitti had to deal with bug reports the last couple of days, where dbus.service was stopped too early during shutdown, so e.g. wpa_supplicant.service and other D-Bus using services failed to stop properly on shutdown. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/5] udev: Update trackpoint rules to allow setting ibm trackpoint sensitivity
On Thu, 02.04.15 11:48, Hans de Goede (hdego...@redhat.com) wrote:
+# Same as below but also sets the TPPS/2 IBM TrackPoint driver sensitivity
+KERNELS==input*, ATTR{device/name}==TPPS/2 IBM TrackPoint, \
+ IMPORT{builtin}=hwdb
'trackpoint:name:$attr{device/name}:$attr{[dmi/id]modalias}', \
+ RUN=/bin/sh -c 'echo -n $env{TRACKPOINT_SENSITIVTY}
/sys$env{DEVPATH}/../../../sensitivity', \
+ GOTO=trackpoint_end
Invoking a shell for writing an attribute is certainly not OK. In
particular since ATTR{} can be used to write attributes.
Also, did you test this? THere's a pretty obvious typo in
TRACKPOINT_SENSITIVTY...
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] [PATCH 3/5] udev: Update trackpoint rules to allow setting ibm trackpoint sensitivity
Hi,
On 02-04-15 12:23, Lennart Poettering wrote:
On Thu, 02.04.15 11:48, Hans de Goede (hdego...@redhat.com) wrote:
+# Same as below but also sets the TPPS/2 IBM TrackPoint driver sensitivity
+KERNELS==input*, ATTR{device/name}==TPPS/2 IBM TrackPoint, \
+ IMPORT{builtin}=hwdb
'trackpoint:name:$attr{device/name}:$attr{[dmi/id]modalias}', \
+ RUN=/bin/sh -c 'echo -n $env{TRACKPOINT_SENSITIVTY}
/sys$env{DEVPATH}/../../../sensitivity', \
+ GOTO=trackpoint_end
Invoking a shell for writing an attribute is certainly not OK. In
particular since ATTR{} can be used to write attributes.
Ok, are there any examples / docs for this ?
Also, did you test this? THere's a pretty obvious typo in
TRACKPOINT_SENSITIVTY...
Yes I tested this, I've copy and pasted the typo to various places so it all
matches
up and thus works ... I'll fix both for v2 of this set.
Regards,
Hans
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/5] udev-builtin-input_id: identify trackpoints and accelerometers
Hi, On 02-04-15 12:27, Lennart Poettering wrote: On Thu, 02.04.15 12:21, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 02.04.15 11:48, Hans de Goede (hdego...@redhat.com) wrote: The kernel has been setting the INPUT_PROP_POINTING_STICK property bit on trackpoints for a while now, and this is useful information to have in various places, so make input_id aware of this and make it set ID_INPUT_POINTING_STICK on trackpoints. While adding support for querying properties, also add support for the recently added INPUT_PROP_ACCELEROMETER property bit. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/udev/udev-builtin-input_id.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c index 46f1c53..5b1790c 100644 --- a/src/udev/udev-builtin-input_id.c +++ b/src/udev/udev-builtin-input_id.c @@ -33,6 +33,14 @@ #include udev.h #include util.h +#ifndef INPUT_PROP_POINTING_STICK +#define INPUT_PROP_POINTING_STICK 0x05 +#endif + +#ifndef INPUT_PROP_ACCELEROMETER +#define INPUT_PROP_ACCELEROMETER0x06 +#endif Are these definitions normally defined in input.h? If so, please add them to missing.h, where we try to centralize definitions of this kind. Also, INPUT_PROP_POINTING_STICK is already introduced by Peter Hutterer's most recent patch. He adds it to missing.h, can you sync the two patche sets up, please? Sure I'll base my set on top of Peters for V2. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] automount: add expire support
On Fri, 27.03.15 12:36, Tom Gundersen (t...@jklm.no) wrote: +if (errno != EAGAIN) +log_error_errno(errno, failed to expire automount: %m); No need for this, it is equivalent to log_error(failed to exprie automount: %m); Not true really. log_error_errno() also adds ERRNO= structured fields to the log message, the simply log_error() does not. Hence, if your are logging about some system error indicated in an Exyz error code, please use log_error_errno(), regardless if you got the errror via errno or via the return value of a function... 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] [PATCH 1/5] udev-builtin-input_id: identify trackpoints and accelerometers
On Thu, 02.04.15 12:21, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 02.04.15 11:48, Hans de Goede (hdego...@redhat.com) wrote: The kernel has been setting the INPUT_PROP_POINTING_STICK property bit on trackpoints for a while now, and this is useful information to have in various places, so make input_id aware of this and make it set ID_INPUT_POINTING_STICK on trackpoints. While adding support for querying properties, also add support for the recently added INPUT_PROP_ACCELEROMETER property bit. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/udev/udev-builtin-input_id.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/src/udev/udev-builtin-input_id.c b/src/udev/udev-builtin-input_id.c index 46f1c53..5b1790c 100644 --- a/src/udev/udev-builtin-input_id.c +++ b/src/udev/udev-builtin-input_id.c @@ -33,6 +33,14 @@ #include udev.h #include util.h +#ifndef INPUT_PROP_POINTING_STICK +#define INPUT_PROP_POINTING_STICK 0x05 +#endif + +#ifndef INPUT_PROP_ACCELEROMETER +#define INPUT_PROP_ACCELEROMETER0x06 +#endif Are these definitions normally defined in input.h? If so, please add them to missing.h, where we try to centralize definitions of this kind. Also, INPUT_PROP_POINTING_STICK is already introduced by Peter Hutterer's most recent patch. He adds it to missing.h, can you sync the two patche sets up, please? 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] [PATCH 3/5] udev: Update trackpoint rules to allow setting ibm trackpoint sensitivity
On Thu, 02.04.15 12:42, Hans de Goede (hdego...@redhat.com) wrote:
Hi,
On 02-04-15 12:23, Lennart Poettering wrote:
On Thu, 02.04.15 11:48, Hans de Goede (hdego...@redhat.com) wrote:
+# Same as below but also sets the TPPS/2 IBM TrackPoint driver sensitivity
+KERNELS==input*, ATTR{device/name}==TPPS/2 IBM TrackPoint, \
+ IMPORT{builtin}=hwdb
'trackpoint:name:$attr{device/name}:$attr{[dmi/id]modalias}', \
+ RUN=/bin/sh -c 'echo -n $env{TRACKPOINT_SENSITIVTY}
/sys$env{DEVPATH}/../../../sensitivity', \
+ GOTO=trackpoint_end
Invoking a shell for writing an attribute is certainly not OK. In
particular since ATTR{} can be used to write attributes.
Ok, are there any examples / docs for this ?
See rules/ in the source tree. Grep for ATTR{ and look for the uses
with = (in contrast to ==). THose are attribute assignments. (And
the ones with == are attribute comparisons...)
It's tersely documented in udev's man page.
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] Masked services start dependencies in any case
On Thursday 2015-04-02 10:35, Lennart Poettering wrote: On Mon, 30.03.15 01:46, Jan Engelhardt (jeng...@inai.de) wrote: What does systemctl status and systemctl show say about the unit in question? (And what is klog.service? Sounds really obsolete...) The issue is not reproducible. Further investigation shows that I must have mixed up something at some point when switching between systems with different systemd versions. (In particular, systemctl status on 210 did not show masked state - fixed in 219.) ___ 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?
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] [PATCH 1/5] udev-builtin-input_id: identify trackpoints and accelerometers
On Thu, 02.04.15 12:39, Hans de Goede (hdego...@redhat.com) wrote: /* we must use this kernel-compatible implementation */ #define BITS_PER_LONG (sizeof(unsigned long) * 8) #define NBITS(x) x)-1)/BITS_PER_LONG)+1) @@ -131,6 +139,7 @@ static void test_pointers (struct udev_device *dev, const unsigned long* bitmask_abs, const unsigned long* bitmask_key, const unsigned long* bitmask_rel, + unsigned long prop, unsigned long? Is this really necessary? Shouldn't we just use uint64_t? here? unsigned long matches what is used in the kernel, it is a bit field, I do not know what type is preferred for bit fields in systemd / udev. Oh god, the kernel is stupid. Using variable size types for kernel/userspace APIs is just stupid... Anyway, if that's how it is, use unsigned long, and also use strtoul then, as before... 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] Synchronization Between Services at Shutdown
On Fri, Apr 3, 2015 at 6:55 AM, Kurt von Laven k...@endlessm.com wrote: On a separate note, how long does systemd wait after sending a SIGTERM to a service before sending it a SIGKILL? http://www.freedesktop.org/software/systemd/man/systemd.kill.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS
Hi!
On 25/03/15 14:36, Patrik Flykt wrote:
IFA_FLAGS is a discrete value and has no preprocessor #define defined for
it. Fix this by always using the value.
Seems that fix was not a real fix:
CC src/libsystemd/sd-id128/libsystemd_internal_la-sd-id128.lo
src/libsystemd/sd-rtnl/rtnl-types.c:361:10: error: ‘IFA_FLAGS’ undeclared here
(not in a function)
[IFA_FLAGS] = { .type = NLA_U32 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in initializer
not of integer type
[IFA_FLAGS] = { .type = NLA_U32 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: (near initialization for
‘rtnl_address_types’)
Makefile:15503: recipe for target
'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
make[3]: *** [src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo]
Error 1
---
src/libsystemd/sd-rtnl/rtnl-types.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
index bf7278f..5ae4790 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -358,9 +358,7 @@ static const NLType rtnl_address_types[IFA_MAX + 1] = {
[IFA_ANYCAST],
[IFA_MULTICAST],
*/
-#ifdef IFA_FLAGS
[IFA_FLAGS] = { .type = NLA_U32 },
-#endif
};
static const NLTypeSystem rtnl_address_type_system = {
Alex.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
Actually I think I just answered my own question and in the process realized that I didn't provide enough context in my original question. There is a race condition in my code because when service B receives SIGTERM, it calls g_dbus_connection_flush_sync https://developer.gnome.org/gio/stable/GDBusConnection.html#g-dbus-connection-flush-sync after a g_dbus_proxy_call https://developer.gnome.org/gio/stable/GDBusProxy.html#g-dbus-proxy-call to service A in an incorrect attempt to ensure that service A has handled the DBus proxy call. The problem with this is that g_dbus_connection_flush_sync ensures all outgoing messages are sent over the DBus connection but doesn't wait around for replies to those messages. Service B should instead call g_dbus_proxy_call_sync https://developer.gnome.org/gio/stable/GDBusProxy.html#g-dbus-proxy-call-sync and call neither g_dbus_connection_flush_sync nor g_dbus_proxy_call. Please correct me if I am missing something. On a separate note, how long does systemd wait after sending a SIGTERM to a service before sending it a SIGKILL? Is it reasonable to assume that a few g_dbus_proxy_call_sync calls would complete in that time if the slowest part of those calls is just the standard overhead of a DBus call? I ask because currently I acquire a shutdown inhibitor http://www.freedesktop.org/wiki/Software/systemd/inhibit/ in service B, and I now suspect this is unnecessary. Be well, Kurt On Thu, Apr 2, 2015 at 9:49 AM, Kurt von Laven k...@endlessm.com wrote: Both services A and B specify Requires=dbus.service and After=dbus.service. If I am interpreting everything that's being said correctly, there is a race condition in my code since service A's implementation doesn't require it to wait until it has processed the method call from service B before it stops listening for method calls. Does that sound right? On Thu, Apr 2, 2015 at 6:31 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.04.15 13:07, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 13:03 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Thu, 02.04.15 13:00, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 11:06 GMT+02:00 Lennart Poettering lenn...@poettering.net: If you want to ensure that bus communication still works in your shutdown code, you hence need to make sure you place After=dbus.service in your services, so that you are shut down before dbus is. Type=dbus service currently only get a dependency on dbus.socket (via After=basic.target). Yeah, and rightfully so. I mean, a service really should be able to shutdown if dbus is dead. In fact, it should be able to shutdown in pretty much any situation... Apparently they don't. There were all sorts of failures caused by dbus being shut down too early. https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612 is one of the related bug reports afair. Hmm? I really don't see how the NFS vs wpa_supplicant issue has anything to do with dbus? NFS doesn't care about dbus at all... You need to order wpa_supplicant and NM Before=remote-fs-pre.target and pull it it via Wants=remote-fs-pre.target. With that in place during shutdown the mounts will be unmounted first, and NM/wpa only shut down after that. See systemd.special(7) for details. I really don't see what dbus has to do with all this... Lennart -- Lennart Poettering, Red Hat -- Kurt von Laven | Endless Mobile | EndlessM.com http://endlessm.com/ -- Kurt von Laven | Endless Mobile | EndlessM.com http://endlessm.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and smartd daemon
Am 02.04.2015 um 20:49 schrieb Al Lau: As a test, the /usr/sbin/smartd $smartd_opts is invoked from the command line and the daemon is forked and stayed up as expected. By default, the /usr/sbin/smartd daemonize. # cat /etc/sysconfig/smartmontools smartd_opts=--interval=3600 --configfile=/etc/smartd.conf From the /var/log/messages, the SIGTERM signal is sent to the forked process. Like to know if this is something that can be worked around as already said: just use Type=simple [root@srv-rhsoft:~]$ systemctl status smartd.service ● smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/usr/lib/systemd/system/smartd.service; enabled) Active: active (running) since Fr 2015-03-27 10:14:58 CET; 6 days ago Main PID: 812 (smartd) CGroup: /system.slice/smartd.service └─812 /usr/sbin/smartd -n -q never Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon After=syslog.target [Service] EnvironmentFile=-/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd -n $smartd_opts ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog [Install] WantedBy=multi-user.target [root@srv-rhsoft:~]$ cat /etc/sysconfig/smartmontools # command line options for smartd smartd_opts=-q never # autogenerated config file options # smartd_conf_opts=-H -m root signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and smartd daemon
В Thu, 2 Apr 2015 11:28:46 -0700 Al Lau laua...@gmail.com пишет: The main process does not show up in the ps and only the forked process shows up. The systemd-cgls shows │ ├─session-14613.scope │ │ ├─ 1577 sshd: root@pts/4 │ │ ├─ 1676 -bash │ │ ├─16792 systemctl start smartd │ │ └─16793 /usr/bin/systemd-tty-ask-password-agent --watch └─system.slice ├─smartd.service │ └─16800 /usr/sbin/smartd --interval=3600 --configfile=/etc/smartd.conf I think the PIDFile is optional. Commenting out the PIDfile line does not help. It does. You need to run systemctl daemon-reload to refresh service definition. PID file is optional unless you say in unit definition that it is mandatory. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] journalctl: Improve boot ID lookup
This method should greatly improve offset based lookup. We now don't have
to aggregate the full boot listing just so we can jump to a specific position,
which can be a real pain on big journals just for a mere -b -1 case.
As an additional benefit --list-boots should improve slightly too, because
we now need to do less seeking.
Note that there can be a change in boot order with this lookup method
because it will use the order of boots in the journal, not the realtime stamp
stored in them. That's arguably better, though.
https://bugs.freedesktop.org/show_bug.cgi?id=72601
---
Hi,
today I realized that it would be nice if we could do without the cursor
seeking.
Turns out we can! I could swear that I tested sd_journal_flush_matches() would
reset our position in the journal. But it seems that sd_journal_next/previous
will advance just fine from the last position we were in, even after a flush.
Though, I would still like someone with better journal internals knowledge
confirm
that this is how it's supposed to work.
Some testing/timing from others than me would be nice too.
Jan
src/journal/journalctl.c | 270 +--
1 file changed, 169 insertions(+), 101 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index b4f88bc..08cd749 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -128,6 +128,7 @@ typedef struct boot_id_t {
sd_id128_t id;
uint64_t first;
uint64_t last;
+LIST_FIELDS(struct boot_id_t, boot_list);
} boot_id_t;
static void pager_open_if_enabled(void) {
@@ -851,111 +852,203 @@ static int add_matches(sd_journal *j, char **args) {
return 0;
}
-static int boot_id_cmp(const void *a, const void *b) {
-uint64_t _a, _b;
+static int discover_next_boot(sd_journal *j,
+ boot_id_t **boot,
+ bool advance_older,
+ bool read_realtime) {
+int r;
+char match[9+32+1] = _BOOT_ID=;
+_cleanup_free_ boot_id_t *next_boot = NULL;
-_a = ((const boot_id_t *)a)-first;
-_b = ((const boot_id_t *)b)-first;
+assert(j);
+assert(boot);
-return _a _b ? -1 : (_a _b ? 1 : 0);
-}
+/* We expect the journal to be on the last position of a boot
+ * (in relation to the direction we are going), so that the next
+ * invocation of sd_journal_next/previous will be from a different
+ * boot. We then collect any information we desire and then jump
+ * to the last location of the new boot by using a _BOOT_ID match
+ * coming from the other journal direction. */
-static int get_boots(sd_journal *j,
- boot_id_t **boots,
- unsigned int *count,
- boot_id_t *query_ref_boot) {
-int r;
-const void *data;
-size_t length, allocated = 0;
+/* Make sure we aren't restricted by any _BOOT_ID matches, so that
+ * we can actually advance to a *different* boot. */
+sd_journal_flush_matches(j);
-assert(j);
-assert(boots);
-assert(count);
+if (advance_older)
+r = sd_journal_previous(j);
+else
+r = sd_journal_next(j);
+if (r 0)
+return r;
+else if (r == 0)
+return 0; /* End of journal, yay. */
-r = sd_journal_query_unique(j, _BOOT_ID);
+next_boot = new0(boot_id_t, 1);
+if (!next_boot)
+return log_oom();
+
+r = sd_journal_get_monotonic_usec(j, NULL, next_boot-id);
if (r 0)
return r;
-*count = 0;
-SD_JOURNAL_FOREACH_UNIQUE(j, data, length) {
-boot_id_t *id;
+if (read_realtime) {
+r = sd_journal_get_realtime_usec(j, next_boot-first);
+if (r 0)
+return r;
+}
-assert(startswith(data, _BOOT_ID=));
+/* Now seek to the last occurrence of this boot ID. */
+sd_id128_to_string(next_boot-id, match + 9);
+r = sd_journal_add_match(j, match, sizeof(match) - 1);
+if (r 0)
+return r;
-if (!GREEDY_REALLOC(*boots, allocated, *count + 1))
-return log_oom();
+if (advance_older)
+r = sd_journal_seek_head(j);
+else
+r = sd_journal_seek_tail(j);
+if (r 0)
+return r;
-id = *boots + *count;
+if (advance_older)
+r = sd_journal_next(j);
+else
+r = sd_journal_previous(j);
+if (r 0)
+return r;
+else if (r == 0)
+return -ENODATA; /* This shouldn't happen. We just came from
this very boot ID. */
-r =
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Thu, 02.04.15 14:33, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/02/2015 01:21 PM, Lennart Poettering wrote: Well, I disagree. And yeah, I still think that /var/lib/machines should be a subvolume, if it is not created manually as something else before. I hear no convincing case why it shouldn't be one. I argue that we should default to directory creation for all filesystems that it is the sane upstream default you say we should default to subvolumes creation for those that are supported ( currently just btrfs ) Now let's hear it from you since you seem to be so eager to dismiss both my arguments along with Martin's, what value does it add, problems it solves and why we ( and thus distribution, administrators, end users and vendors basically all consumers of systemd and btrfs ) should default to create subvolumes. Well, you have not listed any arguments yourself, or what did I miss? Among other things, subvolumes give you the ability to atomically snapshot, atomically delete, apply quota limits, query quota usage, and manage per-subvolume read-only states. This is all very useful for home directories as well as container images. In fact, machined actually even exposes the quota on /var/lib/machines in high-level commands, see machinectl set-limit for details. The atomically deletion magic is useful for factory reset purposes. The read-only flag management is good for allowing root to be read-only while /home being writable, and so on. It would be quite weird if we had all the quota magic exposed in btrfs, but it always fails even on btrfs because we ourselves set things up incorrectly for this to work. Btw my knowledge on btrfs is fine thank you, yours from my pov seems to be limited to a single host implementations where it's more implemented for development than practicality and you somehow seem to be again not taking into account the ramification outside the systemd project itself and it's community, the same thing you did with regards to your *visionary* changes to hostnames, it's meaning and usage which we discussed on one of the hackfests or you recent approval in another thread regarding timedate where I side with and say Kay was and is right. Hmm, visionary changes to hostnames? What's that about? 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] Synchronization Between Services at Shutdown
On Thu, 02.04.15 13:07, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 13:03 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Thu, 02.04.15 13:00, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 11:06 GMT+02:00 Lennart Poettering lenn...@poettering.net: If you want to ensure that bus communication still works in your shutdown code, you hence need to make sure you place After=dbus.service in your services, so that you are shut down before dbus is. Type=dbus service currently only get a dependency on dbus.socket (via After=basic.target). Yeah, and rightfully so. I mean, a service really should be able to shutdown if dbus is dead. In fact, it should be able to shutdown in pretty much any situation... Apparently they don't. There were all sorts of failures caused by dbus being shut down too early. https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612 is one of the related bug reports afair. Hmm? I really don't see how the NFS vs wpa_supplicant issue has anything to do with dbus? NFS doesn't care about dbus at all... You need to order wpa_supplicant and NM Before=remote-fs-pre.target and pull it it via Wants=remote-fs-pre.target. With that in place during shutdown the mounts will be unmounted first, and NM/wpa only shut down after that. See systemd.special(7) for details. I really don't see what dbus has to do with all this... 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] Synchronization Between Services at Shutdown
On Thu, 2015-04-02 at 15:04 +0100, Simon McVittie wrote: On 02/04/15 14:31, Lennart Poettering wrote: Hmm? I really don't see how the NFS vs wpa_supplicant issue has anything to do with dbus? NFS doesn't care about dbus at all... It does inasmuch as it requires networking to be up, which *might* require dbus (e.g. for NetworkManager). NM requires wpa_supplicant running for WiFi because WiFi requires more active management; the AP might go away, you might need to re-key, roam, etc at any moment. The supplicant can't really stop until you no longer need the interface. But in reality, (a) anyone mounting a rootfs over WiFi is asking for trouble, and (b) why the F does NFS still not handle network dropouts reliably? But I digress. You need to order wpa_supplicant and NM Before=remote-fs-pre.target and pull it it via Wants=remote-fs-pre.target. AIUI services with the default dependencies depend on remote-fs.target? Distributions have historically supported NFS /usr and /var if networking is done via ifupdown or something, and used (the LSB equivalent of) remote-fs.target to represent that. NFS /usr or /var with NetworkManager or similar already didn't work, because that needs D-Bus, which needs /usr and /var. NM hasn't needed dbus-daemon running for a long time in early boot, or for any root-level operation. So there's no requirement for /usr or /var or anything else mounted, because root communication happens on a private socket in /run. wpa_supplicant does require dbus, since it has no private socket code. Dan systemd mandates an initramfs that mounts /usr (which has thankfully made it into Debian 8, although for a while it didn't look as though that was going to happen), but AIUI /var is still something that comes up later? It's very easy to get into circular dependencies here; there's the remote filesystem issue, and also the fact that dbus-daemon wants to resolve users/groups, hence might need NIS or LDAP to be up. I personally consider some sort of automatically-synched local cache like sssd to be a far better answer than NIS or LDAP, and NFS root better than NFS /usr and/or /var, but I am not the only one whose opinion matters when considering whether a feature regression in distributions is acceptable. I think the best solution might be a way for dbus-daemon --system to not be required to be Before early targets like sysinit.target (to avoid circular dependencies), but for it to survive until the final killing spree anyway. Does systemd have a way to say that, or are startup/shutdown dependencies always symmetric? Please see https://bugs.freedesktop.org/show_bug.cgi?id=89847 for more on this; one possible hack is to have dbus.service's ExecStop not actually stop dbus-daemon, so that it stays around until the final killing spree just before /usr and /var are unmounted. I'm happy to modify dbus.service if that's (part or all of) the solution, but before I can do that we need to come up with a solution that doesn't cause new dependency cycles. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On Thu, 02.04.15 12:31, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/01/2015 02:37 PM, Lennart Poettering wrote: Note that I intend to add more subvolume lines to tmpfiles even. For example, I am pretty sure /home should be created as subvolume if it doesn't exist already, and similar. I'm afraid that will still only work on a single host setup ( laptop/desktop ) and I'm pretty sure if the intent from you is to default to more subvolume creation i'm afraid you will start conflicting with installers on top of everything else as well. Why would this conflict with installers? Beside the obvious point that you on your own accord have started to decide *for* the end user what his intend are based on your own assumption ( which is something the end user decided at install time or later on if he administrates said host ) after install time, last time I checked installers ( as many other tools ) had a hard time themselves dealing properly with subvolumes and support btrfs properly. Well, first of all, we make decisions for the users all the times. I mean, we declared that /usr is where the OS is located, and not /foobar or any other user-chosen name. And this case isn't even one where we make such a decision, since the user can easily opt-out of the logic, by simple making the dir a dir, so that tmpfiles won't do anything anymore. You thought that /var/lib/machines being a subvolume was the right thing to do and you were wrong, it only works for you on your own host but never in practice for administrators whom are the target audience for that feature. Well, I disagree. And yeah, I still think that /var/lib/machines should be a subvolume, if it is not created manually as something else before. I hear no convincing case why it shouldn't be one. You think that /home should be created as subvolume by default, again wrong not only for the end user who will be scratching their heads wondering where their space went but also for administrators whom have this stored on NAS/SAN with their own specific btrfs policy build on top of storage pools ( if they are using btrfs ) Hmm? where their space went? I am not sure I follow. Multiple subvolumes on the same btrfs volume are all fed from the same big pool. Please read up on btrfs subvolumes, I don't think they work the way you think they do. They aren't fixed size partitions, but simply directories with special semantics. 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] Synchronization Between Services at Shutdown
Lennart Poettering [2015-04-02 15:31 +0200]: You need to order wpa_supplicant and NM Before=remote-fs-pre.target and pull it it via Wants=remote-fs-pre.target. With that in place during shutdown the mounts will be unmounted first, and NM/wpa only shut down after that. wpa_supplicant and NM already have Before=network.target which is even stronger. But that doesn't help -- it's D-Bus which we need to leave running longer, as dbus going down early tears down all dbus clients as well prematurely, thus rendering the above dependencies useless. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedatectl: check for getenv(TZDIR)
On Fri, 27.03.15 09:46, Shawn Landden (sh...@churchofgit.com) wrote: I liked having the DST information. It is a pity glibc doesn't export this information. If TZDIR is set, glibc will look there rather than /usr/share/zoneinfo. See tzset(3). What's the rationale for this? Why would we override the users's choice of $TZDIR? 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] [PATCH 2/2] macro: allow assert_se() assertions to also be optimized out when NDEBUG is set
On Thu, 26.03.15 23:18, Shawn Landden (sh...@churchofgit.com) wrote:
On Thu, Mar 26, 2015 at 1:19 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 24.03.15 11:11, Shawn Landden (sh...@churchofgit.com) wrote:
Will result in slightly smaller binaries, and cuts out the branch, even if
the expression is still executed.
I am sorry, but the whole point of assert_se() is that it has side
effects. That's why it is called that way (the se suffix stands for
side effects), and is different from assert(). You are supposed to
use it whenever the code enclosed in it shall not be suppressed if
NDEBUG is defined. This patch of yours breaks that whole logic!
+#define assert_se(expr) do {expr} while(false)
#define assert(expr) do {} while(false)
No it does not. see {expr}, it still is doing the side effect. It
just doesn't check if the return value is as expected.
I see.
Well, in general I think:
a) actually using NDEBUG is crazy. It's mostly theoretical thing, not
something people should really do.
b) we don't optimize 3k or 7k away. It's negligible.
c) We don't optimize error paths. Optimization we only do for inner
loops.
#ifdef NDEBUG
+#define assert_se(expr) do {expr} while(false)
Does this even work? I mean, lines within the {} of a do/while block
need to end in a semicolon to be useful. Did you actually test this
with -DNDEBUG during compilation?
Also, if somebody uses this:
assert_se(a == 7);
Then you turn this into
do { a == 7 } while(false);
Which (ignoring the fact that the semicolon is missing) will result in
a compiler warning, given that we make a comparison without using its
result. The only way this could work would be this:
#define assert_se(expr) do { (void) (expr) } while(false)
i.e. explicitly casting the result of the expression to (void)...
That all said, I am not convinced that it is worth doing this change
at all.
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
On 02/04/15 14:31, Lennart Poettering wrote: Hmm? I really don't see how the NFS vs wpa_supplicant issue has anything to do with dbus? NFS doesn't care about dbus at all... It does inasmuch as it requires networking to be up, which *might* require dbus (e.g. for NetworkManager). You need to order wpa_supplicant and NM Before=remote-fs-pre.target and pull it it via Wants=remote-fs-pre.target. AIUI services with the default dependencies depend on remote-fs.target? Distributions have historically supported NFS /usr and /var if networking is done via ifupdown or something, and used (the LSB equivalent of) remote-fs.target to represent that. NFS /usr or /var with NetworkManager or similar already didn't work, because that needs D-Bus, which needs /usr and /var. systemd mandates an initramfs that mounts /usr (which has thankfully made it into Debian 8, although for a while it didn't look as though that was going to happen), but AIUI /var is still something that comes up later? It's very easy to get into circular dependencies here; there's the remote filesystem issue, and also the fact that dbus-daemon wants to resolve users/groups, hence might need NIS or LDAP to be up. I personally consider some sort of automatically-synched local cache like sssd to be a far better answer than NIS or LDAP, and NFS root better than NFS /usr and/or /var, but I am not the only one whose opinion matters when considering whether a feature regression in distributions is acceptable. I think the best solution might be a way for dbus-daemon --system to not be required to be Before early targets like sysinit.target (to avoid circular dependencies), but for it to survive until the final killing spree anyway. Does systemd have a way to say that, or are startup/shutdown dependencies always symmetric? Please see https://bugs.freedesktop.org/show_bug.cgi?id=89847 for more on this; one possible hack is to have dbus.service's ExecStop not actually stop dbus-daemon, so that it stays around until the final killing spree just before /usr and /var are unmounted. I'm happy to modify dbus.service if that's (part or all of) the solution, but before I can do that we need to come up with a solution that doesn't cause new dependency cycles. S -- Simon McVittie Collabora Ltd. http://www.collabora.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/02/2015 01:21 PM, Lennart Poettering wrote: Well, I disagree. And yeah, I still think that /var/lib/machines should be a subvolume, if it is not created manually as something else before. I hear no convincing case why it shouldn't be one. I argue that we should default to directory creation for all filesystems that it is the sane upstream default you say we should default to subvolumes creation for those that are supported ( currently just btrfs ) Now let's hear it from you since you seem to be so eager to dismiss both my arguments along with Martin's, what value does it add, problems it solves and why we ( and thus distribution, administrators, end users and vendors basically all consumers of systemd and btrfs ) should default to create subvolumes. Btw my knowledge on btrfs is fine thank you, yours from my pov seems to be limited to a single host implementations where it's more implemented for development than practicality and you somehow seem to be again not taking into account the ramification outside the systemd project itself and it's community, the same thing you did with regards to your *visionary* changes to hostnames, it's meaning and usage which we discussed on one of the hackfests or you recent approval in another thread regarding timedate where I side with and say Kay was and is right. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Add reboot to EFI support
Hi, On 2015-04-02 11:34, Lennart Poettering wrote: On Thu, 26.03.15 16:09, Jan Janssen (medhe...@web.de) wrote: Heya, Hmm, so we already support passing special reboot() parameters, and this is done by manipulating a file in /run, without introducing any new targets. To me it appears that boot-into-firmware-setup is something hat should be handled the same way, i.e. as a special parameter for the *normal* poweroff path, instead of introducing a new poweroff path for it. Of course, instead of manipulating /run for this we should directly manipulate the respective EFI variable. I hence think this should be a new switch --firmware-setup or so to systemctl. Of course, that sounds awfully specific and I don't really like too much adding a new switch just for this flag, but it's the least best option I see. That was my original approach. Kay said --firmware sounded weird. The existing boot argument is passed as-is to the kernel, hence giving the argument efi a special meaning would mean once couldn't pass that parameter anymore to the kernel. I had the same reservation, but it was suggested to ignore this and just piggyback on this instead. I would strongly prefer naming the switch something like firmware instead of EFI, since we shouldn't encode the technology here, but the generic term. Also, this should mention that this is about the setup tool of the firmware, since EFI is available all the time, and this is really about the *setup* tool of the firmware... Someone suggested firmware is too generic, so I switched to EFI. Would be nice if people made up their mind on that one... I think ultimately we need to expose this even in GNOME, similar to the way Window exposes this. To cover that we should probably add a bus API to logind in some form to manipulate the EFI var in question, and systemctl reboot --firmware-setup would use that. (And yes, a similar bus API for specifying the generic reboot parameter probably should exist alongside it). Äääähm... this is exactly what this patch does, adding CanRebootToEfi() and a RebootToEfi() functions. What did I miss? Unless you mean changing those into a pair of properties to just set the indication and then the bus client would have to manually trigger Reboot()? In fact, that's what I kind of got in my mind after sending this patch. It would also work nicely with a separate RebootArguments property without the hassle of introducing more complex logic into the target related functions in logind. My original approach was adding a RebootWithArguments function, but my brain cannot get the code to look nicely. But making them into properties and requiring the client to issue a Reboot themselves would be a neat way around that. Of course the bus API should also support a CanFirmwareSetup() call or so, that reports whether the logic is available at all. As I said, this patch adds this. Though, it would be nice if some consensus would come about whether to call this firmware or EFI. I think being specific is probably nicer. Unless this were to return a string indicating what kind of firmware setup is supported (if ever any others would come about in the future), returning efi for EFI systems. Does this make sense? Lennart Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
Lennart Poettering [2015-04-02 13:03 +0200]: Yeah, and rightfully so. I mean, a service really should be able to shutdown if dbus is dead. In fact, it should be able to shutdown in pretty much any situation... They do, but that's irrelevant here. The problem is that dbus.service shuts down very early as nothing prevents it from that. All dependencies just refer to dbus.socket, but TBH socket (re-)activation totally doesn't work for dbus. On restarts it forgets all of its previous state/connections, so a service which still needs to talk to dbus during shutdown will just fail if dbus.service already stopped. So what happens is that dbus.service gets stopped early, takes NetworkManager, wpasupplicant etc. with it, and then the network mounts can't be unmounted any more as the network is already down (which isn't intended at this point yet, as network.target is still active). Synthesizing After=dbus.service dependencies instead of dbus.socket ones for Type=dbus would help, as then you'd have the ordering which prevents dbus.service from going down early. But this is prone to dependency loops. This has also been discussed with upstream on https://bugs.freedesktop.org/show_bug.cgi?id=89847 I don't really have a good solution, the don't really stop dbus is a relatively safe hack that's appropriate for the we need to release in two weeks freeze. Obviously the really good solution is to get kdbus, then dbus will always be available :-) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
On Thu, 2015-04-02 at 16:31 +0200, Martin Pitt wrote: Lennart Poettering [2015-04-02 15:31 +0200]: You need to order wpa_supplicant and NM Before=remote-fs-pre.target and pull it it via Wants=remote-fs-pre.target. With that in place during shutdown the mounts will be unmounted first, and NM/wpa only shut down after that. wpa_supplicant and NM already have Before=network.target which is even stronger. But that doesn't help -- it's D-Bus which we need to leave running longer, as dbus going down early tears down all dbus clients as well prematurely, thus rendering the above dependencies useless. At least on the NM side, NM shouldn't be doing anything when dbus-daemon exits, except logging something and trying to reconnect. It shouldn't touch network interfaces except those that require a management daemon, like wpa_supplicant or Bluetooth or teamd, provided you use the internal DHCP client. But ethernet, bridge/bond/vlan/infiniband/etc should be fine. Obviously if the supplicant goes down, WiFi goes down, but running something like NFS over WiFi is kinda asking for trouble, given that NFS doesn't handle network dropouts well in the first place. Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-219] Journal spamming by umount / high CPU usage
On Thu, 02.04.15 11:11, Kai Krakow (hurikha...@gmail.com) wrote: Hi! Lennart Poettering lenn...@poettering.net schrieb am Do., 2. Apr. 2015 um 10:49 Uhr: On Sun, 29.03.15 17:12, Kai Krakow (hurikha...@gmail.com) wrote: Hello! I've got a automount point for a daily USB backup job. Due to some instabilities of early USB3 chipsets and early USB3 devices, the mounted device sometimes wents offline and eventually comes back after a while but my backup job is stuck (rsync). I configured rsync to shutdown upon block io timeouts. This in turn makes the systemd automounter think (correctly) that the mount point is no longer in use - but it cannot be unmounted. The problem here is, that it spams the journal with hundreds of messages per minute all day long (or as long as I don't reboot): Hmm? The systemd automount logic so far does not support mount expiration, hence I cannot really parse what you write above? What exactly do you mean with expiration? Expiration by time or by usage? Expiration is what the kernel autofs logic calls when a mount is detected to be idle, and then after a timeout unmounted. systemd does not support expiration right now. very recently there have been posted patches to add this, but they have not been applied yet, and hence on your system whatever you are running into is not related to thus. To me it looks like the automounter tries to unmount unless there's still references open in the filesystem. It does, however, no try to do this after some timeout - which is fine. OTOH, this could be just an effect of the mount point forcibly vanishing because the USB device disconnected. The kernel actually allows unmounting of mounts at any time, even if the backing device has vanished. (In fact, it particularly allows unmounting in that case...) Maybe this is by kernel design? The filesystem forced itself read-only (due to IO errors to an offlined/disconnected device), then went offline. The kernel probably umounted it, and I believe that now another manual umount results in EPERM, tho I cannot test that now. I can test it this evening if it is of interested. I could also test other ideas to debug if you instruct me. I am pretty sure there's something weird going on here. Any chance you can boot with systemd.log_level=debug on the kernel cmdline, then reproduce the issue and paste the output this generates here? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Starting a unit on resume from suspend/hibernate
Hello list, I'm having trouble to auto-activate a unit on resume, after suspend-to-ram or hibernation. The unit properly stops when suspending (because of Conflicts=sleep.target), but does not restart after resuming. The key to achieve this as far as I understand, are the following two clauses: After=sleep.target WantedBy=sleep.target The second one (WantedBy) seems to be problematic. systemctl show does now show sleep.target in there and systemctl enable does not install the proper symlink. Even afer manually symlinking myself, the unit doesn't seem to be started after resuming: ln -s /usr/lib/systemd/system/sysstat.service /etc/systemd/system/sleep.target.wants/sysstat.service Finally I've tried replacing sleep.target with suspend.target with no success. The system logs are showing no errors, and my systemd version is systemd-216-21.fc21.i686. You can see the full unit file here: [Unit] Description=System Activity Accounting # Start the periodic accounting process Requires=sysstat-collect.timer # but make sure we finish first, because the accounting process locks the datafile Before=sysstat-collect.timer sysstat-collect.service # Automatically stop the unit when starting sleep.target Conflicts=sleep.target # and start it again after resume (in combination with WantedBy at the end) After=sleep.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/sa1 --boot -C STARTED ExecStop=/usr/lib/sa1 --boot -C STOPPED [Install] WantedBy=multi-user.target sleep.target Also=sysstat-collect.timer Also=sysstat-summary.timer Any ideas what might be wrong? I understand a workaround would be to install custom scripts under the system-sleep directory, but if the problem can be solved within the unit file, that would be ideal. Thanks in advance, Dimitris P.S. Please keep me CC'd as I'm not subscribed. Let me know if this is not the proper place for such questions, I'd appreciate pointers to the relevant list. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Synchronization Between Services at Shutdown
Both services A and B specify Requires=dbus.service and After=dbus.service. If I am interpreting everything that's being said correctly, there is a race condition in my code since service A's implementation doesn't require it to wait until it has processed the method call from service B before it stops listening for method calls. Does that sound right? On Thu, Apr 2, 2015 at 6:31 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.04.15 13:07, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 13:03 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Thu, 02.04.15 13:00, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-02 11:06 GMT+02:00 Lennart Poettering lenn...@poettering.net : If you want to ensure that bus communication still works in your shutdown code, you hence need to make sure you place After=dbus.service in your services, so that you are shut down before dbus is. Type=dbus service currently only get a dependency on dbus.socket (via After=basic.target). Yeah, and rightfully so. I mean, a service really should be able to shutdown if dbus is dead. In fact, it should be able to shutdown in pretty much any situation... Apparently they don't. There were all sorts of failures caused by dbus being shut down too early. https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612 is one of the related bug reports afair. Hmm? I really don't see how the NFS vs wpa_supplicant issue has anything to do with dbus? NFS doesn't care about dbus at all... You need to order wpa_supplicant and NM Before=remote-fs-pre.target and pull it it via Wants=remote-fs-pre.target. With that in place during shutdown the mounts will be unmounted first, and NM/wpa only shut down after that. See systemd.special(7) for details. I really don't see what dbus has to do with all this... Lennart -- Lennart Poettering, Red Hat -- Kurt von Laven | Endless Mobile | EndlessM.com http://endlessm.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting a unit on resume from suspend/hibernate
В Thu, 2 Apr 2015 18:43:40 +0200 (CEST) Dimitrios Apostolou ji...@gmx.net пишет: Conflicts=sleep.target WantedBy=multi-user.target sleep.target These are mutually conflicting. One one hand Conflicts says to stop your unit when sleep.target gets started, on the other hand WantedBy says to start your unit when sleep.target gets started. Only one can win. As workaround you can start your unit in /usr/lib/systemd/sytem-sleep script post-resume. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting a unit on resume from suspend/hibernate
On Thu, 2 Apr 2015, Andrei Borzenkov wrote: В Thu, 2 Apr 2015 18:43:40 +0200 (CEST) Dimitrios Apostolou ji...@gmx.net пишет: Conflicts=sleep.target WantedBy=multi-user.target sleep.target These are mutually conflicting. One one hand Conflicts says to stop your unit when sleep.target gets started, on the other hand WantedBy says to start your unit when sleep.target gets started. Only one can win. Indeed, but I was assuming that combined with after they could co-exist, starting the unit after the dependency has started and stopped. And if it was a problem I would expect a message, since it's easy to detect. Anyway even removing the Conflicts line does not help. systemctl enable still does not install the symlink, and manually installing the symlink does not change anything. As workaround you can start your unit in /usr/lib/systemd/sytem-sleep script post-resume. Is it possible to keep the logic in the unit file? Thanks, Dimitris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting a unit on resume from suspend/hibernate
On Thu, 2 Apr 2015, Dimitrios Apostolou wrote: On Thu, 2 Apr 2015, Andrei Borzenkov wrote: В Thu, 2 Apr 2015 18:43:40 +0200 (CEST) Dimitrios Apostolou ji...@gmx.net пишет: Conflicts=sleep.target WantedBy=multi-user.target sleep.target These are mutually conflicting. One one hand Conflicts says to stop your unit when sleep.target gets started, on the other hand WantedBy says to start your unit when sleep.target gets started. Only one can win. Indeed, but I was assuming that combined with after they could co-exist, starting the unit after the dependency has started and stopped. And if it was a problem I would expect a message, since it's easy to detect. Anyway even removing the Conflicts line does not help. systemctl enable still does not install the symlink, and manually installing the symlink does not change anything. Hmmm I did some more trials with the conflicts line commented out. While just listing sleep.target didn't work, the following was successful and the unit starts after resuming: After=sleep.target suspend.target hibernate.target hybrid-sleep.target WantedBy=multi-user.target sleep.target suspend.target hibernate.target hybrid-sleep.target In addition systemctl disable/enable didn't create the symlinks, I had to properly add them. Maybe it's a bug? Thanks, Dimitris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and smartd daemon
On Thu, 02.04.15 10:43, Al Lau (laua...@gmail.com) wrote: Hi, I am seeking help and advise on troubleshooting the starting of the smartd daemon. The /usr/sbin/smartd comes from the smartmontools version 6.3. The /usr/lib/systemd/system/smartd.service file looks like this # cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon Documentation=man:smartd(8) man:smartd.conf(5) After=syslog.target This line is not necessary. Nowadays all services are started with /dev/log available. Please remove. [Service] Type=forking PIDFile=/run/smartd.pid ExecStartPre=/bin/rm -f /run/smartd.pid systemd removes PID files listed in PIDFile= automatically these days, this line is unnecessary. EnvironmentFile=/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd $smartd_opts I assume that your $smartd_opts includes any necessary switches to tell smartd to daemonize? ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog This line is not necessary, systemd since quite some time connects all daemon stdout/stderr to the journal anyway. [Install] WantedBy=multi-user.target When systemctl start smartd.service is called, the process forks into a daemon. The problem I'm seeing is that the forked process received a SIGTERM signal and exited. How do I resolve this so that the forked process would not get terminated. # systemctl status smartd.service smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/usr/lib/systemd/system/smartd.service; enabled) Active: failed (Result: timeout) since Thu 2015-04-02 17:19:49 GMT; 4min 39s ago Docs: man:smartd(8) man:smartd.conf(5) Process: 7456 ExecStart=/usr/sbin/smartd $smartd_opts (code=exited, status=0/SUCCESS) Process: 7454 ExecStartPre=/bin/rm -f /run/smartd.pid (code=exited, status=0/SUCCESS) Main PID: 1075 (code=exited, status=0/SUCCESS) Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], opened Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], [TOSHIBA MG03SCA300 5702], lu 00 TB Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], is SMART capable. Adding to monitor list. Apr 02 17:18:20 007 smartd[7456]: Monitoring 0 ATA and 12 SCSI devices Apr 02 17:18:21 007 systemd[1]: PID file /run/smartd.pid not readable (yet?) after start. Apr 02 17:18:21 007 smartd[7463]: smartd has fork()ed into background mode. New PID=7463. Apr 02 17:19:49 007 systemd[1]: smartd.service operation timed out. Terminating. Apr 02 17:19:49 007 smartd[7463]: smartd received signal 15: Terminated Apr 02 17:19:49 007 systemd[1]: Failed to start Self Monitoring and Reporting Technology (SMART) Daemon. Apr 02 17:19:49 007 systemd[1]: Unit smartd.service entered failed state. Hint: Some lines were ellipsized, use -l to show in full. # To verify, I take the /usr/sbin/smartd $smartd_opts and run it from the command line. The smartd daemon forks and the daemon process stays up as expected. The output above really suggests that the daemonization code in smartd is broken? A sysv daemon should do the following when daemonizing: 1) fork twice, exit in the middle child 2) in the grandchild (the main daemon process), set everything up, including writing the PID file 3) exit in the parent It is important that 3) does not happen before 2) is complete and the PID file exists. The output above suggests that smartd doesn't get this right, and sometimes writes the PID file after exiting in the parent. This is a bug that needs to be fixed in smartd, and it is not specific to systemd's way of watching daemons. With this broken things like this on a pure sysv system are racy too: /etc/init.d/smartd start ; /etc/init.d/smartd stop (because the PID file might not exist yet when the stop command tries to read it to kill the daemon). Also see daemon(7) for a more detailed overview. Anyway, this really smells like a daemon bug, not a bug in your unit file, and it needs to be fixed in the daemon. (An alternative is to not let the daemon daemonize, but tell it to stay in the foreground and then use the default Type=simple. However, this means that systemd will not wait for the daemon to be fully initialized, which might or might not be an issue, depending on the daemon, for example whether it needs to be accessible via IPC or so) 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] Starting a unit on resume from suspend/hibernate
On Thu, 02.04.15 18:43, Dimitrios Apostolou (ji...@gmx.net) wrote: Hello list, I'm having trouble to auto-activate a unit on resume, after suspend-to-ram or hibernation. The unit properly stops when suspending (because of Conflicts=sleep.target), but does not restart after resuming. We do not really support that right now. Suspend/hibernate is implemented as a single transaction, and you cannot stop a unit and start it in the same transaction. A hackish way to implement this is by using the suspend callout dir /usr/lib/systemd/system-sleep/ (see systemd-suspend.service(8) for details), and enqueue a stop and a start job from there, depending on whether the hook is called before or after the suspend/hibernation. But yeah, this is hackish. Usually if one wants to do that one is just working around some problems that are better solved in a different way. Why precisely do you need this feature? 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] systemd and smartd daemon
As a test, the /usr/sbin/smartd $smartd_opts is invoked from the command line and the daemon is forked and stayed up as expected. By default, the /usr/sbin/smartd daemonize. # cat /etc/sysconfig/smartmontools smartd_opts=--interval=3600 --configfile=/etc/smartd.conf From the /var/log/messages, the SIGTERM signal is sent to the forked process. Like to know if this is something that can be worked around. Thanks, -Al On Thu, Apr 2, 2015 at 11:30 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.04.15 10:43, Al Lau (laua...@gmail.com) wrote: Hi, I am seeking help and advise on troubleshooting the starting of the smartd daemon. The /usr/sbin/smartd comes from the smartmontools version 6.3. The /usr/lib/systemd/system/smartd.service file looks like this # cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon Documentation=man:smartd(8) man:smartd.conf(5) After=syslog.target This line is not necessary. Nowadays all services are started with /dev/log available. Please remove. [Service] Type=forking PIDFile=/run/smartd.pid ExecStartPre=/bin/rm -f /run/smartd.pid systemd removes PID files listed in PIDFile= automatically these days, this line is unnecessary. EnvironmentFile=/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd $smartd_opts I assume that your $smartd_opts includes any necessary switches to tell smartd to daemonize? ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog This line is not necessary, systemd since quite some time connects all daemon stdout/stderr to the journal anyway. [Install] WantedBy=multi-user.target When systemctl start smartd.service is called, the process forks into a daemon. The problem I'm seeing is that the forked process received a SIGTERM signal and exited. How do I resolve this so that the forked process would not get terminated. # systemctl status smartd.service smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/usr/lib/systemd/system/smartd.service; enabled) Active: failed (Result: timeout) since Thu 2015-04-02 17:19:49 GMT; 4min 39s ago Docs: man:smartd(8) man:smartd.conf(5) Process: 7456 ExecStart=/usr/sbin/smartd $smartd_opts (code=exited, status=0/SUCCESS) Process: 7454 ExecStartPre=/bin/rm -f /run/smartd.pid (code=exited, status=0/SUCCESS) Main PID: 1075 (code=exited, status=0/SUCCESS) Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], opened Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], [TOSHIBA MG03SCA300 5702], lu 00 TB Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], is SMART capable. Adding to monitor list. Apr 02 17:18:20 007 smartd[7456]: Monitoring 0 ATA and 12 SCSI devices Apr 02 17:18:21 007 systemd[1]: PID file /run/smartd.pid not readable (yet?) after start. Apr 02 17:18:21 007 smartd[7463]: smartd has fork()ed into background mode. New PID=7463. Apr 02 17:19:49 007 systemd[1]: smartd.service operation timed out. Terminating. Apr 02 17:19:49 007 smartd[7463]: smartd received signal 15: Terminated Apr 02 17:19:49 007 systemd[1]: Failed to start Self Monitoring and Reporting Technology (SMART) Daemon. Apr 02 17:19:49 007 systemd[1]: Unit smartd.service entered failed state. Hint: Some lines were ellipsized, use -l to show in full. # To verify, I take the /usr/sbin/smartd $smartd_opts and run it from the command line. The smartd daemon forks and the daemon process stays up as expected. The output above really suggests that the daemonization code in smartd is broken? A sysv daemon should do the following when daemonizing: 1) fork twice, exit in the middle child 2) in the grandchild (the main daemon process), set everything up, including writing the PID file 3) exit in the parent It is important that 3) does not happen before 2) is complete and the PID file exists. The output above suggests that smartd doesn't get this right, and sometimes writes the PID file after exiting in the parent. This is a bug that needs to be fixed in smartd, and it is not specific to systemd's way of watching daemons. With this broken things like this on a pure sysv system are racy too: /etc/init.d/smartd start ; /etc/init.d/smartd stop (because the PID file might not exist yet when the stop command tries to read it to kill the daemon). Also see daemon(7) for a more detailed overview. Anyway, this really smells like a daemon bug, not a bug in your unit file, and it needs to be fixed in the daemon. (An alternative is to not let the daemon daemonize, but tell it to stay in the foreground and then use the default Type=simple. However, this means that systemd will not wait for the daemon to be fully initialized, which might or might not be an issue, depending
Re: [systemd-devel] Starting a unit on resume from suspend/hibernate
В Thu, 2 Apr 2015 19:34:55 +0200 (CEST) Dimitrios Apostolou ji...@gmx.net пишет: On Thu, 2 Apr 2015, Dimitrios Apostolou wrote: On Thu, 2 Apr 2015, Andrei Borzenkov wrote: В Thu, 2 Apr 2015 18:43:40 +0200 (CEST) Dimitrios Apostolou ji...@gmx.net пишет: Conflicts=sleep.target WantedBy=multi-user.target sleep.target These are mutually conflicting. One one hand Conflicts says to stop your unit when sleep.target gets started, on the other hand WantedBy says to start your unit when sleep.target gets started. Only one can win. Indeed, but I was assuming that combined with after they could co-exist, starting the unit after the dependency has started and stopped. And if it was a problem I would expect a message, since it's easy to detect. Anyway even removing the Conflicts line does not help. systemctl enable still does not install the symlink, and manually installing the symlink does not change anything. Hmmm I did some more trials with the conflicts line commented out. While just listing sleep.target didn't work, the following was successful and the unit starts after resuming: How is it stopped then? It is apparently started on boot (WantedBy multi-user.target) and there is no conflicts so it is never stopped. After=sleep.target suspend.target hibernate.target hybrid-sleep.target Yes, this works due to the way it is implemented. Not sure if it is committed functionality though. WantedBy=multi-user.target sleep.target suspend.target hibernate.target hybrid-sleep.target This is redundant, WantedBy=sleep.target should be enough. In addition systemctl disable/enable didn't create the symlinks, I had to properly add them. Maybe it's a bug? bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid systemctl status test.servicetest.service - Test Loaded: loaded (/run/systemd/system/test.service; disabled) Active: inactive (dead) bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid sudo systemctl enable test.service bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid systemctl status test.servicetest.service - Test Loaded: loaded (/run/systemd/system/test.service; enabled) Active: inactive (dead) bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid ll /etc/systemd/system/sleep.target.wants/ итого 0 lrwxrwxrwx 1 root root 32 апр 2 20:36 test.service - /run/systemd/system/test.service bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid Thanks, Dimitris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: don't create subvolumes in chroot
On 04/02/2015 03:48 PM, Lennart Poettering wrote: On Thu, 02.04.15 14:33, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 04/02/2015 01:21 PM, Lennart Poettering wrote: Well, I disagree. And yeah, I still think that /var/lib/machines should be a subvolume, if it is not created manually as something else before. I hear no convincing case why it shouldn't be one. I argue that we should default to directory creation for all filesystems that it is the sane upstream default you say we should default to subvolumes creation for those that are supported ( currently just btrfs ) Now let's hear it from you since you seem to be so eager to dismiss both my arguments along with Martin's, what value does it add, problems it solves and why we ( and thus distribution, administrators, end users and vendors basically all consumers of systemd and btrfs ) should default to create subvolumes. Well, you have not listed any arguments yourself, or what did I miss? ? I have made many arguments why subvolumes should not be enabled by default and why that power to enable that should be delegated to the distributions themselves at the time of their choosing (which most likely will be around the time they default to btrfs ). I'm not arguing against systemd integrating itself with all the bells and whistle btrfs has to offer, I'm arguing against those implementation being enabled by default on btrfs since currently they cause more problems then they solve ( due to the fact btrfs has not become widespread enough for users to have learned to manage it ). Among other things, subvolumes give you the ability to atomically snapshot, atomically delete, apply quota limits, query quota usage, and manage per-subvolume read-only states. This is all very useful for home directories as well as container images. In fact, machined actually even exposes the quota on /var/lib/machines in high-level commands, see machinectl set-limit for details. The atomically deletion magic is useful for factory reset purposes. The read-only flag management is good for allowing root to be read-only while /home being writable, and so on. It would be quite weird if we had all the quota magic exposed in btrfs, but it always fails even on btrfs because we ourselves set things up incorrectly for this to work. The only use case ( which seem to be the use case you are fixated on in this particular case ) that we can manage to setup this correctly is for a single host on an local disk and systemd somehow magically takes care of everything with no end user administrator involvement whatsoever so it only works for one consumer group ( desktop ) not two ( embedded + desktop or server + desktop ) or all ( embedded + servers + desktop ). For an upstream default I would say that the default needs to be beneficial to at least two consumer groups, preferably three with the least havoc caused downstream. Btw my knowledge on btrfs is fine thank you, yours from my pov seems to be limited to a single host implementations where it's more implemented for development than practicality and you somehow seem to be again not taking into account the ramification outside the systemd project itself and it's community, the same thing you did with regards to your *visionary* changes to hostnames, it's meaning and usage which we discussed on one of the hackfests or you recent approval in another thread regarding timedate where I side with and say Kay was and is right. Hmm, visionary changes to hostnames? What's that about? Your view on hostnames which conflicted with the entire IT industry's view on hostnames and their historic uses. That discussion happened when we were discussing one of the bugs filed against systemd on one of the systemd hackfest in brno @ Red Hat which ended with the correct resolution once discussed ( in other words you change your mind after that discussion ). It was the hackfest that got recorded if memory serves me correct. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting a unit on resume from suspend/hibernate
On Thu, 2 Apr 2015, Andrei Borzenkov wrote: В Thu, 2 Apr 2015 19:34:55 +0200 (CEST) Dimitrios Apostolou ji...@gmx.net пишет: On Thu, 2 Apr 2015, Dimitrios Apostolou wrote: On Thu, 2 Apr 2015, Andrei Borzenkov wrote: В Thu, 2 Apr 2015 18:43:40 +0200 (CEST) Dimitrios Apostolou ji...@gmx.net пишет: Conflicts=sleep.target WantedBy=multi-user.target sleep.target These are mutually conflicting. One one hand Conflicts says to stop your unit when sleep.target gets started, on the other hand WantedBy says to start your unit when sleep.target gets started. Only one can win. Indeed, but I was assuming that combined with after they could co-exist, starting the unit after the dependency has started and stopped. And if it was a problem I would expect a message, since it's easy to detect. Anyway even removing the Conflicts line does not help. systemctl enable still does not install the symlink, and manually installing the symlink does not change anything. Hmmm I did some more trials with the conflicts line commented out. While just listing sleep.target didn't work, the following was successful and the unit starts after resuming: How is it stopped then? It is apparently started on boot (WantedBy multi-user.target) and there is no conflicts so it is never stopped. Sorry I wasn't clear. The service was manually stopped before suspend/resume. Ofcourse I wouldn't expect the service to stop, since I removed the conflicts line, so this alone can't be the complete solution for my case. After=sleep.target suspend.target hibernate.target hybrid-sleep.target Yes, this works due to the way it is implemented. Not sure if it is committed functionality though. WantedBy=multi-user.target sleep.target suspend.target hibernate.target hybrid-sleep.target This is redundant, WantedBy=sleep.target should be enough. In addition systemctl disable/enable didn't create the symlinks, I had to properly add them. Maybe it's a bug? bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid systemctl status test.servicetest.service - Test Loaded: loaded (/run/systemd/system/test.service; disabled) Active: inactive (dead) bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid sudo systemctl enable test.service bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid systemctl status test.servicetest.service - Test Loaded: loaded (/run/systemd/system/test.service; enabled) Active: inactive (dead) bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid ll /etc/systemd/system/sleep.target.wants/ итого 0 lrwxrwxrwx 1 root root 32 апр 2 20:36 test.service - /run/systemd/system/test.service bor@opensuse:~/src/dmraid/1.0.0.rc16-3/dmraid Thanks, Dimitris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Add reboot to EFI support
On Thu, 02.04.15 15:51, Jan Janssen (medhe...@web.de) wrote: Hi, On 2015-04-02 11:34, Lennart Poettering wrote: On Thu, 26.03.15 16:09, Jan Janssen (medhe...@web.de) wrote: Heya, Hmm, so we already support passing special reboot() parameters, and this is done by manipulating a file in /run, without introducing any new targets. To me it appears that boot-into-firmware-setup is something hat should be handled the same way, i.e. as a special parameter for the *normal* poweroff path, instead of introducing a new poweroff path for it. Of course, instead of manipulating /run for this we should directly manipulate the respective EFI variable. I hence think this should be a new switch --firmware-setup or so to systemctl. Of course, that sounds awfully specific and I don't really like too much adding a new switch just for this flag, but it's the least best option I see. That was my original approach. Kay said --firmware sounded weird. Yeah, he initially said that but 6 hours later suggested suggested --firmware again. http://lists.freedesktop.org/archives/systemd-devel/2015-March/029589.html That said, I think it really should be --firmware-setup and not --firmware, since otherwise one might think this simply uses a different way to reboot, using some firmware call or so. Also note that I figure systemctl poweroff --firmware-setup might be a valid operation too, not just systemctl reboot --firmware-setup. I mean, it's not too useful, but probably valid... The existing boot argument is passed as-is to the kernel, hence giving the argument efi a special meaning would mean once couldn't pass that parameter anymore to the kernel. I had the same reservation, but it was suggested to ignore this and just piggyback on this instead. Nah, I am very much against that, that'd be hackish. I would strongly prefer naming the switch something like firmware instead of EFI, since we shouldn't encode the technology here, but the generic term. Also, this should mention that this is about the setup tool of the firmware, since EFI is available all the time, and this is really about the *setup* tool of the firmware... Someone suggested firmware is too generic, so I switched to EFI. Would be nice if people made up their mind on that one... Hmm, can't see this on the ML. The logic is independent of any particular firmware technology, and I am pretty sure we should not encode that this is about EFI in the name. I mean, in the thread it was suggested that Nexus devices support a similar reboot scheme, without being EFI. Maybe one day we want to hook that up too under the same switch? I think ultimately we need to expose this even in GNOME, similar to the way Window exposes this. To cover that we should probably add a bus API to logind in some form to manipulate the EFI var in question, and systemctl reboot --firmware-setup would use that. (And yes, a similar bus API for specifying the generic reboot parameter probably should exist alongside it). Äääähm... this is exactly what this patch does, adding CanRebootToEfi() and a RebootToEfi() functions. What did I miss? Unless you mean changing those into a pair of properties to just set the indication and then the bus client would have to manually trigger Reboot()? Yes, precisely. Though, it should be a read-only property, plus a call to change it, plus a call that tells you whether it can be change it. It should not be a writable property, since we need to do polkit when the value is changed, and property changes should not really require interactive auth. Hence: - A boolean property RebootToFirmware - A method call SetRebootToFirmware() taking a boolean - A method call CanRebootToFirmware() returning a string, yes, no, challenge In fact, that's what I kind of got in my mind after sending this patch. It would also work nicely with a separate RebootArguments property without the hassle of introducing more complex logic into the target related functions in logind. My original approach was adding a RebootWithArguments function, but my brain cannot get the code to look nicely. But making them into properties and requiring the client to issue a Reboot themselves would be a neat way around that. Yeah, a RebootArgument bus interface would be useful too, much like the above: - A string property RebootArgument - A method call SetRebootArgument() taking a string But probably no CanRebootArgument since this is not a discoverable feature... Of course the bus API should also support a CanFirmwareSetup() call or so, that reports whether the logic is available at all. As I said, this patch adds this. Though, it would be nice if some consensus would come about whether to call this firmware or EFI. I think being specific is probably nicer. Unless this were to return a string indicating what kind of firmware setup is supported (if ever any others would come about in the future), returning efi for EFI systems. Whether
Re: [systemd-devel] [PATCH v2] Add reboot to EFI support
On Thu, Apr 2, 2015 at 8:18 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.04.15 15:51, Jan Janssen (medhe...@web.de) wrote: Hi, On 2015-04-02 11:34, Lennart Poettering wrote: On Thu, 26.03.15 16:09, Jan Janssen (medhe...@web.de) wrote: Heya, Hmm, so we already support passing special reboot() parameters, and this is done by manipulating a file in /run, without introducing any new targets. To me it appears that boot-into-firmware-setup is something hat should be handled the same way, i.e. as a special parameter for the *normal* poweroff path, instead of introducing a new poweroff path for it. Of course, instead of manipulating /run for this we should directly manipulate the respective EFI variable. I hence think this should be a new switch --firmware-setup or so to systemctl. Of course, that sounds awfully specific and I don't really like too much adding a new switch just for this flag, but it's the least best option I see. That was my original approach. Kay said --firmware sounded weird. Yeah, he initially said that but 6 hours later suggested suggested --firmware again. No, I did not. The mail contains only references about the order of options. I dislike the global options for local verbs systemctl does, it is confusing even in the man page, and does not scale. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd and smartd daemon
Hi, I am seeking help and advise on troubleshooting the starting of the smartd daemon. The /usr/sbin/smartd comes from the smartmontools version 6.3. The /usr/lib/systemd/system/smartd.service file looks like this # cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon Documentation=man:smartd(8) man:smartd.conf(5) After=syslog.target [Service] Type=forking PIDFile=/run/smartd.pid ExecStartPre=/bin/rm -f /run/smartd.pid EnvironmentFile=/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd $smartd_opts ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog [Install] WantedBy=multi-user.target When systemctl start smartd.service is called, the process forks into a daemon. The problem I'm seeing is that the forked process received a SIGTERM signal and exited. How do I resolve this so that the forked process would not get terminated. # systemctl status smartd.service smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/usr/lib/systemd/system/smartd.service; enabled) Active: failed (Result: timeout) since Thu 2015-04-02 17:19:49 GMT; 4min 39s ago Docs: man:smartd(8) man:smartd.conf(5) Process: 7456 ExecStart=/usr/sbin/smartd $smartd_opts (code=exited, status=0/SUCCESS) Process: 7454 ExecStartPre=/bin/rm -f /run/smartd.pid (code=exited, status=0/SUCCESS) Main PID: 1075 (code=exited, status=0/SUCCESS) Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], opened Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], [TOSHIBA MG03SCA300 5702], lu 00 TB Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], is SMART capable. Adding to monitor list. Apr 02 17:18:20 007 smartd[7456]: Monitoring 0 ATA and 12 SCSI devices Apr 02 17:18:21 007 systemd[1]: PID file /run/smartd.pid not readable (yet?) after start. Apr 02 17:18:21 007 smartd[7463]: smartd has fork()ed into background mode. New PID=7463. Apr 02 17:19:49 007 systemd[1]: smartd.service operation timed out. Terminating. Apr 02 17:19:49 007 smartd[7463]: smartd received signal 15: Terminated Apr 02 17:19:49 007 systemd[1]: Failed to start Self Monitoring and Reporting Technology (SMART) Daemon. Apr 02 17:19:49 007 systemd[1]: Unit smartd.service entered failed state. Hint: Some lines were ellipsized, use -l to show in full. # To verify, I take the /usr/sbin/smartd $smartd_opts and run it from the command line. The smartd daemon forks and the daemon process stays up as expected. Thanks, -Al ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and smartd daemon
В Thu, 2 Apr 2015 10:43:00 -0700 Al Lau laua...@gmail.com пишет: Hi, I am seeking help and advise on troubleshooting the starting of the smartd daemon. The /usr/sbin/smartd comes from the smartmontools version 6.3. The /usr/lib/systemd/system/smartd.service file looks like this # cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon Documentation=man:smartd(8) man:smartd.conf(5) After=syslog.target [Service] Type=forking PIDFile=/run/smartd.pid ExecStartPre=/bin/rm -f /run/smartd.pid EnvironmentFile=/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd $smartd_opts ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog [Install] WantedBy=multi-user.target When systemctl start smartd.service is called, the process forks into a daemon. The problem I'm seeing is that the forked process received a SIGTERM signal and exited. How do I resolve this so that the forked process would not get terminated. # systemctl status smartd.service smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/usr/lib/systemd/system/smartd.service; enabled) Active: failed (Result: timeout) since Thu 2015-04-02 17:19:49 GMT; 4min 39s ago Docs: man:smartd(8) man:smartd.conf(5) Process: 7456 ExecStart=/usr/sbin/smartd $smartd_opts (code=exited, status=0/SUCCESS) Process: 7454 ExecStartPre=/bin/rm -f /run/smartd.pid (code=exited, status=0/SUCCESS) Main PID: 1075 (code=exited, status=0/SUCCESS) Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], opened Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], [TOSHIBA MG03SCA300 5702], lu 00 TB Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], is SMART capable. Adding to monitor list. Apr 02 17:18:20 007 smartd[7456]: Monitoring 0 ATA and 12 SCSI devices Apr 02 17:18:21 007 systemd[1]: PID file /run/smartd.pid not readable (yet?) after start. Apr 02 17:18:21 007 smartd[7463]: smartd has fork()ed into background mode. New PID=7463. Apr 02 17:19:49 007 systemd[1]: smartd.service operation timed out. Terminating. There are to possibilities - smartd main process does not exit after fork. Check with systemd-cgls immediately after systemctl start. - PID file is not created with path systemd expects Apr 02 17:19:49 007 smartd[7463]: smartd received signal 15: Terminated Apr 02 17:19:49 007 systemd[1]: Failed to start Self Monitoring and Reporting Technology (SMART) Daemon. Apr 02 17:19:49 007 systemd[1]: Unit smartd.service entered failed state. Hint: Some lines were ellipsized, use -l to show in full. # To verify, I take the /usr/sbin/smartd $smartd_opts and run it from the command line. The smartd daemon forks and the daemon process stays up as expected. Thanks, -Al ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and smartd daemon
I am seeking help and advise on troubleshooting the starting of the smartd daemon. The /usr/sbin/smartd comes from the smartmontools version 6.3. and the systemd unit si from where? The /usr/lib/systemd/system/smartd.service file looks like this and is wrong # cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon Documentation=man:smartd(8) man:smartd.conf(5) After=syslog.target [Service] Type=forking PIDFile=/run/smartd.pid ExecStartPre=/bin/rm -f /run/smartd.pid EnvironmentFile=/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd $smartd_opts ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog [Install] WantedBy=multi-user.target When systemctl start smartd.service is called, the process forks into a daemon. The problem I'm seeing is that the forked process received a SIGTERM signal and exited. How do I resolve this so that the forked process would not get terminated no, it don't forke which is the reason it got killed, look below: the fedora systemd-unit is using default which implies Type=simple [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon After=syslog.target [Service] EnvironmentFile=-/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd -n $smartd_opts ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and smartd daemon
The main process does not show up in the ps and only the forked process shows up. The systemd-cgls shows │ ├─session-14613.scope │ │ ├─ 1577 sshd: root@pts/4 │ │ ├─ 1676 -bash │ │ ├─16792 systemctl start smartd │ │ └─16793 /usr/bin/systemd-tty-ask-password-agent --watch └─system.slice ├─smartd.service │ └─16800 /usr/sbin/smartd --interval=3600 --configfile=/etc/smartd.conf I think the PIDFile is optional. Commenting out the PIDfile line does not help. What else can I try? Thanks, -Al On Thu, Apr 2, 2015 at 10:57 AM, Andrei Borzenkov arvidj...@gmail.com wrote: В Thu, 2 Apr 2015 10:43:00 -0700 Al Lau laua...@gmail.com пишет: Hi, I am seeking help and advise on troubleshooting the starting of the smartd daemon. The /usr/sbin/smartd comes from the smartmontools version 6.3. The /usr/lib/systemd/system/smartd.service file looks like this # cat /usr/lib/systemd/system/smartd.service [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon Documentation=man:smartd(8) man:smartd.conf(5) After=syslog.target [Service] Type=forking PIDFile=/run/smartd.pid ExecStartPre=/bin/rm -f /run/smartd.pid EnvironmentFile=/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd $smartd_opts ExecReload=/bin/kill -HUP $MAINPID StandardOutput=syslog [Install] WantedBy=multi-user.target When systemctl start smartd.service is called, the process forks into a daemon. The problem I'm seeing is that the forked process received a SIGTERM signal and exited. How do I resolve this so that the forked process would not get terminated. # systemctl status smartd.service smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/usr/lib/systemd/system/smartd.service; enabled) Active: failed (Result: timeout) since Thu 2015-04-02 17:19:49 GMT; 4min 39s ago Docs: man:smartd(8) man:smartd.conf(5) Process: 7456 ExecStart=/usr/sbin/smartd $smartd_opts (code=exited, status=0/SUCCESS) Process: 7454 ExecStartPre=/bin/rm -f /run/smartd.pid (code=exited, status=0/SUCCESS) Main PID: 1075 (code=exited, status=0/SUCCESS) Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], opened Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], [TOSHIBA MG03SCA300 5702], lu 00 TB Apr 02 17:18:20 007 smartd[7456]: Device: /dev/bus/0 [megaraid_disk_19], is SMART capable. Adding to monitor list. Apr 02 17:18:20 007 smartd[7456]: Monitoring 0 ATA and 12 SCSI devices Apr 02 17:18:21 007 systemd[1]: PID file /run/smartd.pid not readable (yet?) after start. Apr 02 17:18:21 007 smartd[7463]: smartd has fork()ed into background mode. New PID=7463. Apr 02 17:19:49 007 systemd[1]: smartd.service operation timed out. Terminating. There are to possibilities - smartd main process does not exit after fork. Check with systemd-cgls immediately after systemctl start. - PID file is not created with path systemd expects Apr 02 17:19:49 007 smartd[7463]: smartd received signal 15: Terminated Apr 02 17:19:49 007 systemd[1]: Failed to start Self Monitoring and Reporting Technology (SMART) Daemon. Apr 02 17:19:49 007 systemd[1]: Unit smartd.service entered failed state. Hint: Some lines were ellipsized, use -l to show in full. # To verify, I take the /usr/sbin/smartd $smartd_opts and run it from the command line. The smartd daemon forks and the daemon process stays up as expected. Thanks, -Al ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
