Re: [systemd-devel] symbolic link for systemd-stdio-bridge
On Thu, Dec 19, 2013 at 5:34 PM, Umut Tezduyar Lindskog umut.tezdu...@axis.com wrote: It is broken when bindir is /usr/bin and /lib is not symbolic link to /usr/lib. bus-proxyd-install-hook: $(AM_V_LN)$(LN_S) -f ../../lib/systemd/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge Maybe best to use full path. Zbigniew has fixed it with 8f8770706e360d7bf now. Thanks. ___ 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] Add SELinuxContext configuration item
Le lundi 30 décembre 2013 à 03:14 -0600, David Timothy Strauss a écrit : On Sat, Dec 28, 2013 at 10:47 AM, Michael Scherer m...@zarb.org wrote: So using templated units, we could do for example : SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023 In the spirit of making isolation easy, it would be neat to have a built-in convention for selinux isolation in systemd where the full service/unit name has a default context name, constructed much like the quoted example, that the admin or packager can use simply by turning isolation on (SELinux=true). We would love to use SELinuxContext= or SELinux= for our needs at Pantheon. Using SELinux=true is a bit weird when it come to the naming, because SELinux=false wouldn't disable selinux, it would just let the current policy do the transition, that's a bit misleading. I am not sure of the value of having 2 configuration file doing the same thing. What about SELinuxContext=auto , and so replace auto by some default configuration in that case ? -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] install: Assume *.wants symlinks have the same name as their target for scalability.
В Вс, 29/12/2013 в 18:57 +0100, Zbigniew Jędrzejewski-Szmek пишет:
Hi,
I'd like to reopen this thread.
I have been looking at our bugs [1-10, there are others too] related to
enabling/disabling of units and following of symlinks. Currently this
is an unintuitive mess and some changes will have to be made.
I think that the general rules should be:
(/lib is short for /usr/lib, /usr/local/lib, etc.,
.wants is short for .wants or .requires)
1. when given a unit, it must be possible to read information about
this unit without reading all other units
2. all symlinks in /run and /etc are considered configuration and
will be removed by systemctl disable
3. symlinks within the configuration directories must have
(a) the same symlink and target name, or
(b) the symlink can be a instance and the target a template with
the same stem and type
(c) in /lib, the name can be different, but the type must match, and this
provides an alias
4. systemd must follow the same logic as systemctl and must enforce
the rules.
This means that:
If I read this correctly, the end effect is that every systemd unit file
must be found under standard systemd directories. Right?
1. when linking a unit with 'systemctl enable /path/to/file',
the unit must be linked both into /etc/systemd/system/ and
/etc/systemd/systemd/whatever.wants/. This is what systemctl enable
currently does, but we allowed only the second part done
manually. systemd would be changed to ignore all files in .wants/,
and it would be changed to ignore symlinks in .wants if the unit
cannot be loaded by name otherwise.
What is semantic of having symlink in .wants to different unit file that
would normally be found by systemd. I.e. having both /lib/foo.service
and /etc/foo.service will use /etc version; but what if there is symlink
that points into /lib?
2. symlinking to units to provide an alias is allowed only in /lib.
When systemctl disable is executed, all symlinks in /etc and /run will
be nuked, but /lib will be left alone. I think this is current behaviour.
3. .wants directories and .d directories will only be honored for
the main unit name. The problem that we have currently is that
if the alias unit is not pulled in by anything, this extra configuration
is ignored. But even 'systemctl status' loads the unit, and loads
this extra configuration. systemd would be changed to warn about this
and ignore those extra dirs.
4. support for aliases will be provided on a best-effort basis: If
the alias is done by symlinking in /lib, it is always known.
If the alias is provided by Alias= configuration directive, it
is only known if the unit was already loaded.
There's a bug that 'systemctl disable' removes too much stuff for
instance units. I can't find the report atm, but this is a bug that
should be fixed too.
Zbyszek
[1] https://bugs.freedesktop.org/show_bug.cgi?id=72611
systemctl is-enabled scales poorly with many units (this one)
[2] https://bugs.freedesktop.org/show_bug.cgi?id=63621
systemctl enable doesn't work for Alias names
[3] https://bugs.freedesktop.org/show_bug.cgi?id=72154
systemctl enable named.service yields error messages used for legacy
sysinit scripts
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1014311
RFE: allow systemctl enable work on symlinked units
[5] https://bugzilla.redhat.com/show_bug.cgi?id=864298
systemctl is-enabled reports 'static' incorrectly (it appears)
[6] https://bugzilla.redhat.com/show_bug.cgi?id=955379
systemctl enable fails for user-defined service files in
/etc/systemd/system
[7] https://bugs.freedesktop.org/show_bug.cgi?id=65255
some units can be started when the file is just copied into .wants/
[8] https://bugs.freedesktop.org/show_bug.cgi?id=54560
systemd does not follow symlinks that point outside of
/etc/systemd/system or /usr/lib/systemd/system
[9] https://bugzilla.redhat.com/show_bug.cgi?id=1002806
runlevel command returns unknown
[10] https://bugzilla.redhat.com/show_bug.cgi?id=815835
/sbin/runlevel reports unknown where it shouldn't
On Fri, Dec 13, 2013 at 01:03:30PM -0800, da...@davidstrauss.net wrote:
From: David Strauss da...@davidstrauss.net
---
src/shared/install.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 17e8a75..512e3df 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -419,10 +419,15 @@ static int find_symlinks_fd(
r = q;
} else if (de-d_type == DT_LNK) {
-_cleanup_free_ char *p = NULL, *dest = NULL;
+_cleanup_free_ char *p = NULL, *dest = NULL,
*no_inst = NULL;
bool found_path, found_dest, b = false;
Re: [systemd-devel] [PATCH] boot-efi: Remove superfluous assignment
On Mon, Dec 30, 2013 at 11:32 PM, Stefan Beller stefanbel...@googlemail.com wrote: 2 lines after the changed line we assign err to efi_get_variable(...) unconditionally, so it makes no sense to initialize it to some value. --- src/boot/boot-efi.c | 2 +- Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to control socket activation when it run respawn infinitely.
First of all, thank you for advice you said. You are right, I am a novice on TCP/IP, so I had studied that for a few days. Now, I understand that UDS Protocol and the difference between Accept=true and Accept=false. But What I really want to know is why the server process always waited in the accept stage, when I executed client process for the first after system boot. As you know that socket activation makes a service related with socket unit executed with connection of client process. If the procedure for socket activation would run like that, the server process executed for the first may not prepare the passive connection which should be set beforehand because of client connection. In my view, this waiting problem will be continue as far as the server process is simultaneously executed with the client process. what do you think about it? Thanks. 2013/12/31 David Timothy Strauss da...@davidstrauss.net On Mon, Dec 30, 2013 at 7:59 AM, Tony Seo tonys...@gmail.com wrote: That situation continued whether Accept= true or not in service unit. The reason I encouraged you to learn more about socket programming is because this Accept= option isn't some sort of optimization or nuanced thing you just try either way until you get it working. What layer handles accept() for connection-oriented protocols (systemd versus a daemon) is a fundamental aspect of socket programming. If you don't understand what Accept=true and Accept=false are supposed to do and just go about trying both, you still have more learning to do. Specifically, Accept=true means systemd handles the accept() calls and spawns an instance of the service for each connection. The socket passed into the service is one corresponding to a single client's connection. It is therefore appropriate to simply read from and write to fd=3. Trying to accept() from fd=3 will probably block forever if it works at all. Accept=false (the default) means systemd merely handles the listener socket. The service must make its own accept() calls to get sockets corresponding to individual client connections. The service should not directly read from and write from fd=3; it should do that with the socket instantiated by accept(). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal: Add missing byte order conversions
Convert entry_array.items[0] to host byte order prior to passing it to chain_cache_put(). Signed-off-by: George McCollister george.mccollis...@gmail.com --- src/journal/journal-file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c index 121b40a..275324b 100644 --- a/src/journal/journal-file.c +++ b/src/journal/journal-file.c @@ -1452,7 +1452,7 @@ static int generic_array_get( found: /* Let's cache this item for the next invocation */ -chain_cache_put(f-chain_cache, ci, first, a, o-entry_array.items[0], t, i); +chain_cache_put(f-chain_cache, ci, first, a, le64toh(o-entry_array.items[0]), t, i); r = journal_file_move_to_object(f, OBJECT_ENTRY, p, o); if (r 0) @@ -1685,7 +1685,7 @@ found: return 0; /* Let's cache this item for the next invocation */ -chain_cache_put(f-chain_cache, ci, first, a, array-entry_array.items[0], t, subtract_one ? (i 0 ? i-1 : (uint64_t) -1) : i); +chain_cache_put(f-chain_cache, ci, first, a, le64toh(array-entry_array.items[0]), t, subtract_one ? (i 0 ? i-1 : (uint64_t) -1) : i); if (subtract_one i == 0) p = last_p; -- 1.8.2.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] rtnl: fix memory corruptions after realloc
struct sd_rtnl_message would keep two additional pointers into the hdr
field. Every time hdr was realloced, those pointers should be adjusted,
but weren't. It seems less error-prone to keep offsets instead.
---
Hi Tom,
this fixes errors reported by valgrind and should make the code more
robust, imo.
Zbyszek
src/libsystemd-rtnl/rtnl-message.c | 54 ++
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/src/libsystemd-rtnl/rtnl-message.c
b/src/libsystemd-rtnl/rtnl-message.c
index 24f2e6f..f2ca98c 100644
--- a/src/libsystemd-rtnl/rtnl-message.c
+++ b/src/libsystemd-rtnl/rtnl-message.c
@@ -35,14 +35,14 @@ struct sd_rtnl_message {
RefCount n_ref;
struct nlmsghdr *hdr;
-
-struct rtattr *current_container;
-
+size_t container_offset;
struct rtattr *next_rta;
bool sealed:1;
};
+#define CURRENT_CONTAINER(m) ((m)-container_offset ? (struct
rtattr*)((uint8_t*)(m)-hdr + (m)-container_offset) : NULL)
+
static int message_new(sd_rtnl_message **ret, size_t initial_size) {
sd_rtnl_message *m;
@@ -296,8 +296,8 @@ int sd_rtnl_message_link_get_flags(sd_rtnl_message *m,
unsigned *flags) {
return 0;
}
-/* If successful the updated message will be correctly aligned, if
unsuccessful the old message is
- untouched */
+/* If successful the updated message will be correctly aligned, if
+ unsuccessful the old message is untouched. */
static int add_rtattr(sd_rtnl_message *m, unsigned short type, const void
*data, size_t data_length) {
uint32_t rta_length, message_length;
struct nlmsghdr *new_hdr;
@@ -311,48 +311,46 @@ static int add_rtattr(sd_rtnl_message *m, unsigned short
type, const void *data,
/* get the size of the new rta attribute (with padding at the end) */
rta_length = RTA_LENGTH(data_length);
-/* get the new message size (with padding at the end)
- */
+
+/* get the new message size (with padding at the end) */
message_length = m-hdr-nlmsg_len + RTA_ALIGN(rta_length);
/* realloc to fit the new attribute */
new_hdr = realloc(m-hdr, message_length);
if (!new_hdr)
return -ENOMEM;
-/* update the location of the next rta for reading */
-m-next_rta = (struct rtattr *) ((uint8_t *) m-next_rta +
- ((uint8_t *) new_hdr -
- (uint8_t *) m-hdr));
+
+/* update the location of the next rta */
+m-next_rta = (struct rtattr *) ((uint8_t *) m-next_rta - (uint8_t *)
m-hdr
+ + (uint8_t *) new_hdr);
m-hdr = new_hdr;
/* get pointer to the attribute we are about to add */
rta = (struct rtattr *) ((uint8_t *) m-hdr + m-hdr-nlmsg_len);
-/* update message size */
-m-hdr-nlmsg_len = message_length;
-/* we are inside a container, extend it */
-if (m-current_container)
-m-current_container-rta_len = (uint8_t *) m-hdr +
-m-hdr-nlmsg_len -
-(uint8_t *)
m-current_container;
+/* if we are inside a container, extend it */
+if (CURRENT_CONTAINER(m))
+CURRENT_CONTAINER(m)-rta_len += message_length -
m-hdr-nlmsg_len;
/* fill in the attribute */
rta-rta_type = type;
rta-rta_len = rta_length;
if (!data) {
-/* this is a container, set pointer */
-m-current_container = rta;
+/* this is the start of a new container */
+m-container_offset = m-hdr-nlmsg_len;
} else {
/* we don't deal with the case where the user lies about the
type
* and gives us too little data (so don't do that)
*/
padding = mempcpy(RTA_DATA(rta), data, data_length);
/* make sure also the padding at the end of the message is
initialized */
-memset(padding, '\0', (uint8_t *) m-hdr +
- m-hdr-nlmsg_len -
- (uint8_t *) padding);
+memzero(padding,
+(uint8_t *) m-hdr + message_length - (uint8_t *)
padding);
}
+/* update message size */
+m-hdr-nlmsg_len = message_length;
+
return 0;
}
@@ -373,8 +371,8 @@ int sd_rtnl_message_append_string(sd_rtnl_message *m,
unsigned short type, const
case RTM_SETLINK:
case RTM_GETLINK:
case RTM_DELLINK:
-if (m-current_container) {
-if (m-current_container-rta_type !=
IFLA_LINKINFO ||
+if (CURRENT_CONTAINER(m)) {
+if
Re: [systemd-devel] How to control socket activation when it run respawn infinitely.
On Tue, Dec 31, 2013 at 9:20 AM, Tony Seo tonys...@gmail.com wrote: But What I really want to know is why the server process always waited in the accept stage, when I executed client process for the first after system boot. It may hang in accept() if the service is Accept=true and the daemon still tries to accept(). It may also hang on accept() if it's simply blocking until the next connection. As you know that socket activation makes a service related with socket unit executed with connection of client process. If the procedure for socket activation would run like that, the server process executed for the first may not prepare the passive connection which should be set beforehand because of client connection. In my view, this waiting problem will be continue as far as the server process is simultaneously executed with the client process. what do you think about it? There is no race condition, if that's what you mean. systemd waits using epoll for the appropriate event for starting a child daemon (for Accept=false) or child processes (for Accept=true). For Accept=false, it's the same effect as if a daemon used epoll on the listener socket and only ran accept() in a callback, just possibly with a bit more delay. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] rtnl: fix memory corruptions after realloc
struct sd_rtnl_message would keep two additional pointers into the hdr
field. Every time hdr was realloced, those pointers should be adjusted,
but weren't. It seems less error-prone to keep offsets instead.
---
Previous version was missing some hunks...
Zbyszek
src/libsystemd-rtnl/rtnl-message.c | 86 ++
1 file changed, 41 insertions(+), 45 deletions(-)
diff --git a/src/libsystemd-rtnl/rtnl-message.c
b/src/libsystemd-rtnl/rtnl-message.c
index 24f2e6f..517df61 100644
--- a/src/libsystemd-rtnl/rtnl-message.c
+++ b/src/libsystemd-rtnl/rtnl-message.c
@@ -35,14 +35,16 @@ struct sd_rtnl_message {
RefCount n_ref;
struct nlmsghdr *hdr;
-
-struct rtattr *current_container;
-
-struct rtattr *next_rta;
+size_t container_offset; /* offset from hdr to container start */
+size_t next_rta_offset; /* offset from hdr to next rta */
bool sealed:1;
};
+#define CURRENT_CONTAINER(m) ((m)-container_offset ? (struct
rtattr*)((uint8_t*)(m)-hdr + (m)-container_offset) : NULL)
+#define NEXT_RTA(m) ((struct rtattr*)((uint8_t*)(m)-hdr +
(m)-next_rta_offset))
+#define UPDATE_RTA(m, new) (m)-next_rta_offset = (uint8_t*)(new) -
(uint8_t*)(m)-hdr;
+
static int message_new(sd_rtnl_message **ret, size_t initial_size) {
sd_rtnl_message *m;
@@ -154,7 +156,7 @@ int sd_rtnl_message_route_new(uint16_t nlmsg_type, unsigned
char rtm_family,
rtm = NLMSG_DATA((*ret)-hdr);
-(*ret)-next_rta = RTM_RTA(rtm);
+UPDATE_RTA(*ret, RTM_RTA(rtm));
rtm-rtm_family = rtm_family;
rtm-rtm_scope = RT_SCOPE_UNIVERSE;
@@ -208,7 +210,7 @@ int sd_rtnl_message_link_new(uint16_t nlmsg_type, int
index, sd_rtnl_message **r
ifi-ifi_index = index;
ifi-ifi_change = 0x;
-(*ret)-next_rta = IFLA_RTA(ifi);
+UPDATE_RTA(*ret, IFLA_RTA(ifi));
return 0;
}
@@ -236,7 +238,7 @@ int sd_rtnl_message_addr_new(uint16_t nlmsg_type, int
index, unsigned char famil
ifa-ifa_scope = scope;
ifa-ifa_index = index;
-(*ret)-next_rta = IFA_RTA(ifa);
+UPDATE_RTA(*ret, IFA_RTA(ifa));
return 0;
}
@@ -296,8 +298,8 @@ int sd_rtnl_message_link_get_flags(sd_rtnl_message *m,
unsigned *flags) {
return 0;
}
-/* If successful the updated message will be correctly aligned, if
unsuccessful the old message is
- untouched */
+/* If successful the updated message will be correctly aligned, if
+ unsuccessful the old message is untouched. */
static int add_rtattr(sd_rtnl_message *m, unsigned short type, const void
*data, size_t data_length) {
uint32_t rta_length, message_length;
struct nlmsghdr *new_hdr;
@@ -311,48 +313,42 @@ static int add_rtattr(sd_rtnl_message *m, unsigned short
type, const void *data,
/* get the size of the new rta attribute (with padding at the end) */
rta_length = RTA_LENGTH(data_length);
-/* get the new message size (with padding at the end)
- */
+
+/* get the new message size (with padding at the end) */
message_length = m-hdr-nlmsg_len + RTA_ALIGN(rta_length);
/* realloc to fit the new attribute */
new_hdr = realloc(m-hdr, message_length);
if (!new_hdr)
return -ENOMEM;
-/* update the location of the next rta for reading */
-m-next_rta = (struct rtattr *) ((uint8_t *) m-next_rta +
- ((uint8_t *) new_hdr -
- (uint8_t *) m-hdr));
m-hdr = new_hdr;
/* get pointer to the attribute we are about to add */
rta = (struct rtattr *) ((uint8_t *) m-hdr + m-hdr-nlmsg_len);
-/* update message size */
-m-hdr-nlmsg_len = message_length;
-/* we are inside a container, extend it */
-if (m-current_container)
-m-current_container-rta_len = (uint8_t *) m-hdr +
-m-hdr-nlmsg_len -
-(uint8_t *)
m-current_container;
+/* if we are inside a container, extend it */
+if (CURRENT_CONTAINER(m))
+CURRENT_CONTAINER(m)-rta_len += message_length -
m-hdr-nlmsg_len;
/* fill in the attribute */
rta-rta_type = type;
rta-rta_len = rta_length;
if (!data) {
-/* this is a container, set pointer */
-m-current_container = rta;
+/* this is the start of a new container */
+m-container_offset = m-hdr-nlmsg_len;
} else {
/* we don't deal with the case where the user lies about the
type
* and gives us too little data (so don't do that)
*/
padding = mempcpy(RTA_DATA(rta), data, data_length);
/* make sure also the padding at the end of the
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On Tue, Dec 31, 2013 at 3:33 AM, Michael Scherer m...@zarb.org wrote: I am not sure of the value of having 2 configuration file doing the same thing. What about SELinuxContext=auto , and so replace auto by some default configuration in that case ? That works for me. I just like the idea of naming that corresponds to the unit's name. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
