[systemd-devel] ability to associate new process with cgroups of an RPC client
I'm looking for guidance on how the following can be done with systemd or if there is a different approach. Imagine I have a daemon that forks processes based on a RPC request. If the deamon is running in daemon.service and the RPC client is running is session-42.scope. I would like the daemon to be able to fork a new process in session-42.scope, or as a new cgroup that is a child of the callers cgroup. >From what I understand of systemd is that the only way to create a process and put it in a cgroup is to create a transient unit with the PIDs property, but there seems to be no way to associate the transient unit with an existing cgroup. I realize creating a transient unit in an existing cgroup may not make any sense because the unit no longer can use cgroups for grouping processes. So it seems that there should be a different API of systemd to join a process to an arbitrary cgroup. Darren ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add edit verb
2014-10-13 16:13 GMT+02:00 Simon McVittie : > On 13/10/14 14:38, Dale R. Worley wrote: >> My general understanding is that the traditional behavior when "you >> need an editor but the user hasn't specified one" is to use "vi", and >> so people who don't want "vi" *always* set $VISUAL in their >> environment. > > The Right Thing™ is distro-specific. Debian and its derivatives have > sensible-editor(1) which is a shell script that uses $VISUAL, $EDITOR, > nano[1] or vi; I would expect systemd in Debian to use sensible-editor > as its fallback, either via a configure option or a patch. > > In distros without sensible-editor, I'm tempted to say the solution is > "stop being a distro without sensible-editor". New systemd API? :-) > Before I resend the patch, we should agree on what to do here, for me it makes more sense to raise an error asking to set either EDITOR or SYSTEMD_EDITOR than running vi or a "sensible-editor" like you said. Because, someone used to its editor will quit vi or "sensible-editor" and will try to find out how to set the editor for systemctl (Even if it is well known for EDITOR or VISUAL, some people don't set these variables). If we raise an error, someone not used to these variables but having a favorite editor will know how to change this. And if this person does not have a favorite editor and never used one (unlikely but I think this is the purpose of the sensible-editor ?), we can advice to set EDITOR to nano or an equivalent. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] odd seek_tail behaviour
Christian Hesse on Mon, 2014/10/13 20:22: > Daurnimator on Mon, 2014/10/13 01:27: > > Hi All, > > > > I was trying to write a program that tailed the journal, but found that > > sd_journal_seek_tail() didn't work as expected. > > That is: that it would seek to the last/most recent thing in the journal, > > and I could tail things from there. > > > > I whipped up a quick demonstration program, that shows that messages I > > 'next' through, are before the 'cutoff': > > > > [code and output] > > > > Is this behaviour expected? I'm using systemd 216. > > I do see a similar problem in my code [0]. I do call sd_journal_previous() > after sd_journal_seek_tail(), but I still do see some older message come up. > > sd_journal_next() is the first I call in while loop. Perhaps even this is a > problem? > > [0] https://github.com/eworm-de/journal-notify/blob/master/journal-notify.c Looks like I was right. For any reason sd_journal_next() can jump to old journal entries (even if sd_journal_previous() has been called before). That happens before sd_journal_wait() is called the first time. Sadly I do not know how to reproduce. It happens very seldom and I could not find the culprit so far. -- main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);} signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] sd-journal: consistently use ternany for all direction checks
From: Christian Hesse --- src/journal/sd-journal.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c index 479444c..daa04ac 100644 --- a/src/journal/sd-journal.c +++ b/src/journal/sd-journal.c @@ -849,10 +849,8 @@ static int next_beyond_location(sd_journal *j, JournalFile *f, direction_t direc int k; k = compare_with_location(f, c, &j->current_location); -if (direction == DIRECTION_DOWN) -found = k > 0; -else -found = k < 0; + +found = direction == DIRECTION_DOWN ? k > 0 : k < 0; } else found = true; -- 2.1.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] odd seek_tail behaviour
Daurnimator on Mon, 2014/10/13 01:27: > Hi All, > > I was trying to write a program that tailed the journal, but found that > sd_journal_seek_tail() didn't work as expected. > That is: that it would seek to the last/most recent thing in the journal, > and I could tail things from there. > > I whipped up a quick demonstration program, that shows that messages I > 'next' through, are before the 'cutoff': > > [code and output] > > Is this behaviour expected? I'm using systemd 216. I do see a similar problem in my code [0]. I do call sd_journal_previous() after sd_journal_seek_tail(), but I still do see some older message come up. sd_journal_next() is the first I call in while loop. Perhaps even this is a problem? [0] https://github.com/eworm-de/journal-notify/blob/master/journal-notify.c -- main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/*Chris get my mail address:*/=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig*/b/42*2-3)*42);} signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] odd seek_tail behaviour
On 13 October 2014 07:22, Sascha Kattelmann wrote: > here is a related "bug" report: > https://bugs.freedesktop.org/show_bug.cgi?id=64614 sd_journal_next() is documented as returning '0' if there are no more entries available after the current position. So this sounds like a bug to me. > Doing a "next" after "seek_tail" ends up in some unexpected behaviour. > Just do a "previous" after seeking the tail and everything works fine. > The problem is symmetrical: Same goes for "previous" after "seek_head". > You need to do a "next" immediately after "seek_head". > If this is the API contract; why not perform "next's" functionality inside of seek_head? Thanks for the work around. I just commited an example script: https://github.com/daurnimator/lua-systemd/blob/master/examples/tail_logs.lua ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] selinux: set selinux context applied on exec() before closing all fds
On Mon, Oct 13, 2014 at 04:57:13PM +0200, Michal Sekletar wrote: > We need original socket_fd around otherwise label_get_child_mls_label fails > with > -EINVAL return code. > --- > src/core/execute.c | 58 > -- > 1 file changed, 30 insertions(+), 28 deletions(-) > > diff --git a/src/core/execute.c b/src/core/execute.c > index b165b33..d64fa7c 100644 > --- a/src/core/execute.c > +++ b/src/core/execute.c > @@ -1578,6 +1578,36 @@ static int exec_child(ExecCommand *command, > } > } > I don't like the fact that now SELINUX context would be applied before closing of the fds, and other contexts after. I think it would be much nicer to simply extract getting the label, i.e. this part: > +if (params->selinux_context_net && socket_fd >= 0) { > +_cleanup_free_ char *label = NULL; > + > +err = label_get_child_mls_label(socket_fd, > command->path, &label); > +if (err < 0) { > +*error = EXIT_SELINUX_CONTEXT; > +return err; > +} above the closing of the fds, and keep the rest where it was. > +#ifdef HAVE_SELINUX > +if (params->apply_permissions) { > +if (use_selinux()) { > +if (context->selinux_context) { > +err = setexeccon(context->selinux_context); > +if (err < 0 && > !context->selinux_context_ignore) { > +*error = EXIT_SELINUX_CONTEXT; > +return err; > +} > +} > + > +if (params->selinux_context_net && socket_fd >= 0) { > +_cleanup_free_ char *label = NULL; > + > +err = label_get_child_mls_label(socket_fd, > command->path, &label); > +if (err < 0) { > +*error = EXIT_SELINUX_CONTEXT; > +return err; > +} > + > +err = setexeccon(label); > +if (err < 0) { > +*error = EXIT_SELINUX_CONTEXT; > +return err; > +} > +} > +} > +} > +#endif BTW, it is quite confusing for me that setexeccon() is called twice. IIUC, this is because "only the descurity level is used from the information provided the peer". Is this correct? Could you add a comment to the code that explains this? Zbyszek > + > /* We repeat the fd closing here, to make sure that > * nothing is leaked from the PAM modules. Note that > * we are more aggressive this time since socket_fd > @@ -1665,34 +1695,6 @@ static int exec_child(ExecCommand *command, > } > #endif > > -#ifdef HAVE_SELINUX > -if (use_selinux()) { > -if (context->selinux_context) { > -err = setexeccon(context->selinux_context); > -if (err < 0 && > !context->selinux_context_ignore) { > -*error = EXIT_SELINUX_CONTEXT; > -return err; > -} > -} > - > -if (params->selinux_context_net && socket_fd >= 0) { > -_cleanup_free_ char *label = NULL; > - > -err = label_get_child_mls_label(socket_fd, > command->path, &label); > -if (err < 0) { > -*error = EXIT_SELINUX_CONTEXT; > -return err; > -} > - > -err = setexeccon(label); > -if (err < 0) { > -*error = EXIT_SELINUX_CONTEXT; > -return err; > -} > -} > -} > -#endif > - > #ifdef HAVE_APPARMOR > if (context->apparmor_profile && use_apparmor()) { > err = aa_change_onexec(context->apparmor_profile); ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] selinux: set selinux context applied on exec() before closing all fds
We need original socket_fd around otherwise label_get_child_mls_label fails with -EINVAL return code. --- src/core/execute.c | 58 -- 1 file changed, 30 insertions(+), 28 deletions(-) diff --git a/src/core/execute.c b/src/core/execute.c index b165b33..d64fa7c 100644 --- a/src/core/execute.c +++ b/src/core/execute.c @@ -1578,6 +1578,36 @@ static int exec_child(ExecCommand *command, } } +#ifdef HAVE_SELINUX +if (params->apply_permissions) { +if (use_selinux()) { +if (context->selinux_context) { +err = setexeccon(context->selinux_context); +if (err < 0 && !context->selinux_context_ignore) { +*error = EXIT_SELINUX_CONTEXT; +return err; +} +} + +if (params->selinux_context_net && socket_fd >= 0) { +_cleanup_free_ char *label = NULL; + +err = label_get_child_mls_label(socket_fd, command->path, &label); +if (err < 0) { +*error = EXIT_SELINUX_CONTEXT; +return err; +} + +err = setexeccon(label); +if (err < 0) { +*error = EXIT_SELINUX_CONTEXT; +return err; +} +} +} +} +#endif + /* We repeat the fd closing here, to make sure that * nothing is leaked from the PAM modules. Note that * we are more aggressive this time since socket_fd @@ -1665,34 +1695,6 @@ static int exec_child(ExecCommand *command, } #endif -#ifdef HAVE_SELINUX -if (use_selinux()) { -if (context->selinux_context) { -err = setexeccon(context->selinux_context); -if (err < 0 && !context->selinux_context_ignore) { -*error = EXIT_SELINUX_CONTEXT; -return err; -} -} - -if (params->selinux_context_net && socket_fd >= 0) { -_cleanup_free_ char *label = NULL; - -err = label_get_child_mls_label(socket_fd, command->path, &label); -if (err < 0) { -*error = EXIT_SELINUX_CONTEXT; -return err; -} - -err = setexeccon(label); -if (err < 0) { -*error = EXIT_SELINUX_CONTEXT; -return err; -} -} -} -#endif - #ifdef HAVE_APPARMOR if (context->apparmor_profile && use_apparmor()) { err = aa_change_onexec(context->apparmor_profile); -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] selinux: fix potential double free crash in child process
Before returning from function we should reset ret to NULL, thus cleanup function is nop. Also context_str() returns pointer to a string containing context but not a copy, hence we must make copy it explicitly. --- src/shared/label.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/shared/label.c b/src/shared/label.c index b6af38d..89fb49e 100644 --- a/src/shared/label.c +++ b/src/shared/label.c @@ -334,7 +334,8 @@ int label_get_child_mls_label(int socket_fd, const char *exe, char **label) { } freecon(mycon); -mycon = context_str(bcon); +mycon = NULL; +mycon = strdup(context_str(bcon)); if (!mycon) { r = -errno; goto out; @@ -348,6 +349,7 @@ int label_get_child_mls_label(int socket_fd, const char *exe, char **label) { } *label = ret; +ret = NULL; r = 0; out: -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
On Mon, Oct 13, 2014 at 09:36:16AM +0200, Jan Synacek wrote: > Hello, > > currently, unicode characters are not correctly displayed in the > console. After login, when I run /usr/bin/unicode_start, unicode works > fine. I tried to create a service file that runs this script, linking > tty to stdout and stderr, but that didn't work. Is there a way how to > turn on unicode support in console after boot using a service file? Or > any other type of unit? Or is this something that has to be patched in > the source (logind perhaps?)? Please try editing /usr/lib/systemd/system/systemd-vconsole-setup.service and remove RemainAfterExit=yes, then regenerate your initramfs image by running dracut command. Add back RemainAfterExit=yes to service file. Reboot. Michal > > Cheers, > -- > Jan Synacek > Software Engineer, 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] systemctl: add edit verb
On 13/10/14 14:38, Dale R. Worley wrote: > My general understanding is that the traditional behavior when "you > need an editor but the user hasn't specified one" is to use "vi", and > so people who don't want "vi" *always* set $VISUAL in their > environment. The Right Thing™ is distro-specific. Debian and its derivatives have sensible-editor(1) which is a shell script that uses $VISUAL, $EDITOR, nano[1] or vi; I would expect systemd in Debian to use sensible-editor as its fallback, either via a configure option or a patch. In distros without sensible-editor, I'm tempted to say the solution is "stop being a distro without sensible-editor". New systemd API? :-) S [1] chosen for being small, self-documenting (hotkeys shown at the bottom of the screen), and unlike vi, not having a learning curve like a brick wall. I use vim myself, but I wouldn't want to inflict it on beginners. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
On Monday 13 October 2014 at 15:36:00, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Oct 13, 2014 at 03:13:50PM +0200, Jan Synacek wrote: > > Andrei Borzenkov writes: > > > [...] > > > > > > Does booting with plymouth.enable=0 change anything? > > > > Nope, that doesn't help. After "loadkeys cz", I still see white > > rectangles instead of proper characters. > Could be a kernel bug too, don't rule this out. IIRC, some settings do > not get propagated from the foreground console to other consoles, or they > get reset at some point, or something like that (should be the ML archives). It is also possible that settings get reset after the framebuffer driver is changed (e. g. i915 module is loaded)... BTW, I'm still seeking for a correct method to handle this. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add edit verb
> From: David Herrmann > > On Sat, Oct 11, 2014 at 8:17 PM, Daniel Buch wrote: > > Nice, I was in the process of implementing this. Looks good to me. But I > > think it would be better to use "vi" instead of "vim" if no &editor is set. > > Vim is not installed on every system as default but vi is most likely. > > I'd prefer doing nothing. "vi" has quite different behavior than > "vim", especially in Ex mode. And for people uncomfortable with 'vi' > it's even worth. And everyone should have set EDITOR anyway.. My general understanding is that the traditional behavior when "you need an editor but the user hasn't specified one" is to use "vi", and so people who don't want "vi" *always* set $VISUAL in their environment. If you're being really nice, the program determines whether the terminal is dumb or visual, and then goes through the sequence of choices: 1) $VISUAL if the terminal is visual and it is specified 2) $EDITOR if it is specified (or if $VISUAL fails to execute) 3) vi if the terminal is visual 4) ed or ex (I think) (I don't know what the test for visual is. It may simply have been trying to execute $VISUAL (and vi) and seeing if they exit with an error.) Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
On Mon, Oct 13, 2014 at 03:13:50PM +0200, Jan Synacek wrote: > Andrei Borzenkov writes: > > On Mon, Oct 13, 2014 at 4:33 PM, Jan Synacek wrote: > >> Andrei Borzenkov writes: > >>> On Mon, Oct 13, 2014 at 12:48 PM, Jan Synacek wrote: > Mantas Mikulėnas writes: > > On Mon, Oct 13, 2014 at 10:36 AM, Jan Synacek > > wrote: > >> Hello, > >> > >> currently, unicode characters are not correctly displayed in the > >> console. After login, when I run /usr/bin/unicode_start, unicode works > >> fine. I tried to create a service file that runs this script, linking > >> tty to stdout and stderr, but that didn't work. Is there a way how to > >> turn on unicode support in console after boot using a service file? Or > >> any other type of unit? Or is this something that has to be patched in > >> the source (logind perhaps?)? > > > > This is already done by systemd-vconsole-setup [1], but only if the > > system locale is a UTF-8 one [2]. > > > > [1]: > > http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c?h=a158dbf156ac#n70 > > [2]: > > http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c?h=a158dbf156ac#n5547 > > Thank you. There seems to be something wrong with the > systemd-vconsole-setup.service, it doesn't seem to be run correctly at > boot. If restarted, I get the unicode support. > > >>> > >>> Do you use graphical splash screen (plymouth) by any chance? > >> > >> Yes, I'm trying this in somewhat newish rawhide, I believe plymouth is > >> on by default. I tried removing "rhgb" from the kernel command line, but > >> that didn't change anything. > >> > > > > Does booting with plymouth.enable=0 change anything? > > Nope, that doesn't help. After "loadkeys cz", I still see white > rectangles instead of proper characters. Could be a kernel bug too, don't rule this out. IIRC, some settings do not get propagated from the foreground console to other consoles, or they get reset at some point, or something like that (should be the ML archives). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus-proxyd: improve compatibility with dbus-1
'GetConnectionUnixProcessID', 'GetConnectionUnixUser' and 'GetConnectionSELinuxSecurityContext' methods should return 'NameHasNoOwner' error (if chosen name is not available on bus) with more detailed description - like dbus-1: Could not get PID of name 'org.freedesktop.test': no such name. Could not get UID of name 'org.freedesktop.test': no such name. Could not get security context of name 'org.freedesktop.test': no such name. Otherwise we have only laconic message without proper dbus error: Error System.Error.ENXIO: No such device or address --- src/bus-proxyd/bus-proxyd.c | 36 +--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c index 52498f3..1bd7fee 100644 --- a/src/bus-proxyd/bus-proxyd.c +++ b/src/bus-proxyd/bus-proxyd.c @@ -643,27 +643,57 @@ static int process_driver(sd_bus *a, sd_bus *b, sd_bus_message *m) { return synthetic_reply_method_return(m, NULL); } else if (sd_bus_message_is_method_call(m, "org.freedesktop.DBus", "GetConnectionSELinuxSecurityContext")) { +const char *name; _cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL; +_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL; -r = get_creds_by_message(a, m, SD_BUS_CREDS_SELINUX_CONTEXT, &creds, NULL); +r = sd_bus_message_read(m, "s", &name); +if (r < 0) +return r; + +r = get_creds_by_name(a, name, SD_BUS_CREDS_SELINUX_CONTEXT, &creds, NULL); +if (r == -ESRCH || r == -ENXIO) { +sd_bus_error_setf(&error, SD_BUS_ERROR_NAME_HAS_NO_OWNER, "Could not get security context of name '%s': no such name.", name); +return synthetic_reply_method_errno(m, r, &error); +} if (r < 0) return synthetic_reply_method_errno(m, r, NULL); return synthetic_reply_method_return(m, "y", creds->label, strlen(creds->label)); } else if (sd_bus_message_is_method_call(m, "org.freedesktop.DBus", "GetConnectionUnixProcessID")) { +const char *name; _cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL; +_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL; -r = get_creds_by_message(a, m, SD_BUS_CREDS_PID, &creds, NULL); +r = sd_bus_message_read(m, "s", &name); +if (r < 0) +return r; + +r = get_creds_by_name(a, name, SD_BUS_CREDS_PID, &creds, NULL); +if (r == -ESRCH || r == -ENXIO) { +sd_bus_error_setf(&error, SD_BUS_ERROR_NAME_HAS_NO_OWNER, "Could not get PID of name '%s': no such name.", name); +return synthetic_reply_method_errno(m, r, &error); +} if (r < 0) return synthetic_reply_method_errno(m, r, NULL); return synthetic_reply_method_return(m, "u", (uint32_t) creds->pid); } else if (sd_bus_message_is_method_call(m, "org.freedesktop.DBus", "GetConnectionUnixUser")) { +const char *name; _cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL; +_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL; -r = get_creds_by_message(a, m, SD_BUS_CREDS_UID, &creds, NULL); +r = sd_bus_message_read(m, "s", &name); +if (r < 0) +return r; + +r = get_creds_by_name(a, name, SD_BUS_CREDS_UID, &creds, NULL); +if (r == -ESRCH || r == -ENXIO) { +sd_bus_error_setf(&error, SD_BUS_ERROR_NAME_HAS_NO_OWNER, "Could not get UID of name '%s': no such name.", name); +return synthetic_reply_method_errno(m, r, &error); +} if (r < 0) return synthetic_reply_method_errno(m, r, NULL); -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
Andrei Borzenkov writes: > On Mon, Oct 13, 2014 at 4:33 PM, Jan Synacek wrote: >> Andrei Borzenkov writes: >>> On Mon, Oct 13, 2014 at 12:48 PM, Jan Synacek wrote: Mantas Mikulėnas writes: > On Mon, Oct 13, 2014 at 10:36 AM, Jan Synacek wrote: >> Hello, >> >> currently, unicode characters are not correctly displayed in the >> console. After login, when I run /usr/bin/unicode_start, unicode works >> fine. I tried to create a service file that runs this script, linking >> tty to stdout and stderr, but that didn't work. Is there a way how to >> turn on unicode support in console after boot using a service file? Or >> any other type of unit? Or is this something that has to be patched in >> the source (logind perhaps?)? > > This is already done by systemd-vconsole-setup [1], but only if the > system locale is a UTF-8 one [2]. > > [1]: > http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c?h=a158dbf156ac#n70 > [2]: > http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c?h=a158dbf156ac#n5547 Thank you. There seems to be something wrong with the systemd-vconsole-setup.service, it doesn't seem to be run correctly at boot. If restarted, I get the unicode support. >>> >>> Do you use graphical splash screen (plymouth) by any chance? >> >> Yes, I'm trying this in somewhat newish rawhide, I believe plymouth is >> on by default. I tried removing "rhgb" from the kernel command line, but >> that didn't change anything. >> > > Does booting with plymouth.enable=0 change anything? Nope, that doesn't help. After "loadkeys cz", I still see white rectangles instead of proper characters. -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
On Mon, Oct 13, 2014 at 4:33 PM, Jan Synacek wrote: > Andrei Borzenkov writes: >> On Mon, Oct 13, 2014 at 12:48 PM, Jan Synacek wrote: >>> Mantas Mikulėnas writes: On Mon, Oct 13, 2014 at 10:36 AM, Jan Synacek wrote: > Hello, > > currently, unicode characters are not correctly displayed in the > console. After login, when I run /usr/bin/unicode_start, unicode works > fine. I tried to create a service file that runs this script, linking > tty to stdout and stderr, but that didn't work. Is there a way how to > turn on unicode support in console after boot using a service file? Or > any other type of unit? Or is this something that has to be patched in > the source (logind perhaps?)? This is already done by systemd-vconsole-setup [1], but only if the system locale is a UTF-8 one [2]. [1]: http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c?h=a158dbf156ac#n70 [2]: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c?h=a158dbf156ac#n5547 >>> >>> Thank you. There seems to be something wrong with the >>> systemd-vconsole-setup.service, it doesn't seem to be run correctly at >>> boot. If restarted, I get the unicode support. >>> >> >> Do you use graphical splash screen (plymouth) by any chance? > > Yes, I'm trying this in somewhat newish rawhide, I believe plymouth is > on by default. I tried removing "rhgb" from the kernel command line, but > that didn't change anything. > Does booting with plymouth.enable=0 change anything? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
Andrei Borzenkov writes: > On Mon, Oct 13, 2014 at 12:48 PM, Jan Synacek wrote: >> Mantas Mikulėnas writes: >>> On Mon, Oct 13, 2014 at 10:36 AM, Jan Synacek wrote: Hello, currently, unicode characters are not correctly displayed in the console. After login, when I run /usr/bin/unicode_start, unicode works fine. I tried to create a service file that runs this script, linking tty to stdout and stderr, but that didn't work. Is there a way how to turn on unicode support in console after boot using a service file? Or any other type of unit? Or is this something that has to be patched in the source (logind perhaps?)? >>> >>> This is already done by systemd-vconsole-setup [1], but only if the >>> system locale is a UTF-8 one [2]. >>> >>> [1]: >>> http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c?h=a158dbf156ac#n70 >>> [2]: >>> http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c?h=a158dbf156ac#n5547 >> >> Thank you. There seems to be something wrong with the >> systemd-vconsole-setup.service, it doesn't seem to be run correctly at >> boot. If restarted, I get the unicode support. >> > > Do you use graphical splash screen (plymouth) by any chance? Yes, I'm trying this in somewhat newish rawhide, I believe plymouth is on by default. I tried removing "rhgb" from the kernel command line, but that didn't change anything. -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add edit verb
Hi On Sat, Oct 11, 2014 at 8:17 PM, Daniel Buch wrote: > Nice, I was in the process of implementing this. Looks good to me. But I > think it would be better to use "vi" instead of "vim" if no &editor is set. > Vim is not installed on every system as default but vi is most likely. I'd prefer doing nothing. "vi" has quite different behavior than "vim", especially in Ex mode. And for people uncomfortable with 'vi' it's even worth. And everyone should have set EDITOR anyway.. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
On Mon, Oct 13, 2014 at 12:48 PM, Jan Synacek wrote: > Mantas Mikulėnas writes: >> On Mon, Oct 13, 2014 at 10:36 AM, Jan Synacek wrote: >>> Hello, >>> >>> currently, unicode characters are not correctly displayed in the >>> console. After login, when I run /usr/bin/unicode_start, unicode works >>> fine. I tried to create a service file that runs this script, linking >>> tty to stdout and stderr, but that didn't work. Is there a way how to >>> turn on unicode support in console after boot using a service file? Or >>> any other type of unit? Or is this something that has to be patched in >>> the source (logind perhaps?)? >> >> This is already done by systemd-vconsole-setup [1], but only if the >> system locale is a UTF-8 one [2]. >> >> [1]: >> http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c?h=a158dbf156ac#n70 >> [2]: >> http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c?h=a158dbf156ac#n5547 > > Thank you. There seems to be something wrong with the > systemd-vconsole-setup.service, it doesn't seem to be run correctly at > boot. If restarted, I get the unicode support. > Do you use graphical splash screen (plymouth) by any chance? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
Mantas Mikulėnas writes: > On Mon, Oct 13, 2014 at 10:36 AM, Jan Synacek wrote: >> Hello, >> >> currently, unicode characters are not correctly displayed in the >> console. After login, when I run /usr/bin/unicode_start, unicode works >> fine. I tried to create a service file that runs this script, linking >> tty to stdout and stderr, but that didn't work. Is there a way how to >> turn on unicode support in console after boot using a service file? Or >> any other type of unit? Or is this something that has to be patched in >> the source (logind perhaps?)? > > This is already done by systemd-vconsole-setup [1], but only if the > system locale is a UTF-8 one [2]. > > [1]: > http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c?h=a158dbf156ac#n70 > [2]: > http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c?h=a158dbf156ac#n5547 Thank you. There seems to be something wrong with the systemd-vconsole-setup.service, it doesn't seem to be run correctly at boot. If restarted, I get the unicode support. -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unicode support in console after boot
On Mon, Oct 13, 2014 at 10:36 AM, Jan Synacek wrote: > Hello, > > currently, unicode characters are not correctly displayed in the > console. After login, when I run /usr/bin/unicode_start, unicode works > fine. I tried to create a service file that runs this script, linking > tty to stdout and stderr, but that didn't work. Is there a way how to > turn on unicode support in console after boot using a service file? Or > any other type of unit? Or is this something that has to be patched in > the source (logind perhaps?)? This is already done by systemd-vconsole-setup [1], but only if the system locale is a UTF-8 one [2]. [1]: http://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/vconsole-setup.c?h=a158dbf156ac#n70 [2]: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.c?h=a158dbf156ac#n5547 -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unicode support in console after boot
Hello, currently, unicode characters are not correctly displayed in the console. After login, when I run /usr/bin/unicode_start, unicode works fine. I tried to create a service file that runs this script, linking tty to stdout and stderr, but that didn't work. Is there a way how to turn on unicode support in console after boot using a service file? Or any other type of unit? Or is this something that has to be patched in the source (logind perhaps?)? Cheers, -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should user mode linux register with machined?
Jan Synacek writes: > Lennart Poettering writes: >> On Fri, 10.10.14 18:48, Richard Weinberger (rich...@nod.at) wrote: >> >>> Lennart, >>> >>> Am 10.10.2014 um 18:44 schrieb Lennart Poettering: >>> > It's a bit more complex. While UML, qemu, kvm, currently don't, LXC, >>> > systemd-nspawn and libvirt-lxc all do talk directly to machined. (Note >>> > that LXC and libvirt-lxc are separate codebases, the latter is *not* a >>> > wrapper around the former). >>> > >>> > So, dunno, it really is up to how you intend UML to be used. If UML >>> > shall be nice and useful without libvirt, then it's worth doing the >>> > registration natively, but it's also OK to just leave this to libvirt, >>> > if that's your primary envisioned usecase... >>> >>> What is the benefit of this registration? >>> I boot all day long UML and qemu-kvm VMs without registering them to >>> systemd, >>> so I don't really know what I'm missing. :-) >>> But if there is a nice use case I'll happily add the registration to UML. >> >> Hmm, I figure this mail didn't make it through to you? >> >> http://lists.freedesktop.org/archives/systemd-devel/2014-October/023875.html > > I don't see that mail in my mailbox either and I know that you noticed > some mail not arriving before. It seems to cause quite a lot of > confusion in discussion and patch submission. I'm not sure who to report > this to. Bah, never mind, I can see the mail now... -- Jan Synacek Software Engineer, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel