Re: [systemd-devel] [systemd-commits] 5 commits - configure.ac Makefile.am src/analyze src/bus-proxyd src/cgtop src/core src/delta src/journal src/journal-remote src/libsystemd src/libsystemd-network
On Mon, Sep 15, 2014 at 07:30:26AM -0700, Michal Schmidt wrote: commit f44541bc934c6e2b0219e9eeb17a13a09558 Author: Michal Schmidt mschm...@redhat.com Date: Fri Aug 15 16:33:03 2014 +0200 build: colorize gcc only if on tty Rather than forcing gcc to always produce colorized error messages whether on tty or not, enable automatic colorization by ensuring GCC_COLORS is set to a non-empty string. Doing it this way removes the need for workarounds in ~/.emacs or ~/.vimrc for M-x compile or :make, respectively, to work. Hi, this idea was discussed and rejected before, because with this change standard 'make -j8' does not produce color output anymore. So working around this in the editor is a better option. Also, it only needs to be done once, so is not such a huge problem. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - configure.ac Makefile.am src/analyze src/bus-proxyd src/cgtop src/core src/delta src/journal src/journal-remote src/libsystemd src/libsystemd-network
[sorry for the double post] On Mon, Sep 15, 2014 at 07:30:26AM -0700, Michal Schmidt wrote: commit f44541bc934c6e2b0219e9eeb17a13a09558 Author: Michal Schmidt mschm...@redhat.com Date: Fri Aug 15 16:33:03 2014 +0200 build: colorize gcc only if on tty Rather than forcing gcc to always produce colorized error messages whether on tty or not, enable automatic colorization by ensuring GCC_COLORS is set to a non-empty string. Doing it this way removes the need for workarounds in ~/.emacs or ~/.vimrc for M-x compile or :make, respectively, to work. Hi, this idea was discussed and rejected before, because with this change standard 'make -j8' does not produce color output anymore. So working around this in the editor is a better option. Also, it only needs to be done once, so is not such a huge problem. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - configure.ac Makefile.am src/analyze src/bus-proxyd src/cgtop src/core src/delta src/journal src/journal-remote src/libsystemd src/libsystemd-network
On 09/16/2014 12:07 PM, Zbigniew Jędrzejewski-Szmek wrote: Rather than forcing gcc to always produce colorized error messages whether on tty or not, enable automatic colorization by ensuring GCC_COLORS is set to a non-empty string. Hi, this idea was discussed and rejected before, because with this change standard 'make -j8' does not produce color output anymore. Was the discussion on the mailing list? I could not find it. The coloring with make -j8 works for me on Fedora and Debian. Is there a deciding factor I am missing? Wouldn't the lack of colors in this case be a bug in gcc and/or make? Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] [WIP] [kdbus] Attempt to recursively pass fd
Hi On Mon, Sep 15, 2014 at 11:53 PM, Daniel Mack dan...@zonque.org wrote: We might eventually allow this once we have a generic GC implementation for file descriptors (currently, there's only one, and that one only works for unix domain sockets). For now, we'll also need something that disallows passing kdbus handles over UDS. The patch looks good. But I doubt we can fix this via a GC implementation. I mean, there is no natural way to limit the recursion level. If we recursively open an FD and queue the previous one into it, we end up eating all kernel memory, but *all* FDs are still retrievable! If we stop at like 10k FDs, you can still recursively read all the queued FDs again, one per FD. What I'm saying is, if we allow queuing kdbus FDs on kdbus, we need a fixed recursion level or we have to account the user for the underlying file even if they close it. The fixed recursion level for unix sockets is not reliable, though. If you look at the kernel patch, you see they only reset the recursion level if the queue is emptied, not if the offending messaged is read. That is, if you queue a message with recursion-level 4, then one without any FD, but only the first message is read (that is, the real recursion level is 0 now), you cannot queue this FD anywhere else. The effective recursion level is still 4, as is only reset if that non-offending message is read, too. They had to do this, as computing the real recursion level is not doable in O(1), but O(n) (n is queue-length) and they cannot break backwards-compatibility. So I think your kdbus patch is the way to go. And if we every want to allow passing kdbus over kdbus, I'd vote for a recursion level 1. That is, we only allow passing kdbus messages with an empty queue. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/5] Coverity fixes
Hi Thomas, On 16/09/14 08:56, Thomas H.P. Andersen wrote: Yesterday I finally got to revive the systemd Coverity project on scan.coverity.org Unfortunately to see the errors reported you need to sign up, but I will make sure to approve requests for seeing the bugs whenever they show up. Hi Philippe, I was wondering if it is possible to enable selinux for the scans? We have a lot of reports of Logically dead code. They are mostly due to selinux_unit_access_check() being defined as #define selinux_unit_access_check(unit, message, permission, error) 0 when HAVE_SELINUX is not set. See e.g. CID#1237573 I can of course just mark them as false positive but it would be better to have those code paths covered as well. Actually I was just looking at them and wondering about the same ;) You're email saved me from looking at the code to figure out why things are defined as such. Will make a build with selinux and upload sometime today. Cheers, Philippe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] sd-bus: sd_bus_message_get_errno should only return positive errno
Hi On Mon, Sep 15, 2014 at 11:15 PM, Thomas H.P. Andersen pho...@gmail.com wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com sd_bus_message_get_errno can currently return either a number of different poitive errno values (from bus-error-mapping), or a negative EINVAL if passed null as parameter. The check for null parameter was introduced in 40ca29a1370379d43e44c0ed425eecc7218dcbca at the same as the function was renamed from bus_message_to_errno and made public API. Before becoming public the function used to return only negative values. It is weird to have a function return both positive and negative errno and it generally looks like a mistake. The function is guarded by the --enable-kdbus flags so I wonder if we still have time to fix it up? It does not have any documentation yet. However, except for a few details it is just a convenient way to call sd_bus_error_get_errno which is documented to return only positive errno. This patch makes it return only positive errno and fixes up the two calls to the function that tried to cope with both positive and negative values. Look both fine with me. And yes, we can still safely break anything under --enable-kdbus. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - configure.ac Makefile.am src/analyze src/bus-proxyd src/cgtop src/core src/delta src/journal src/journal-remote src/libsystemd src/libsystemd-network
On Tue, Sep 16, 2014 at 12:29:03PM +0200, Michal Schmidt wrote: On 09/16/2014 12:07 PM, Zbigniew Jędrzejewski-Szmek wrote: Rather than forcing gcc to always produce colorized error messages whether on tty or not, enable automatic colorization by ensuring GCC_COLORS is set to a non-empty string. Hi, this idea was discussed and rejected before, because with this change standard 'make -j8' does not produce color output anymore. Was the discussion on the mailing list? I could not find it. The coloring with make -j8 works for me on Fedora and Debian. Is there a deciding factor I am missing? Wouldn't the lack of colors in this case be a bug in gcc and/or make? Maybe on IRC, don't rembember. I'll check again, maybe I have some local settings which break color output. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
Hi, consider the situation that admin has /etc/systemd/system/a.service, which includes via .include the /usr/lib/systemd/system/a.service. Then in our case there exists also packaged /usr/lib/systemd/system/a.service.d/ with existing drop-in. In this case - the setup from /etc/ is beaten by drop-in files from /usr/lib. Reproducer is in Red Hat Bugzilla [1]. I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. The use-case to make it complete: I would like to have the .include supported just for compatibility with older admin's settings. Then I would like to install two service files 'a.service' and 'a@.service', both hardlinked (ideally). The 'a.service' would diverge from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf settings. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1141824 Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
Hi Colin, This approach gives you nice flexibility and control over instance units, but still gives you the ability to start/stop individual instances and control all of them at once too! Yes, you are right. I tried this and it works pretty well. However, the knot.target can be used only for start, stop, and restart. It cannot be used for reload... :-( Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote: Hi, consider the situation that admin has /etc/systemd/system/a.service, which includes via .include the /usr/lib/systemd/system/a.service. Then in our case there exists also packaged /usr/lib/systemd/system/a.service.d/ with existing drop-in. In this case - the setup from /etc/ is beaten by drop-in files from /usr/lib. Reproducer is in Red Hat Bugzilla [1]. I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. At least not without a very good reason which would make it worth to upset existing users. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] libsystemd-network: avoid double-free in error case
Don't manually free 'n' in error path as it's already tagged
_cleanup_free_ and will be freed once it goes out of scope,
leading to double-free in this case.
Found with coverity. Fixes: CID#1237786
Signed-off-by: Andreas Henriksson andr...@fatal.se
---
src/libsystemd-network/network-internal.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/libsystemd-network/network-internal.c
b/src/libsystemd-network/network-internal.c
index 208c314..372f3ed 100644
--- a/src/libsystemd-network/network-internal.c
+++ b/src/libsystemd-network/network-internal.c
@@ -199,7 +199,6 @@ int config_parse_ifname(const char *unit,
if (!ascii_is_valid(n) || strlen(n) = IFNAMSIZ) {
log_syntax(unit, LOG_ERR, filename, line, EINVAL,
Interface name is not ASCII clean or is too long,
ignoring assignment: %s, rvalue);
-free(n);
return 0;
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tue, Sep 16, 2014 at 03:16:12PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote: Hi, consider the situation that admin has /etc/systemd/system/a.service, which includes via .include the /usr/lib/systemd/system/a.service. Then in our case there exists also packaged /usr/lib/systemd/system/a.service.d/ with existing drop-in. In this case - the setup from /etc/ is beaten by drop-in files from /usr/lib. Reproducer is in Red Hat Bugzilla [1]. I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. At least not without a very good reason which would make it worth to upset existing users. I'd like to ask why dropins are packaged in the first placed? Do you (Pavel) have some variants of the package that share common unit file? -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libsystemd-network: avoid double-free in error case
Applied. Thanks!
On Tue, Sep 16, 2014 at 3:50 PM, Andreas Henriksson andr...@fatal.se wrote:
Don't manually free 'n' in error path as it's already tagged
_cleanup_free_ and will be freed once it goes out of scope,
leading to double-free in this case.
Found with coverity. Fixes: CID#1237786
Signed-off-by: Andreas Henriksson andr...@fatal.se
We don't do s-o-b, so I dropped this line.
Cheers,
Tom
src/libsystemd-network/network-internal.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/libsystemd-network/network-internal.c
b/src/libsystemd-network/network-internal.c
index 208c314..372f3ed 100644
--- a/src/libsystemd-network/network-internal.c
+++ b/src/libsystemd-network/network-internal.c
@@ -199,7 +199,6 @@ int config_parse_ifname(const char *unit,
if (!ascii_is_valid(n) || strlen(n) = IFNAMSIZ) {
log_syntax(unit, LOG_ERR, filename, line, EINVAL,
Interface name is not ASCII clean or is too
long, ignoring assignment: %s, rvalue);
-free(n);
return 0;
}
--
2.1.0
___
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] Prioritize the /etc configuration over /usr/lib also with .include
This is reply to both Tomasz and Zbigniew, thanks for reactions! On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: On Tue, Sep 16, 2014 at 03:16:12PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote: I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. This should not be a revert. Just make it properly defined? At least not without a very good reason which would make it worth to upset existing users. Oh, yeah - that would not be nice; but the way how it is done now does not seem to be logical (and breaks otherwise nice possibilities) - so I would call it good reason (unless somebody hits me with good reason :)). I'm just not sure who we could upset - do you think there is anybody relying on the current approach? What would be the use case? On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: I'd like to ask why dropins are packaged in the first placed? Do you (Pavel) have some variants of the package that share common unit file? Look at the initial email: | Then I would like to install two service files 'a.service' and | 'a@.service', both hardlinked (ideally). The 'a.service' would diverge | from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf | settings. To make it more clear - such service 'a' would have its defaults preconfigured in package; run by `systemctl start a` and configurable 'a@whatever.service'. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tue, Sep 16, 2014 at 04:35:50PM +0200, Pavel Raiskup wrote: This is reply to both Tomasz and Zbigniew, thanks for reactions! On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: On Tue, Sep 16, 2014 at 03:16:12PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote: I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. This should not be a revert. Just make it properly defined? It was already properly defined, maybe just not explicitly documented for this case. And yes, this is used: for example tmpfiles.d/systemd.conf and tmpfiles.d/systemd-nologin.conf are split exactly for the purpose of making it easier to override separately. The case of unit files is slightly different, but we really want to have the same semantics for all configuration file overrides in systemd. At least not without a very good reason which would make it worth to upset existing users. Oh, yeah - that would not be nice; but the way how it is done now does not seem to be logical (and breaks otherwise nice possibilities) - so I would call it good reason (unless somebody hits me with good reason :)). I'm just not sure who we could upset - do you think there is anybody relying on the current approach? What would be the use case? On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: I'd like to ask why dropins are packaged in the first placed? Do you (Pavel) have some variants of the package that share common unit file? Look at the initial email: | Then I would like to install two service files 'a.service' and | 'a@.service', both hardlinked (ideally). The 'a.service' would diverge | from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf | settings. To make it more clear - such service 'a' would have its defaults preconfigured in package; run by `systemctl start a` and configurable 'a@whatever.service'. So we return to Tomasz'es question: why would you split the configuration into two files? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tuesday 16 of September 2014 16:41:49 Zbigniew Jędrzejewski-Szmek wrote: On Tue, Sep 16, 2014 at 04:35:50PM +0200, Pavel Raiskup wrote: This should not be a revert. Just make it properly defined? It was already properly defined, maybe just not explicitly documented for this case. And yes, this is used: Well, yeah .. :( ok, probably I'm doing something wrong. for example tmpfiles.d/systemd.conf and tmpfiles.d/systemd-nologin.conf are split exactly for the purpose of making it easier to override separately. The case of unit files is slightly different, but we really want to have the same semantics for all configuration file overrides in systemd. Could you please be more specific? You mean that the /usr/lib configuration should have bigger priority than /etc? At least not without a very good reason which would make it worth to upset existing users. Oh, yeah - that would not be nice; but the way how it is done now does not seem to be logical (and breaks otherwise nice possibilities) - so I would call it good reason (unless somebody hits me with good reason :)). I'm just not sure who we could upset - do you think there is anybody relying on the current approach? What would be the use case? On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: I'd like to ask why dropins are packaged in the first placed? Do you (Pavel) have some variants of the package that share common unit file? Look at the initial email: | Then I would like to install two service files 'a.service' and | 'a@.service', both hardlinked (ideally). The 'a.service' would diverge | from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf | settings. To make it more clear - such service 'a' would have its defaults preconfigured in package; run by `systemctl start a` and configurable 'a@whatever.service'. So we return to Tomasz'es question: why would you split the configuration into two files? Oh, I probably missed the purpose of the original question, really sorry then. The answer: I don't want to maintain the ugly long (configured) version 'service@DEFAULT.service'. And also it is needed to keep the compatibility with older /etc/*service files. Some users are already including our default service.service. This is becoming off-topic the original request, anyway. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Should user mode linux register with machined?
Hi, I wrote a small patch for user-mode linux to register with machined by calling CreateMachine. Is this a good idea to do so? I think machined gives you a nice overview over all running UML instances, also you get the scope unit and the control groups with above registration to machined. anything else on the plus side? The user-mode-mailing list did ask why exactly my patch is needed. So what do you think? with kind regards thomas PS: I wonder what happens when I write a service unit file that starts an user mode linux instance and that instance will register with machined? won't both control groups overlap, i.e. the scope unit and the service unit? or is this not a problem? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On 09/16/2014 01:16 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Sep 16, 2014 at 01:21:30PM +0200, Pavel Raiskup wrote: Hi, consider the situation that admin has /etc/systemd/system/a.service, which includes via .include the /usr/lib/systemd/system/a.service. Then in our case there exists also packaged /usr/lib/systemd/system/a.service.d/ with existing drop-in. In this case - the setup from /etc/ is beaten by drop-in files from /usr/lib. Reproducer is in Red Hat Bugzilla [1]. I would expect that parser starts at /etc/systemd/*/*.service, which invokes the .include ~ so '/usr/lib/*/*.service is parsed, then '/usr/lib/*/*.service.d', then remaining part of '/etc/*/*.service is parsed and as the last step, the '/etc/*/*.service.d/' dropins should be done. This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. At least not without a very good reason which would make it worth to upset existing users. The problem which was pretty obvious was going to happen when dropins got added and now is causing confusion and even breakage ( think mix match of combinations of ways to overwrite ) is that we need to reduce the means you can overwrite existing unit files to one and deprecate the other ones. Bottom line we should only have one way to do things to keep things simple not three not five not fifty. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should user mode linux register with machined?
On Tue, Sep 16, 2014 at 5:31 PM, Thomas Meyer tho...@m3y3r.de wrote: Hi, I wrote a small patch for user-mode linux to register with machined by calling CreateMachine. Is this a good idea to do so? I think machined gives you a nice overview over all running UML instances, also you get the scope unit and the control groups with above registration to machined. anything else on the plus side? The user-mode-mailing list did ask why exactly my patch is needed. The user-mode-mailing is also reading this list BTW. :) -- Thanks, //richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] missing: memfd_create takes unsigned int flags in final version
---
src/shared/missing.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index 023c680..b441149 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -209,7 +209,7 @@ static inline int fanotify_mark(int fanotify_fd, unsigned
int flags, uint64_t ma
#endif
#ifndef HAVE_MEMFD_CREATE
-static inline int memfd_create(const char *name, uint64_t flags) {
+static inline int memfd_create(const char *name, unsigned int flags) {
return syscall(__NR_memfd_create, name, flags);
}
#endif
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tuesday 16 of September 2014 16:42:32 Jóhann B. Guðmundsson wrote: On 09/16/2014 01:16 PM, Zbigniew Jędrzejewski-Szmek wrote: This would change the way that drop-ins work. Your model is not necessarily worse, but dropins have been the advertised way to do overiddes for a while, and we cannot simply revert the order in which they are applied. At least not without a very good reason which would make it worth to upset existing users. The problem which was pretty obvious was going to happen when dropins got added and now is causing confusion and even breakage No confusion on my site, I believe. Nor brakage - only avoiding future breakages. I'm just thinking about doing something better than it is done now, tbh. To not confuse you, I am just (a) trying to get rid of .include statement we supported so far and (b) start using drop-ins, but (c) stay compatible with .include as users are already using that. And as (d) I try to incorporate the nice additional @ unit syntax the cleanest way :). And I try to be constructive - so letting you know. ( think mix match of combinations of ways to overwrite ) is that we need to reduce the means you can overwrite existing unit files to one and deprecate the other ones. Deprecation is fine, though .. Bottom line we should only have one way to do things to keep things simple not three not five not fifty. .. that sounds like something against InterfaceStabilityPromise in this context. And it is definitely not something any of us wants. Pavel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bootchart: oom-check correct variable
Coverity warned that we have already dereferenced ps-sample before
null-checking it. I suspect that's not really the issue and that
the check is checking the wrong variable.
Likely the oom-check should be on the just allocated ps-sample-next.
Found by coverity. Fixes: CID#1237765
---
src/bootchart/store.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bootchart/store.c b/src/bootchart/store.c
index 2d2ea42..e6aafd8 100644
--- a/src/bootchart/store.c
+++ b/src/bootchart/store.c
@@ -394,7 +394,7 @@ schedstat_next:
continue;
ps-sample-next = new0(struct ps_sched_struct, 1);
-if (!ps-sample) {
+if (!ps-sample-next) {
log_oom();
exit(EXIT_FAILURE);
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bootchart: oom-check correct variable
Applied.
Thanks!
Tom
On Tue, Sep 16, 2014 at 7:40 PM, Andreas Henriksson andr...@fatal.se wrote:
Coverity warned that we have already dereferenced ps-sample before
null-checking it. I suspect that's not really the issue and that
the check is checking the wrong variable.
Likely the oom-check should be on the just allocated ps-sample-next.
Found by coverity. Fixes: CID#1237765
---
src/bootchart/store.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bootchart/store.c b/src/bootchart/store.c
index 2d2ea42..e6aafd8 100644
--- a/src/bootchart/store.c
+++ b/src/bootchart/store.c
@@ -394,7 +394,7 @@ schedstat_next:
continue;
ps-sample-next = new0(struct ps_sched_struct, 1);
-if (!ps-sample) {
+if (!ps-sample-next) {
log_oom();
exit(EXIT_FAILURE);
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: fix resource leak in manager_environment_add
Second error path must free the (potentially) allocated memory in the
first code chunk before returning.
Found by coverity. Fixes: CID#1237750
---
src/core/manager.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index 0770727..e0c1cd1 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2751,8 +2751,10 @@ int manager_environment_add(Manager *m, char **minus,
char **plus) {
if (!strv_isempty(plus)) {
b = strv_env_merge(2, l, plus);
-if (!b)
+if (!b) {
+strv_free(a);
return -ENOMEM;
+}
l = b;
}
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysv-generator: fix resource leak
The unit string allocation is not freed on either error or success path.
Found by coverity. Fixes: CID#1237755
---
src/sysv-generator/sysv-generator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/sysv-generator/sysv-generator.c
b/src/sysv-generator/sysv-generator.c
index 6c3281f..e5902ab 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -114,9 +114,9 @@ static int add_symlink(const char *service, const char
*where) {
}
static int generate_unit_file(SysvStub *s) {
-char *unit;
char **p;
_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *unit = NULL;
_cleanup_free_ char *before = NULL;
_cleanup_free_ char *after = NULL;
_cleanup_free_ char *wants = NULL;
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: fix resource leak in config_parse_default_instance
The recently allocated printed is not freed on error path.
Found by coverity. Fixes: CID#1237745
---
src/shared/install.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 5d3fcf5..61e572b 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1025,8 +1025,10 @@ static int config_parse_default_instance(
if (r 0)
return r;
-if (!unit_instance_is_valid(printed))
+if (!unit_instance_is_valid(printed)) {
+free(printed);
return -EINVAL;
+}
free(i-default_instance);
i-default_instance = printed;
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] missing: memfd_create takes unsigned int flags in final version
On 09/16/2014 07:17 PM, Cristian Rodríguez wrote:
---
src/shared/missing.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/missing.h b/src/shared/missing.h
index 023c680..b441149 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -209,7 +209,7 @@ static inline int fanotify_mark(int fanotify_fd, unsigned
int flags, uint64_t ma
#endif
#ifndef HAVE_MEMFD_CREATE
-static inline int memfd_create(const char *name, uint64_t flags) {
+static inline int memfd_create(const char *name, unsigned int flags) {
return syscall(__NR_memfd_create, name, flags);
}
#endif
Applied, thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: fix resource leak in manager_environment_add
On 09/16/2014 09:11 PM, Andreas Henriksson wrote:
Second error path must free the (potentially) allocated memory in the
first code chunk before returning.
Found by coverity. Fixes: CID#1237750
---
src/core/manager.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index 0770727..e0c1cd1 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2751,8 +2751,10 @@ int manager_environment_add(Manager *m, char **minus,
char **plus) {
if (!strv_isempty(plus)) {
b = strv_env_merge(2, l, plus);
-if (!b)
+if (!b) {
+strv_free(a);
return -ENOMEM;
+}
l = b;
}
Applied, thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: fix resource leak in config_parse_default_instance
On 09/16/2014 09:36 PM, Andreas Henriksson wrote:
The recently allocated printed is not freed on error path.
Found by coverity. Fixes: CID#1237745
---
src/shared/install.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 5d3fcf5..61e572b 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1025,8 +1025,10 @@ static int config_parse_default_instance(
if (r 0)
return r;
-if (!unit_instance_is_valid(printed))
+if (!unit_instance_is_valid(printed)) {
+free(printed);
return -EINVAL;
+}
free(i-default_instance);
i-default_instance = printed;
Applied, thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: fix resource leak
On 09/16/2014 09:22 PM, Andreas Henriksson wrote:
The unit string allocation is not freed on either error or success path.
Found by coverity. Fixes: CID#1237755
---
src/sysv-generator/sysv-generator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/sysv-generator/sysv-generator.c
b/src/sysv-generator/sysv-generator.c
index 6c3281f..e5902ab 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -114,9 +114,9 @@ static int add_symlink(const char *service, const char
*where) {
}
static int generate_unit_file(SysvStub *s) {
-char *unit;
char **p;
_cleanup_fclose_ FILE *f = NULL;
+_cleanup_free_ char *unit = NULL;
_cleanup_free_ char *before = NULL;
_cleanup_free_ char *after = NULL;
_cleanup_free_ char *wants = NULL;
Applied, thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] util : Remove dead code
From: Philippe De Swert philippedesw...@gmail.com
We only break out of the pre-ceding loop into the rest of the code
if fd is actually = 0. So the 0 check will never be true and
not necessary.
Found with Coverity. Fixes: CID#1237577
---
src/shared/util.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 61d6680..30b0364 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1878,9 +1878,6 @@ int open_terminal(const char *name, int mode) {
c++;
}
-if (fd 0)
-return -errno;
-
r = isatty(fd);
if (r 0) {
safe_close(fd);
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] [RFC]sd-bus: remove some dead code
From: Philippe De Swert philippedesw...@gmail.com The r 0 test has been done before we reach it in the loop, and we returned out of the function. So this cannot be reached. But it could actually be that something is missing. --- src/libsystemd/sd-bus/bus-objects.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/libsystemd/sd-bus/bus-objects.c b/src/libsystemd/sd-bus/bus-objects.c index 81c840f..48054da 100644 --- a/src/libsystemd/sd-bus/bus-objects.c +++ b/src/libsystemd/sd-bus/bus-objects.c @@ -1180,8 +1180,6 @@ static int process_get_managed_objects( if (require_fallback !c-is_fallback) continue; -if (r 0) -return r; if (r == 0) continue; -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] journal: Do not count on the compiler initializing found_last to false
From: Philippe De Swert philippedesw...@gmail.com There is a very unlikely case where this can happen since gcc usually does the sane thing. But let's make sure found_last is initialized anyway. Fixes: CID#996386 --- src/journal/journal-verify.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/journal/journal-verify.c b/src/journal/journal-verify.c index 6c8ca8c..b4e8f73 100644 --- a/src/journal/journal-verify.c +++ b/src/journal/journal-verify.c @@ -804,7 +804,7 @@ int journal_file_verify( usec_t last_usec = 0; int data_fd = -1, entry_fd = -1, entry_array_fd = -1; unsigned i; -bool found_last; +bool found_last = false; #ifdef HAVE_GCRYPT uint64_t last_tag = 0; #endif -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] util : Remove dead code
On Tue, Sep 16, 2014 at 11:27 PM, philippedesw...@gmail.com wrote:
From: Philippe De Swert philippedesw...@gmail.com
We only break out of the pre-ceding loop into the rest of the code
if fd is actually = 0. So the 0 check will never be true and
not necessary.
Found with Coverity. Fixes: CID#1237577
I pushed a fix for this one 20 minutes ago. (I also set the CID as
assigned to me but maybe we need a better way to coordinate?)
---
src/shared/util.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 61d6680..30b0364 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1878,9 +1878,6 @@ int open_terminal(const char *name, int mode) {
c++;
}
-if (fd 0)
-return -errno;
-
r = isatty(fd);
if (r 0) {
safe_close(fd);
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] util : Remove dead code
Hi Thomas, On 17/09/14 00:36, Thomas H.P. Andersen wrote: We only break out of the pre-ceding loop into the rest of the code if fd is actually = 0. So the 0 check will never be true and not necessary. Found with Coverity. Fixes: CID#1237577 I pushed a fix for this one 20 minutes ago. (I also set the CID as assigned to me but maybe we need a better way to coordinate?) Oh yes you did. Missed it. Late night hacking ;) My mistake I should have looked at the side box. I think setting it assigned was the right way. Cheers, Philippe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] buildsys, missing: include linux/memfd.h if found
That's in order to get the system 's definitions of memfd API flags instead of relying on the locally defined ones. --- configure.ac | 1 + src/shared/missing.h | 4 2 files changed, 5 insertions(+) diff --git a/configure.ac b/configure.ac index fb16904..5ebe6ae 100644 --- a/configure.ac +++ b/configure.ac @@ -283,6 +283,7 @@ AM_CONDITIONAL([HAVE_PYTHON_DEVEL], [test $have_python_devel = yes]) AC_SEARCH_LIBS([dlsym], [dl], [], [AC_MSG_ERROR([*** Dynamic linking loader library not found])]) AC_CHECK_HEADERS([sys/capability.h], [], [AC_MSG_ERROR([*** POSIX caps headers not found])]) AC_CHECK_HEADERS([linux/btrfs.h], [], []) +AC_CHECK_HEADERS_ONCE([linux/memfd.h]) # unconditionally pull-in librt with old glibc versions AC_SEARCH_LIBS([clock_gettime], [rt], [], []) diff --git a/src/shared/missing.h b/src/shared/missing.h index b441149..9da6e71 100644 --- a/src/shared/missing.h +++ b/src/shared/missing.h @@ -45,6 +45,10 @@ #include asm/sgidefs.h #endif +#ifdef HAVE_LINUX_MEMFD_H +#include linux/memfd.h +#endif + #ifndef RLIMIT_RTTIME #define RLIMIT_RTTIME 15 #endif -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should user mode linux register with machined?
On Tue, Sep 16, 2014 at 05:31:05PM +0200, Thomas Meyer wrote: Hi, I wrote a small patch for user-mode linux to register with machined by calling CreateMachine. Is this a good idea to do so? Yes, this sounds useful. After all is just another mechanism of virtualization, and in this case can be treated similarly to containers and vms. PS: I wonder what happens when I write a service unit file that starts an user mode linux instance and that instance will register with machined? won't both control groups overlap, i.e. the scope unit and the service unit? or is this not a problem? systemd-nspawn has --keep-unit. You probably need something similar to disable the creation of scope. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Prioritize the /etc configuration over /usr/lib also with .include
On Tue, Sep 16, 2014 at 05:07:06PM +0200, Pavel Raiskup wrote: for example tmpfiles.d/systemd.conf and tmpfiles.d/systemd-nologin.conf are split exactly for the purpose of making it easier to override separately. The case of unit files is slightly different, but we really want to have the same semantics for all configuration file overrides in systemd. Could you please be more specific? You mean that the /usr/lib configuration should have bigger priority than /etc? There are two independent rules: one is that files with the same name override each other (and /etc has higher priority than /usr/lib), and second that dropins have higher priority than the basic configuration files. So to answer your question directly: no, /usr/lib configuration has lower priority, but it might still be visible if not override by a file with the same name in /etc or /run. At least not without a very good reason which would make it worth to upset existing users. Oh, yeah - that would not be nice; but the way how it is done now does not seem to be logical (and breaks otherwise nice possibilities) - so I would call it good reason (unless somebody hits me with good reason :)). I'm just not sure who we could upset - do you think there is anybody relying on the current approach? What would be the use case? On Tuesday 16 of September 2014 16:14:16 Tomasz Torcz wrote: I'd like to ask why dropins are packaged in the first placed? Do you (Pavel) have some variants of the package that share common unit file? Look at the initial email: | Then I would like to install two service files 'a.service' and | 'a@.service', both hardlinked (ideally). The 'a.service' would diverge | from 'a@.service' just by e.g. /usr/lib/systemd/a.service/50-default.conf | settings. To make it more clear - such service 'a' would have its defaults preconfigured in package; run by `systemctl start a` and configurable 'a@whatever.service'. So we return to Tomasz'es question: why would you split the configuration into two files? Oh, I probably missed the purpose of the original question, really sorry then. The answer: I don't want to maintain the ugly long (configured) version 'service@DEFAULT.service'. And also it is needed to keep the compatibility with older /etc/*service files. Some users are already including our default service.service. This is becoming off-topic the original request, anyway. I don't think that drop-ins are a solutions for this anyway. But the settings from the instance override the settings from the template. Isn't this enough? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] test: some tests to enforce routing messages by connections ID
Add kdbus_fork_test_by_id() to test connections by id under different
uids. Currently we succeed at this test.
Update:
1) kdbus_msg_recv() to get the offset of the slice, so we can
release it later.
2) kdbus_msg_recv_poll() to pass the offset argument to
kdbus_msg_recv().
We do this to follow best practice and to be able to free the returned
kdbus_msg and the slice pointed by that offset.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
Hi Daniel, before applying please make sure that we want this. It
follows what I've discussed in the other mail, otherwise just test it,
it will give a better view of the routing policy.
test/kdbus-util.c | 15 -
test/kdbus-util.h | 7 ++-
test/test-activator.c | 2 +-
test/test-chat.c| 4 +-
test/test-connection.c | 4 +-
test/test-daemon.c | 2 +-
test/test-fd.c | 2 +-
test/test-message.c | 2 +-
test/test-metadata-ns.c | 2 +-
test/test-monitor.c | 7 ++-
test/test-policy-ns.c | 160
test/test-sync.c| 2 +-
12 files changed, 166 insertions(+), 43 deletions(-)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index c72b8fe..fe4565c 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -630,6 +630,9 @@ void kdbus_msg_free(struct kdbus_msg *msg)
const struct kdbus_item *item;
int nfds, i;
+ if (!msg)
+ return;
+
KDBUS_ITEM_FOREACH(item, msg, items) {
switch (item-type) {
/* close all memfds */
@@ -648,7 +651,9 @@ void kdbus_msg_free(struct kdbus_msg *msg)
}
}
-int kdbus_msg_recv(struct kdbus_conn *conn, struct kdbus_msg **msg_out)
+int kdbus_msg_recv(struct kdbus_conn *conn,
+ struct kdbus_msg **msg_out,
+ uint64_t *offset)
{
struct kdbus_cmd_recv recv = {};
struct kdbus_msg *msg;
@@ -665,6 +670,9 @@ int kdbus_msg_recv(struct kdbus_conn *conn, struct
kdbus_msg **msg_out)
if (msg_out) {
*msg_out = msg;
+
+ if (offset)
+ *offset = recv.offset;
} else {
kdbus_msg_free(msg);
@@ -677,13 +685,14 @@ int kdbus_msg_recv(struct kdbus_conn *conn, struct
kdbus_msg **msg_out)
}
int kdbus_msg_recv_poll(struct kdbus_conn *conn,
+ unsigned int timeout_ms,
struct kdbus_msg **msg_out,
- unsigned int timeout_ms)
+ uint64_t *offset)
{
int ret;
for (; timeout_ms; timeout_ms--) {
- ret = kdbus_msg_recv(conn, NULL);
+ ret = kdbus_msg_recv(conn, msg_out, offset);
if (ret == -EAGAIN) {
usleep(1000);
continue;
diff --git a/test/kdbus-util.h b/test/kdbus-util.h
index c2370e7..8e3d0a8 100644
--- a/test/kdbus-util.h
+++ b/test/kdbus-util.h
@@ -56,9 +56,10 @@ int kdbus_name_release(struct kdbus_conn *conn, const char
*name);
int kdbus_name_acquire(struct kdbus_conn *conn, const char *name,
uint64_t flags);
void kdbus_msg_free(struct kdbus_msg *msg);
-int kdbus_msg_recv(struct kdbus_conn *conn, struct kdbus_msg **msg);
-int kdbus_msg_recv_poll(struct kdbus_conn *conn, struct kdbus_msg **msg_out,
- unsigned int timeout_ms);
+int kdbus_msg_recv(struct kdbus_conn *conn,
+ struct kdbus_msg **msg, uint64_t *offset);
+int kdbus_msg_recv_poll(struct kdbus_conn *conn, unsigned int timeout_ms,
+ struct kdbus_msg **msg_out, uint64_t *offset);
int kdbus_free(const struct kdbus_conn *conn, uint64_t offset);
void kdbus_msg_dump(const struct kdbus_conn *conn,
const struct kdbus_msg *msg);
diff --git a/test/test-activator.c b/test/test-activator.c
index eb57b52..7bdcbf3 100644
--- a/test/test-activator.c
+++ b/test/test-activator.c
@@ -79,7 +79,7 @@ int kdbus_test_activator(struct kdbus_test_env *env)
}
if (fds[1].revents POLLIN) {
- kdbus_msg_recv(env-conn, NULL);
+ kdbus_msg_recv(env-conn, NULL, NULL);
break;
}
}
diff --git a/test/test-chat.c b/test/test-chat.c
index 11c140d..b2bcc31 100644
--- a/test/test-chat.c
+++ b/test/test-chat.c
@@ -86,7 +86,7 @@ int kdbus_test_chat(struct kdbus_test_env *env)
if (count 2)
kdbus_name_release(conn_a, foo.bar.baz);
- ret = kdbus_msg_recv(conn_a, NULL);
+ ret = kdbus_msg_recv(conn_a, NULL, NULL);
ASSERT_RETURN(ret == 0);
ret = kdbus_msg_send(conn_a, NULL,
0xc000 | cookie++,
@@ -95,7 +95,7 @@ int kdbus_test_chat(struct kdbus_test_env *env)
}
if
[systemd-devel] [PATCH 2/2] test: Use 'CapBnd' string for capability bounding set
Signed-off-by: Djalal Harouni tix...@opendz.org --- test/kdbus-util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/kdbus-util.c b/test/kdbus-util.c index fe4565c..b1c5864 100644 --- a/test/kdbus-util.c +++ b/test/kdbus-util.c @@ -569,7 +569,7 @@ void kdbus_msg_dump(const struct kdbus_conn *conn, const struct kdbus_msg *msg) for (i = 0; i n; i++) kdbus_printf(%08x, cap[(2 * n) + (n - i - 1)]); - kdbus_printf( CapInh=); + kdbus_printf( CapBnd=); for (i = 0; i n; i++) kdbus_printf(%08x, cap[(3 * n) + (n - i - 1)]); kdbus_printf(\n); -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] udev: do NOT re-label smack
If selinux is disabled and smack is only enabled, smack label is relable-ed by label_fix. To avoid, make only be labeled for selinux. --- src/udev/udev-node.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/udev/udev-node.c b/src/udev/udev-node.c index f46638f..3c49482 100644 --- a/src/udev/udev-node.c +++ b/src/udev/udev-node.c @@ -313,8 +313,8 @@ static int node_permissions_apply(struct udev_device *dev, bool apply, } /* set the defaults */ -if (!selinux) -label_fix(devnode, true, false); +if (!selinux use_selinux()) +mac_selinux_fix(devnode, true, false); if (!smack) mac_smack_path(devnode, NULL); } -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/2] label: rearrange mandatory access control(MAC) apis
rebased again. It make a conflict by long pending. WaLyong Cho (2): label: rearrange mandatory access control(MAC) apis udev: do NOT re-label smack src/core/main.c | 4 +- src/core/namespace.c | 4 +- src/core/selinux-setup.c | 4 +- src/core/socket.c | 24 +-- src/hostname/hostnamed.c | 2 +- src/locale/localed.c | 2 +- src/login/logind-dbus.c | 2 +- src/shared/dev-setup.c| 4 +- src/shared/fileio-label.c | 12 +- src/shared/label.c| 445 +- src/shared/label.h| 26 +-- src/shared/mkdir-label.c | 26 +++ src/shared/mkdir.h| 2 +- src/shared/selinux-util.c | 365 +- src/shared/selinux-util.h | 14 ++ src/shared/smack-util.c | 53 - src/shared/smack-util.h | 10 +- src/shared/socket-label.c | 6 +- src/sysusers/sysusers.c | 2 +- src/test/test-udev.c | 4 +- src/timedate/timedated.c | 2 +- src/tmpfiles/tmpfiles.c | 32 +-- src/udev/udev-node.c | 18 +- src/udev/udevadm.c| 4 +- src/udev/udevd.c | 4 +- src/update-done/update-done.c | 6 +- 26 files changed, 528 insertions(+), 549 deletions(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
Hallo, On 14 September 2014 19:49, Andrei Borzenkov arvidj...@gmail.com wrote: В Thu, 11 Sep 2014 21:53:27 +0200 Tobias Geerinckx-Rice tobias.geerinckx.r...@gmail.com пишет: From my reading of the thread, this is to emulate as closely ye olde initscripts' unreliable and flawed behaviour of attempting to mount one or more devices exactly once (i.e., a one-shot mount -a), but not until an arbitrary time-out has elapsed after which all external devices are blindly assumed to have been initialised for no good reason. This thread is not about blindly assuming anything. Indeed it isn't. But the traditional application of fstab was. Badly [1]. That's not to say that it didn't happen to work most of the time. I just hoped systemd could do better. I still do. Actually, it is systemd which blindly assumes user wants to always mount device as soon at it appears. The device is in fstab, marked 'auto'. I submit that's closer to a reasonable assumption than a blind one -- however... This isn't hard to achieve with systemd, In case you missed it - it is impossible to achieve with systemd right now. At least, it is impossible to achieve what the goal of OP was - attempt to automount device exactly once on system boot and give up if it was not successful. ...yeah. Sorry. Quick story: for some unholy reason, the vintage Arch VM I last used to test this always did the Right Thing: - Add a nofail fstab line, boot with the device present. - Verify that it was 'auto'-mounted. umount and (physically) unplug it. - Plug it back in. The device has the same path and active unit. - Yet nothing is mounted. All is well, if you like it that way. Now, of course, that VM is gone. And now, with exactly the same (logged) commands, the device is indeed silently mounted. Every time. Even with old systemd. Grr. Now: is always mounting better than the old behaviour? -- Still think so. Is it different from how everyone historically expects fstab to work, and therefore confusing as hell until either properly documented or (meh) made configurable? -- Hell yes. Regardless: sorry for any noise! T G-R [1]: Lennart's remark, 'a concept of mount at boot if it is there, otherwise don't cannot work' https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg21973.html, isn't theoretical: it regularly broke on some dodgy hardware I'm thankful to no longer own. To paraphrase the OP: It never *really* worked. I don't want it back. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
