Re: [systemd-devel] The whole su/pkexec session debate
Hi On Mon, Dec 2, 2013 at 8:17 PM, Colin Walters walt...@verbum.org wrote: On Mon, 2013-12-02 at 14:37 +0100, David Herrmann wrote: But then gnome-session should simply call ReleaseSession() on the bus itself.. I'd rather have some sort of API where a particular process is the session leader, and its exit implies closing. Something like a pid file in /run/systemd/sessions/c0/leader/pid which is owned by the session's uid/gid? There is no sane way to watch for specific childs in systemd-logind. We don't have a childfd(2) call or poll(2) on /proc/pid... So we usually just apply this policy on the first process in a session (which we get SIGCHLD for). Once it exists, we mark the session as closing. I think that's a good compromise. But for the ssh case we'd need something to inhibit this behavior. Like a bus call Session.KeepOpen() which keeps the session open until the caller closes the bus-connection. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Last question about systemd before my presentation
Partial answer: On Dec 5, 2013 8:40 AM, Cecil Westerhof cecil.wester...@snow.nl wrote: Today I am giving my presentation about systemd/journald for a not very enthusiastic public. I would like some last answers on a ‘few’ questions. I understood that you could let systemd start-up the services sequential for debugging purposes. How is that done? Is it possible to change the limits dynamically? When I change the service files and do a reload, are the new limits used, without a reboot being needed? One of the problems mentioned is that services can be started only when they are used for the first time. As I understood it, you can make sure that a service is always loaded, so that there is no waiting time the first time it is called. This is not a problem. This is a configuration choice. If the service supports activation, you *can* let it be activated if that suits you, but you can also configure it to be started on boot as any other service (i.e. make multi-user.target depend on the service directly). Note that activation benefits even boot-started services, because their sockets still become available very early, while the service's startup is still pending. Various existing services already run this way - e.g. dbus.service always starts on boot, but it is *also* activated, so all other programs can connect to it without a failure and the kernel will queue up connections. Also note that this is not new in systemd. DBus has always worked this way - if program X sends a message to DBus service Y, dbus-daemon starts Y on demand. I understood you could deny a service network connection. How is this done? Until no I could not find it. Is it possible to limit the bandwidth a service is allowed to use? PrivateNetwork=yes will create a dedicated net namespace for that service, which does not have any network interfaces by default. (Relevant man pages: clone, unshare, setns, nsenter; LXC also uses this.) When virtual machines are implementd as a service. You need to let the host define the limits per guest I suppose? How do you let a block-device be read-only for a service? Any last tips about what to share? -- Cecil Westerhof Snow B.V. ___ 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] Last question about systemd before my presentation
On 12/05/2013 10:08 AM, Mantas Mikulėnas wrote: One of the problems mentioned is that services can be started only when they are used for the first time. As I understood it, you can make sure that a service is always loaded, so that there is no waiting time the first time it is called. This is not a problem. This is a configuration choice. If the service supports activation, you *can* let it be activated if that suits you, but you can also configure it to be started on boot as any other service (i.e. make multi-user.target depend on the service directly). OK, when I use: [Install] WantedBy=multi-user.target What I did until now, the service is just started. When I do not use it, only a socket is made and it is started the first time it is used. Correct? When a service is started because it was used (loaded on the first use), does it keeps running, or is it unloaded after some time? Or can this be configured? I understood you could deny a service network connection. How is this done? Until no I could not find it. Is it possible to limit the bandwidth a service is allowed to use? PrivateNetwork=yes will create a dedicated net namespace for that service, which does not have any network interfaces by default. (Relevant man pages: clone, unshare, setns, nsenter; LXC also uses this.) OK, it is an on/off switch. There is not a possibility to limit the bandwidth? Met vriendelijke groet, Cecil Westerhof Engineer mobiel +31 - 6 - 25 00 38 81 -- Snow B.V. Unix Specialists De Ooyen 11 4191 PB Geldermalsen http://www.snow.nl tel. +31 - 345 - 65 66 66 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Last question about systemd before my presentation
On Dec 5, 2013 11:27 AM, Cecil Westerhof cecil.wester...@snow.nl wrote: On 12/05/2013 10:08 AM, Mantas Mikulėnas wrote: One of the problems mentioned is that services can be started only when they are used for the first time. As I understood it, you can make sure that a service is always loaded, so that there is no waiting time the first time it is called. This is not a problem. This is a configuration choice. If the service supports activation, you *can* let it be activated if that suits you, but you can also configure it to be started on boot as any other service (i.e. make multi-user.target depend on the service directly). OK, when I use: [Install] WantedBy=multi-user.target What I did until now, the service is just started. When I do not use it, only a socket is made and it is started the first time it is used. Correct? Mostly, yes. All units of all types can have an [Install] section for 'systemctl enable', they can be permanently enabled if the package installs them to foobar.target.wants/, etc. (For example, sockets usually have WantedBy=sockets.target) In other words, you're correct but should remember that a .socket has to be enabled too, just like any other unit. When a service is started because it was used (loaded on the first use), does it keeps running, or is it unloaded after some time? Or can this be configured? systemd has no way of knowing when the service becomes idle, therefore the service itself must be programmed to exit when unneeded. (Meanwhile, with inetd-style aka Accept=yes services, there is exactly one instance per connection, so if there are no connections, there aren't any instances either.) I understood you could deny a service network connection. How is this done? Until no I could not find it. Is it possible to limit the bandwidth a service is allowed to use? PrivateNetwork=yes will create a dedicated net namespace for that service, which does not have any network interfaces by default. (Relevant man pages: clone, unshare, setns, nsenter; LXC also uses this.) OK, it is an on/off switch. There is not a possibility to limit the bandwidth? It might be possible, by moving a virtual interface (veth) into the same namespace, then bridging it with eth0, and setting up traffic shaping or something. But network namespaces are meant to provide separation, so extra features probably were not part of the original design... (Does LXC support this?) Met vriendelijke groet, Cecil Westerhof Engineer mobiel +31 - 6 - 25 00 38 81 -- Snow B.V. Unix Specialists De Ooyen 11 4191 PB Geldermalsen http://www.snow.nl tel. +31 - 345 - 65 66 66 ___ 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] systemd unit review requested
On 12/05/2013 06:50 AM, Peter Hutterer wrote: ExecStartPre=/usr/sbin/modprobe wacom_w8001 Add a configuration file called wacom-w8001.conf to /etc/modules-load.d directory with the following content to load the module ( /etc/modules-load.d/wacom-w8001.conf ) # Load wacom_w8001 at boot wacom_w8001 If necessary add any additional module options to same named file under /etc/modprobe.d directory if necessary as in... ( /etc/modprobe.d/wacom-w8001.conf ) #Wacom w8001 module options options foo bar Never use a systemd unit to call modprobe. Each time you do so someone's beer goes flat... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH] bus: Add destination field to sd_bus_message_new_signal() and sd_bus_emit_signal()
destination - the unique bus name for the destination for the signal
or NULL to emit to all listeners.
This path makes libsystemd-bus API more consistent and similar
to GDBUS API, for reference:
gboolean g_dbus_connection_emit_signal (GDBusConnection *connection,
const gchar *destination_bus_name,
const gchar *object_path,
const gchar *interface_name,
const gchar *signal_name,
GVariant *parameters,
GError **error);
---
src/cgroups-agent/cgroups-agent.c | 1 +
src/core/dbus-job.c| 6 --
src/core/dbus-manager.c| 12 ++--
src/core/dbus-unit.c | 6 --
src/core/dbus.c| 4 ++--
src/libsystemd-bus/bus-convenience.c | 3 ++-
src/libsystemd-bus/bus-kernel.c| 1 +
src/libsystemd-bus/bus-message.c | 8
src/libsystemd-bus/bus-objects.c | 6 +++---
src/libsystemd-bus/sd-bus.c| 1 +
src/libsystemd-bus/test-bus-chat.c | 1 +
src/libsystemd-bus/test-bus-kernel-bloom.c | 2 +-
src/libsystemd-bus/test-bus-kernel.c | 2 +-
src/libsystemd-bus/test-bus-match.c| 2 +-
src/login/logind-dbus.c| 1 +
src/login/logind-seat-dbus.c | 1 +
src/login/logind-session-dbus.c| 2 ++
src/login/logind-session-device.c | 8 +++-
src/login/logind-user-dbus.c | 1 +
src/machine/machine-dbus.c | 1 +
src/systemd/sd-bus.h | 4 ++--
21 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/src/cgroups-agent/cgroups-agent.c
b/src/cgroups-agent/cgroups-agent.c
index d1d843b..8c7237f 100644
--- a/src/cgroups-agent/cgroups-agent.c
+++ b/src/cgroups-agent/cgroups-agent.c
@@ -53,6 +53,7 @@ int main(int argc, char *argv[]) {
}
r = sd_bus_emit_signal(bus,
+ NULL,
/org/freedesktop/systemd1/agent,
org.freedesktop.systemd1.Agent,
Released,
diff --git a/src/core/dbus-job.c b/src/core/dbus-job.c
index 8c12b52..c689751 100644
--- a/src/core/dbus-job.c
+++ b/src/core/dbus-job.c
@@ -137,6 +137,7 @@ static int send_new_signal(sd_bus *bus, const char
*destination, Job *j) {
r = sd_bus_message_new_signal(
bus,
+destination,
/org/freedesktop/systemd1,
org.freedesktop.systemd1.Manager,
JobNew,
@@ -148,7 +149,7 @@ static int send_new_signal(sd_bus *bus, const char
*destination, Job *j) {
if (r 0)
return r;
-return sd_bus_send_to(bus, m, destination, NULL);
+return sd_bus_send(bus, m, NULL);
}
static int send_changed_signal(sd_bus *bus, const char *destination, Job *j) {
@@ -196,6 +197,7 @@ static int send_removed_signal(sd_bus *bus, const char
*destination, Job *j) {
r = sd_bus_message_new_signal(
bus,
+destination,
/org/freedesktop/systemd1,
org.freedesktop.systemd1.Manager,
JobRemoved,
@@ -207,7 +209,7 @@ static int send_removed_signal(sd_bus *bus, const char
*destination, Job *j) {
if (r 0)
return r;
-return sd_bus_send_to(bus, m, destination, NULL);
+return sd_bus_send(bus, m, NULL);
}
void bus_job_send_removed_signal(Job *j) {
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index a2707ee..718d383 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -1338,11 +1338,11 @@ static int send_unit_files_changed(sd_bus *bus, const
char *destination, void *u
assert(bus);
-r = sd_bus_message_new_signal(bus, /org/freedesktop/systemd1,
org.freedesktop.systemd1.Manager, UnitFilesChanged, message);
+r = sd_bus_message_new_signal(bus, destination,
/org/freedesktop/systemd1, org.freedesktop.systemd1.Manager,
UnitFilesChanged, message);
if (r 0)
return r;
-return sd_bus_send_to(bus, message, destination, NULL);
+return sd_bus_send(bus, message, NULL);
}
static int reply_unit_file_changes_and_free(
@@ -1668,7 +1668,7 @@ static int send_finished(sd_bus *bus, const char
*destination, void *userdata) {
assert(bus);
assert(times);
-r = sd_bus_message_new_signal(bus, /org/freedesktop/systemd1,
org.freedesktop.systemd1.Manager, StartupFinished, message);
+r = sd_bus_message_new_signal(bus, destination,
/org/freedesktop/systemd1,
Re: [systemd-devel] systemd unit review requested
2013/12/5 Jóhann B. Guðmundsson johan...@gmail.com: On 12/05/2013 06:50 AM, Peter Hutterer wrote: ExecStartPre=/usr/sbin/modprobe wacom_w8001 Add a configuration file called wacom-w8001.conf to /etc/modules-load.d directory with the following content to load the module ( /etc/modules-load.d/wacom-w8001.conf ) # Load wacom_w8001 at boot wacom_w8001 Well, this loads the kernel module unconditionally, though. Even for users which don't have that hardware. So this approach isn't that great. It also depends on the wacom_w8001 and how it reacts when it's loaded and no hardware is present. Peter, couldn't this module be autoloaded? Michael -- 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] [RFC][PATCH] bus: Add destination field to sd_bus_message_new_signal() and sd_bus_emit_signal()
On 05/12/13 12:13, Lukasz Skalski wrote: destination - the unique bus name for the destination for the signal or NULL to emit to all listeners. This is rarely-needed functionality, but sometimes necessary. If anyone is going to replicate the client-facing functionality of the dbus-daemon using libsystemd-bus, you'll need this for NameAcquired and NameLost; and I've seen other real-world APIs where unicast signals were also desirable. Depending where you want to be on a scale from maximally flexible to promote the common case, and make the rare case slightly tedious you could either add the parameter all the time as in Lucasz' patch, or go for something more like this to encourage those in doubt to use the more conventional broadcast signals: int sd_bus_message_new_signal(sd_bus *bus, const char *path, const char *interface, const char *member, sd_bus_message **m); int sd_bus_message_new_unicast_signal(sd_bus *bus, const char *destination, /* must be non-NULL */ const char *path, const char *interface, const char *member, sd_bus_message **m); Regards, S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On 12/05/2013 12:28 PM, Michael Biebl wrote:
2013/12/5 Jóhann B. Guðmundssonjohan...@gmail.com:
On 12/05/2013 06:50 AM, Peter Hutterer wrote:
ExecStartPre=/usr/sbin/modprobe wacom_w8001
Add a configuration file called wacom-w8001.conf to /etc/modules-load.d
directory with the following content to load the module
( /etc/modules-load.d/wacom-w8001.conf )
# Load wacom_w8001 at boot
wacom_w8001
Well, this loads the kernel module unconditionally, though. Even for
users which don't have that hardware. So this approach isn't that
great.
It also depends on the wacom_w8001 and how it reacts when it's loaded
and no hardware is present.
Peter, couldn't this module be autoloaded?
I'm not that familiar with udev policy regarding rules rule but I would
think that if you autoload module you tie the startup of the systemd
unit to the module being loaded ( if the intent is to trigger a unit )
So we need an udev wacom-serial-driver rule that might look like this
for the wacom serial devices
ACTION==remove, GOTO=drivers_end
ENV{MODALIAS}==?*, RUN{builtin}=kmod load $env{MODALIAS}
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==WACf*,
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
,RUN{builtin}=kmod load wacom_w8001
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==FUJ*,
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
,RUN{builtin}=kmod load wacom_w8001
LABEL=drivers_end
Followed by an systemd rule that looks something like this
SUBSYSTEM==module, KERNEL==wacom*, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=wacom-inputattach@%k.service
And the modprobe would be dropped from that unit file but as I say I'm
not all that familiar with udev policy rules and I personally had not
planned on mastering udev until I started the cleanup process in Fedora
which might never happen today thanks to the that WG process.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Never use a systemd unit to call modprobe. And, even if you did, modprobe would be Type=oneshot (maybe also with RemainAfterExit=true), definitely not Type=simple. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] bus: Add destination field to sd_bus_message_new_signal() and sd_bus_emit_signal()
On Thu, 05.12.13 13:13, Lukasz Skalski (l.skal...@partner.samsung.com) wrote: destination - the unique bus name for the destination for the signal or NULL to emit to all listeners. This path makes libsystemd-bus API more consistent and similar to GDBUS API, for reference: Hmm, I thought about this for a while. And decided not do that since setting a destination is certainly the exception not the rule, and a very seldom exception. And we do cover this by allowing people to create the message first, then attach the destination to it, and then send it. In fact I recently went through the API and tried to get rid of all parameters that I could get rid of, that I felt weren't really necessary. I am pretty sure I don't want to reverse this... Sorry, but this really was a concious decision. 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] [RFC][PATCH] bus: Add destination field to sd_bus_message_new_signal() and sd_bus_emit_signal()
On Thu, 05.12.13 13:09, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 05/12/13 12:13, Lukasz Skalski wrote: destination - the unique bus name for the destination for the signal or NULL to emit to all listeners. This is rarely-needed functionality, but sometimes necessary. If anyone is going to replicate the client-facing functionality of the dbus-daemon using libsystemd-bus, you'll need this for NameAcquired and NameLost; and I've seen other real-world APIs where unicast signals were also desirable. Note that libsystemd-bus when used on top of kdbus actually gets rid of NameLost/NameAcquired. They are entirely redundant due to NameOwnerChanged, and people should just use that. libsystemd-bus when used against dbus-daemon will still get these though. And the compat proxy will fake them in too, so that dbus1 clients continue to work. BTW, I started documenting the differences between dbus1 and kdbus a bit here: http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/DIFFERENCES We also want to enforce gvariant native endian marshalling on kdbus, and I documented how we map things to the old structures then: http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/GVARIANT-SERIALIZATION I just put those docs together yesterday. Eventually I'll submit them for the dbus spec. This makes no attempt of establishing gvariant as an alternative marshalling on socket connections, it's only focussed on kdbus transports so far. We could allow it on sockets too though, but this requires explicit nego to stay compatible. Either way systemd-bus-proxyd will do the necessary remarshalling when connecting dbus1 clients to kdbus. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: fix buggy mount_binds, now works for bind-mounted files
---
src/nspawn/nspawn.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index dd7337b..c1212c0 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -416,6 +416,7 @@ static int mount_all(const char *dest) {
static int mount_binds(const char *dest, char **l, unsigned long flags) {
char **x, **y;
+int r;
STRV_FOREACH_PAIR(x, y, l) {
_cleanup_free_ char *where = NULL;
@@ -426,31 +427,40 @@ static int mount_binds(const char *dest, char **l,
unsigned long flags) {
return -errno;
}
-where = strjoin(dest, /, *y, NULL);
+where = strjoin(dest, *y, NULL);
if (!where)
return log_oom();
-if (stat(where, dest_st) == 0) {
+r = stat(where, dest_st);
+if (r == 0) {
if ((source_st.st_mode S_IFMT) != (dest_st.st_mode
S_IFMT)) {
log_error(The file types of %s and %s do not
match. Refusing bind mount,
*x, where);
return -EINVAL;
}
-} else {
-/* Create the mount point, but be conservative --
refuse to create block
- * and char devices. */
-if (S_ISDIR(source_st.st_mode))
-mkdir_p_label(where, 0755);
-else if (S_ISFIFO(source_st.st_mode))
-mkfifo(where, 0644);
-else if (S_ISSOCK(source_st.st_mode))
-mknod(where, 0644 | S_IFSOCK, 0);
-else if (S_ISREG(source_st.st_mode))
-touch(where);
-else {
-log_error(Refusing to create mountpoint for
file: %s, *x);
-return -ENOTSUP;
+} else if (errno == ENOENT) {
+r = mkdir_parents_label(where, 0755);
+if (r 0) {
+log_error(Failed to bind mount %s: %s, *x,
strerror(-r));
+return r;
}
+} else {
+log_error(Failed to bind mount %s: %s, *x,
strerror(errno));
+return -errno;
+}
+/* Create the mount point, but be conservative -- refuse to
create block
+* and char devices. */
+if (S_ISDIR(source_st.st_mode))
+mkdir_label(where, 0755);
+else if (S_ISFIFO(source_st.st_mode))
+mkfifo(where, 0644);
+else if (S_ISSOCK(source_st.st_mode))
+mknod(where, 0644 | S_IFSOCK, 0);
+else if (S_ISREG(source_st.st_mode))
+touch(where);
+else {
+log_error(Refusing to create mountpoint for file:
%s, *x);
+return -ENOTSUP;
}
if (mount(*x, where, bind, MS_BIND, NULL) 0) {
--
1.8.5.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: fix misuse of memcmp
---
src/shared/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index b4ed2c4..d685966 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5919,7 +5919,7 @@ int shall_restore_state(void) {
return 1;
FOREACH_WORD_QUOTED(w, l, line, state)
-if (l == 23 memcmp(w, systemd.restore_state=0, 23))
+if (l == 23 memcmp(w, systemd.restore_state=0, 23) == 0)
return 0;
return 1;
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On 12/05/2013 01:57 PM, David Timothy Strauss wrote: On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Never use a systemd unit to call modprobe. And, even if you did, modprobe would be Type=oneshot (maybe also with RemainAfterExit=true), definitely not Type=simple. You never and I mean never should load or unload modules in systemd units so it's irrelevant what those type should be. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 05, 2013 at 04:50:54PM +1000, Peter Hutterer wrote:
the new rule now is:
SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd
And the matching wacom-inputattach@.service file shows:
[Unit]
Description=Start inputattach for Wacom ISDv4-compatible serial devices
[Service]
Type=simple
ExecStartPre=/usr/sbin/modprobe wacom_w8001
ExecStart=/usr/bin/inputattach -w8001 /dev/%I
Anything I'm missing, anything I should change?
Looks OK, except for the question where the module should be loaded from,
discussed in the other part of this thread.
Also, do I need this in any target, or is dropping this into
/usr/lib/systemd/system/ enough?
Yes, but wait until https://bugzilla.redhat.com/show_bug.cgi?id=1026860
is fixed (hopefully today).
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
'Twas brillig, and Jóhann B. Guðmundsson at 05/12/13 14:30 did gyre and gimble: On 12/05/2013 01:57 PM, David Timothy Strauss wrote: On Thu, Dec 5, 2013 at 3:53 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Never use a systemd unit to call modprobe. And, even if you did, modprobe would be Type=oneshot (maybe also with RemainAfterExit=true), definitely not Type=simple. You never and I mean never should load or unload modules in systemd units so it's irrelevant what those type should be. The above statement not withstanding, but the Type and RemainAfterExit applies only to ExecStart. This unit calls modprobe in ExecStartPre which is always expected to do something and return. So this branch of the thread really doesn't apply to this unit. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 05, 2013 at 04:27:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 05, 2013 at 04:50:54PM +1000, Peter Hutterer wrote:
the new rule now is:
SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd
And the matching wacom-inputattach@.service file shows:
[Unit]
Description=Start inputattach for Wacom ISDv4-compatible serial devices
This will be displayed as Starting Start inputattach for Wacom
ISDv4-compatible serial devices, and later Stopping Start
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 5, 2013 at 7:29 AM, Colin Guthrie gm...@colin.guthr.ie wrote: The above statement not withstanding, but the Type and RemainAfterExit applies only to ExecStart. This unit calls modprobe in ExecStartPre which is always expected to do something and return. So this branch of the thread really doesn't apply to this unit. Oh, indeed. I misread the unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On 5 Dec 2013 07:48, Peter Hutterer peter.hutte...@who-t.net wrote:
When I fired up F20 on one of my laptops here I noticed that inputattach
doesn't work anymore for serial Wacom devices. It used to be started
through
udev, but that doesn't work anymore. So moving to a systemd service it is,
but I'd like a review of the changes please.
The goal is to start inputattach for a serial Wacom device if the pnpid
matches a certain set. The old udev rule was:
SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
RUN+=/usr/sbin/modprobe wacom_w8001, \
RUN+=/usr/sbin/inputattach --daemon -w8001 /dev/%k
the new rule now is:
SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd
And the matching wacom-inputattach@.service file shows:
[Unit]
Description=Start inputattach for Wacom ISDv4-compatible serial devices
[Service]
Type=simple
ExecStartPre=/usr/sbin/modprobe wacom_w8001
Seems like this should be auto loaded? If not, you might want to load it
directly from the udev rule using the kmod built-in.
Cheers,
Tom
ExecStart=/usr/bin/inputattach -w8001 /dev/%I
Anything I'm missing, anything I should change?
Also, do I need this in any target, or is dropping this into
/usr/lib/systemd/system/ enough?
Thanks in advance.
Cheers,
Peter
~
___
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
[systemd-devel] [PATCH] test: add run-qemu script
from Alexander Graf's script: http://www.spinics.net/lists/kvm/msg72389.html
---
Hi,
It adds a little script which try to find a QEMU binary on the system and
enable kvm if it's available. This script is used when running QEMU in the
tests. (We can also specify a different kernel and initramfs)
Ronny
TODO| 1 -
test/README.testsuite | 19 -
test/TEST-01-BASIC/test.sh | 6 +-
test/TEST-02-CRYPTSETUP/test.sh | 6 +-
test/TEST-03-JOBS/test.sh | 6 +-
test/run-qemu.sh| 150
test/test-functions | 10 +--
7 files changed, 170 insertions(+), 28 deletions(-)
create mode 100755 test/run-qemu.sh
diff --git a/TODO b/TODO
index 9698082..f493dbb 100644
--- a/TODO
+++ b/TODO
@@ -168,7 +168,6 @@ Features:
* test/:
- add 'set -e' to scripts in test/
- make stuff in test/ work with separate output dir
- - qemu wrapper script: http://www.spinics.net/lists/kvm/msg72389.html
* systemctl delete x.snapshot leaves no trace in logs (at least at default
level).
diff --git a/test/README.testsuite b/test/README.testsuite
index 54d0eaa..3b841cd 100644
--- a/test/README.testsuite
+++ b/test/README.testsuite
@@ -25,11 +25,24 @@ $ make all
$ cd test/TEST-01-BASIC
$ sudo make clean setup run
+QEMU
+
+
If you want to log in the testsuite virtual machine, you can specify
-additional kernel command line parameter with $DEBUGFAIL.
+additional kernel command line parameter with $KERNEL_APPEND.
-$ sudo make DEBUGFAIL=systemd.unit=multi-user.target clean setup run
+$ sudo make KERNEL_APPEND=systemd.unit=multi-user.target clean setup run
you can even skip the clean and setup if you want to run the machine again.
-$ sudo make DEBUGFAIL=systemd.unit=multi-user.target run
+$ sudo make KERNEL_APPEND=systemd.unit=multi-user.target run
+
+You can specify a different kernel and initramfs with $KERNEL_BIN and $INITRD.
+(Fedora's default kernel path and initramfs are used by default)
+
+$ sudo make KERNEL_BIN=/boot/vmlinuz-foo INITRD=/boot/initramfs-bar clean check
+
+A script will try to find your QEMU binary. If you want to specify a different
+one you can use $QEMU_BIN.
+
+$ sudo make QEMU_BIN=/path/to/qemu/qemu-kvm clean check
diff --git a/test/TEST-01-BASIC/test.sh b/test/TEST-01-BASIC/test.sh
index aaf63f4..c598af9 100755
--- a/test/TEST-01-BASIC/test.sh
+++ b/test/TEST-01-BASIC/test.sh
@@ -5,9 +5,6 @@ TEST_DESCRIPTION=Basic systemd setup
. $TEST_BASE_DIR/test-functions
-# Uncomment this to debug failures
-#DEBUGFAIL=systemd.unit=multi-user.target
-
check_result_qemu() {
ret=1
mkdir -p $TESTDIR/root
@@ -23,8 +20,7 @@ check_result_qemu() {
}
test_run() {
-if check_qemu ; then
-run_qemu
+if run_qemu; then
check_result_qemu || return 1
else
dwarn can't run qemu-kvm, skipping
diff --git a/test/TEST-02-CRYPTSETUP/test.sh b/test/TEST-02-CRYPTSETUP/test.sh
index 86617df..b9161e7 100755
--- a/test/TEST-02-CRYPTSETUP/test.sh
+++ b/test/TEST-02-CRYPTSETUP/test.sh
@@ -5,9 +5,6 @@ TEST_DESCRIPTION=cryptsetup systemd setup
. $TEST_BASE_DIR/test-functions
-# Uncomment this to debug failures
-#DEBUGFAIL=systemd.unit=multi-user.target
-
check_result_qemu() {
ret=1
mkdir -p $TESTDIR/root
@@ -28,8 +25,7 @@ check_result_qemu() {
test_run() {
-if check_qemu ; then
-run_qemu
+if run_qemu; then
check_result_qemu || return 1
else
dwarn can't run qemu-kvm, skipping
diff --git a/test/TEST-03-JOBS/test.sh b/test/TEST-03-JOBS/test.sh
index 6303258..9190eb0 100755
--- a/test/TEST-03-JOBS/test.sh
+++ b/test/TEST-03-JOBS/test.sh
@@ -5,9 +5,6 @@ TEST_DESCRIPTION=Job-related tests
. $TEST_BASE_DIR/test-functions
-# Uncomment this to debug failures
-#DEBUGFAIL=systemd.unit=multi-user.target
-
check_result_qemu() {
ret=1
mkdir -p $TESTDIR/root
@@ -23,8 +20,7 @@ check_result_qemu() {
}
test_run() {
-if check_qemu ; then
-run_qemu
+if run_qemu; then
check_result_qemu || return 1
else
dwarn can't run qemu-kvm, skipping
diff --git a/test/run-qemu.sh b/test/run-qemu.sh
new file mode 100755
index 000..17708da
--- /dev/null
+++ b/test/run-qemu.sh
@@ -0,0 +1,150 @@
+#!/bin/bash
+#
+# based on: http://www.spinics.net/lists/kvm/msg72389.html
+#
+
+# Uncomment this to debug failures
+#KERNEL_APPEND=systemd.unit=multi-user.target
+KERNEL_VER=${KERNEL_VER-$(uname -r)}
+[ $KERNEL_BIN ] || KERNEL_BIN=/boot/vmlinuz-$KERNEL_VER
+[ $INITRD ] || INITRD=/boot/initramfs-${KERNEL_VER}.img
+[ $SMP ] || SMP=1
+BASENAME=$(basename $0)
+IMAGE=
+
+function usage() {
+echo $BASENAME IMAGE -- [QEMU_OPTIONS]
+}
+
+function verify_qemu() {
+QEMU=$(which $1 2/dev/null)
+
+# binary exists?
+[ -x $QEMU ] || exit 1
+
+# we need a version that knows -machine
+if ! $QEMU --help | grep -q -- '-machine'; then
+exit 1
+fi
+
+echo $QEMU
+
[systemd-devel] ptyfwd (nspawn): Correctly handle output redirection
Ping http://lists.freedesktop.org/archives/systemd-devel/2013-November/thread.html#14661 Happy hacking, ~ Luke Shumaker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] help with dependicies
Hello I have four unit files. 1. xxx.target 2. tmp-testy.mount 3. tmp-testy_ro.mount 4. temp-testy_rw.mount I want the xxx.target to automatically start the three .mount unit files on boot. Item, 2. tmp-testy is a union mount of the two unit files 3. and 4. In order to get this to work, I have to specify all three .mount files in the requires= and after= sections in the .target unit file. I was thinking that I would only need to specify item 2. in the xxx.target unit file and that item 2. would specify it needed item 3 and 4. However this does not work. Here are the contents of the four unit files, at the end is a unit file as it works and how I thought it would work, but alas is does not. [root@xxx ~]# cat /lib/systemd/system/tmp-testy.mount [Unit] Description=The /tmp/testy unionfs Directory Before=local-fs.target [Mount] What=funionfs#none Where=/tmp/testy Type=fuse FsckPassNo=0 Options=dirs=/tmp/testy_ro=RO:/tmp/testy_rw,allow_other,nonempty Requires=tmp-testy_ro.mount tmp-testy_rw.mount After=tmp-testy_ro.mount tmp-testy_rw.mount = [root@xxx ~]# cat /lib/systemd/system/tmp-testy_ro.mount [Unit] Description=Mount control of testy_ro Directory Before=tmp-testy.mount [Mount] Where=/tmp/testy_ro What=/tmp/mnt/hp_tools/Hewlett-Packard/HV/testy-ro.bin Options=loop,ro = [root@ ~]# cat /lib/systemd/system/tmp-testy_rw.mount [Unit] Description=Mount control of testy_rw Directory Before=tmp-testy.mount [Mount] Where=/tmp/testy_rw What=tmpfs Type=tmpfs Options=size=1M,nr_inodes=1k,mode=755 = This works [root@ ~]# cat /lib/systemd/system/xxx.target [Unit] Description=x System Documentation=man:systemd.special(7) Requires=tmp-testy_rw.mount tmp-testy_ro.mount tmp-testy.mount etc.mount Wants=sshd.service After=tmp-testy_rw.mount tmp-testy_ro.mount tmp-testy.mount etc.mount RefuseManualStart=yes [root@xxx ~]# This does not. It will mount /tmp/testy but /tmp/testy_ro and /tmp/testy_rw will not be mounted. [root@ ~]# cat /lib/systemd/system/xxx2.target [Unit] Description=x System Documentation=man:systemd.special(7) Requires=tmp-testy.mount etc.mount Wants=sshd.service After=tmp-testy.mount etc.mount RefuseManualStart=yes [root@xxx ~]# -- John F. Davis 6 Kandes Court Durham, NC 27713 919-888-8358 独树一帜 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Last question about systemd before my presentation
On Thu, 05.12.13 07:40, Cecil Westerhof (cecil.wester...@snow.nl) wrote: Today I am giving my presentation about systemd/journald for a not very enthusiastic public. I would like some last answers on a ‘few’ questions. I understood that you could let systemd start-up the services sequential for debugging purposes. How is that done? Nope you cannot. If a service A starts up, and requests a service B and needs it for initilization you need to start that too, while you are still initializing A. There's no way around it. This is why we do not allow serialization of the startup in systemd. However, you can enable systemd.confirm_spawn=1 on the kernel cmdline and then you get a question asked each time systemd is about to start something. Is it possible to change the limits dynamically? When I change the service files and do a reload, are the new limits used, without a reboot being needed? You can change cgroup limits at runtime using systemctl set-property. Classic UNIX resource limits however are only applied when a process is started, not later on. I understood you could deny a service network connection. How is this done? Until no I could not find it. Using network namespacing. See PrivateNetwork=yes in systemd.exec(5). Is it possible to limit the bandwidth a service is allowed to use? systemd won't help you doing that. When virtual machines are implementd as a service. You need to let the host define the limits per guest I suppose? Not following? You can pack as many services in a slice as you want, and you can create a tree of slices, so that you can run a couple of services against a common set of resource limits. How do you let a block-device be read-only for a service? Using file system namespacing. See ReadOnlyDirectory= in systemd.exec(5). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Presentation was a success
It was a lot of work, but the presentation about systemd/journald was a success. I got several colleges interested: so mission accomplished. There are some things I still should respond to, but I am a ‘little’ tired, so I will respond later. Thank everyone who helped me in making this presentation a success. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] File system gets remounted read-only after using nspawn
Hi; I've been playing with systemd-nspawn with Gentoo. I'm running systemd 208, and the normal Gentoo stage3 image [1], installing systemd 204 inside it. Everything works great, but for some reason after powering off the container, the file system where it resides gets remounted read-only. I should notice that this is a file system different from /. Also, I usually need to machinectl terminate the machine, otherwise I cannot start the same container with the same name (I think this is a known bug). Any idea why do this happens? I took a quick glance through nspawn.c code, but the only read-only related code I've seen is when using bind mounts, which I don't need to use to trigger this behavior. Regards. [1] http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Presentation was a success
On 05.12.2013 21:10, Cecil Westerhof wrote: It was a lot of work, but the presentation about systemd/journald was a success. I got several colleges interested: so mission accomplished. There are some things I still should respond to, but I am a ‘little’ tired, so I will respond later. Thank everyone who helped me in making this presentation a success. I'll tell you one word, vitamins! Are some of the forms of presentation publicly available? poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/core
On Thu, 05.12.13 14:38, Zbigniew Jędrzejewski-Szmek
(zbys...@kemper.freedesktop.org) wrote:
src/core/device.c | 10 ++
1 file changed, 10 insertions(+)
New commits:
commit e775289d56ace2f8d23e62ed79316d71332d6d05
Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
Date: Thu Dec 5 00:41:12 2013 -0500
systemd: add a start job for all units in SYSTEMD_[USER_]WANTS=
diff --git a/src/core/device.c b/src/core/device.c
index 4ff7c37..19fc745 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -264,6 +264,7 @@ static int device_update_unit(Manager *m, struct
udev_device *dev, const char *p
FOREACH_WORD_QUOTED(w, l, wants, state) {
_cleanup_free_ char *n = NULL;
char e[l+1];
+Unit *other;
memcpy(e, w, l);
e[l] = 0;
@@ -277,6 +278,15 @@ static int device_update_unit(Manager *m, struct
udev_device *dev, const char *p
r = unit_add_dependency_by_name(u,
UNIT_WANTS, n, NULL, true);
if (r 0)
goto fail;
+
+other = manager_get_unit(u-manager, n);
+if (!other || !unit_can_start(other))
+continue;
+
+r = manager_add_job(u-manager, JOB_START,
other, JOB_REPLACE, true, NULL, NULL);
+if (r 0)
+log_warning(Failed to add job
%s/%s, ignoring: %s.,
+other-id,
job_type_to_string(JOB_START), strerror(-r));
What's the rationale here?
We already add UNIT_WANTS dependencies, that should be all that is
needed. When the device is set to PLUGGED state, then via unit_notify we
should end up starting the UNIT_WANTS units retroactively via
retroactively_start_dependencies().
If this didn't work correctly, then we need to fix this, but please
don't tape over this by adding both deps and queueing jobs.
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-commits] src/core
On Fri, Dec 06, 2013 at 03:16:08AM +0100, Lennart Poettering wrote:
On Thu, 05.12.13 14:38, Zbigniew Jędrzejewski-Szmek
(zbys...@kemper.freedesktop.org) wrote:
src/core/device.c | 10 ++
1 file changed, 10 insertions(+)
New commits:
commit e775289d56ace2f8d23e62ed79316d71332d6d05
Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
Date: Thu Dec 5 00:41:12 2013 -0500
systemd: add a start job for all units in SYSTEMD_[USER_]WANTS=
diff --git a/src/core/device.c b/src/core/device.c
index 4ff7c37..19fc745 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -264,6 +264,7 @@ static int device_update_unit(Manager *m, struct
udev_device *dev, const char *p
FOREACH_WORD_QUOTED(w, l, wants, state) {
_cleanup_free_ char *n = NULL;
char e[l+1];
+Unit *other;
memcpy(e, w, l);
e[l] = 0;
@@ -277,6 +278,15 @@ static int device_update_unit(Manager *m, struct
udev_device *dev, const char *p
r = unit_add_dependency_by_name(u,
UNIT_WANTS, n, NULL, true);
if (r 0)
goto fail;
+
+other = manager_get_unit(u-manager, n);
+if (!other || !unit_can_start(other))
+continue;
+
+r = manager_add_job(u-manager, JOB_START,
other, JOB_REPLACE, true, NULL, NULL);
+if (r 0)
+log_warning(Failed to add job
%s/%s, ignoring: %s.,
+other-id,
job_type_to_string(JOB_START), strerror(-r));
What's the rationale here?
We already add UNIT_WANTS dependencies, that should be all that is
needed. When the device is set to PLUGGED state, then via unit_notify we
should end up starting the UNIT_WANTS units retroactively via
retroactively_start_dependencies().
Yes, it didn't work. I committed this version because it seems to work nicely,
but I didn't investigage why retroactively_start_dependencies doesn't work.
I'll check that.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nspawn: fix buggy mount_binds, now works for bind-mounted files
Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: fix misuse of memcmp
On Thu, Dec 05, 2013 at 10:30:04PM +0800, Yuxuan Shui wrote:
---
src/shared/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index b4ed2c4..d685966 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -5919,7 +5919,7 @@ int shall_restore_state(void) {
return 1;
FOREACH_WORD_QUOTED(w, l, line, state)
-if (l == 23 memcmp(w, systemd.restore_state=0, 23))
+if (l == 23 memcmp(w, systemd.restore_state=0, 23) == 0)
return 0;
Applied, with memcmp changed to strneq.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 05, 2013 at 04:38:45PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 05, 2013 at 04:27:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Dec 05, 2013 at 04:50:54PM +1000, Peter Hutterer wrote:
the new rule now is:
SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*, \
ENV{SYSTEMD_WANTS}=wacom-inputattach@%k.service,TAG+=systemd
And the matching wacom-inputattach@.service file shows:
[Unit]
Description=Start inputattach for Wacom ISDv4-compatible serial devices
This will be displayed as Starting Start inputattach for Wacom
ISDv4-compatible serial devices, and later Stopping Start
easy fix, thanks.
Cheers,
Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Thu, Dec 05, 2013 at 01:24:10PM +, Jóhann B. Guðmundsson wrote:
On 12/05/2013 12:28 PM, Michael Biebl wrote:
2013/12/5 Jóhann B. Guðmundssonjohan...@gmail.com:
On 12/05/2013 06:50 AM, Peter Hutterer wrote:
ExecStartPre=/usr/sbin/modprobe wacom_w8001
Add a configuration file called wacom-w8001.conf to /etc/modules-load.d
directory with the following content to load the module
( /etc/modules-load.d/wacom-w8001.conf )
# Load wacom_w8001 at boot
wacom_w8001
Well, this loads the kernel module unconditionally, though. Even for
users which don't have that hardware. So this approach isn't that
great.
It also depends on the wacom_w8001 and how it reacts when it's loaded
and no hardware is present.
Peter, couldn't this module be autoloaded?
the module just sits there, it needs to be triggered by
inputattach to actually hook onto the device. there's a small number of
devices only that need it, so unconditionally modprobing it seems a bit
wasteful.
I'm not that familiar with udev policy regarding rules rule but I
would think that if you autoload module you tie the startup of the
systemd unit to the module being loaded ( if the intent is to
trigger a unit )
So we need an udev wacom-serial-driver rule that might look like
this for the wacom serial devices
ACTION==remove, GOTO=drivers_end
ENV{MODALIAS}==?*, RUN{builtin}=kmod load $env{MODALIAS}
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==WACf*,
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
,RUN{builtin}=kmod load wacom_w8001
SUBSYSTEM==tty|pnp, SUBSYSTEMS==pnp, ATTRS{id}==FUJ*,
ENV{ID_MODEL}=Serial Wacom Tablet $attr{id}, ENV{ID_INPUT}=1,
ENV{ID_INPUT_TABLET}=1, ENV{NAME}=Serial Wacom Tablet $attr{id}
,RUN{builtin}=kmod load wacom_w8001
LABEL=drivers_end
Followed by an systemd rule that looks something like this
SUBSYSTEM==module, KERNEL==wacom*, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=wacom-inputattach@%k.service
And the modprobe would be dropped from that unit file but as I say
I'm not all that familiar with udev policy rules and I personally
had not planned on mastering udev until I started the cleanup
process in Fedora which might never happen today thanks to the that
WG process.
thanks, that seems to be the best solution so far (haven't tested it yet
though :). Can anyone confirm that this matches the current policies?
Thanks
Cheers,
Peter
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
