Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Hello Tom, replying on-list again, if you don't mind. Tom Gundersen [2013-06-16 22:52 +0200]: On Sun, Jun 16, 2013 at 10:32 PM, Martin Pitt martin.p...@ubuntu.com wrote: We actually generate the hwdb during package build and ship hwdb.bin statically. The problem with that is that local configuration in /etc/udev/hwdb.d/ will be ignored, so it seems to me that the correct thing to do is to generate hwdb.bin in post-install. This bit striked me as overengineered, so for now our udev package doesn't even ship /etc/udev/. pci.ids or usb.ids aren't user-configurable, and there has never been a case that we heard of where the admin would have the need to change the name of a piece of hardware. Michael proposed a compromise where the hwdb.bin would be in /lib/udev, and as soon as there are files in /etc/udev/hwdb.d/ it would move the cache to /etc/udev/. I can't say I like that very much as it would introduce the same problem with just less predictability, but I want to mention it for the records. Anyway, Lennart's and your responses have demonstrated that putting the cache into /etc wasn't by accident but deliberate; that's fine, so let's keep it as it is, and we keep the patch downstream for now. As it is it is trivial to revert or change as it only changes statically shipped files in the package. Thanks for the discussion! 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] udev hwdb: Store binary database in libdir, not in /etc
Lennart Poettering [2013-06-17 2:52 +0200]: The file is supposed to be be built on the installed system so that other packages or the admin can drop in additional hwdb files. And yes, it is not a package manager controlled file, which is precisely why I am saying it belongs to /etc, not /usr. (See my other response to Tom about details) No, by placing it in /usr (or /lib, for old distributions which haven't done the /usr merge yet) you break the rule that the files the systemd package installs in /usr should be the same on all installations of the same package version. It doesn't at the moment, as the file is in the package it is the same on all installations (of the same architecture). 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
[systemd-devel] [PATCH] udev: Make builtin firmware to find in subdirectories
From: WaLyong Cho walyong@samsung.com
We can specify firmware path using --with-firmware-path configure
option.
In some of system, firmware can be located in subdirectories of the
firmware path.
If there are many firmware directories in below specified path then we
have to define those to --with-firmware-path.
To avoid this, if builtin firmware could not find firmware in specified
directories then try to find firmware in subdirectories.
Signed-off-by: WaLyong Cho walyong@samsung.com
---
src/udev/udev-builtin-firmware.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/src/udev/udev-builtin-firmware.c b/src/udev/udev-builtin-firmware.c
index b80940b..fb43a37 100644
--- a/src/udev/udev-builtin-firmware.c
+++ b/src/udev/udev-builtin-firmware.c
@@ -74,6 +74,34 @@ exit:
return ret;
}
+static FILE* find_firmware(const char *path, const char *fwpath, const char
*firmware)
+{
+char searchpath[UTIL_PATH_SIZE];
+FILE *fwfile = NULL;
+DIR *srcdir;
+struct dirent *dent;
+struct stat statbuf;
+
+srcdir = opendir(path);
+while ((dent = readdir(srcdir)) != NULL) {
+if (strcmp(dent-d_name, .) == 0 || strcmp(dent-d_name,
..) == 0)
+continue;
+if (fstatat(dirfd(srcdir), dent-d_name, statbuf, 0) 0)
+continue;
+if (S_ISDIR(statbuf.st_mode)) {
+strscpyl(fwpath, UTIL_PATH_SIZE, path, dent-d_name,
/, firmware, NULL);
+fwfile = fopen(fwpath, re);
+if (fwfile == NULL) {
+strscpyl(searchpath, UTIL_PATH_SIZE, path,
dent-d_name, /, NULL);
+fwfile = find_firmware(searchpath, fwpath,
firmware);
+}
+if (fwfile != NULL)
+return fwfile;
+}
+}
+return NULL;
+}
+
static int builtin_firmware(struct udev_device *dev, int argc, char *argv[],
bool test)
{
struct udev *udev = udev_device_get_udev(dev);
@@ -107,6 +135,11 @@ static int builtin_firmware(struct udev_device *dev, int
argc, char *argv[], boo
fwfile = fopen(fwpath, re);
if (fwfile != NULL)
break;
+else {
+fwfile = find_firmware(searchpath[i], fwpath,
firmware);
+if (fwfile != NULL)
+break;
+}
}
strscpyl(loadpath, sizeof(loadpath), udev_device_get_syspath(dev),
/loading, NULL);
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, Jun 17, 2013 at 6:41 AM, Martin Pitt martin.p...@ubuntu.com wrote: Lennart Poettering [2013-06-17 2:52 +0200]: The file is supposed to be be built on the installed system so that other packages or the admin can drop in additional hwdb files. And yes, it is not a package manager controlled file, which is precisely why I am saying it belongs to /etc, not /usr. (See my other response to Tom about details) No, by placing it in /usr (or /lib, for old distributions which haven't done the /usr merge yet) you break the rule that the files the systemd package installs in /usr should be the same on all installations of the same package version. It doesn't at the moment, as the file is in the package it is the same on all installations (of the same architecture). The hwdb files are overwritable/extendable the same way as udev rules are, Admins can update add individual keys/values with files in /etc, which will result in different binary databases. Udev is not the only package that will install the source files, the hwdb files will be used like udev rules, sane scanner rules, gphoto rules, upower stuff, ... should all use hwdb files instead of udev rules in the future. Therefore, the binary database must be generated on the target host system and never be shipped by the udev package. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Make builtin firmware to find in subdirectories
On Mon, Jun 17, 2013 at 8:17 AM, WaLyong Cho fyd0...@gmail.com wrote: We can specify firmware path using --with-firmware-path configure option. This was configurable because some systems had no /lib directory, it is not meant to carry device or driver specific directories. In some of system, firmware can be located in subdirectories of the firmware path. Sure, but the request of the firware would carry the subdirectory. Why would systems do that otherwise? It does not sound right. If there are many firmware directories in below specified path then we have to define those to --with-firmware-path. I don't understand this. The non-kernel-version subdirectories should be included in the kernel request, not added by the firmware loader. To avoid this, if builtin firmware could not find firmware in specified directories then try to find firmware in subdirectories. This is incompatible with the current in-kernel loader which works without any userspace helper. Things should really not work the way the patch introduces. Leading directories should be added to the kernel firmware request, not searched the firmware loader. Btw, the entire userspace firmware loading is already disabled by default in the udev sources, and will be entirely removed in the near future. Firmware will not be loaded by userspace anymore. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADSUP] systemd cgroup changes
Heya, in the past weeks we have been sitting down with the cgroup maintainer in the kernel, Tejun Heo, at a number of conferences. During these discussions it became very clear to us that the way systemd currently exposes cgroups exposes too much of the guts of it, and is incompatible with how the kernel cgroup subsystem will be cleaned up in the near-term feature. Hence I'd like to let everybody in the systemd community know that the cgroup settings, commands and APIs in systemd will change soon. Please be aware of this when you make use of advanced cgroup functionality. - The functionality to define orthogonal cgroup trees for the various controllers will be removed. In fact we'll likely remove the entire API for setting abritrary per-controller paths for each unit. Instead we will introduce a new concept of Slices which will allow you to partition system resources in a tree and move units, users, and machines to arbitrary places in it. There will only be a single cgroup tree, but the various controllers may be enabled/disabled separately for each group, so that individual controllers might only see a subtree of the full tree, but not orthogonal trees anymore. The ConrolGroup= unit setting will go away, and be replaced by Slice= plus EnableControllers= or so. - ControlGroupPersistent= will likely go away, systemd will be the only component of the OS that sets up the cgroup tree. - ControlGroupAttribute= will most likely go away entirely. Instead we will introduce more high level controls like the existing CPUShares=, MemoryLimit= and so on. (BTW, if there's a specific attribute we currently don't cover but which you really need let us know and we will see if we can add a high-level control for it.) - CPUShares=, MemoryLimit= and so on will continue to exist as before. - systemctl set-cgroup will go away, and be replaced by systemctl set-slice or something similar. - systemctl set-cgroup-attr will go away, and be replaced by systemctl set-attr or so, which only can set the high level attributes. - The (currently undocumented) bus APIs for cgroup controls will be replaced. Sorry for this disruption. Thankfully we have not documented these APIs yet and we haven't made the funcionality too widely known. We hate to make incompatible changes like this, but in this case it's probably better to clean this up early when it is not often used instead of late when everybody already uses this. This will remove a few bits of functionality but all in all give you a lot more back. For example, the slice functionality will provide you with a powerful and naturally built-in way to partition your resources in arbitrary ways, and can be used to not only assign resource limits to systemd units but also login users and machines. We haven't hashed out all the details yet, but expect this to land very soon in git. Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: only run systemd-sysctl when a network device is added
On Mon, Jun 17, 2013 at 12:09:53AM +0200, Michał Bartoszkiewicz wrote: On Sun, Jun 16, 2013 at 11:58 PM, Ross Lagerwall rosslagerw...@gmail.com wrote: OK, thanks. But my testing shows otherwise: I created a .conf file with: net.ipv4.conf.enp1s0.forwarding=1 (where eth0 is the old name, enp1s0 is the new, predictable name) It *correctly* sets /proc/sys/net/ipv4/conf/enp1s0/forwarding=1 after a reboot with the patch applied. This works because systemd-sysctl runs from 99-systemd.rules, so the name has already been changed by earlier rules. Yeah, that was what I understood to be happening but I wasn't sure if there is another case where something can go wrong. Thanks -- Ross Lagerwall ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles, man: Add xattr support to tmpfiles
This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.
To keep backwards compatibility Argument field is used. If word starts
with xattr=, then it is cut out from Argument and parsed. There may be
many xattrs. Full format is:
xattr=name=value
If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.
Example:
d /var/run/cups - - - - xattr=security.SMACK64=printing
---
man/tmpfiles.d.xml | 22 ++-
src/tmpfiles/tmpfiles.c | 158
2 files changed, 179 insertions(+), 1 deletion(-)
diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 519f9bc..36021b1 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -309,6 +309,26 @@ L/tmp/foobar ----
/dev/null/programlisting
a short string that is written to the file,
suffixed by a newline. Ignored for all other
lines./para
+
+paraIf commandsystemd-tmpfiles/command was
+compiled with extended attributes support, then
+argument field can be used to set extended attributes.
+Such argument should follow format:/para
+
+
programlistingxattr=replaceablename/replaceable=replaceablevalue/replaceable/programlisting
+
+paraWhere replaceablename/replaceable is
extended
+attribute name and replaceablevalue/replaceable is
+value to be set. If value contains spaces, it must be
+between quotation marks. If value contains quotation
+mark, which should be set, then it must be escaped
with
+backslash./para
+
+paraSuch special arguments are cut out and from
argument
+field, so there's no influence on other meanigs of
argument
+field./para
+
+paraxattr= can be especially used to set SMACK
security labels./para
/refsect2
/refsect1
@@ -320,7 +340,7 @@ L/tmp/foobar ----
/dev/null/programlisting
paracommandscreen/command needs two directories
created at boot with specific modes and ownership./para
programlistingd /var/run/screens 1777 root root 10d
-d /var/run/uscreens 0755 root root 10d12h/programlisting
+d /var/run/uscreens 0755 root root 10d12h xattr=user.owner=John Koval
xattr=security.SMACK64=screen/programlisting
/example
/refsect1
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index f4885ec..9869e58 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -39,6 +39,9 @@
#include glob.h
#include fnmatch.h
#include sys/capability.h
+#ifdef HAVE_XATTR
+#include attr/xattr.h
+#endif
#include log.h
#include util.h
@@ -83,6 +86,7 @@ typedef struct Item {
char *path;
char *argument;
+char **xattrs;
uid_t uid;
gid_t gid;
mode_t mode;
@@ -447,6 +451,52 @@ static int item_set_perms(Item *i, const char *path) {
return label_fix(path, false, false);
}
+static int item_set_xattrs(Item *i, const char *path) {
+#ifdef HAVE_XATTR
+char *name, *value;
+char **x;
+int n;
+if (!i-xattrs)
+return 0;
+STRV_FOREACH(x, i-xattrs) {
+value = *x;
+name = strsep(value, =);
+if (name == NULL || value == NULL) {
+log_warning(%s: %s is not valid xattr, ignoring.,
path, *x);
+continue;
+}
+n = strlen(value);
+if (value[n-1] == '\')
+value[n-1] = '\0';
+if (value[0] == '\')
+memmove(value, value+1, n);
+value = strreplace(value, \\\, \);
+if (!value)
+return log_oom();
+n = strlen(value);
+if (i-type == CREATE_SYMLINK) {
+if (lsetxattr(path, name, value, n+1, 0) 0) {
+log_error(lsetxattr(%s) failed: %m, path);
+free(value);
+return -errno;
+}
+}
+else if (setxattr(path, name, value, n+1, 0) 0) {
+log_error(setxattr(%s) failed: %m, path);
+free(value);
+return -errno;
+}
+free(value);
+}
+
Re: [systemd-devel] [PATCH] tmpfiles, man: Add xattr support to tmpfiles
On Mon, 17.06.13 16:27, Maciej Wereski (m.were...@partner.samsung.com) wrote: This patch makes it possible to set extended attributes on files created by tmpfiles. This can be especially used to set SMACK security labels on volatile files and directories. To keep backwards compatibility Argument field is used. If word starts with xattr=, then it is cut out from Argument and parsed. There may be many xattrs. Full format is: xattr=name=value If value contains spaces, then it must be surrounded by quotation marks. User can also put quotation mark in value by escaping it with backslash. I think adding this certainly makes sense, but I am not sure I like the syntax. Maybe it would be simpler to add an extra char for this (a or so?). That way creating a dir and applying an xattr would require two lines instead of one, but the stuff isn't atomic anyway. Admittedly adding a new a isn't particularly nice either, but I have no better idea than that... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 17.06.13 06:35, Martin Pitt (martin.p...@ubuntu.com) wrote: Anyway, Lennart's and your responses have demonstrated that putting the cache into /etc wasn't by accident but deliberate; that's fine, so let's keep it as it is, and we keep the patch downstream for now. As it is it is trivial to revert or change as it only changes statically shipped files in the package. I'd really prefer if Ubuntu wouldn't do its own thing for everything they possibly can. We try to push some of the more exotic device metadata into the respective packages and the developers of those packages should be able to rely on being able to drop in additional hwdb and have things work everywhere. If Ubuntu then goes and doesn't allow drop-ins and moves generation of these files to compile-time then you effectively make that impossible. And that's really uncool of you. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 17.06.13 06:41, Martin Pitt (martin.p...@ubuntu.com) wrote: No, by placing it in /usr (or /lib, for old distributions which haven't done the /usr merge yet) you break the rule that the files the systemd package installs in /usr should be the same on all installations of the same package version. It doesn't at the moment, as the file is in the package it is the same on all installations (of the same architecture). I cannot parse this. Let me try to explain this a different way: in RPM-speak the files in /etc should ideally either be %ghost'ed or %config'ed, and the ones in /usr should be neither. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
On Sun, 16.06.13 19:18, David Greaves (da...@dgreaves.com) wrote:
On 06/06/13 08:33, Lennart Poettering wrote:
On Sat, 18.05.13 23:44, Michael Scherer (m...@zarb.org) wrote:
So I planned to warn if the unit are directly in /lib, but I know there
is some distribution that didn't choose this path yet. So when /usr is
not merged, what is the canonical location ( ie, for Opensuse, Mandriva,
since they are both rpm based ) ?
I'd recommend adding a warning for all units that aren't located in
%_unitdir.
Would it make sense to add:
%define _userunitdir %{_libdir}/systemd/user/
at this time?
I added this now to the macros.systemd file we ship upstream.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to get a device name matching .device to use into a dynamic@.unit ?
On Thu, 13.06.13 13:20, Pablo Saratxaga (pa...@walon.org) wrote: Hello, I'm learning (and appreciating) the new systemd; and I'm currently trying to make it work to load some firmware, in the most generic way. The hardware needing that firmware is a cheap bluetooth usb dongle; so cheap that without loading the firware it just plain doesn't work. If firmware loading is a one-time thing you need to execute when the device is plugged in, and is relatively quick to execute there is no need to involve a systemd service and you can simply run this from a udev rule directly. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to get a device name matching .device to use into a dynamic@.unit ?
On Mon, Jun 17, 2013 at 06:40:54PM +0200, Lennart Poettering wrote: On Thu, 13.06.13 13:20, Pablo Saratxaga (pa...@walon.org) wrote: Hello, I'm learning (and appreciating) the new systemd; and I'm currently trying to make it work to load some firmware, in the most generic way. The hardware needing that firmware is a cheap bluetooth usb dongle; so cheap that without loading the firware it just plain doesn't work. If firmware loading is a one-time thing you need to execute when the device is plugged in, and is relatively quick to execute there is no need to involve a systemd service and you can simply run this from a udev rule directly. Firmware should be loaded directly from the kernel itself these days, no need for a udev rule, or anything else, it should just work. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
2013/6/17 Kay Sievers k...@vrfy.org: On Mon, Jun 17, 2013 at 6:41 AM, Martin Pitt martin.p...@ubuntu.com wrote: Lennart Poettering [2013-06-17 2:52 +0200]: The file is supposed to be be built on the installed system so that other packages or the admin can drop in additional hwdb files. And yes, it is not a package manager controlled file, which is precisely why I am saying it belongs to /etc, not /usr. (See my other response to Tom about details) No, by placing it in /usr (or /lib, for old distributions which haven't done the /usr merge yet) you break the rule that the files the systemd package installs in /usr should be the same on all installations of the same package version. It doesn't at the moment, as the file is in the package it is the same on all installations (of the same architecture). The hwdb files are overwritable/extendable the same way as udev rules are, Admins can update add individual keys/values with files in /etc, which will result in different binary databases. Udev is not the only package that will install the source files, the hwdb files will be used like udev rules, sane scanner rules, gphoto rules, upower stuff, ... should all use hwdb files instead of udev rules in the future. Therefore, the binary database must be generated on the target host system and never be shipped by the udev package. I guess we can all agree that the cache file in /etc is not really nice and that /etc/ld.so.cache already exists, doesn't really make that better. A 5+ MB blob is really annoying, especially if you use tools like etckeeper. Putting the cache files in /lib (or /usr/lib), isn't really great either, even though we have some precedence here too, like /lib/modules/*/ or icon and gsettings cache files. What about this compromise: a/ udevadm hwdb --update should be run in postinst, i.e. do not ship a pre-generated cache file b/ let udevadm hwdb --update check, if /var or /var/cache is on a separate partition. If not, store the cache file in /var/cache/udev, /etc/udev otherwise c/ update udev to read from both locations, /var/cache having preference The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. But I guess I could live with that, given that because of a missing hwdb.bin, we won't fail to boot. 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
[systemd-devel] [PATCH] install: make reenable work with templated units
Before, systemctl reenable getty@tty1.service would fail with:
Failed to issue method call: File exists
To fix this, reimplement reenable explicitly as a disable followed by
an enable.
This is shorter and is how the man page documents its behavior.
---
src/shared/install.c | 38 +-
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index d2dd276..1bda79a 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1533,43 +1533,15 @@ int unit_file_reenable(
bool force,
UnitFileChange **changes,
unsigned *n_changes) {
+int r;
-_cleanup_lookup_paths_free_ LookupPaths paths = {};
-_cleanup_install_context_done_ InstallContext c = {};
-char **i;
-_cleanup_free_ char *config_path = NULL;
-_cleanup_set_free_free_ Set *remove_symlinks_to = NULL;
-int r, q;
-
-assert(scope = 0);
-assert(scope _UNIT_FILE_SCOPE_MAX);
-
-r = lookup_paths_init_from_scope(paths, scope);
-if (r 0)
-return r;
-
-r = get_config_path(scope, runtime, root_dir, config_path);
+r = unit_file_disable(scope, runtime, root_dir, files, changes,
+ n_changes);
if (r 0)
return r;
-STRV_FOREACH(i, files) {
-r = mark_symlink_for_removal(remove_symlinks_to, *i);
-if (r 0)
-return r;
-
-r = install_info_add_auto(c, *i);
-if (r 0)
-return r;
-}
-
-r = remove_marked_symlinks(remove_symlinks_to, config_path, changes,
n_changes, files);
-
-/* Returns number of symlinks that where supposed to be installed. */
-q = install_context_apply(c, paths, config_path, root_dir, force,
changes, n_changes);
-if (r == 0)
-r = q;
-
-return r;
+return unit_file_enable(scope, runtime, root_dir, files, force,
+changes, n_changes);
}
int unit_file_set_default(
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to end a socket activated daemon
On Fri, 14.06.13 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Jun 14, 2013 at 10:03:00AM +0200, Łukasz Stelmach wrote: Hi. We are converting some daemons to socket activation. Most of them open unix sockets and manage incoming connections in a main-loop, so the easiest way to convert it is to create Accept=false socket with systemd. Now, it is quite well described how to start such daemon, however, there is little about shutting it down. Should the daemon close(2) the received sockets? Should it unlink(2) them from a filesystem? close() yes, unlink() no. Strictly speaking you don't even have to do that. The kernel will clean up left-over fds when your process exits, hence you don't have to close it explicitly. But you certainly should not unlink() the socket in the fs, because then the socket will not be accessible anymore. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: switch to journal when socket is listening
On Thu, 13.06.13 21:26, Umut Tezduyar (u...@tezduyar.com) wrote:
systemd starts using journal as soon as the journal
socket is in listening state instead of waiting for
journal's socket to switch to 'running' state.
---
src/core/manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index f16621a..cebc43e 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2613,7 +2613,8 @@ void manager_recheck_journal(Manager *m) {
return;
u = manager_get_unit(m, SPECIAL_JOURNALD_SOCKET);
-if (u SOCKET(u)-state != SOCKET_RUNNING) {
+if (u SOCKET(u)-state != SOCKET_RUNNING
+ SOCKET(u)-state != SOCKET_LISTENING) {
log_close_journal();
return;
}
This might result in a deadlock. If we start writing to the log socket
we might trigger starting of the journal daemon, which we ourselves have
to do, but if we block on the log socket then this might possible
deadlock.
We should probably instead try making SOCKET_RUNNING more reliable.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: switch to journal when socket is listening
On Thu, 13.06.13 21:28, Umut Tezduyar (u...@tezduyar.com) wrote:
On Thu, Jun 13, 2013 at 9:26 PM, Umut Tezduyar u...@tezduyar.com wrote:
systemd starts using journal as soon as the journal
socket is in listening state instead of waiting for
journal's socket to switch to 'running' state.
---
src/core/manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index f16621a..cebc43e 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2613,7 +2613,8 @@ void manager_recheck_journal(Manager *m) {
return;
u = manager_get_unit(m, SPECIAL_JOURNALD_SOCKET);
-if (u SOCKET(u)-state != SOCKET_RUNNING) {
+if (u SOCKET(u)-state != SOCKET_RUNNING
+ SOCKET(u)-state != SOCKET_LISTENING) {
log_close_journal();
return;
}
Hi,
Due to a race condition (at least I think) between systemd and
journald, systemd might keep logging to kmsg even though journal is up
and running. Systemd switches to using journal for logging when both
journal's socket and service are in running state. Occasionally I
have ended up finding my system in the following state after booting
to basic.target.
systemd-journald.service loaded active running Journal Service
systemd-journald.socketloaded active listening Journal Socket
At this point journal is up, program's stdout/err is sent to journal
(can be seen by journalctl) but systemd still thinks journal is not
usable for its own logging and keeps logging to kmsg.
If you are using kernel 3.5, the effect of the problem is not being
able to see systemds logs in journalctl.
---
I think what is happening is both journald and systemd are racing for
the EPOLLIN event on the journal's sockets. If journal is receiving
EPOLLIN events all the time, then systemd will never get notified of
the activity on the sockets and never switch the socket to running
state.
If I disable the EPOLLIN event registration on the journald side, I
can see that systemd-journald.socket switches to running state %100.
Since systemd-journal.socket and systemd-journal.service are starting
on boot up anyways, I don't see the necessity of waiting for
systemd-journald.socket to go to running state.
If anyone would like to get more information, I can reproduce the
problem pretty often. I have tried both kernel 3.4 and 3.8 as well as
different ISAs.
I see the problem. In most other cases it never mattered that the
socket's state is correctly updated. I guess it actually does for the
journald socket at least.
The cleanest way to fix this appears to me is updating the socket's
state to RUNNING as soon as its matching service is activated, instead
of only when we receive EPOLLIN. We already get notifications when the
service dies, we should just extend that for when the service starts up.
As it turns out this recently became a bit easier with the unit logic,
there's now a trigger_notify() callback in UnitVTable that is invoked
each time a unit that is triggered by a unit changes state. It's
probably just a matter of adding a callback in there, and doing a simple
state change. Patch appreciated (though I added this to the TODO list,
too.)
(In fact, service.c's service_notify_sockets_dead() should probably be
replaced by the same trigger_notify() handler, if possible, but that's
just the cherry on top).
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] mount: Don't add conflicts with umount.target for certain mounts
On Thu, 13.06.13 08:46, Ross Lagerwall (rosslagerw...@gmail.com) wrote:
-r = unit_add_dependency_by_name(u, UNIT_CONFLICTS,
SPECIAL_UMOUNT_TARGET, NULL, true);
-if (r 0)
-goto fail;
+if (!path_equal(where, /) !path_equal(where, /usr)
+!mount_test_option(options, x-initrd.mount)) {
+r = unit_add_dependency_by_name(u, UNIT_CONFLICTS,
SPECIAL_UMOUNT_TARGET, NULL, true);
+if (r 0)
+goto fail;
+}
Hmm x-initrd.mount will never show up in the options variable, since
that's from the kernel, and the kernel doesn't know that option, that's
purely a userspace option.
For now I have commited a simpler patch which only checks for /, which
also mimics what fstab-generator currently does.
(In the long run we really should figure out which deps fstab-genrator
generates and which are implicitly added in by mount.c. Currently,
there's no clear structure in there, and quite a bit of duplication.)
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: only run systemd-sysctl when a network device is added
On Mon, Jun 17, 2013 at 3:30 PM, Ross Lagerwall rosslagerw...@gmail.com wrote: On Mon, Jun 17, 2013 at 12:09:53AM +0200, Michał Bartoszkiewicz wrote: On Sun, Jun 16, 2013 at 11:58 PM, Ross Lagerwall rosslagerw...@gmail.com wrote: OK, thanks. But my testing shows otherwise: I created a .conf file with: net.ipv4.conf.enp1s0.forwarding=1 (where eth0 is the old name, enp1s0 is the new, predictable name) It *correctly* sets /proc/sys/net/ipv4/conf/enp1s0/forwarding=1 after a reboot with the patch applied. This works because systemd-sysctl runs from 99-systemd.rules, so the name has already been changed by earlier rules. Yeah, that was what I understood to be happening but I wasn't sure if there is another case where something can go wrong. The rules order should not matter actually, we collect all RUN keys during rules execution and execute them later. The device renaming happens between the rule exec and the RUN exec. Therefore, it should be fine to limit sysctl to add events. Applied it now. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Make builtin firmware to find in subdirectories
On Mon, Jun 17, 2013 at 03:17:12PM +0900, WaLyong Cho wrote: From: WaLyong Cho walyong@samsung.com We can specify firmware path using --with-firmware-path configure option. In some of system, firmware can be located in subdirectories of the firmware path. If there are many firmware directories in below specified path then we have to define those to --with-firmware-path. To avoid this, if builtin firmware could not find firmware in specified directories then try to find firmware in subdirectories. Ick, how is the kernel handling all of this, now that it does this type of thing instead of udev doing it? We are thinking of adding multiple paths to find firmware to the kernel, but for subdirectories? No, the driver should be passing a sane name to the firmware subsystem, no need to be digging through the disk like this. In fact, we should really just delete the firmware logic from udev entirely now that the kernel doesn't even call it anymore, right? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, Jun 17, 2013 at 7:43 PM, Michael Biebl mbi...@gmail.com wrote: I guess we can all agree that the cache file in /etc is not really nice and that /etc/ld.so.cache already exists, doesn't really make that better. A 5+ MB blob is really annoying, especially if you use tools like etckeeper. Putting the cache files in /lib (or /usr/lib), isn't really great either, even though we have some precedence here too, like /lib/modules/*/ or icon and gsettings cache files. What about this compromise: a/ udevadm hwdb --update should be run in postinst, i.e. do not ship a pre-generated cache file b/ let udevadm hwdb --update check, if /var or /var/cache is on a separate partition. If not, store the cache file in /var/cache/udev, /etc/udev otherwise c/ update udev to read from both locations, /var/cache having preference The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. I agree with Lennart that we don't want this scheme, but rather something predictable. How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Make builtin firmware to find in subdirectories
On Mon, Jun 17, 2013 at 9:57 PM, Greg KH gre...@linuxfoundation.org wrote: In fact, we should really just delete the firmware logic from udev entirely now that the kernel doesn't even call it anymore, right? This fimware logic is not compiled by default, but for people with old kernels it can be enabled with a configure switch. Maybe rip it out next time we bump the kernel version requirement? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Make builtin firmware to find in subdirectories
On Mon, Jun 17, 2013 at 10:23:53PM +0200, Tom Gundersen wrote: On Mon, Jun 17, 2013 at 9:57 PM, Greg KH gre...@linuxfoundation.org wrote: In fact, we should really just delete the firmware logic from udev entirely now that the kernel doesn't even call it anymore, right? This fimware logic is not compiled by default, but for people with old kernels it can be enabled with a configure switch. Maybe rip it out next time we bump the kernel version requirement? Sounds good to me, given the upcoming cgroup changes, perhaps that would be the good time to do it? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Make builtin firmware to find in subdirectories
On Mon, Jun 17, 2013 at 10:31 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Jun 17, 2013 at 10:23:53PM +0200, Tom Gundersen wrote: On Mon, Jun 17, 2013 at 9:57 PM, Greg KH gre...@linuxfoundation.org wrote: In fact, we should really just delete the firmware logic from udev entirely now that the kernel doesn't even call it anymore, right? This fimware logic is not compiled by default, but for people with old kernels it can be enabled with a configure switch. Maybe rip it out next time we bump the kernel version requirement? Sounds good to me, given the upcoming cgroup changes, perhaps that would be the good time to do it? Yeah, It will be deleted entirely as soon as any other thing requires a newer kernel which also has the in-kernel firmware loader. Currently it is 2.6.39. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, Jun 17, 2013 at 10:12 PM, Tom Gundersen t...@jklm.no wrote: How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Well, it's not a cache, it will not be re-created automatically like a cache, and it will not work with the file missing, it will just fail completely if the database is not there. Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? I don't think the name is convincing. The rootfs is not really a place for cache files, it should be seen as read-only. Maybe etcetera is a nice name. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 17.06.13 22:12, Tom Gundersen (t...@jklm.no) wrote: The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. I agree with Lennart that we don't want this scheme, but rather something predictable. How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? Well, this is about very few files only. AFAICS only systemd/udev, kmod, ld.so need binary caches around this early during boot. It sounds a bit like overkill to introduce an entirely new root level hierarchy for that. Note that beyond caches there are a number of non-text-files in /etc. For example /etc/localtime, /etc/selinux/targeted/policy/policy.27, /etc/pki/*.db, /etc/aliases.db, /etc/ld.so.cache, /etc/prelink.cache and so on. I am not convinced that text file vs. binary file is the best check to decide whether something belongs in /etc or not. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
Lennart Poettering [2013-06-17 18:27 +0200]: We try to push some of the more exotic device metadata into the respective packages and the developers of those packages should be able to rely on being able to drop in additional hwdb and have things work everywhere. If Ubuntu then goes and doesn't allow drop-ins and moves generation of these files to compile-time then you effectively make that impossible. And that's really uncool of you. It wasn't really about not allowing things, but rather about making it easy to change or revert the current patch while this is being discussed. I wanted to fix the hwdb integration without adding a config file which then needs special treatment again for removal, as in dpkg config files are basically holy. If/once there are actually other packages wanting to add stuff there, we'll re-add the dynamic generation of course. But for now there is no reason to do so, it just wastes cycles, dramatically complicates the handling of the cache files, and adds an extra 5 MB to the install footprint. 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] udev hwdb: Store binary database in libdir, not in /etc
Lennart Poettering [2013-06-17 18:28 +0200]: On Mon, 17.06.13 06:41, Martin Pitt (martin.p...@ubuntu.com) wrote: No, by placing it in /usr (or /lib, for old distributions which haven't done the /usr merge yet) you break the rule that the files the systemd package installs in /usr should be the same on all installations of the same package version. It doesn't at the moment, as the file is in the package it is the same on all installations (of the same architecture). I cannot parse this. Let me try to explain this a different way: in RPM-speak the files in /etc should ideally either be %ghost'ed or %config'ed, and the ones in /usr should be neither. That's the situation with a dynamically created file as you have in current Fedora. But the current Ubuntu package just ships a static /lib/udev/hwdb.bin, thus it is perfectly shareable between installations and thus Tom's concern about not being a package-owned file doesn't apply. That's of course unrelated to the question whether we should move to dynamic creation of that file, at which point it wouldn't be suited very well in /lib (but still much better than in /etc). 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] udev hwdb: Store binary database in libdir, not in /etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/17/2013 04:50 PM, Lennart Poettering wrote: On Mon, 17.06.13 22:12, Tom Gundersen (t...@jklm.no) wrote: The only case, where this scheme would fail, is if you backup and restore a system to a different partitioning scheme. I agree with Lennart that we don't want this scheme, but rather something predictable. How about Colin's suggestion of putting hwdb.bin (and similar files that cannot always be in /var/cache) in /etc/cache? Or if anyone have the stomach for a huge fight, try to convince everyone of the usefulness of /cache? Well, this is about very few files only. AFAICS only systemd/udev, kmod, ld.so need binary caches around this early during boot. It sounds a bit like overkill to introduce an entirely new root level hierarchy for that. Note that beyond caches there are a number of non-text-files in /etc. For example /etc/localtime, /etc/selinux/targeted/policy/policy.27, /etc/pki/*.db, /etc/aliases.db, /etc/ld.so.cache, /etc/prelink.cache and so on. I am not convinced that text file vs. binary file is the best check to decide whether something belongs in /etc or not. Lennart One of these days I plan on getting the policy file out of /etc and into /usr/lib/selinux, But any customizations by the admin or other packages would end up putting content into /etc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG/fLgACgkQrlYvE4MpobPmQQCfeKqc3i3+JxaNMPFOxccPLesi q/EAniJUO5bYv+Ei9B5YPJpgZdtt3GoF =R+DF -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
2013/6/17 Lennart Poettering lenn...@poettering.net: I am pretty sure we really shouldn't do an automatism like that. This is very opaque to the user, easily appears random, and certainly deoesn't help uniformity, testability, or documentability. Why should this be relevant for the user? This is an internal implementation detail (btw, another reason, why it shouldn't be visible/accessible in /etc) -- 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] [HEADSUP] systemd cgroup changes
On Mon, 2013-06-17 at 14:49 +0200, Lennart Poettering wrote: We haven't hashed out all the details yet, but expect this to land very soon in git. Looks like nothing is installing system.slice? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc
On Mon, 2013-06-17 at 19:43 +0200, Michael Biebl wrote: b/ let udevadm hwdb --update check, if /var or /var/cache is on a separate partition. If it was just udevadm, that wouldn't be so hard, but replicating the (what I expect to be fairly fragile) code to detect /var's paritioning scheme across any other components (e.g. fontconfig) would be ugly. Though I do keep coming back to the hwdb being a special case, since almost none of the other caches need to unify data from /usr and /etc. That does point out another potential solution - have two caches, one in /usr and one in /etc, and the /etc one is only created if there's anything to cache. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
Hi Elena,
On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com) wrote:
Hi,
This is the patch for review for enabling smack labelling for device nodes.
The functionality and reasoning is inside. I will be happy to answer any
questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Thank you,
Kyungmin Park
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Mon, Jun 17, 2013 at 9:37 PM, Kyungmin Park kmp...@infradead.org wrote:
Hi Elena,
On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com) wrote:
Hi,
This is the patch for review for enabling smack labelling for device nodes.
The functionality and reasoning is inside. I will be happy to answer any
questions.
So, this needs some HAVE_SMACK ifdeffery at least.
That said, I wonder if we should instead make this a generic
XATTR{foobar}=waldo thing. Kay?
Any update for this? if we use SMACK for udev, it requires it.
Lennart's suggestion seems more than reasonable - it would make it
generic enough to do:
XATTR{security.SMACK64}=label
which I think is all we need here. Elena, do you need help respinning this?
Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
