Re: [systemd-devel] [PATCH 1/3] tmpfiles: skip the path entirely if configured as type x
On St 11. prosinec 2013, 03:02:48 CET, Lennart Poettering wrote: On Fri, 08.11.13 07:32, Michal Sekletar (msekl...@redhat.com) wrote: On Thu, Nov 07, 2013 at 10:39:19PM +0100, Lennart Poettering wrote: On Wed, 06.11.13 11:18, Michal Sekletar (msekl...@redhat.com) wrote: Type x in tmpfiles configuration accepts shell style globs instead of normal paths. If user uses normal path he might expect that the path will be left untouched. However this is not the case for directories and content of the directory will be cleaned according to the Age parameter, we should rather skip the path entirely in such case. Hi Lennart, Not sure I follow. dir_cleanup() already skips all items listed in the glob hashmap anyway, no? What does your patch add on top of that? In dir_cleanup() we skip if there is an item configured for the path or it matches the glob, however we are doing it on the subpaths of currently processed directory. This won't work in the case mentioned in the commit message. If user wants to exclude path from cleanup entirely he has to use x /path/*, this way all subpaths match the glob. In case of x /path/ no subpath matches such glob and we remove them, hence checking explicitly beforehand. Hope that makes some sense. Nope. Still not following. Can you give an explicit example of a complete but minimal tmpfiles snippet that currently doesn't behave correctly and that does with your patch? Maybe I grok it then! Thanks, Lennart We discussed and tested it here with Michal and Lukas again and came to conclusion the behavior is correct as is. Thanks, Vaclav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user@.service doesn't stop on logout
Am 10.12.2013 22:55, schrieb Thomas Bächler: > # /run/systemd/users/1000 > # This is private data. Do not parse. > NAME=test > STATE=closing > RUNTIME=/run/user/1000 > SERVICE=user@1000.service > SLICE=user-1000.slice > REALTIME=1386712031039381 > MONOTONIC=14242584 > SESSIONS=1 > SEATS=seat0 > ACTIVE_SESSIONS= > ONLINE_SESSIONS= > ACTIVE_SEATS= > ONLINE_SEATS= > > I checked loginctl list-sessions, and there is no session 1. This test > was done with systemd-git 171754a. I tested a bit more on another box with systemd 208. It seems that when I log out, my session is left in SESSIONS=. Whenever the same user logs in or out another session, the old session is cleaned up (but then, the current session stays around). signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HACK/RFC/PATCH] systemd-su: "su" on steroids
Hi On Wed, Dec 11, 2013 at 12:18 AM, Lennart Poettering wrote: > On Mon, 02.12.13 21:47, David Herrmann (dh.herrm...@gmail.com) wrote: > >> >> 4h later, I present "systemd-su": >> >> If you want to give it a try, run: >> systemd-su -u david /bin/sh >> >> It requires the systemd-suexec helper internally, so if you didn't install >> it, use something like this: >> SYSTEMD_SUEXEC=/home/david/dev/systemd/systemd-suexec ./systemd-su -u >> david sh >> Otherwise, systemd-su cannot find the systemd-suexec binary. > > Hmm, if we allow that "su -" tells logind to create an entirely new > session even when called from an existing one, do we still need > "systemd-su"? That should be pretty close, no? That sounds easier to > do... You cannot start a session from within an existing session. At least if audit-loginids are immutable, this also means the audit-sessionid is immutable (as the session ID is updated if, and only if, the logind-uid changes). Of course, immutable audit IDs are a somewhat controversial feature (and afaik don't work with containers?) but I still dislike the idea of starting sessions from within an existing session. It's ugly and we don't actually need it, do we? Currently su/sudo don't start new sessions and I think that is fine. Imho, their intention is to change the EUID, not to spawn a new session. So my hack here is just some example to play with, not something for real to replace su/sudo. >> Additionally, I create an anonymous AF_UNIX socket in systemd-su which >> systemd-suexec connects to. I then pass file-descriptors to systemd-suexec >> which installes them as STDIN/OUT/ERR. >> I actually think it would be quite useful to extend the >> StartTransientUnit() dbus call to allow passing FDs. It would allow us to >> "store" FDs with active units, which would be useful for a lot of other >> concepts (like storing DRM framebuffer handles..). > > Hmm, so we thought about adding support for something like a per-service > fd storage facility in systemd. This would be populated from the .socket > units, but could also be passed in for transient units by the caller or > even updated by the services themselves if they want to store additional > fds in systemd. This would solve a number of issues for us, including > one big one: currently if you restart systemd-journald you lose the > per-service stdout/stderr connections because there's no way to save > them. Yepp! I think we talked about it 2 years ago at LPC. Would be a pretty useful feature.. If I find time for it, I will give it a try. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv5] tmpfiles, man: Add xattr support to tmpfiles
10.12.2013 at 20:48 Lennart Poettering wrote:
On Wed, 04.12.13 15:27, Maciej Wereski (m.were...@partner.samsung.com)
wrote:
+#ifdef HAVE_XATTR
+static int get_xattrs_from_arg(Item *i){
+_cleanup_free_ char *xattr = NULL;
+_cleanup_strv_free_ char **tmp = NULL;
+char *p;
+unsigned n, len, strv_len;
+
+assert(i);
+if (i->type != SET_XATTR)
+return 0;
+
+if (!i->argument) {
+log_error("%s: Argument can't be empty!", i->path);
+return -EBADMSG;
+}
+xattr = new0(char, strlen(i->argument)+1);
+if (!xattr)
+return log_oom();
+
+tmp = strv_split(i->argument, WHITESPACE);
+if (!tmp)
+return log_oom();
+
+strv_len = strv_length(tmp);
+for (n = 0; n < strv_len; ++n) {
Sounds like a job for the STRV_FOREACH() macro. Since you don't actually
need the strv as strv here it sounds like you actually really want to
use FOREACH_WORD_QUOTED() for this, which will also do the unquoting for
you.
Well, FOREACH_WORD_QUOTED() won't work properly, because quotation marks
aren't first chars in strings (e.g. user.name="John Smith"). Maybe better
idea would be to introduce mandatory separator (e.g. semicolon) instead of
quotation marks.
regards,
--
Maciej Wereski
Samsung R&D Institute Poland
Samsung Electronics
m.were...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logging in an enterprise environment
On 12/10/2013 07:16 PM, Lennart Poettering wrote: As I understand it, journald is mend to log locally. Two methods to log centrally are, if I have understand it correctly: - mounting and merging through NFS - systemd-journal-gateway Whereby the first would be the preferred method. That would not be always acceptable for our clients. As I understood it there are environments where now 700+ systems are monitored from one log server. Using NFS for this would ask to much resources. I think that systemd-journal-gateway also would not be very handy for this because it is a pulling solution. To make things even more complicated: sometimes they want no local logging at all, all logging should be done remotely, so that not one user on the system could read the logs. Would something like this be possible to implement? If so, how much work would it be? Probably our company would be prepared to let programmers write this functionality. Journald's primary job is local logging, for complex logging setups we recommend installing a logging services like rsyslog. Would you not loose some of the advantages of journald this way? I understand that with using imjournal in rsyslog this probably could mostly be circumvented. I have seen that the local logging can be disabled with: Storage=none You can to centralized logging with the journal too, by simply making the journal files you want to look at accessible on the same machine. This could be done via NFS sharing, or by copying them to a central host via rsync or scp or even ftp, whatever you prefer. "journalctl -m" will then be able to coalesce them on display. NFS is not acceptable I am told, but I'll inquire about the other possibilities. By the way: is just copying possible? What if an event is logged at the moment the copy is done? Eventually journald should provide you with both a pull and a push model, however it currently onyl supports a pull model. Note that for Where can I information about that, or do you mean copying the files? large setups a pull model is actually the more deseriable since the centralized logging serve can then pull logs out of the cluster on its own terms and schedule. Such a setup in push scenario might make the log server vulnerable to flooding when some event happens across the whole cluster (example: the cluster networked is portscanned, or power state changes for all cluster machines at the same time). Sounds reasonable. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logging in an enterprise environment
On 12/11/2013 02:25 PM, Cecil Westerhof wrote: You can to centralized logging with the journal too, by simply making the journal files you want to look at accessible on the same machine. This could be done via NFS sharing, or by copying them to a central host via rsync or scp or even ftp, whatever you prefer. "journalctl -m" will then be able to coalesce them on display. NFS is not acceptable I am told, but I'll inquire about the other possibilities. By the way: is just copying possible? What if an event is logged at the moment the copy is done? I just had a little check. Copying is not acceptable. Logging on the log-server should be real-time. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logging in an enterprise environment
Am 11.12.2013 14:43, schrieb Cecil Westerhof: > On 12/11/2013 02:25 PM, Cecil Westerhof wrote: >>> You can to centralized logging with the journal too, by simply making >>> the journal files you want to look at accessible on the same >>> machine. This could be done via NFS sharing, or by copying them to a >>> central host via rsync or scp or even ftp, whatever you >>> prefer. "journalctl -m" will then be able to coalesce them on display. >> >> NFS is not acceptable I am told, but I'll inquire about the other >> possibilities. >> >> By the way: is just copying possible? What if an event is logged at the >> moment the copy is done? > > I just had a little check. Copying is not acceptable. Logging on the > log-server should be real-time so just install rsyslog and you have the same as before rsyslog is running here on any machine and journald with Storage=none signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logging in an enterprise environment
On 12/11/2013 02:25 PM, Cecil Westerhof wrote: Eventually journald should provide you with both a pull and a push model, however it currently onyl supports a pull model. Note that for Where can I information about that, or do you mean copying the files? You probably mend systemd-journal-gateway? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd unit review requested
On Wed, 11.12.13 12:34, Peter Hutterer (peter.hutte...@who-t.net) wrote: > > If a module exposes those alias lines then the module is auto-loaded by > > udev as soon as matching hardware shows up. That's the preferable way to > > load kernel modules these days, instead of loading them explicitly they > > way you are doing it. > > > > Of course, what's behind an rs232 port is generally not automatically > > discoverable, that's why Kay was asking whether the modalias line is > > insufficient. > > ok, after spending half the day going down the most likely wrong track: are > we talking about auto-loading the module once inputattach is launched, or > dropping the need for inputattach? > > because if it's the former then yes, I can confirm that works and the module > is loaded correctly so the modalias seems to work here. we can drop the kmod > from the udev rule. Well, it's udev that loads the kmod as the hw shows up, not inputattach that triggers the loading. inputattach comes later... > > It sounds like a good idea to get rid of the explicit module loading and > > simply rely on the modalias stuff for that. Then, if your program really > > only does what you list above (i.e. nothing that can block for longer or > > that needs to stay around during runtime), then you could just do this > > synchronously as part of an udev rule, no? > > sorry, I wasn't clear enough. inputattach does the above and then just sits > with a 0-byte read() to keep the line open. as soon as inputattach finishes > the device will revert back to just being a serial device. > so it's definitely not a one-shot, we need it to sit there. OK, then doing this as systemd service is the right thing. 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] Logging in an enterprise environment
On 12/11/2013 02:52 PM, Reindl Harald wrote: I just had a little check. Copying is not acceptable. Logging on the log-server should be real-time so just install rsyslog and you have the same as before rsyslog is running here on any machine and journald with Storage=none I already suggested that. They want to talk more about it later. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: support Distribute=n to distribute to n workers
On Tue, 10.12.13 18:53, Shawn Landden (sh...@churchofgit.com) wrote:
> @@ -116,6 +115,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
> SD_BUS_PROPERTY("MessageQueueMessageSize", "x",
> bus_property_get_long, offsetof(Socket, mq_msgsize), 0),
> SD_BUS_PROPERTY("Result", "s", property_get_result, offsetof(Socket,
> result), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
> SD_BUS_PROPERTY("ReusePort", "b", bus_property_get_bool,
> offsetof(Socket, reuse_port), 0),
Did you turn reuseport into a tristate as suggested? If so, then
bus_property_get_bool needs to become bus_property_get_tristate here so
that the right type is serialized to dbus.
> +Socket.ReusePort,config_parse_bool, -1,
>offsetof(Socket, reuse_port)
Similar here... (and what's the -1?)
As it turns out I recently removed config_parse_tristate() as part of
9588bc32096fc8342bfd8b989689717186d7d86e. You should probably restore
that function from that commit to make use of it here...
> +Socket *socket = SOCKET(UNIT_DEREF(s->accept_socket));
> log_debug_unit(u->id,
> "%s: got READY=1", u->id);
>
> +if (socket && socket->distribute > socket->n_connections)
> +socket_enter_listening(socket);
> +
Hmm, I would prefer if we wouldn't reach over too much into the socket
here, i.e. handle this within socket_trigger_notify(). That function is
always called when a unit that is triggered by the socket changes state.
> +if (s->reuse_port == -1) {
I'd prefer not checking against specific values,but really just if <
0, > 0, or == 0. Checking against specific values would kinda suggest
that there are more than three values.
if (s->reuse_port < 0) ...
Also, please do this part as part of socket_load() somewhere, so that
the < 0 state is turned into > 0 or == 0 already when loading the unit.
> -if (cfd < 0) {
> +if (cfd < 0 && !(s->distribute)) {
The extra ()... Also, please use == 0 here since it is a number...
(Same fix at a few other places...)
> +if (s->distribute > 0 && (s->n_connections >= s->distribute
> || SERVICE(UNIT_DEREF(s->service))->type == SERVICE_NOTIFY))
> +socket_set_state(s, SOCKET_RUNNING);
> +
Why do you check for SERVICE_NOTIFY here?
Also, maybe I missed something, but if SO_REUSEPORT is used you need to
create a new socket for each connection and bind it to the same
address. You have to duplicate the existing socket, but not with dup(),
but instead by creating a new one with the same parameters and with
SO_REUSEPORT... The first instance this spawns should get the original
socket though, but all others should get one of these copies...
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] [PATCHv5] tmpfiles, man: Add xattr support to tmpfiles
On Wed, 11.12.13 14:24, Maciej Wereski (m.were...@partner.samsung.com) wrote:
> >>+xattr = new0(char, strlen(i->argument)+1);
> >>+if (!xattr)
> >>+return log_oom();
> >>+
> >>+tmp = strv_split(i->argument, WHITESPACE);
> >>+if (!tmp)
> >>+return log_oom();
> >>+
> >>+strv_len = strv_length(tmp);
> >>+for (n = 0; n < strv_len; ++n) {
> >
> >Sounds like a job for the STRV_FOREACH() macro. Since you don't actually
> >need the strv as strv here it sounds like you actually really want to
> >use FOREACH_WORD_QUOTED() for this, which will also do the unquoting for
> >you.
>
> Well, FOREACH_WORD_QUOTED() won't work properly, because quotation marks
> aren't first chars in strings (e.g. user.name="John Smith"). Maybe better
> idea would be to introduce mandatory separator (e.g. semicolon) instead of
> quotation marks.
Yeah, FOREACH_WORD_QUOTED() is quite badly designed. We should fix it to
do somewhat sane quoting and escaping. I'll look into it.
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] Logging in an enterprise environment
On Wed, 11.12.13 14:25, Cecil Westerhof (cecil.wester...@snow.nl) wrote: > >Journald's primary job is local logging, for complex logging setups we > >recommend installing a logging services like rsyslog. > > Would you not loose some of the advantages of journald this way? I > understand that with using imjournal in rsyslog this probably could > mostly be circumvented. Well, you cannot look at the logs with journalctl if you do this, but you cannot have it all.. > By the way: is just copying possible? What if an event is logged at > the moment the copy is done? That's fine. The journal parser is designed to handle half written files as good as it can. > >Eventually journald should provide you with both a pull and a push > >model, however it currently onyl supports a pull model. Note that for > > Where can I information about that, or do you mean copying the files? By pull model I was referring to the GET HTTP command to the journal gateway or copying via rsync/scp/ 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] Logging in an enterprise environment
On Wed, 11.12.13 14:43, Cecil Westerhof (cecil.wester...@snow.nl) wrote: > > On 12/11/2013 02:25 PM, Cecil Westerhof wrote: > >>You can to centralized logging with the journal too, by simply making > >>the journal files you want to look at accessible on the same > >>machine. This could be done via NFS sharing, or by copying them to a > >>central host via rsync or scp or even ftp, whatever you > >>prefer. "journalctl -m" will then be able to coalesce them on display. > > > >NFS is not acceptable I am told, but I'll inquire about the other > >possibilities. > > > >By the way: is just copying possible? What if an event is logged at the > >moment the copy is done? > > I just had a little check. Copying is not acceptable. Logging on the > log-server should be real-time. If you want logging on the server in real-time, then use rsyslog. 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] libsystemd-bus: Add checking masks creds in bus_creds_dump() function
log_assert_failed_return macro generates a lot of logs when we use
bus_message_dump() function without checking masks in creds.
---
src/libsystemd-bus/bus-dump.c | 93 +++
1 file changed, 59 insertions(+), 34 deletions(-)
diff --git a/src/libsystemd-bus/bus-dump.c b/src/libsystemd-bus/bus-dump.c
index ddad418..85396aa 100644
--- a/src/libsystemd-bus/bus-dump.c
+++ b/src/libsystemd-bus/bus-dump.c
@@ -322,9 +322,12 @@ int bus_creds_dump(sd_bus_creds *c, FILE *f) {
fprintf(f, " TID=%lu", (unsigned long) c->tid);
if (c->mask & SD_BUS_CREDS_UID)
fprintf(f, " UID=%lu", (unsigned long) c->uid);
-r = sd_bus_creds_get_owner_uid(c, &owner);
-if (r >= 0)
-fprintf(f, " OwnerUID=%lu", (unsigned long) owner);
+if (c->mask & SD_BUS_CREDS_OWNER_UID) {
+r = sd_bus_creds_get_owner_uid(c, &owner);
+if (r >= 0)
+fprintf(f, " OwnerUID=%lu", (unsigned long) owner);
+}
+
if (c->mask & SD_BUS_CREDS_GID)
fprintf(f, " GID=%lu", (unsigned long) c->gid);
@@ -359,29 +362,45 @@ int bus_creds_dump(sd_bus_creds *c, FILE *f) {
if (c->mask & SD_BUS_CREDS_CGROUP)
fprintf(f, " CGroup=%s", c->cgroup);
-sd_bus_creds_get_unit(c, &u);
-if (u)
-fprintf(f, " Unit=%s", u);
-sd_bus_creds_get_user_unit(c, &uu);
-if (uu)
-fprintf(f, " UserUnit=%s", uu);
-sd_bus_creds_get_slice(c, &sl);
-if (sl)
-fprintf(f, " Slice=%s", sl);
-sd_bus_creds_get_session(c, &s);
-if (s)
-fprintf(f, " Session=%s", s);
+if (c->mask & SD_BUS_CREDS_UNIT) {
+sd_bus_creds_get_unit(c, &u);
+if (u)
+fprintf(f, " Unit=%s", u);
+}
+
+if (c->mask & SD_BUS_CREDS_USER_UNIT) {
+sd_bus_creds_get_user_unit(c, &uu);
+if (uu)
+fprintf(f, " UserUnit=%s", uu);
+}
+
+if (c->mask & SD_BUS_CREDS_SLICE) {
+sd_bus_creds_get_slice(c, &sl);
+if (sl)
+fprintf(f, " Slice=%s", sl);
+}
+
+if (c->mask & SD_BUS_CREDS_SESSION) {
+sd_bus_creds_get_session(c, &s);
+if (s)
+fprintf(f, " Session=%s", s);
+}
if ((c->mask & SD_BUS_CREDS_CGROUP) || u || uu || sl || s)
fputs("\n", f);
-if (sd_bus_creds_get_audit_login_uid(c, &audit_loginuid) >= 0) {
-audit_loginuid_is_set = true;
-fprintf(f, " AuditLoginUID=%lu", (unsigned long)
audit_loginuid);
+if (c->mask & SD_BUS_CREDS_AUDIT_LOGIN_UID) {
+if (sd_bus_creds_get_audit_login_uid(c, &audit_loginuid) >= 0)
{
+audit_loginuid_is_set = true;
+fprintf(f, " AuditLoginUID=%lu", (unsigned long)
audit_loginuid);
+}
}
-if (sd_bus_creds_get_audit_session_id(c, &audit_sessionid) >= 0) {
-audit_sessionid_is_set = true;
-fprintf(f, " AuditSessionID=%lu", (unsigned long)
audit_sessionid);
+
+if (c->mask & SD_BUS_CREDS_AUDIT_SESSION_ID) {
+if (sd_bus_creds_get_audit_session_id(c, &audit_sessionid) >=
0) {
+audit_sessionid_is_set = true;
+fprintf(f, " AuditSessionID=%lu", (unsigned long)
audit_sessionid);
+}
}
if (audit_loginuid_is_set || audit_sessionid_is_set)
@@ -390,27 +409,33 @@ int bus_creds_dump(sd_bus_creds *c, FILE *f) {
if (c->mask & SD_BUS_CREDS_UNIQUE_NAME)
fprintf(f, " UniqueName=%s", c->unique_name);
-if (sd_bus_creds_get_well_known_names(c, &well_known) >= 0) {
-char **i;
+if (c->mask & SD_BUS_CREDS_WELL_KNOWN_NAMES) {
+if (sd_bus_creds_get_well_known_names(c, &well_known) >= 0) {
+char **i;
-fputs(" WellKnownNames={", f);
-STRV_FOREACH(i, well_known) {
-if (i != well_known)
-fputc(' ', f);
+fputs(" WellKnownNames={", f);
+STRV_FOREACH(i, well_known) {
+if (i != well_known)
+fputc(' ', f);
-fputs(*i, f);
-}
+fputs(*i, f);
+}
-fputc('}', f);
+fputc('}', f);
+}
}
if (c->mask & SD_BUS_CREDS_UNIQUE_NAME || well_known)
fputc('\n', f);
-dump_capabilities(c, f, "EffectiveCapabilities",
Re: [systemd-devel] [HACK/RFC/PATCH] systemd-su: "su" on steroids
On Wed, 11.12.13 13:54, David Herrmann (dh.herrm...@gmail.com) wrote:
>
> Hi
>
> On Wed, Dec 11, 2013 at 12:18 AM, Lennart Poettering
> wrote:
> > On Mon, 02.12.13 21:47, David Herrmann (dh.herrm...@gmail.com) wrote:
> >
> >>
> >> 4h later, I present "systemd-su":
> >>
> >> If you want to give it a try, run:
> >> systemd-su -u david /bin/sh
> >>
> >> It requires the systemd-suexec helper internally, so if you didn't install
> >> it, use something like this:
> >> SYSTEMD_SUEXEC=/home/david/dev/systemd/systemd-suexec ./systemd-su -u
> >> david sh
> >> Otherwise, systemd-su cannot find the systemd-suexec binary.
> >
> > Hmm, if we allow that "su -" tells logind to create an entirely new
> > session even when called from an existing one, do we still need
> > "systemd-su"? That should be pretty close, no? That sounds easier to
> > do...
>
> You cannot start a session from within an existing session. At least
> if audit-loginids are immutable, this also means the audit-sessionid
> is immutable (as the session ID is updated if, and only if, the
> logind-uid changes).
>
> Of course, immutable audit IDs are a somewhat controversial feature
> (and afaik don't work with containers?) but I still dislike the idea
> of starting sessions from within an existing session. It's ugly and we
> don't actually need it, do we? Currently su/sudo don't start new
> sessions and I think that is fine. Imho, their intention is to change
> the EUID, not to spawn a new session.
>
> So my hack here is just some example to play with, not something for
> real to replace su/sudo.
The new switch I was suggesting for pam_systemd ("force-new-session=1")
would cause a new session to be started from within an existing one, in
that case decoupling the session id from the audit id. Hence, when you
first log into a computer you will get a session with a session ID
identical to the audit id. However if you use "su -" which then does
force-new-session=1 on pam_system you will get a new session that gets
an independent id, that is decoupled from the audi session, and to avoid
namespace clashes is prefixed with a lower-case "c". We'd only do that
for "su -"/"sudo -i", not for "su", "su -".
"su -" and "sudo -i" would hence do the "greatest possible"
disconnection from the originating session. (switch everything possible
except the tty itself)
Normal "su" and "sudo" OTOH would to the "smallest possible" disconnectn
from the originating session. (i.e. only switch uid/gid)
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] [HACK/RFC/PATCH] systemd-su: "su" on steroids
Hey
On Wed, Dec 11, 2013 at 3:27 PM, Lennart Poettering
wrote:
> On Wed, 11.12.13 13:54, David Herrmann (dh.herrm...@gmail.com) wrote:
>
>>
>> Hi
>>
>> On Wed, Dec 11, 2013 at 12:18 AM, Lennart Poettering
>> wrote:
>> > On Mon, 02.12.13 21:47, David Herrmann (dh.herrm...@gmail.com) wrote:
>> >
>> >>
>> >> 4h later, I present "systemd-su":
>> >>
>> >> If you want to give it a try, run:
>> >> systemd-su -u david /bin/sh
>> >>
>> >> It requires the systemd-suexec helper internally, so if you didn't install
>> >> it, use something like this:
>> >> SYSTEMD_SUEXEC=/home/david/dev/systemd/systemd-suexec ./systemd-su -u
>> >> david sh
>> >> Otherwise, systemd-su cannot find the systemd-suexec binary.
>> >
>> > Hmm, if we allow that "su -" tells logind to create an entirely new
>> > session even when called from an existing one, do we still need
>> > "systemd-su"? That should be pretty close, no? That sounds easier to
>> > do...
>>
>> You cannot start a session from within an existing session. At least
>> if audit-loginids are immutable, this also means the audit-sessionid
>> is immutable (as the session ID is updated if, and only if, the
>> logind-uid changes).
>>
>> Of course, immutable audit IDs are a somewhat controversial feature
>> (and afaik don't work with containers?) but I still dislike the idea
>> of starting sessions from within an existing session. It's ugly and we
>> don't actually need it, do we? Currently su/sudo don't start new
>> sessions and I think that is fine. Imho, their intention is to change
>> the EUID, not to spawn a new session.
>>
>> So my hack here is just some example to play with, not something for
>> real to replace su/sudo.
>
> The new switch I was suggesting for pam_systemd ("force-new-session=1")
> would cause a new session to be started from within an existing one, in
> that case decoupling the session id from the audit id. Hence, when you
> first log into a computer you will get a session with a session ID
> identical to the audit id. However if you use "su -" which then does
> force-new-session=1 on pam_system you will get a new session that gets
> an independent id, that is decoupled from the audi session, and to avoid
> namespace clashes is prefixed with a lower-case "c". We'd only do that
> for "su -"/"sudo -i", not for "su", "su -".
Yeah, I understand that and our code already does that, except for
CreateSession() which always tries to pick up existing sessions. My
question rather is: why would anyone want "su --login" to start a new
session? Yeah, it's needed to set env-variables correctly on
uid-change or set other things. But I've never seen a use-case where
someone really wants a new session. Imho, su/sudo is exclusively used
to change euids.
> "su -" and "sudo -i" would hence do the "greatest possible"
> disconnection from the originating session. (switch everything possible
> except the tty itself)
There is actually one thing, that you *cannot* share between
legacy/unix sessions, which is the CTTY. Only one SID can be assigned
a given TTY as CTTY. We can avoid the setsid() call, obviously, but
that seriously questions the idea why a new session is needed. Again,
if you want to share the CTTY (which su/sudo usually do), it seems
weird to not share the session.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Last question about systemd before my presentation
On 12/05/2013 08:39 PM, Lennart Poettering wrote: When virtual machines are implementd as a service. You need to let the host define the limits per guest I suppose? Not following? You can pack as many services in a slice as you want, and you can create a tree of slices, so that you can run a couple of services against a common set of resource limits. What I mend was the following: As I understood it, there are Virtual Machine solutions that are implemented as a service. When there are several VM's running in this service and one of those should get a lot more from the processor as the rest, then it is not something that could be taken care of by systemd, but should be done by the service that provides the Virtual Machine itself. I was told I could expect a question about this, but I did not get it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions I got about systemd
On 12/06/2013 01:18 PM, Mantas Mikulėnas wrote: > Is it possible to do an automatic shutdown when there is no more room to for journald to log? (They did not want to have logging removed.) Currently no. journald tries to never use more than the configured % of disk space and rotates away old logs, so it won't ever see a "disk full" error. But a syslog daemon might help. The person asking it found it not acceptable that logging disappeared. But it could be done by a cron job of-course. > Is there something to automatically convert the inittab? No. But there is very little to convert; in most distros inittab was not used to run services directly (aside from getty, which systemd always ships unit files for, and xdm/kdm/gdm, which also ship their own). I did not find it hard to convert. ;-) Next time I am asked this, I have an answer. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: support Distribute=n to distribute to n workers
On Tue, Dec 10, 2013 at 06:53:33PM -0800, Shawn Landden wrote:
Please add a commit message that says what the commit does.
This part can remain, but please prefix it with "Some open
questions remain:" or something.
> Because it takes a while for the service to start up, and
> until then we spin in a fast epoll loop, this tends to
> start up all the instances all at once. There are a number
> of ways we can slow this instanciation down:
> 1) Call accept() and pass an additional fd to the service
> 2) Use EPOLLET: requires event to be prioritized and always
> dispatched.
> 3) Disable and then reenable the event source every time we
> enqueue an instance.
>
> With Type=notify, we wait until a service tells us it is ready
> before we listen again and thereby start up more instances.
>
> What if someone want to use the templating namespace ('@')
> with Distribute=?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions I got about systemd
On Dec 11, 2013 5:38 PM, "Cecil Westerhof" wrote: > > On 12/06/2013 01:18 PM, Mantas Mikulėnas wrote: >> >> > Is it possible to do an automatic shutdown when there is no more room >> to for journald to log? (They did not want to have logging removed.) >> >> Currently no. journald tries to never use more than the configured % of >> disk space and rotates away old logs, so it won't ever see a "disk full" >> error. But a syslog daemon might help. > > > The person asking it found it not acceptable that logging disappeared. But it could be done by a cron job of-course. Logging does not disappear; /old/ logs do. If they need to be preserved, run a syslog daemon (either local with /var/log/syslog or remote with a logserver), or periodically back up old (rotated) .journals... Or, well, post a feature request? (Actually, I wonder what happens if you set the maximum to 100% of disk...) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions I got about systemd
On Wed, Dec 11, 2013 at 08:24:34PM +0200, Mantas Mikulėnas wrote: > On Dec 11, 2013 5:38 PM, "Cecil Westerhof" wrote: > > > > On 12/06/2013 01:18 PM, Mantas Mikulėnas wrote: > >> > >> > Is it possible to do an automatic shutdown when there is no more room > >> to for journald to log? (They did not want to have logging removed.) > >> > >> Currently no. journald tries to never use more than the configured % of > >> disk space and rotates away old logs, so it won't ever see a "disk full" > >> error. But a syslog daemon might help. > > > > > > The person asking it found it not acceptable that logging disappeared. > But it could be done by a cron job of-course. > > Logging does not disappear; /old/ logs do. If they need to be preserved, > run a syslog daemon (either local with /var/log/syslog or remote with a > logserver), or periodically back up old (rotated) .journals... Or, well, > post a feature request? (Actually, I wonder what happens if you set the > maximum to 100% of disk...) I vaguely remember that something like this was already discussed a few years ago. For some certifications (medical?), it is required to shut down if logging is not possible. I'm not sure what the result of those converstations was. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions I got about systemd
On 2013-12-11 19:41, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Dec 11, 2013 at 08:24:34PM +0200, Mantas Mikulėnas wrote: >> On Dec 11, 2013 5:38 PM, "Cecil Westerhof" wrote: >>> >>> On 12/06/2013 01:18 PM, Mantas Mikulėnas wrote: > Is it possible to do an automatic shutdown when there is no more room to for journald to log? (They did not want to have logging removed.) Currently no. journald tries to never use more than the configured % of disk space and rotates away old logs, so it won't ever see a "disk full" error. But a syslog daemon might help. >>> >>> >>> The person asking it found it not acceptable that logging disappeared. >> But it could be done by a cron job of-course. >> >> Logging does not disappear; /old/ logs do. If they need to be preserved, >> run a syslog daemon (either local with /var/log/syslog or remote with a >> logserver), or periodically back up old (rotated) .journals... Or, well, >> post a feature request? (Actually, I wonder what happens if you set the >> maximum to 100% of disk...) > I vaguely remember that something like this was already discussed a > few years ago. For some certifications (medical?), it is required to > shut down if logging is not possible. I don't think that's even theoretically possible unless *everything* is running fully synchronously, including writing to disk and the LAZORS (well, electromagnetic beams) that are hitting the patient. If you just want some measure of assurance, here's a few things that one could try: a) have a dedicated logging partition which nothing else writes to, and b) calculate an upper bound on the rate and size of log messages, which both combine to give you the option of doing: c) try to anticipate a "log full" condition some time in advance (given the above bounds and how much space is left) and shut things down preemptively before reaching the "log is full" condition. (This would involve using a dedicated logging daemon, obviously.) Regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] login: Don't stop a running user manager from garbage-collecting the user.
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 6ba8d98..42a7524 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -612,18 +612,6 @@ bool user_check_gc(User *u, bool drop_not_started) {
if (user_check_linger_file(u) > 0)
return true;
-if (u->slice_job && manager_job_is_active(u->manager, u->slice_job))
-return true;
-
-if (u->service_job && manager_job_is_active(u->manager,
u->service_job))
-return true;
-
-if (u->slice && manager_unit_is_active(u->manager, u->slice) != 0)
-return true;
-
-if (u->service && manager_unit_is_active(u->manager, u->service) != 0)
-return true;
-
return false;
}
--
1.8.5.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] login: Don't stop a running user manager from garbage-collecting the user.
Am 11.12.2013 19:56, schrieb Thomas Bächler: > With the current logic, a user will never be garbage-collected, since its > manager will always be around. Change the logic such that a user is > garbage-collected when it has no sessions and linger is disabled. This seems to fix my current problem. However, if I have two sessions and close one, both the dbus properties of the user/seat as well as the /run/systemd/users/$UID file still list the closed session until another session for the user closes or opens. This seems to be a separate problem, but still a flaw in the logic somewhere. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions I got about systemd
On 12/11/2013 07:24 PM, Mantas Mikulėnas wrote: >> > Is it possible to do an automatic shutdown when there is no more room >> to for journald to log? (They did not want to have logging removed.) >> >> Currently no. journald tries to never use more than the configured % of >> disk space and rotates away old logs, so it won't ever see a "disk full" >> error. But a syslog daemon might help. > > > The person asking it found it not acceptable that logging disappeared. But it could be done by a cron job of-course. Logging does not disappear; /old/ logs do. If they need to be preserved, But that was what the original questioner did not find acceptable. He found shutting down a better option as removing old logs. I did not understand it, but there are more things I do not understand. :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions I got about systemd
On Wed, Dec 11, 2013 at 7:41 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Dec 11, 2013 at 08:24:34PM +0200, Mantas Mikulėnas wrote: >> On Dec 11, 2013 5:38 PM, "Cecil Westerhof" wrote: >> > >> > On 12/06/2013 01:18 PM, Mantas Mikulėnas wrote: >> >> >> >> > Is it possible to do an automatic shutdown when there is no more room >> >> to for journald to log? (They did not want to have logging removed.) >> >> >> >> Currently no. journald tries to never use more than the configured % of >> >> disk space and rotates away old logs, so it won't ever see a "disk full" >> >> error. But a syslog daemon might help. >> > >> > >> > The person asking it found it not acceptable that logging disappeared. >> But it could be done by a cron job of-course. >> >> Logging does not disappear; /old/ logs do. If they need to be preserved, >> run a syslog daemon (either local with /var/log/syslog or remote with a >> logserver), or periodically back up old (rotated) .journals... Or, well, >> post a feature request? (Actually, I wonder what happens if you set the >> maximum to 100% of disk...) > I vaguely remember that something like this was already discussed a > few years ago. For some certifications (medical?), it is required to > shut down if logging is not possible. I'm not sure what the result of > those converstations was. Audit can do some of that stuff, including halting the machine if things do not work according to policy. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] TODO man/journalctl.xml man/sd_journal_open.xml src/journal src/libsystemd-bus src/shared src/systemd
On Wed, Dec 11, 2013 at 01:05:33PM -0800, Lennart Poettering wrote: > journal: add ability to browse journals of running OS containers > > This adds the new library call sd_journal_open_container() and a new > "-M" switch to journalctl. Particular care is taken that journalctl's > "-b" switch resolves to the current boot ID of the container, not the > host. For anyone reading this... In related news, 'journalctl -D /path/to/journal -b -0' also shows the "current"/last boot in the directory specified with -D. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] No security on systemd-journal-gatewayd
I tried out systemd-journal-gatewayd. But it looks like that everyone that can contact, can get log info. Is that true, or am I overlooking something? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timedatectl: work with old timedated
Which does have TimeUSec. Should we specifically check for this method
instead of assuming time=0 means it doesn't exist?
Before:
shawn@debian-T61:~/git/systemd$ ./timedatectl
Local time: Wed 1969-12-31 16:00:00 PST
Universal time: Thu 1970-01-01 00:00:00 UTC
RTC time: n/a
Timezone: America/Los_Angeles (PST, -0800)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: no
Last DST change: DST ended at
Sun 1969-10-26 01:59:59 PDT
Sun 1969-10-26 01:00:00 PST
Next DST change: DST begins (the clock jumps one hour forward) at
Sun 1970-04-26 01:59:59 PST
Sun 1970-04-26 03:00:00 PDT
After:
shawn@debian-T61:~/git/systemd$ ./timedatectl
Local time: Wed 2013-12-11 14:03:21 PST
Universal time: Wed 2013-12-11 22:03:21 UTC
RTC time: n/a
Timezone: America/Los_Angeles (PST, -0800)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: no
Last DST change: DST ended at
Sun 2013-11-03 01:59:59 PDT
Sun 2013-11-03 01:00:00 PST
Next DST change: DST begins (the clock jumps one hour forward) at
Sun 2014-03-09 01:59:59 PST
Sun 2014-03-09 03:00:00 PDT
---
src/timedate/timedatectl.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9b81513..7dba8e9 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -106,14 +106,19 @@ static void print_status_info(const StatusInfo *i) {
assert(i);
+if (i->time)
+sec = (time_t) (i->time / USEC_PER_SEC);
+else if (arg_transport == BUS_TRANSPORT_LOCAL)
+sec = time(NULL);
+else
+return (void)fprintf(stderr, "Could not get time from
timedated and not operating locally.\n\n");
+
/* Enforce the values of /etc/localtime */
if (getenv("TZ")) {
fprintf(stderr, "Warning: ignoring the TZ variable, reading
the system's timezone setting only.\n\n");
unsetenv("TZ");
}
-sec = (time_t) (i->time / USEC_PER_SEC);
-
zero(tm);
assert_se(strftime(a, sizeof(a), "%a %Y-%m-%d %H:%M:%S %Z",
localtime_r(&sec, &tm)) > 0);
char_array_0(a);
--
1.8.5.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
On Wed, Dec 11, 2013 at 2:41 AM, Lennart Poettering
wrote:
> On Wed, 11.12.13 02:13, Daniel Buch (boogiewasth...@gmail.com) wrote:
>
> Heya,
>
> Hmm, so thinking about it I have the suspicion this should probably be
> linked into libsystemd-bus, and thus live in src/libsystemd-bus/. The
> reason for this is cyclic deps: libsystemd-bus really should make use of
> this to resolve host names when used in tcp mode. However, this stuff
> really should come with integration into sd-event out of the box too
> which is already part of libsystemd-bus (for similar reasons). So we'd
> have asyncns both as consumer of APIs of libsystemd-bus and as
> provider of APIs to it.
>
> Of course, one could argue that DNS is hardly part of bus access but
> then again, sd-event is neither. Maybe we should just start treating
> libsystemd-bus as that library where everything we expose ends up in,
> except when it is really clear that it's only consumer, never provider
> to stuff in libsystemd-bus.
>
>> Reindentation is done to fit systemd
>> ---
>> Makefile.am | 23 +
>> src/libsystemd-asyncns/asyncns.c | 1513
>> +
>> src/libsystemd-asyncns/asyncns.h | 163
>> src/libsystemd-asyncns/test-asyncns.c | 178
>> 4 files changed, 1877 insertions(+)
>> create mode 100644 src/libsystemd-asyncns/asyncns.c
>> create mode 100644 src/libsystemd-asyncns/asyncns.h
>> create mode 100644 src/libsystemd-asyncns/test-asyncns.c
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 19da6ea..a0564b5 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -659,6 +659,29 @@ tests += test-rtnl
>>
>> #
>> --
>> noinst_LTLIBRARIES += \
>> + libsystemd-asyncns.la
>> +
>> +libsystemd_asyncns_la_SOURCES = \
>> + src/libsystemd-asyncns/asyncns.c \
>> + src/libsystemd-asyncns/asyncns.h
>
> To follow the naming scheme of the other libs we should probably call
> this "sd-asyncs.c", and the header file should be in src/systemd/
> together with the other public APIs.
>
>> +
>> +libsystemd_asyncns_la_CFLAGS = \
>> + -pthread
>> +
>> +test_asyncns_SOURCES = \
>> + src/libsystemd-asyncns/test-asyncns.c
>> +
>> +test_asyncns_LDADD = \
>> + libsystemd-asyncns.la
>> +
>> +test_asyncns_LDFLAGS = \
>> + -lresolv \
>> + -pthread
>
> I figure the -lresolv thing will eventually need a configure.ac check,
> but for now I'd just leave it like this, when this breaks for people I
> am sure they will cook up a patch quickly...
>
>> +#ifdef HAVE_CONFIG_H
>> +#include
>> +#endif
>
> Unnecessary, we do this on the gcc cmdline implicitly far all our files...
>
>> +
>> +/* #undef HAVE_PTHREAD */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#ifdef HAVE_SYS_PRCTL_H
>> +#include
>> +#endif
>
> This file isn't optional for us...
>
>> +
>> +#if HAVE_PTHREAD
>> +#include
>> +#endif
>> +
>> +#include "asyncns.h"
>> +
>> +#ifndef MSG_NOSIGNAL
>> +#define MSG_NOSIGNAL 0
>> +#endif
>
> This is non-Linux compat and should go i figure...
>
>> +struct asyncns {
>
> probably should be called sd_asyncns now...
>
>> +int fds[MESSAGE_FD_MAX];
>> +
>> +#ifndef HAVE_PTHREAD
>> +pid_t workers[MAX_WORKERS];
>> +#else
>> +pthread_t workers[MAX_WORKERS];
>> +#endif
>
> We should probably stick to one implementation here... Either with
> process or with threads, but not chicken out anymore like I did
> before...
>
> Every other day I come to different conclusions which one would be the
> one and only mode we should support.
>
> The big advantage of the process option is that things are neatly
> isolated from the parent. THe big disadvantages are that it pollutes the
> "ps" output and might generate page faults in the parent all the time,
> since we fork and don't exec().
>
> Right now I am more leaning towards the thread option. But maybe that
> changes tomorrow again. Other opinions? Kay?
>
> glib is embedding a copy of libasyncns currently, they opted for the
> thread solution. Maybe we should follow suit.
>
> (Actually, it might be worth checking the glib copy, and see if they
> made any changes to the sources, which we might want to steal back for us.
It was removed from glib again (see
https://bugzilla.gnome.org/show_bug.cgi?id=616754)
Just before the removal the glib version had this history:
https://git.gnome.org/browse/glib/log/gio/libasyncns/asyncns.c?id=aa586f63543fd584b782dbc1f90bcfae2c96502e
So just non-linux fixes.
>> +#ifndef HAVE_PTHREAD
>> +
>> +static int close_allv(const int except_fds[]) {
>
> We already have this in close_many() in util.h. This function can go away
> without replacement.
>
>> +static int reset_sigsv(const int except[
Re: [systemd-devel] No security on systemd-journal-gatewayd
Am 11.12.2013 22:41, schrieb Cecil Westerhof: > I tried out systemd-journal-gatewayd. But it looks like that everyone that > can > contact, can get log info. Is that true, or am I overlooking something? as far as i remeber from older posts about it the intention is that a) it is not on by default b) if you turn it on you need to open the port in the firewall too c) if you open the port you do this only for trusted sources signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal: pipe journalctl help output into a pager
journalctl help output might run off the screen, so be consistent
as other systemd tools do and pipe it into a pager.
---
src/journal/journalctl.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 5d12c2b..cc338e0 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -114,8 +114,18 @@ typedef struct boot_id_t {
uint64_t last;
} boot_id_t;
+static void pager_open_if_enabled(void) {
+
+if (arg_no_pager)
+return;
+
+pager_open(arg_pager_end);
+}
+
static int help(void) {
+pager_open_if_enabled();
+
printf("%s [OPTIONS...] [MATCHES...]\n\n"
"Query the journal.\n\n"
"Flags:\n"
@@ -1647,8 +1657,8 @@ int main(int argc, char *argv[]) {
return EXIT_FAILURE;
}
-if (!arg_no_pager && !arg_follow)
-pager_open(arg_pager_end);
+if (!arg_follow)
+pager_open_if_enabled();
if (!arg_quiet) {
usec_t start, end;
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] test-fileio: replace mktemp with mkstemp to avoid warnings
From: Thomas Hindoe Paaboel Andersen
This is a fairly useless thing to do but it makes the compilers
and analyzers shut up about the use of mktemp.
---
src/test/test-fileio.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/test/test-fileio.c b/src/test/test-fileio.c
index 06f3e28..b005f3b 100644
--- a/src/test/test-fileio.c
+++ b/src/test/test-fileio.c
@@ -41,7 +41,9 @@ static void test_parse_env_file(void) {
char **i;
unsigned k;
-assert_se(mktemp(p));
+fd = mkstemp(p);
+assert_se(fd >= 0);
+close(fd);
fd = mkostemp(t, O_CLOEXEC);
assert_se(fd >= 0);
@@ -152,7 +154,9 @@ static void test_parse_multiline_env_file(void) {
_cleanup_strv_free_ char **a = NULL, **b = NULL;
char **i;
-assert_se(mktemp(p));
+fd = mkstemp(p);
+assert_se(fd >= 0);
+close(fd);
fd = mkostemp(t, O_CLOEXEC);
assert_se(fd >= 0);
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
From: David Strauss --- src/shared/install.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/shared/install.c b/src/shared/install.c index 17e8a75..14c0f4b 100644 --- a/src/shared/install.c +++ b/src/shared/install.c @@ -423,6 +423,11 @@ static int find_symlinks_fd( bool found_path, found_dest, b = false; int q; +/* Skip symlinks with a different basename than + * the target unit */ +if (!streq(basename(de->d_name), name)) +continue; + /* Acquire symlink name */ p = path_make_absolute(de->d_name, path); if (!p) -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test-fileio: replace mktemp with mkstemp to avoid warnings
On Thu, Dec 12, 2013 at 12:32:43AM +0100, Thomas H.P. Andersen wrote: > From: Thomas Hindoe Paaboel Andersen > > This is a fairly useless thing to do but it makes the compilers > and analyzers shut up about the use of mktemp. Please apply it. Spurious warnings are very annoying. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
After watching the results for an hour or so, this massively improves the performance of is-enabled and several other systems on our heavily loaded boxes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test-fileio: replace mktemp with mkstemp to avoid warnings
On Thu, Dec 12, 2013 at 1:41 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Dec 12, 2013 at 12:32:43AM +0100, Thomas H.P. Andersen wrote: >> From: Thomas Hindoe Paaboel Andersen >> >> This is a fairly useless thing to do but it makes the compilers >> and analyzers shut up about the use of mktemp. > Please apply it. Spurious warnings are very annoying. Applied. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test-fileio: replace mktemp with mkstemp to avoid warnings
Thank you for this! On Wed, Dec 11, 2013 at 5:55 PM, Thomas H.P. Andersen wrote: > On Thu, Dec 12, 2013 at 1:41 AM, Zbigniew Jędrzejewski-Szmek > wrote: >> On Thu, Dec 12, 2013 at 12:32:43AM +0100, Thomas H.P. Andersen wrote: >>> From: Thomas Hindoe Paaboel Andersen >>> >>> This is a fairly useless thing to do but it makes the compilers >>> and analyzers shut up about the use of mktemp. >> Please apply it. Spurious warnings are very annoying. > Applied. 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] [HACK/RFC/PATCH] systemd-su: "su" on steroids
On Tue, Dec 10, 2013 at 3:18 PM, Lennart Poettering wrote: > On Mon, 02.12.13 21:47, David Herrmann (dh.herrm...@gmail.com) wrote: > >> >> 4h later, I present "systemd-su": >> >> If you want to give it a try, run: >> systemd-su -u david /bin/sh >> >> It requires the systemd-suexec helper internally, so if you didn't install >> it, use something like this: >> SYSTEMD_SUEXEC=/home/david/dev/systemd/systemd-suexec ./systemd-su -u >> david sh >> Otherwise, systemd-su cannot find the systemd-suexec binary. > > Hmm, if we allow that "su -" tells logind to create an entirely new > session even when called from an existing one, do we still need > "systemd-su"? That should be pretty close, no? That sounds easier to > do... > >> Additionally, I create an anonymous AF_UNIX socket in systemd-su which >> systemd-suexec connects to. I then pass file-descriptors to systemd-suexec >> which installes them as STDIN/OUT/ERR. >> I actually think it would be quite useful to extend the >> StartTransientUnit() dbus call to allow passing FDs. It would allow us to >> "store" FDs with active units, which would be useful for a lot of other >> concepts (like storing DRM framebuffer handles..). > > Hmm, so we thought about adding support for something like a per-service > fd storage facility in systemd. This would be populated from the .socket > units, but could also be passed in for transient units by the caller or > even updated by the services themselves if they want to store additional > fds in systemd. This would solve a number of issues for us, including > one big one: currently if you restart systemd-journald you lose the > per-service stdout/stderr connections because there's no way to save > them. We need to do this in order to integrate criu into systemd as well. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > 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] journal: pipe journalctl help output into a pager
On Thu, Dec 12, 2013 at 12:22:48AM +0100, Djalal Harouni wrote: > journalctl help output might run off the screen, so be consistent > as other systemd tools do and pipe it into a pager. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No security on systemd-journal-gatewayd
On Wed, Dec 11, 2013 at 11:53 PM, Reindl Harald wrote: > Am 11.12.2013 22:41, schrieb Cecil Westerhof: >> I tried out systemd-journal-gatewayd. But it looks like that everyone that >> can >> contact, can get log info. Is that true, or am I overlooking something? > > as far as i remeber from older posts about it the intention is that > > a) it is not on by default > b) if you turn it on you need to open the port in the firewall too > c) if you open the port you do this only for trusted sources The current implementation is more a proof-of-concept, not used or enabled by default. It has zero built-in security, it cannot be used or enabled in untrusted environments without externally provided protection. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
В Wed, 11 Dec 2013 15:54:39 -0800 da...@davidstrauss.net пишет: > From: David Strauss > > --- > src/shared/install.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/src/shared/install.c b/src/shared/install.c > index 17e8a75..14c0f4b 100644 > --- a/src/shared/install.c > +++ b/src/shared/install.c > @@ -423,6 +423,11 @@ static int find_symlinks_fd( > bool found_path, found_dest, b = false; > int q; > > +/* Skip symlinks with a different basename than > + * the target unit */ > +if (!streq(basename(de->d_name), name)) > +continue; > + This completely changes semantic of what it does. In this case no symlink is needed in the first place - just "touch .../unit.wants/other.unit" would be enough, as long as we assume units can only be located in standard config paths. > /* Acquire symlink name */ > p = path_make_absolute(de->d_name, path); > if (!p) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: add missing include
Needed for socketpair, recv --- src/shared/logs-show.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc75..0e3fd3d 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include -- 1.8.5.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/8] add GOP mode setting and splash drawing support
Hi Greg, I sent another set of patches, this time from command line, and at least I do not observe any line-wrapping with them when viewing the e-mail source. Did they apply fine for you? Regards, Joonas On 10.12.2013 10:03, Greg KH wrote: On Tue, Dec 10, 2013 at 09:50:58AM +0200, Joonas Lahtinen wrote: Add support for two new configuration directives gfxmode and splash which respectively allow setting the screen graphics mode and drawing splash image during gummiboot execution. See README.gop for more details. Signed-off-by: Joonas Lahtinen Reviewed-by: Mikko Ylinen Acked-by: Darren Hart --- Makefile.am | 5 ++ README.gop | 46 ++ configure.ac| 7 +++ src/efi/gop.c | 137 Your patch is line-wrapped and can't be applied :( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
