Re: [systemd-devel] Systemd 212 RemoveIPC=yes breaks postgresql
On Tue, May 20, 2014 at 6:37 PM, Lennart Poettering lenn...@poettering.net wrote: THis should be fixed now in systemd git. We will now check against the system user UID threshold before removing the IPC objects. Awesome, Thank you!. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl --since today --follow weirdness
'Twas brillig, and Colin Guthrie at 23/04/14 16:12 did gyre and gimble: Hiya, A colleague pointed out an oddity in journalctl --since today --follow output. It seems the two arguments somewhat contradict each other: one asks for all the output for today and the other asks for all future messages, but using them together should obviously behave in a somewhat sensible way! What I was expecting was basically the same as what journalctl --follow would produce, but excluding any output not from today. e.g. if the first 5 lines of a standard journalctl -f happened to be from yesterday, then I'd expect only the 5 lines from today to be printed and then any further output as it happens. What appears to happen instead is that you get the first 10 lines from the day (i.e. after midnight) and then *all* lines from today following that after a small delay (likely not a deliberate delay - just whatever overhead it takes to lookup and output the data), thus taking quite some time to page through which is definitely not what you expect from --follow, but arguably what you would expect from --since today. It's only the delay before full output that makes this very much feel like a bug rather than intentional (i.e. --since having a higher precedence than --follow's 10 line limit!) This is with a recent version of the 208-stable branch. Can someone confirm is this is still a problem in more recent versions? Just to follow up on this while I notice the bug (so I can recheck on more recent versions when I pull my finger out), but I noticed more strange behaviour today. My home server has been a little unstable of late and there have been a couple random reboots... this morning I thought I'd try and look at the logs to see if there was anything interesting before the reboot: [root@marley ~]# date Fri 23 May 09:05:38 BST 2014 [root@marley ~]# journalctl --since '2014-05-22 00:00:00' | tail -n1 May 23 07:42:01 marley.rasta.guthr.ie CROND[15012]: (root) CMD (/root/lcc/update) Hmm, the last line in the log is from more than an hour ago... seems unlikely... [root@marley ~]# journalctl --since '2014-05-23 00:00:00' | head -n2 -- Logs begin at Tue 2014-05-13 20:45:11 BST, end at Fri 2014-05-23 09:05:45 BST. -- May 23 07:43:08 marley.rasta.guthr.ie systemd-journal[553]: Runtime journal is using 8.0M (max allowed 196.0M, trying to leave 294.0M free of 1.9G available → current limit 196.0M). Hmmm, strange, I change the --since argument to today's date and suddenly the *first* line is from *after* the previous command's last line... doesn't seem right! [root@marley ~]# journalctl --since '2014-05-23 00:00:00' | tail -n1 May 23 09:05:45 marley.rasta.guthr.ie postfix/smtpd[3729]: disconnect from unknown[117.213.206.10] And just to confirm, a tail -n1 of the journal with a day newer --since argument and it gets different results. Something is wrong here. I suspect it's some kind of bug due to improperly closed journals (i.e. my unexpected reboot). FWIW, This is on a semi-recent 208-stable build, so no idea if this has actually been fixed subsequently, but incorrect querying of data is pretty bad. I'll try and see if updated versions behave better (I've kept a backup of my journal files to play with). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GDM session is not activated
Hi On Thu, May 22, 2014 at 9:19 PM, Oleg Samarin osamari...@gmail.com wrote: I have two-seat configuration on my PC. The problem is that when I log in to GDM session on seat0, it rests being not active, and I can not activate it with 'loginctl activate' command. gdm is responsible of setting XDG_VTNR before doing the pam-authentication. Recent gdm version do this, so I guess this is a bug with your systemd+gdm combination. Can you tell me the systemd and gdm version you are running? The patch you're referring to has long been superceded, so it's hard to tell what's going wrong. Can you also paste your environment? (bash: export) Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix several small typos
Fix some small comment/log typos
--
CODING_STYLE | 2 +-
src/core/unit.c| 6 +++---
src/network/networkd-wait-online.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/CODING_STYLE b/CODING_STYLE
index 996897b..4ec5923 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -16,7 +16,7 @@
half-initialized objects, too
- Error codes are returned as negative Exxx. i.e. return -EINVAL. There
- are some exceptions: for constructors its is OK to return NULL on
+ are some exceptions: for constructors it is OK to return NULL on
OOM. For lookup functions NULL is fine too for not found.
Be strict with this. When you write a function that can fail due to
diff --git a/src/core/unit.c b/src/core/unit.c
index 3f862aa..6e40bc6 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1574,7 +1574,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
/* Note that this is called for all low-level state changes,
* even if they might map to the same high-level
- * UnitActiveState! That means that ns == os is OK an expected
+ * UnitActiveState! That means that ns == os is an expected
* behavior here. For example: if a mount point is remounted
* this function will be called too! */
@@ -1597,7 +1597,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
u-active_exit_timestamp = ts;
}
-/* Keep track of failed of units */
+/* Keep track of failed units */
if (ns == UNIT_FAILED os != UNIT_FAILED)
set_put(u-manager-failed_units, u);
else if (os == UNIT_FAILED ns != UNIT_FAILED)
@@ -1722,7 +1722,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
if (UNIT_IS_ACTIVE_OR_RELOADING(ns)) {
if (unit_has_name(u, SPECIAL_DBUS_SERVICE))
-/* The bus just might have become available,
+/* The bus might have just become available,
* hence try to connect to it, if we aren't
* yet connected. */
bus_init(m, true);
diff --git a/src/network/networkd-wait-online.c
b/src/network/networkd-wait-online.c
index 0b8e35d..c6038c6 100644
--- a/src/network/networkd-wait-online.c
+++ b/src/network/networkd-wait-online.c
@@ -124,7 +124,7 @@ static bool all_configured(Manager *m) {
r = sd_rtnl_message_new_link(m-rtnl, message,
RTM_GETLINK, 0);
if (r 0) {
-log_warning(colud not create GETLINK
message: %s, strerror(-r));
+log_warning(could not create GETLINK
message: %s, strerror(-r));
return false;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix a few compiler warnings
On Wed, May 21, 2014 at 10:46:21AM +0200, Lennart Poettering wrote:
On Wed, 21.05.14 10:29, Thomas H.P. Andersen (pho...@gmail.com) wrote:
On Tue, May 20, 2014 at 5:43 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 19.05.14 19:52, Tom Gundersen (t...@jklm.no) wrote:
_public_ int sd_peer_get_session(int fd, char **session) {
-struct ucred ucred;
+struct ucred ucred = {};
I can't reproduce this warning, but more importantly, why is this
necessary in this function and not the subsequent noes (which all seem
to be more or less equivalent)?
Hmm, given the current flakiness of the gcc warnings when -flto is in
the mix I think we should follow the rule that we do not fix gcc
warnings that show up only with -flto is used. We can revisit that in a
few years when LTO has settled a bit, but for now I am pretty sure
trying to fix all those issues is a waste of time and certainly don't
improve our code...
Cristian, are those warnings you saw related to -flto?
The warning in namespace_open is not related to LTO. It shows up with
autogen.sh g make and that gets in the way for my workflow. It
would make my life easier if we could silence it with the fix in this
patch or suppress it with
#pragma GCC diagnostic ignored -Wmaybe-uninitialized
Would that be okay?
Ok, fixed that one. It is a false positive, but I can see why gcc gets
confused, and this sounds OK to fix. Have done so now. Please test!
Yes, thank you! I was spammed with reports of namespace_open due to
optimization flags and later by the LTO on that function each time its
unit is involved in linking.
There is also this one genrated by LTO, IMO it's a false positive since
we do *check* for lease but the code is not consistent since in that
code path, lease is initialized to NULL in other places, except for
this one:
src/resolve/resolved-manager.c: In function 'manager_update_resolv_conf':
src/libsystemd-network/sd-dhcp-lease.c:67:18: warning: 'lease' may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (lease-dns_size) {
^
src/network/sd-network.c:146:24: note: 'lease' was declared here
sd_dhcp_lease *lease;
^
Thanks!
--
Djalal Harouni
http://opendz.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix a few compiler warnings
On Fri, May 23, 2014 at 11:25 PM, Djalal Harouni tix...@opendz.org wrote:
On Wed, May 21, 2014 at 10:46:21AM +0200, Lennart Poettering wrote:
On Wed, 21.05.14 10:29, Thomas H.P. Andersen (pho...@gmail.com) wrote:
On Tue, May 20, 2014 at 5:43 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 19.05.14 19:52, Tom Gundersen (t...@jklm.no) wrote:
_public_ int sd_peer_get_session(int fd, char **session) {
-struct ucred ucred;
+struct ucred ucred = {};
I can't reproduce this warning, but more importantly, why is this
necessary in this function and not the subsequent noes (which all seem
to be more or less equivalent)?
Hmm, given the current flakiness of the gcc warnings when -flto is in
the mix I think we should follow the rule that we do not fix gcc
warnings that show up only with -flto is used. We can revisit that in a
few years when LTO has settled a bit, but for now I am pretty sure
trying to fix all those issues is a waste of time and certainly don't
improve our code...
Cristian, are those warnings you saw related to -flto?
The warning in namespace_open is not related to LTO. It shows up with
autogen.sh g make and that gets in the way for my workflow. It
would make my life easier if we could silence it with the fix in this
patch or suppress it with
#pragma GCC diagnostic ignored -Wmaybe-uninitialized
Would that be okay?
Ok, fixed that one. It is a false positive, but I can see why gcc gets
confused, and this sounds OK to fix. Have done so now. Please test!
Yes, thank you! I was spammed with reports of namespace_open due to
optimization flags and later by the LTO on that function each time its
unit is involved in linking.
There is also this one genrated by LTO, IMO it's a false positive since
we do *check* for lease but the code is not consistent since in that
code path, lease is initialized to NULL in other places, except for
this one:
src/resolve/resolved-manager.c: In function 'manager_update_resolv_conf':
src/libsystemd-network/sd-dhcp-lease.c:67:18: warning: 'lease' may be used
uninitialized in this function [-Wmaybe-uninitialized]
if (lease-dns_size) {
^
src/network/sd-network.c:146:24: note: 'lease' was declared here
sd_dhcp_lease *lease;
^
Thanks!
I agree, that's a false positive. However, no harm in fixing it, so
pushed a fix now. Let me know if it is still an issue.
Thanks for reporting!
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] sd-dhcp-client: return NULL from _unref() like the other sd-* libraries
On Thu, 22.05.14 15:29, Tom Gundersen (t...@jklm.no) wrote: Let's keep this behavior consistent across our libraries. In order to keep the refcounting working, a DONT_DESTROY macro similar to the one in sd-bus was introduced. The DON_DESTROY stuff you only really need when you dispatch some calback from a function call. It's there to make sure that the callback can drop the final ref for the object, but you can still access the object after it finished. There's no point in placing the macro in all functions, that's entirely unnecessary. 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] The best way to deal with a deamon with two binary options
On Thu, 22.05.14 11:17, Luis R. Rodriguez (mcg...@do-not-panic.com) wrote: Hey folks, Xen systemd support with active sockets and sd_notify() is under way, we're in what seems to be the final rounds of patch review. One of the last items we are reviewing is how to best deal with a deamon that has two binary options for the daemon. They share the same arguments and in order to support legacy init we have a sysconfig/default configuration file with options. I realize the expressed position on sysconfig/default directory [0] but since we wish to upkeep and share with legacy init some behavior it seems best to use EnvironmentFile for that sysconfig/default file for now. We have two possible deamons: one written in C who's binary is called xenstored, and another one written in Ocaml, oxenstored.At boot up one or the other can run, it doesn't matter which one, and we require a reboot to change daemons, we can't stop the service. The old legacy init can replace the binary through an environment variable, for systemd we don't allow variables for the ExecStart so this won't work there. As per discussions at the LF Linux collaboration with Brandon one way to support this in systemd is to provide separate service unit files for both binaries, and provide a target unit file. System dependencies would then depend on the target, not the service files. Switching between binaries then would require manual intervention by the system administrator, disable one, enable the other. These service unit files would be mutually exclusive however. In order to maintain compatibility with the legacy init approach however another possibility we're not reviewing is the launcher concept which would simply getenv() and execve() the appropriate daemon. We'd rename for example the C version of xenstored to cxenstored, the Ocaml to oxenstored, and the launcher would take up the general xenstored. The benefit of this approach is we'd maintain one service unit file, and the flipping of the daemons would consist of a simple edit on a configuration file. Would like feedback on this type of situation and recommendations as to the best way to provide support for this type of situation. Any other ideas are course always welcomed. Another option is to have two unit files and then one alias (i.e. symlink) that points to one or another. Let's say you have two implementations foo.service and bar.service, then place this in both: [Install] Alias=waldo.service THis way you cannot enable both at the same time, as the symlink can only point to one of them, and systemctl install will complain about that... (unless --force) is used. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Use %m instead of strerror(errno) where appropiate
---
src/journal/sd-journal.c| 6 ++
src/libsystemd-network/sd-dhcp-client.c | 4 ++--
src/nspawn/nspawn.c | 2 +-
src/shared/label.c | 2 +-
4 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
index 11de8ef..ca805f8 100644
--- a/src/journal/sd-journal.c
+++ b/src/journal/sd-journal.c
@@ -1455,8 +1455,7 @@ static int add_directory(sd_journal *j, const char
*prefix, const char *dirname)
de = readdir(d);
if (!de errno != 0) {
r = -errno;
-log_debug(Failed to read directory %s: %s,
- m-path, strerror(errno));
+log_debug(Failed to read directory %s: %m, m-path);
return r;
}
if (!de)
@@ -1546,8 +1545,7 @@ static int add_root_directory(sd_journal *j, const char
*p) {
de = readdir(d);
if (!de errno != 0) {
r = -errno;
-log_debug(Failed to read directory %s: %s,
- m-path, strerror(errno));
+log_debug(Failed to read directory %s: %m, m-path);
return r;
}
if (!de)
diff --git a/src/libsystemd-network/sd-dhcp-client.c
b/src/libsystemd-network/sd-dhcp-client.c
index 67593c4..0300a6b 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -1200,7 +1200,7 @@ static int client_receive_message_udp(sd_event_source *s,
int fd,
len = read(fd, message, buflen);
if (len 0) {
log_dhcp_client(client, could not receive message from UDP
-socket: %s, strerror(errno));
+socket: %m);
return 0;
} else if ((size_t)len sizeof(DHCPMessage))
return 0;
@@ -1245,7 +1245,7 @@ static int client_receive_message_raw(sd_event_source *s,
int fd,
len = recvmsg(fd, msg, 0);
if (len 0) {
log_dhcp_client(client, could not receive message from raw
-socket: %s, strerror(errno));
+socket: %m);
return 0;
} else if ((size_t)len sizeof(DHCPPacket))
return 0;
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index eb9c5e0..73158a0 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -657,7 +657,7 @@ static int mount_binds(const char *dest, char **l, unsigned
long flags) {
return r;
}
} else {
-log_error(Failed to bind mount %s: %s, *x,
strerror(errno));
+log_error(Failed to bind mount %s: %m, *x);
return -errno;
}
/* Create the mount point, but be conservative -- refuse to
create block
diff --git a/src/shared/label.c b/src/shared/label.c
index 70e5c85..3b7b86e 100644
--- a/src/shared/label.c
+++ b/src/shared/label.c
@@ -79,7 +79,7 @@ static int smack_relabel_in_dev(const char *path) {
r = setxattr(path, security.SMACK64, label, strlen(label), 0);
if (r 0) {
-log_error(Smack relabeling \%s\ %s, path, strerror(errno));
+log_error(Smack relabeling \%s\ %m, path);
return -errno;
}
#endif
--
1.8.4.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
