Re: [systemd-devel] Creating containers from local .raw or tar images
On Mon, 02.03.15 15:45, Erik Johnson (e...@saltstack.com) wrote: The machinectl pull-* commands allow you to download container images, but no such option (yet) exists for deploying from an image or tar file on your local filesystem. Are there plans to expand the machinectl pull-* commands to support either absolute file paths or file:/// URLs? My current dirty hack is to run an nginx instance that listens only on localhost, and pull from http://localhost/path/to/container.tar.gz, but this is far from ideal. You can simply place your raw or tar images in /var/lib/machines/ directly. But yeah, pretty high on my list is to add machinectl import-raw, machinectl import-tar, machinectl export-raw, machinectl export-tar, for doing this in a nice way. 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] Unable to remove images using machinectl
On Mon, 02.03.15 14:10, Erik Johnson (e...@saltstack.com) wrote: On Mon, Mar 02, 2015 at 07:51:35PM +0100, Lennart Poettering wrote: On Mon, 02.03.15 11:06, Erik Johnson (e...@saltstack.com) wrote: I'm getting a similar error to the one described in the following post from a couple weeks ago: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html I get an access denied error when running machinectl remove, even as root. This was a bug in the dbus policy. It should be fixed with this commit: http://cgit.freedesktop.org/systemd/systemd/commit/src/machine/org.freedesktop.machine1.conf?id=72c3897f77a7352618ea76b880a6764f52d6327b Lennart -- Lennart Poettering, Red Hat Thanks. I applied the patch, restarted dbus, and now I get the following after a 20-30 second pause: Could not remove image: Activation of org.freedesktop.machine1 timed out dbus is not a service that cannot be restarted during normal operation. This is a well-known limitation of dbus. Reloading configuration should be sufficient. You probably need to reboot now to get back to a working system... 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] Creating containers from local .raw or tar images
AFAIK, all the pull-* commands do is download into /var/lib/machines. You could easily enough just copy things into there yourself. Or even less work: don't copy them in there at all, and pass your image directly to systemd-nspawn (which is what machinectl uses) See: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html On 2 March 2015 at 17:45, Erik Johnson e...@saltstack.com wrote: The machinectl pull-* commands allow you to download container images, but no such option (yet) exists for deploying from an image or tar file on your local filesystem. Are there plans to expand the machinectl pull-* commands to support either absolute file paths or file:/// URLs? My current dirty hack is to run an nginx instance that listens only on localhost, and pull from http://localhost/path/to/container.tar.gz, but this is far from ideal. -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com ___ 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] Unable to remove images using machinectl
On Mon, Mar 02, 2015 at 07:51:35PM +0100, Lennart Poettering wrote: On Mon, 02.03.15 11:06, Erik Johnson (e...@saltstack.com) wrote: I'm getting a similar error to the one described in the following post from a couple weeks ago: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html I get an access denied error when running machinectl remove, even as root. This was a bug in the dbus policy. It should be fixed with this commit: http://cgit.freedesktop.org/systemd/systemd/commit/src/machine/org.freedesktop.machine1.conf?id=72c3897f77a7352618ea76b880a6764f52d6327b Lennart -- Lennart Poettering, Red Hat Thanks. I applied the patch, restarted dbus, and now I get the following after a 20-30 second pause: Could not remove image: Activation of org.freedesktop.machine1 timed out -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com pgpw42om1BjH5.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Creating containers from local .raw or tar images
The machinectl pull-* commands allow you to download container images, but no such option (yet) exists for deploying from an image or tar file on your local filesystem. Are there plans to expand the machinectl pull-* commands to support either absolute file paths or file:/// URLs? My current dirty hack is to run an nginx instance that listens only on localhost, and pull from http://localhost/path/to/container.tar.gz, but this is far from ideal. -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com pgpFotC_3B5wf.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to disable the log of services' status?
Hi all, I'm trying to reduce the log output when OS starts. The messages reporting the services' status like: [ OK ] Started Console Getty. [ OK ] Reached target Login Prompts. [ OK ] Started Login Service. [ OK ] Reached target Multi-User System. ... are useless to me. Anyone who knows how to close these messages? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: Fail verbosely if acls can't be read
If the acls of a file couldn't be retrieved (probably due to missing acl
support in the filesytem), systemd-tmpfiles just silently failed.
Now it logs an error, just as it already does if the acls cannot be set.
---
src/tmpfiles/tmpfiles.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 2642934..de8aa76 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -703,7 +703,9 @@ static int path_set_acl(const char *path, acl_type_t type,
acl_t acl, bool modif
if (modify) {
r = acls_for_file(path, type, acl, dup);
if (r 0)
-return r;
+return log_error_errno(r, Getting %s ACL on %s
failed: %m,
+ type == ACL_TYPE_ACCESS ?
access : default,
+ path);
r = calc_acl_mask_if_needed(dup);
if (r 0)
--
2.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
Hey, Lennart reviewed this in IRC and suggested I refactor the change in this manner. Now, we have an array of capability:sys call pairs, and iterate through that and then only add the seccomp filter if the capability doesn’t exist. The new patch is attached, and available here: https://github.com/jayofdoom/systemd/pull/5.patch. nspawn-seccomp-capabilities.patch Description: nspawn-seccomp-capabilities.patch Thanks all,Jay FaulknerOn Feb 27, 2015, at 12:15 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,My apologies if this is frowned upon, but this has been posted for a week and I haven’t gotten any feedback on it. I’d appreciate if this could get reviewed and if adequate, merged. I’m waiting on this change in order to be able to continue using systemd-nspawn containers, properly configured, to perform system tasks (such as firmware and bios flashing).Thanks,Jay FaulknerOn Feb 20, 2015, at 6:59 PM, Jay Faulkner j...@jvf.cc wrote:After some additional testing, I found a bug in this patch where it would not compile with seccomp disabled. I’ve updated the patch athttps://github.com/jayofdoom/systemd/pull/4.patch— also I’ve attached the fixed patch.-Jayrefactor-nspawn-map-seccomp-to-capabilities.patchOn Feb 20, 2015, at 4:18 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,At the suggestion (and with the assistance of) a co-worker, we remade this patch to not have quite as much repeated code. The new version is attached and can be found herehttps://github.com/jayofdoom/systemd/pull/4.patch— thanks!refactor-nspawn-map-seccomp-to-capabilities.patchThanks,Jay FaulknerOn Feb 20, 2015, at 2:24 PM, Jay Faulkner j...@jvf.cc wrote:Hi all,Two weeks ago[1] I patched systemd-nspawn to respect CAP_SYS_MODULE with regards to setting seccomp filters. As I needed access to some of the other blocked syscalls as well, I have a patch to map all seccomp filters to various capabilities, and to only set those filters if the matching capability is dropped. The matching capabilities were taken from the man pages of the syscalls involved.I’d also suggest that in the future, additional filters use this same mapping as to avoid breaking use cases like mine in the future. :)The patch is attached, but in case it gets mangled in transport as the last one did, feel free to get it directly from github here: https://github.com/jayofdoom/systemd/pull/3.patch.Thanks,Jay Faulknernspawn-map-seccomp-to-capabilities.patch___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/systemd-devel___systemd-devel mailing listsystemd-devel@lists.freedesktop.orghttp://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] How to disable the log of services' status?
В Tue, 3 Mar 2015 11:12:20 +0800 Wang Sen wang...@linux.vnet.ibm.com пишет: Hi all, I'm trying to reduce the log output when OS starts. The messages reporting the services' status like: [ OK ] Started Console Getty. [ OK ] Reached target Login Prompts. [ OK ] Started Login Service. [ OK ] Reached target Multi-User System. ... are useless to me. Anyone who knows how to close these messages? a) add quiet to kernel command line b) See show_status and ShowStatus in man systemd and man systemd-system.conf ___ 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] Creating containers from local .raw or tar images
On Mon, Mar 02, 2015 at 06:03:42PM -0500, Daurnimator wrote: AFAIK, all the pull-* commands do is download into /var/lib/machines. You could easily enough just copy things into there yourself. Or even less work: don't copy them in there at all, and pass your image directly to systemd-nspawn (which is what machinectl uses) See: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html I've done that before, but I am writing nspawn support for SaltStack (http://saltstack.com) and I need to start and stop them unattended. -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com pgpxDnjOGH0PC.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating containers from local .raw or tar images
On Tue, Mar 03, 2015 at 12:24:10AM +0100, Lennart Poettering wrote: On Mon, 02.03.15 15:45, Erik Johnson (e...@saltstack.com) wrote: The machinectl pull-* commands allow you to download container images, but no such option (yet) exists for deploying from an image or tar file on your local filesystem. Are there plans to expand the machinectl pull-* commands to support either absolute file paths or file:/// URLs? My current dirty hack is to run an nginx instance that listens only on localhost, and pull from http://localhost/path/to/container.tar.gz, but this is far from ideal. You can simply place your raw or tar images in /var/lib/machines/ directly. But yeah, pretty high on my list is to add machinectl import-raw, machinectl import-tar, machinectl export-raw, machinectl export-tar, for doing this in a nice way. Lennart -- Lennart Poettering, Red Hat Nice, I figured this would be the logical next step. Right now I am writing support for managing nspawn images in SaltStack, so I was just considering possibilities for functions to add. -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com pgpL51MUnHJLT.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to remove images using machinectl
Excerpts from Erik Johnson's message of 2015-03-02 14:10:06 -0700: Thanks. I applied the patch, restarted dbus, and now I get the following after a 20-30 second pause: @Erik Did you use the aur package or did you compile systemd and install it using make? Do you have experience rolling back to the normal package provided by arch? I'm just asking because I thought about installing systemd on my arch, but as it is my machine which I use very frequently I don't want to crash it. :-) @Lennart Is is difficult to get rid of a systemd package installed from git? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable the log of services' status?
Thanks a lot. I added the kernel argument systemd.show_status=0 and it works. On Tue, Mar 03, 2015 at 07:02:31AM +0300, Andrei Borzenkov wrote: В Tue, 3 Mar 2015 11:12:20 +0800 Wang Sen wang...@linux.vnet.ibm.com пишет: Hi all, I'm trying to reduce the log output when OS starts. The messages reporting the services' status like: [ OK ] Started Console Getty. [ OK ] Reached target Login Prompts. [ OK ] Started Login Service. [ OK ] Reached target Multi-User System. ... are useless to me. Anyone who knows how to close these messages? a) add quiet to kernel command line b) See show_status and ShowStatus in man systemd and man systemd-system.conf ___ 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] Unable to remove images using machinectl
On Tue, Mar 03, 2015 at 07:11:18AM +0100, Peter Paule wrote: Excerpts from Erik Johnson's message of 2015-03-02 14:10:06 -0700: Thanks. I applied the patch, restarted dbus, and now I get the following after a 20-30 second pause: @Erik Did you use the aur package or did you compile systemd and install it using make? Do you have experience rolling back to the normal package provided by arch? I'm just asking because I thought about installing systemd on my arch, but as it is my machine which I use very frequently I don't want to crash it. :-) The patch was to the dbus policy, it did not require a recompile. You can always boot to an Arch snapshot ISO, mount your partitions under /mnt, and do an arch-chroot /mnt, then install a previous systemd from /var/cache/pacman/pkg. @Lennart Is is difficult to get rid of a systemd package installed from git? -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com pgpssCM2ZTpWb.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service watchdog feature in state ACTIVATING ?
Hi Umut, thx for answering -Original Message- From: Umut Tezduyar Lindskog [mailto:u...@tezduyar.com] Sent: Monday, March 02, 2015 8:51 PM To: Hoyer, Marko (ADITG/SW2) Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Service watchdog feature in state ACTIVATING ? Hi Marko, On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) mho...@de.adit- jv.com wrote: Hi, I ran into a use case where the activation phase of a service takes significantly longer than the desired watchdog period (Activating: 10-20secs, Watchdog: 1-5secs). I found out that the watchdog features starts not before the service is in state START_POST. This means for my use case that the system is blind for 10-20secs (whatever I set as startup timeout here). Is there any way to activate the watchdog feature already in phase ACTIVATING? Why would you need this? Watchdog is to prevent system being stuck somewhere. If activation fails within TimeoutStartSec=, systemd will put the service in failed to activate state anyways. Is waiting 20 seconds to detect the freeze is too much for your case? Is it not possible to lower the activation time? Yes it is too long. The process is a kind of application starter and observer processing a startup phase. It is responsible for: - observing the application internal states of upcoming applications - it kicks off the startup of applications depending on the internal state of other once - it delays the startup of late services started the normal way by systemd once the startup phase is done And yes, one could say that we are implementing a kind of second systemd started by systemd. The difference is that our starter knows about some more states than just ACTIVATING and RUNING which is not really realizable with systemd especially when more than one application is contained in one process. So the idea was to bring up a set of applications with our starter application and stay with our starter in state ACTIVATING until it is done with bringing up the set of applications. Depending on the product, bringing up our set of applications can take 10-20secs. Since the starter is a kind of sensible application, it needs to be supervised by a watchdog with a timeout far less than 20secs. Hope this gives a rough picture of our use case. Umut I guess there should be a second watchdog configuration parameter to allow services to use different values for the states ACTIVATING and RUNING. Otherwise, people who are not interested in having a watchdog observation during startup will run into troubles ... Any opinions on that? Best regards Marko Hoyer Advanced Driver Information Technology GmbH Software Group II (ADITG/SW2) Robert-Bosch-Str. 200 31139 Hildesheim Germany Tel. +49 5121 49 6948 Fax +49 5121 49 6999 mho...@de.adit-jv.com javascript:; ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car Multimedia GmbH and DENSO Corporation Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 Geschaeftsfuehrung: Wilhelm Grabow, Katsuyoshi Maeda ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org javascript:; http://lists.freedesktop.org/mailman/listinfo/systemd-devel Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH/RFC] FuseMAC: user space MAC in systemd
Intercept and filter filesystem operations of processes launched
by systemd with FUSE.
Implement learning, enforcing and auto enforcing/learning modes,
enabled with new exec directive FuseMAC.
FS operations can be filtered by access type (e.g. getattr/read,
cf. AppArmor or TOMOYO Linux) or for more fine grained control,
which area of the file is being accessed.
Due to limitations of FUSE, API file systems can't be intercepted.
Also the patch seems to trigger bugs in kernel (hang CPU).
---
Makefile.am |9 +-
configure.ac | 13 +
src/core/dbus-execute.c |3 +
src/core/execute.c| 22 +
src/core/execute.h| 16 +
src/core/fusemac.c| 1118 +
src/core/load-fragment-gperf.gperf.m4 |5 +-
src/core/load-fragment.c | 31 +
src/core/load-fragment.h |1 +
src/shared/build.h|9 +-
src/shared/exit-status.c |3 +
src/shared/exit-status.h |1 +
src/shared/util.c |2 +-
src/shared/util.h |2 +
14 files changed, 1231 insertions(+), 4 deletions(-)
create mode 100644 src/core/fusemac.c
diff --git a/Makefile.am b/Makefile.am
index 9d41a2c..61598bf 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1186,6 +1186,11 @@ libsystemd_core_la_SOURCES = \
src/core/failure-action.c \
src/core/failure-action.h
+if HAVE_FUSE
+libsystemd_core_la_SOURCES += \
+ src/core/fusemac.c
+endif
+
nodist_libsystemd_core_la_SOURCES = \
src/core/load-fragment-gperf.c \
src/core/load-fragment-gperf-nulstr.c
@@ -1198,6 +1203,7 @@ libsystemd_core_la_CFLAGS = \
$(APPARMOR_CFLAGS) \
$(SECCOMP_CFLAGS) \
$(MOUNT_CFLAGS) \
+ $(FUSE_CFLAGS) \
-pthread
libsystemd_core_la_LIBADD = \
@@ -1211,7 +1217,8 @@ libsystemd_core_la_LIBADD = \
$(KMOD_LIBS) \
$(APPARMOR_LIBS) \
$(SECCOMP_LIBS) \
- $(MOUNT_LIBS)
+ $(MOUNT_LIBS) \
+ $(FUSE_LIBS)
if HAVE_SECCOMP
libsystemd_core_la_LIBADD += \
diff --git a/configure.ac b/configure.ac
index 419b5d4..12d7937 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1332,6 +1332,19 @@ AC_ARG_ENABLE(ldconfig,
AM_CONDITIONAL(ENABLE_LDCONFIG, [test x$enable_ldconfig = xyes])
#
--
+have_fuse=no
+AC_ARG_ENABLE(fuse, AS_HELP_STRING([--disable-fuse], [Disable optional FUSE
support]))
+if test x$enable_fuse != xno; then
+PKG_CHECK_MODULES(FUSE, [ fuse ],
+[AC_DEFINE(HAVE_FUSE, 1, [Define if FUSE is available])
have_fuse=yes], have_fuse=no)
+if test x$have_fuse = xno -a x$enable_fuse = xyes; then
+AC_MSG_ERROR([*** FUSE support requested but libraries not
found])
+fi
+M4_DEFINES=$M4_DEFINES -DHAVE_FUSE
+fi
+AM_CONDITIONAL(HAVE_FUSE, [test $have_fuse = yes])
+
+#
--
# Location of the init scripts as mandated by LSB
SYSTEM_SYSVINIT_PATH=/etc/init.d
SYSTEM_SYSVRCND_PATH=/etc/rc.d
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index a9f7971..9611f29 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -49,6 +49,8 @@ static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_exec_input,
exec_input, ExecInp
static BUS_DEFINE_PROPERTY_GET_ENUM(bus_property_get_protect_home,
protect_home, ProtectHome);
static BUS_DEFINE_PROPERTY_GET_ENUM(bus_property_get_protect_system,
protect_system, ProtectSystem);
+static BUS_DEFINE_PROPERTY_GET_ENUM(bus_property_get_fusemac_mode,
fusemac_mode, FuseMAC);
+
static int property_get_environment_files(
sd_bus *bus,
const char *path,
@@ -665,6 +667,7 @@ const sd_bus_vtable bus_exec_vtable[] = {
SD_BUS_PROPERTY(RestrictAddressFamilies, (bas),
property_get_address_families, 0, SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(RuntimeDirectoryMode, u, bus_property_get_mode,
offsetof(ExecContext, runtime_directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(RuntimeDirectory, as, NULL, offsetof(ExecContext,
runtime_directory), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(FuseMAC, s, bus_property_get_fusemac_mode,
offsetof(ExecContext, fusemac_mode), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_VTABLE_END
};
diff --git a/src/core/execute.c b/src/core/execute.c
index 39ec5ad..08686bd 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1600,9 +1600,19 @@ static int exec_child(
log_close();
} else if (r 0) {
*exit_status = EXIT_NAMESPACE;
+
+}
+}
+
+#ifdef HAVE_FUSE
+if (context-fusemac_mode != FUSEMAC_NO) {
+r =
Re: [systemd-devel] [PATCH] po: update Russian translation
On 2 March 2015 at 13:04, Sergey Ptashnick 0comff...@inbox.ru wrote: On 02.03.2015 02:26, Ivan Shapovalov wrote: Hmm... Here (and in similar cases below) the comma should not be used, because для is just a preposition and hence для управления does not introduce neither a subordinate clause; it's a word in genitive case. Such form used also in other statements. If you think that removing this comma will improve readability, please prepare patch for all of them. (I don't think so, and leave this to your discretion.) If it was up to me, I'd switch the sentence around: Необходимо пройти аутентификацию для управления виртуальными машинами и контейнерами. I also wouldn't want to see foreign bored terms like менеджер and юнит used in translation and instead use e.g. управляющий and единица. But I'm not a sysadmin in a Russian speaking environment, so I cannot judge whether the foreign terms are actually already wide-spread in IT context and became de-facto terms. -- Regards, Dimitri. Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update Russian translation
On 02.03.2015 02:26, Ivan Shapovalov wrote: Hmm... Here (and in similar cases below) the comma should not be used, because для is just a preposition and hence для управления does not introduce neither a subordinate clause; it's a word in genitive case. Such form used also in other statements. If you think that removing this comma will improve readability, please prepare patch for all of them. (I don't think so, and leave this to your discretion.) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr
On Mon, 02.03.15 06:56, Peter Paule (systemd-de...@fedux.org) wrote: Hi, is it ok for you to have a configuration file for machined? It would be wonderful if one could add the dkr index url to that file because for me it's always the same. You can specify it at build time as a configure parameter. And maybe you could also support multiple values for the url to support private and public registries at the same time: 1. Lookup the name of the dkr image at the first registry 2. Return if found 3. Go on with info message if not found 4. Lookup the name of the dkr image at the second registry 5. Return if found 6. Fail with error message if not found Does this makes sense to you? I am not really sure, it sounds slightly problematic regarding security since it would not be clear anymore what you get if you ask for a specific name. 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] Errors using machinectl pull-tar and machinectl pull-dkr
Quoting Lennart Poettering lenn...@poettering.net: Thanks for clarifying this. :-) Any ETA for this? I'm looking for better integrated solution into systemd than docker and I really like the idea of having a systemd-daemon managing the containers. This is actually in place now in git. The first time you invoke one of the machinectl pull-xyz commands we create /var/lib/machines.raw as loop back file with btrfs inside which is then mounted to /var/lib/machines. With the machinectl set-limit command you can then set the size of this file dynamically, which resizes the btrfs and the loopback file, as well as the btrfs quota settings inside. It's really nice to use. Next step: make the file grow automatically during pull, if a certain fill level of the file system is reached. Great. Thanks for that. Do you always create that loop back file or only if on non-btrfs-filesystems? Do you have a solution for the trustdb-stuff already? I only found this in the manual for gnupg2: --trustdb-name file Use file instead of the default trustdb. If file begins with a tilde and a slash, these are replaced by the $HOME directory. If the filename does not contain a slash, it is assumed to be in the GnuPG home directory (‘~/.gnupg’ if --homedir or $GNUPGHOME is not used). Maybe you should just create your own trustdb-file and ship it as well or create it on the first run of machined. There was no other obvious option for that I found. But I'm not really a gpg-pro. Maybe some other guy has a better idea about solving this thing. BTW: Even RHEL 6.6 ships with gpg2 already. Do you really need to support gpg1? :-) Be aware: I think I send one of my mails in this thread directly to you (by accident) and forgot to add the mailinglist. Fixed that with this mail. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] heads-up: chasing journal(?) related regression in 219 causing boot hang/fail
Hey Lennart, Lennart Poettering [2015-02-28 13:05 +0100]: Any idea about the details of this? For the record, I'm still working on this on-and-off (I got some other urgent things to work on, though). It took me a while to install Fedora, as the rawhide images and upgrade are both broken ATM, but I now have F21 with rawhide's dbus and systemd in a VM. That's fairly close to Debian sid plus systemd from experimental. We did get reports about that hang under Debian, so it's at least likely that Fedora is affected too. But so far my simple reproducer doesn't trigger it under either, so I need to keep digging and experimenting, and probably go with the full reboot test iterations. Of course I'll follow up here once I find out more. 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] Errors using machinectl pull-tar and machinectl pull-dkr
On Mon, 02.03.15 11:00, Peter Paule (systemd-de...@fedux.org) wrote: Quoting Lennart Poettering lenn...@poettering.net: Thanks for clarifying this. :-) Any ETA for this? I'm looking for better integrated solution into systemd than docker and I really like the idea of having a systemd-daemon managing the containers. This is actually in place now in git. The first time you invoke one of the machinectl pull-xyz commands we create /var/lib/machines.raw as loop back file with btrfs inside which is then mounted to /var/lib/machines. With the machinectl set-limit command you can then set the size of this file dynamically, which resizes the btrfs and the loopback file, as well as the btrfs quota settings inside. It's really nice to use. Next step: make the file grow automatically during pull, if a certain fill level of the file system is reached. Great. Thanks for that. Do you always create that loop back file or only if on non-btrfs-filesystems? Only on non-btrfs. Do you have a solution for the trustdb-stuff already? I only found this in the manual for gnupg2: --trustdb-name file Use file instead of the default trustdb. If file begins with a tilde and a slash, these are replaced by the $HOME directory. If the filename does not contain a slash, it is assumed to be in the GnuPG home directory (‘~/.gnupg’ if --homedir or $GNUPGHOME is not used). I wonder if we can use --trustdb-name /dev/null Maybe you should just create your own trustdb-file and ship it as well or create it on the first run of machined. There was no other obvious option for that I found. But I'm not really a gpg-pro. Maybe some other guy has a better idea about solving this thing. BTW: Even RHEL 6.6 ships with gpg2 already. Do you really need to support gpg1? :-) Well, gpg1 is kinda the default on FEdora at least since it is installed as /usr/bin/gpg... We can of course switch to gpg2 instead, but that's a package that is not as frequently installed I think. Hence maybe a scheme where we use /usr/bin/gpg with a fallback to /usr/bin/gpg2 might work. 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] Errors using machinectl pull-tar and machinectl pull-dkr
Quoting Lennart Poettering lenn...@poettering.net: I wonder if we can use --trustdb-name /dev/null I think, no. I got a weird error using /dev/null % strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring --no-auto-key-locate --no-auto-check-trustdb --batch --trust-model=always --keyring=/usr/lib/systemd/import-pubring.gpg --verify ~/data/halde/signature.sig --trustdb-name /dev/null trusty-server-cloudimg-amd64-root.tar.gz gpg: Note: '--trustdb-name' is not considered an option gpg: can't open signed data '--trustdb-name' gpg: can't hash datafile: No such file or directory % strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring --no-auto-key-locate --no-auto-check-trustdb --batch --trust-model=always --keyring=/usr/lib/systemd/import-pubring.gpg --verify ~/data/halde/signature.sig trusty-server-cloudimg-amd64-root.tar.gz gpg: Signature made Sat 28 Feb 2015 02:07:02 CET using RSA key ID 7DB87C81 gpg: BAD signature from UEC Image Automatic Signing Key cdim...@ubuntu.com [unknown] /pp ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: fix Inappropriate ioctl for device on ext4
On Mon, Mar 02, 2015 at 03:58:48AM +0300, Ivan Shapovalov wrote: On 2015-03-01 at 21:13 -0300, Cristian Rodríguez wrote: Logs constantly show systemd-journald[395]: Failed to set file attributes: Inappropriate ioctl for device This is because ext4 does not support FS_NOCOW_FL. --- src/journal/journal-file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c index 9c9a548..ecabfd3 100644 --- a/src/journal/journal-file.c +++ b/src/journal/journal-file.c @@ -2610,7 +2610,8 @@ int journal_file_open( * checksumming). */ r = chattr_fd(f-fd, true, FS_NOCOW_FL); if (r 0) -log_warning_errno(errno, Failed to set file attributes: %m); +if(r != -ENOTTY) Maybe it's better to just say if (r 0 r != -ENOTTY) here? Just nitpicking, Yeah, it is. Applied, with the suggested change. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
On Mon, 02.03.15 09:45, Jordan Hargrave (jhar...@gmail.com) wrote: There are currently two competing naming mechanisms for network cards, biosdevname and systemd. Systemd currently has some limitations on naming cards that use network partitioning or support SR-IOV. Proposal is to add support for biosdevname-like names as part of systemd. The names would be created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could then be used in the udev rules scripts to replace the external biosdevname handler. No. We didn't adopt the biosdevname names in udev since they didn't actually deliver what they claimed to deliver, and resorted to naming things after probing order in the end. Use biosdevname if you want biosdevname names, it still works. Sorry, but this has no place in systemd/udev. We didn't adopt the names for a reason. At least on Dell systems, systemd generates unusable names (PCI B:D:F vs Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, but they do have a SMBIOS slot number. unusable? Can you elaborate what you mean by that? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd
It would be nice if systemd could discover and display enclosure/bay slot mappings for drives in the system. The /dev/disk/by-path method doesn't quite work, for SAS drives the ID can change on hotplug. The slot mapping also doesn't handle PCIe SSD devices as they are bare block devices and don't use SCSI midlayer. Proposing to add support for something like /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Proposal: Add biosdevname naming scheme to systemd
There are currently two competing naming mechanisms for network cards, biosdevname and systemd. Systemd currently has some limitations on naming cards that use network partitioning or support SR-IOV. Proposal is to add support for biosdevname-like names as part of systemd. The names would be created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could then be used in the udev rules scripts to replace the external biosdevname handler. At least on Dell systems, systemd generates unusable names (PCI B:D:F vs Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, but they do have a SMBIOS slot number. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd
В Mon, 2 Mar 2015 09:48:51 -0600 Jordan Hargrave jhar...@gmail.com пишет: It would be nice if systemd could discover and display enclosure/bay slot mappings for drives in the system. The /dev/disk/by-path method doesn't quite work, for SAS drives the ID can change on hotplug. The slot mapping also doesn't handle PCIe SSD devices as they are bare block devices and don't use SCSI midlayer. Proposing to add support for something like /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices. How it should be discovered? Is there universal method that can be used on majority of systems? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd
On Mon, Mar 2, 2015 at 10:24 AM, Andrei Borzenkov arvidj...@gmail.com wrote: В Mon, 2 Mar 2015 09:48:51 -0600 Jordan Hargrave jhar...@gmail.com пишет: It would be nice if systemd could discover and display enclosure/bay slot mappings for drives in the system. The /dev/disk/by-path method doesn't quite work, for SAS drives the ID can change on hotplug. The slot mapping also doesn't handle PCIe SSD devices as they are bare block devices and don't use SCSI midlayer. Proposing to add support for something like /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices. How it should be discovered? Is there universal method that can be used on majority of systems? For Dell system PCIE SSD it requires using ipmitool OEM command to get the correct Bus:Device:Function to Enclosure:Slot mapping. For devices using SAS controllers it's a bit more tricky. There is a sysfs variable for enclosure/slot in sysfs for SAS devices with 8 drives on our servers. The driver for some reason doesn't export this info for Dell systems with 8 drives. Ideally there should be an enclosure.c device defined for every device type. Currently only ses.c seems to use this, but SCSI enclosure services aren't available on SSDs. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd
On Mon, Mar 2, 2015 at 12:48 PM, Jordan Hargrave jhar...@gmail.com wrote: It would be nice if systemd could discover and display enclosure/bay slot mappings for drives in the system. The /dev/disk/by-path method doesn't quite work, for SAS drives the ID can change on hotplug. The slot mapping also doesn't handle PCIe SSD devices as they are bare block devices and don't use SCSI midlayer. Proposing to add support for something like /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices. As far as I am aware, no new things dealing with storage naming rules will be added to udev/systemd, it has to go to whatever other project..(sg3_utils last time I checked) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to remove images using machinectl
On Mon, 02.03.15 11:06, Erik Johnson (e...@saltstack.com) wrote: I'm getting a similar error to the one described in the following post from a couple weeks ago: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html I get an access denied error when running machinectl remove, even as root. This was a bug in the dbus policy. It should be fixed with this commit: http://cgit.freedesktop.org/systemd/systemd/commit/src/machine/org.freedesktop.machine1.conf?id=72c3897f77a7352618ea76b880a6764f52d6327b Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unable to remove images using machinectl
I'm getting a similar error to the one described in the following post from a couple weeks ago: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html I get an access denied error when running machinectl remove, even as root. For reference, /var/lib/machines is on a btrfs partition and I am running systemd 219 on an Arch Linux host. I am, however, unexperienced with btrfs and may have done something wrong. I did not manually create any subvolumes. I tried stopping systemd-machined and running it under strace to check for permission errors as mentioned by Lennart in the reply to the thread I referenced above. But to my surprise, when I attempted to remove the container I did not get the same permission error and the container was successfully removed. So, it occurs to me that the issue might have to do with the options in the unit file. Below are the contents of the unit file, with the commented lines at the beginning removed for brevity. Any insight that can be offered would be appreciated. [Unit] Description=Virtual Machine and Container Registration Service Documentation=man:systemd-machined.service(8) Documentation=http://www.freedesktop.org/wiki/Software/systemd/machined Wants=machine.slice After=machine.slice [Service] ExecStart=/usr/lib/systemd/systemd-machined BusName=org.freedesktop.machine1 CapabilityBoundingSet=CAP_KILL CAP_SYS_PTRACE CAP_SYS_ADMIN CAP_SETGID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH WatchdogSec=1min PrivateTmp=yes PrivateDevices=yes PrivateNetwork=yes ProtectSystem=full ProtectHome=yes -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com pgp0FuM9AKBoY.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd
Hi Jordan, On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave jhar...@gmail.com wrote: There are currently two competing naming mechanisms for network cards, biosdevname and systemd. Systemd currently has some limitations on naming cards that use network partitioning or support SR-IOV. Could you point to an example so we can fix it? I thought all bug reports had been handled, but maybe I lost track of something. Proposal is to add support for biosdevname-like names as part of systemd. The names would be created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could then be used in the udev rules scripts to replace the external biosdevname handler. I don't think this makes much sense. If biosdevname had been acceptable, the udev naming scheme would not have been introduced in the first place. At least on Dell systems, systemd generates unusable names (PCI B:D:F vs Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, but they do have a SMBIOS slot number. Wouldn't the better approach be to simply add SMBIOS support to udev then? I must admit I don't know what challenges that entails, but seems like a natural first step. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tmpfiles.d specifier support on argument when operating on files
On Wed, Feb 18, 2015 at 06:17:17PM -0300, Cristian Rodríguez wrote:
El 18/02/15 a las 07:10, Lennart Poettering escribió:
On Tue, 17.02.15 17:35, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
Please fix this for all arguments, not just symlinks.
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index c948d4d..1b35b8e 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1590,6 +1590,12 @@ static int parse_line(const char *fname, unsigned
line, const char *buffer) {
i.argument = strappend(/usr/share/factory/,
i.path);
if (!i.argument)
return log_oom();
+} else {
+r = specifier_printf(i.argument,
specifier_table, NULL, i.argument);
Here's a memory leak, you need to free the old i.argument.
Indentation! Please have a look at CODING_STYLE. You need to indent by
8ch. 4ch indenting is not acceptable.
+if (r 0) {
+log_error([%s:%u] Failed to replace specifiers:
%s, fname, line, path);
+return r;
+}
HI again:
Is the attached version cool for you ?
Hi,
sorry for the delay. We seem to have trouble getting all patches
reviewed recently. Hopefully this is just
conferences/vacations/fedora-alpha-releases, and things will
return to normal.
From ee8e4f440def745b6f0655b897e65d48321e46c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= crrodrig...@opensuse.org
Date: Wed, 18 Feb 2015 18:09:16 -0300
Subject: [PATCH] tmpfiles: implement specifier substitution for file
argument
Only for L and C types where it makes sense.
---
src/tmpfiles/tmpfiles.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 88ba7e4..6de477b 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1568,6 +1568,18 @@ static int parse_line(const char *fname, unsigned
line, const char *buffer) {
}
}
+if(IN_SET(i.type, CREATE_SYMLINK, COPY_FILES)) {
Please add a space after if and for...
+if(i.argument) {
+_cleanup_free_ char *resolved_iarg = NULL;
...and empty line after variable declarations.
+r = specifier_printf(i.argument, specifier_table,
NULL, resolved_iarg);
+if(r 0)
+return log_error_errno(r, [%s:%u] Failed to
replace specifiers: %s, fname, line, path);
+r = free_and_strdup(i.argument, resolved_iarg);
There's no need to to use free_and_strdup here. resolved_arg was just
newly allocated, so it can be used without any strdup.
+if(r 0)
+return log_oom();
+}
+}
+
switch (i.type) {
Otherwise looks OK.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Proposal: Add Drive Enclosure/Slot mapping to systemd
On Mon, 02.03.15 15:33, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: On Mon, Mar 2, 2015 at 12:48 PM, Jordan Hargrave jhar...@gmail.com wrote: It would be nice if systemd could discover and display enclosure/bay slot mappings for drives in the system. The /dev/disk/by-path method doesn't quite work, for SAS drives the ID can change on hotplug. The slot mapping also doesn't handle PCIe SSD devices as they are bare block devices and don't use SCSI midlayer. Proposing to add support for something like /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices. As far as I am aware, no new things dealing with storage naming rules will be added to udev/systemd, it has to go to whatever other project..(sg3_utils last time I checked) Well, that's not precisely true. Yes, more exotic stuff like SCSI/SAS should be maintained elsewhere, like in sg3_utils, but if something is common enough, so that it used on a large percentage of systems (like SATA), then we of course will support this in systemd/udev natively. 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] Proposal: Add Drive Enclosure/Slot mapping to systemd
On Mon, Mar 2, 2015 at 5:42 PM, Jordan Hargrave jhar...@gmail.com wrote: On Mon, Mar 2, 2015 at 10:24 AM, Andrei Borzenkov arvidj...@gmail.com wrote: В Mon, 2 Mar 2015 09:48:51 -0600 Jordan Hargrave jhar...@gmail.com пишет: It would be nice if systemd could discover and display enclosure/bay slot mappings for drives in the system. The /dev/disk/by-path method doesn't quite work, for SAS drives the ID can change on hotplug. The slot mapping also doesn't handle PCIe SSD devices as they are bare block devices and don't use SCSI midlayer. Proposing to add support for something like /dev/disk/by-enclosure/encl-XXX-slot-YYY symlink for block devices. How it should be discovered? Is there universal method that can be used on majority of systems? For Dell system PCIE SSD it requires using ipmitool OEM command to get the correct Bus:Device:Function to Enclosure:Slot mapping. For devices using SAS controllers it's a bit more tricky. There is a sysfs variable for enclosure/slot in sysfs for SAS devices with 8 drives on our servers. The driver for some reason doesn't export this info for Dell systems with 8 drives. Ideally there should be an enclosure.c device defined for every device type. Currently only ses.c seems to use this, but SCSI enclosure services aren't available on SSDs. Sounds like something the kernel could/should expose in some uniform way, no? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr
On Mon, 02.03.15 12:28, Peter Paule (systemd-de...@fedux.org) wrote: Quoting Lennart Poettering lenn...@poettering.net: I wonder if we can use --trustdb-name /dev/null I think, no. I got a weird error using /dev/null % strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring --no-auto-key-locate --no-auto-check-trustdb --batch --trust-model=always --keyring=/usr/lib/systemd/import-pubring.gpg --verify ~/data/halde/signature.sig --trustdb-name /dev/null trusty-server-cloudimg-amd64-root.tar.gz gpg: Note: '--trustdb-name' is not considered an option gpg: can't open signed data '--trustdb-name' gpg: can't hash datafile: No such file or directory % strace -e file -o /tmp/blub1 gpg --no-options --no-default-keyring --no-auto-key-locate --no-auto-check-trustdb --batch --trust-model=always --keyring=/usr/lib/systemd/import-pubring.gpg --verify ~/data/halde/signature.sig trusty-server-cloudimg-amd64-root.tar.gz gpg: Signature made Sat 28 Feb 2015 02:07:02 CET using RSA key ID 7DB87C81 gpg: BAD signature from UEC Image Automatic Signing Key cdim...@ubuntu.com [unknown] I have now added some code to git that should make the logic work with both gpg 1 and gpg 2. I now create a throw-away home directory in /tmp to use with gpg's --homedir= parameter, and remove it right after gpg ran. gpg can then create whatever it wants there, and I'll remove it right after. 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] Service watchdog feature in state ACTIVATING ?
Hi Marko, On Sunday, March 1, 2015, Hoyer, Marko (ADITG/SW2) mho...@de.adit-jv.com wrote: Hi, I ran into a use case where the activation phase of a service takes significantly longer than the desired watchdog period (Activating: 10-20secs, Watchdog: 1-5secs). I found out that the watchdog features starts not before the service is in state START_POST. This means for my use case that the system is blind for 10-20secs (whatever I set as startup timeout here). Is there any way to activate the watchdog feature already in phase ACTIVATING? Why would you need this? Watchdog is to prevent system being stuck somewhere. If activation fails within TimeoutStartSec=, systemd will put the service in failed to activate state anyways. Is waiting 20 seconds to detect the freeze is too much for your case? Is it not possible to lower the activation time? Umut I guess there should be a second watchdog configuration parameter to allow services to use different values for the states ACTIVATING and RUNING. Otherwise, people who are not interested in having a watchdog observation during startup will run into troubles ... Any opinions on that? Best regards Marko Hoyer Advanced Driver Information Technology GmbH Software Group II (ADITG/SW2) Robert-Bosch-Str. 200 31139 Hildesheim Germany Tel. +49 5121 49 6948 Fax +49 5121 49 6999 mho...@de.adit-jv.com javascript:; ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car Multimedia GmbH and DENSO Corporation Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 Geschaeftsfuehrung: Wilhelm Grabow, Katsuyoshi Maeda ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org javascript:; 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] Systemd-219: Failed to start Create Volatile...
Hi all, I'm using this tip to solve problem in systemd-TMPFILES-setup.service: http://forums.gentoo.org/viewtopic-t-1011254-view-previous.html?sid=4a7ba76e913f996abfa6e09aee95 http://www.google.com/url?q=http%3A%2F%2Fforums.gentoo.org%2Fviewtopic-t-1011254-view-previous.html%3Fsid%3D4a7ba76e913f996abfa6e09aee95sa=Dsntz=1usg=AFQjCNEAeFsiM_50wA7SSsdJej8T6aPpQA So I commented the following lines in systemd.conf file: # a+ /var/log/journal/%m - - - - d:group:adm:r-x,d:group:wheel:r-x # A+ /var/log/journal/%m - - - - group:adm:r-x,group:wheel:r-x Now the service is starting correctly :) *# **Active: active (exited) since Seg 2015-03-02 13:37:04 BRT; 3h 1min ago* I do not understand the failure, nor why it occurs, not even because this solution solved .. :( Anyway, what is the relationship between TMPFILES and journal? Atenciosamente * RICARDO BASTOS CAMPOS * Análise e Desenvolvimento de Sistemas MS Researcher at INF in P arallel and D istributed P rocessing Systems (UFRGS) Porto Alegre, RS - Brasil ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
