Re: [systemd-devel] systemd fails to build with static kmod library
El 04/06/13 04:39, Lennart Poettering escribió: On Mon, 03.06.13 00:52, Stephan Raue (mailingli...@openelec.tv) wrote: Am 02.06.2013 19:36, schrieb Greg KH: On Sun, Jun 02, 2013 at 07:28:57PM +0200, Stephan Raue wrote: i dont agree, i some cases it makes sense. since udev is included in systemd and udev has now its own buildins for the modprobe stuff it should be possible to use kmod statically linked, esp. if no other installed program uses kmod (and for our usage the kmod userspace binarys are not neccessary) If you are so worried about other programs / users calling kmod, then just build your needed kernel modules into the kernel and don't use any kernel modules at all. i am not much worried about this, but more about the comment "Do not use static linking, with systemd, ever, in fact do not use with any other component.". Statically linking works for so many programs and even kmod supports the "--enable-static" configure option. So basically i tried to report this broken behavior, because i never seen a statement like "dont link anything statically against systemd" Static linking is broken for many reasons. One reason is the namespace issue you ran into. If you want to make static linking work for you, then I recommend working on binutils to fix the namespacing issues (i.e. introduce private visibility to static libraries, good luck). To make this very clear: we will continue to use *private* symbols in systemd that are not namespaced. We will not rename these symbols just because some other library has similarly named *private* symbols. Staticially linking means creating a universal namespace for symbols, and that's just impossible and broken... Attached is a patch to disallow --enable-static when building systemd. >From ff9c55d74e64a00bf2895f63b139e63d981783c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= Date: Tue, 4 Jun 2013 14:42:56 -0400 Subject: [PATCH] Do not allow --enable static --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index d266601..bd46b33 100644 --- a/configure.ac +++ b/configure.ac @@ -44,6 +44,8 @@ AS_IF([test "x$host_cpu" = "xmips" || test "x$host_cpu" = "xmipsel" || LT_PREREQ(2.2) LT_INIT([disable-static]) +AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static is not supported by systemd])]) + # i18n stuff for the PolicyKit policy files IT_PROG_INTLTOOL([0.40.0]) -- 1.8.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] journalctl: Add support for showing messages from a previous boot
On Tue, 04.06.13 19:43, Jan Janssen (medhe...@web.de) wrote: > >Hmm, looking for startup messages plus an extra check for the boot ID of > >the oldest entry in all journals should give you a full list. > > Any journal file could contain messages from more than one boot. And > if you have a (user) journal file with two or more boot IDs from boots > that are not in the list obtained by message ID, you'd miss some boot > IDs. Or I just don't grok your approach. Yeah, we'd miss journal entries which have boot ID that we have no startup message for, and that is not the the boot id of the oldest entry we know. But I am not really convinced that this would really be a problem. But if we consider this a problem, I am still not convinced that we should do an O(n) algorithm whith n being the numer of all entries in the db... There must be a better way. The unique boot ids are actually strictly in-order in the individual journal files. The order is only lost when we interleave multiple journal files. I wonder if we can salvage this somehow, though. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Identical mount resulting in different options
On Tue, 21.05.13 23:03, Florian Lindner (mailingli...@xgm.de) wrote: > Hello! > > I am on an Arch Linux machine. Kernel is 3.9.3 x86_64, systemd 204. > > I have two identical hard drives. Both have a gparted created GPT table and a > CLI created ext4 filesystem with no options other than -L (label). > Archiv_1 was created like two weeks before Archiv_2 (which was created right > now). I don't know about the exact kernel version or Archiv_1. > > Both are set in fstab with identical fstab options: > > LABEL=Archiv_1 /mnt/Archiv_1 ext4defaults > LABEL=Archiv_2 /mnt/Archiv_2 ext4defaults > > yet they are actually mounted using a different option: > > /dev/sde1 on /mnt/Archiv_1 type ext4 (rw,relatime) > /dev/sdd1 on /mnt/Archiv_2 type ext4 (rw,relatime,data=ordered) > > Default mount options from tune2fs are identical: > > root@horus /mnt/Archiv_2 # tune2fs -l /dev/sde1 | grep "mount options" > Default mount options:user_xattr acl > root@horus /mnt/Archiv_2 # tune2fs -l /dev/sdd1 | grep "mount options" > Default mount options:user_xattr acl > > so is the mount file in run/systemd/generator/ > > But somehow systemd uses different options: > > root@horus ~ # systemctl show mnt-Archiv_1.mount > A1 > root@horus ~ # systemctl show mnt-Archiv_2.mount > A2 > root@horus ~ # diff -y A1 A2 > [...] > Where=/mnt/Archiv_1 | > Where=/mnt/Archiv_2 > > What=/dev/sde1| What=/dev/sdd1 > > Options=rw,relatime,rw| > Options=rw,relatime,rw,data=ordered > [...] > > How do the entries in /proc/self/mountinfo look like? Do they have the same mount options there? Note that data=ordered is the default anyway, so the two option strings are effectively identical. My guess is that the string is not passed in from userspace but added by the kernel, and the kernel is broked and sometimes omits adding this, and sometimes doesn't. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] journalctl: Add support for showing messages from a previous boot
Sorry, I failed to hit Reply-All. On 06/04/2013 07:10 PM, Lennart Poettering wrote: On Tue, 04.06.13 18:47, Jan Janssen (medhe...@web.de) wrote: On 06/04/2013 04:42 PM, Lennart Poettering wrote: On Thu, 30.05.13 17:24, Jan Janssen (medhe...@web.de) wrote: I like this idea! The format to specify the boot ID is inspired by git's ^n syntax and it even allows to look into the future. Unfortunately, to get a chronological list of boot IDs, we need search through the journal. sd_journal_enumerate_unique() doesn't help us here, because order of returned values is undefined. To make things less painful, an initial search for the reference boot ID is performed, which will either quickly fail so we don't have to needlessly walk the full journal or give us a cursor from which to start the slow lookup process. Hmm, I think this should be implemented differently: we should define a new message with a fixed message ID which is ussed once during boot, which we then can search for. We already have SD_MESSAGE_STARTUP_FINISHED which kinda does that, but is generated only after startup finished. For this feature we should have a message that is generated as early as possible in the boot process as possible (i.e. right after the journal is up), and from PID1, and only once during boot. We'd then simply search for this message ID in the database, and this would return a nicely ordered list of boots. We then pick the one we want and use it in an entirely new query. This would work, but only if this message won't rotate away. Otherwise results would be unexpected to users. Although, now that I think about it, I guess I could look into ensuring that... Hmm, looking for startup messages plus an extra check for the boot ID of the oldest entry in all journals should give you a full list. Any journal file could contain messages from more than one boot. And if you have a (user) journal file with two or more boot IDs from boots that are not in the list obtained by message ID, you'd miss some boot IDs. Or I just don't grok your approach. I am not sure I really like the "^" syntax. This after all is different >from git, as the "^" would works strictly by time, there is no real "ancestral" information. (or in other words: the result of ^ differs when you use different filters...). Actually, the final boot ID result doesn't change even if you provide other filters. The lookup is done before all user defined filters are added. Yeah, but that's not what I meant. I meant that on the conceptional level in git the "^" actually indicates an ancestral relation, but this --boot= stuff would give you different results if you would apply a filter, or there are missing journal files and so on. it would simply return the newest boot id that is before the specified id _which_is_in_the_current_dataset_. If you follow what I mean... Now I see what you mean. I'll try some other/better phrasing for docs. Maybe we can use a different syntax? Something like "--boot=-5" or "--boot=bd1b92058dd24e1eab573808e114f18b-5" or so? If there is consent on one. Hyphen is rather sub-optimal. It clashes with boot IDs given in UUIDs form (6bf79b04-3e50-4336-94ff-4ccf1083a005). It's supported, though not explicitly stated. Indeed, "-" sucks. Hmm, not sure what we could use instead. I'd like a syntax that is sufficiently different from git's so that people don't make the wrong assumption, but something that is still easy to type... Maybe use bd1b92058dd24e1eab573808e114f18b:-5 and bd1b92058dd24e1eab573808e114f18b:+5 or so? degree should probably be an "unsigned" rather than an "int". We try to use types that indicate the sensible range of the variable, and a negative value here doesn't appear to make sense, so please use "unsigned". A negative value does make sense. It allows to see into the future. To try it, just look for a past boot ID and look up the following boot by appending "^-1". Trying it on the current boot will fail for obvious reasons. Oh, true. Sorry for my confusion... Lennart Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Automatic Reboot Protocol
On Thu, 30.05.13 00:05, systemdki...@yopmail.com (systemdki...@yopmail.com) wrote: > > Andrey Borzenkov, > > > May be if you explain what you are trying to achieve > > A nightly "cron job" with post-execution reboot upon successful completion. > We may use cron if systemd can't do it. I expect it can, but know not how. > Obvious things and list advice didn't work. Thanks. > > Files under test: > http://lists.freedesktop.org/archives/systemd-devel/2013-May/07.html What exactly fails? Do you get any error? Can you paste some relevant log output, please? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't Inhibit shutdown with logind
On Tue, 28.05.13 01:28, Brendan J (bhenryj0...@googlemail.com) wrote: > Hi all, > > I'm trying to use the Inhibit() API exposed by logind on dbus > (org.freedesktop.login1.Manager) to prevent shutdown. > The call seems superficially to have worked, as the result from > ListInhibitors() includes the block I created. However my machine is not > prevented from shutting down. > > I'm pretty stumped on how to proceed with debugging this, beyond checking > what signals get sent (my program receives PrepareForShutdown(true)). > Could anyone suggest anything? Note that inhibitors aren't something that protects you from yourself. System inhibitors a user took will inhibit shutdown for everybody else, but not for him, and not for root. The idea is that a user should always be able to override his apps if he really wants to. It is the job of your DE to present active locks on screen when the user selects shutdown, and if he really wants to ignore them to forward this to the system. Or in other words: if you ran your test code as the same user as the one initiating the shutdown it's not surprising nothong was inhibited. Also note that suspending via lid-close by default ignores inhibitors since there is no way to show such an override message since we cannot stop the user from closing the lid. (But you can change this via LidSwitchIgnoreInhibited=). Does this explain the issue? Otherwise, you need to give me more details what you exactly tried as which users... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Automatic Reboot Protocol
On Sat, 25.05.13 23:19, systemdki...@yopmail.com (systemdki...@yopmail.com) wrote: > How to reboot from a systemd timer? We have > > systemd timer calls > systemd unit calls > bash script calls > systemctl reboot > > The script runs fine each day, except for its last step, "systemctl > reboot." What's the right protocol? Is it wrong to call systemctl from a > script? This should definitely work. If it doesn't this would be a bug, and please file a bug in that case with a minimal test case... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Delay dbus connection for user session
On Wed, 29.05.13 08:59, Yang Chengwei (chengwei.y...@intel.com) wrote:
> > > diff --git a/src/core/manager.c b/src/core/manager.c
> > > index 0508628..467b5ba 100644
> > > --- a/src/core/manager.c
> > > +++ b/src/core/manager.c
> > > @@ -503,7 +503,7 @@ int manager_new(SystemdRunningAs running_as, Manager
> > > **_m) {
> > > goto fail;
> > >
> > > /* Try to connect to the busses, if possible. */
> > > -r = bus_init(m, running_as != SYSTEMD_SYSTEM);
> > > +r = bus_init(m, running_as != SYSTEMD_SYSTEM && running_as !=
> > > SYSTEMD_USER);
> > > if (r < 0)
> > > goto fail;
> >
> > So, I've looked at this code again as I've spotted this problem over a
> > year ago, and I'm wondering if this entire section should just be
> > removed, since running_as only has 2 values (_SYSTEM and _USER)
> > anyway...
> >
> > Would there be any objection to just dropping these 4 lines entirely?
> > Lennart, Kay? I don't see how we'd have a 3rd manager type here.
>
> Yes, just in that case. If all of you agreed, I'd like submit a V2 to
> drop these lines.
Hmm, this would break my usual testing routine, where i run user systemd
against a bus daemon that is already running... I have no doubt that
dropping the check entirely is the right way to go eventually, but maybe
we can find a better way so that this continues to work for me until
GNOME has switched over to systemd as service manager.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add command set-log-level
On Wed, 29.05.13 16:08, Vaclav Pavlin (vpav...@redhat.com) wrote:
> From: Václav Pavlín
>
> Command changes current log level
> ---
> man/systemctl.xml | 8
> src/systemctl/systemctl.c | 48
> +++
> 2 files changed, 56 insertions(+)
>
> diff --git a/man/systemctl.xml b/man/systemctl.xml
> index 9c3a5b0..af72972 100644
> --- a/man/systemctl.xml
> +++ b/man/systemctl.xml
> @@ -1016,6 +1016,14 @@ kobject-uevent 1 systemd-udevd-kernel.socket
> systemd-udevd.service
>
>
>
> +set-log-level
> LEVEL
> +
> +
> + Change current log level to LEVEL.
> +
> +
> +
> +
> load
> NAME...
>
>
> diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> index 0955f2c..e6e2f2b 100644
> --- a/src/systemctl/systemctl.c
> +++ b/src/systemctl/systemctl.c
> @@ -4462,6 +4462,53 @@ finish:
> return r;
> }
>
> +static int set_log_level(DBusConnection *bus, char **args) {
> +_cleanup_dbus_error_free_ DBusError error;
> +_cleanup_dbus_message_unref_ DBusMessage *m = NULL, *reply = NULL;
> +DBusMessageIter iter, sub;
> +const char* property = "LogLevel";
> +const char* interface = "org.freedesktop.systemd1.Manager";
> +const char* value;
> +
> +assert(bus);
> +assert(args);
> +
> +value = args[1];
> +dbus_error_init(&error);
> +
> +if (!(m = dbus_message_new_method_call(
> +"org.freedesktop.systemd1",
> +"/org/freedesktop/systemd1",
> +"org.freedesktop.DBus.Properties",
> +"Set")))
> +return log_oom();
For new code we prefer this:
m = foo();
if (!m) { ...
rather than this:
if (!(m = foo())) { ...
> static int unit_is_enabled(DBusConnection *bus, char **args) {
> _cleanup_dbus_error_free_ DBusError error;
> int r;
> @@ -5705,6 +5752,7 @@ static int systemctl_main(DBusConnection *bus, int
> argc, char *argv[], DBusError
> { "list-dependencies", LESS, 2, list_dependencies },
> { "set-default", EQUAL, 2, enable_unit },
> { "get-default", LESS, 1, get_default },
> +{ "set-log-level", EQUAL, 2, set_log_level },
> };
Shouldn't this be listed in --help, too?
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add command set-log-level
On Tue, Jun 04, 2013 at 04:44:51PM +0200, Lennart Poettering wrote:
> On Wed, 29.05.13 16:08, Vaclav Pavlin (vpav...@redhat.com) wrote:
>
> > From: Václav Pavlín
> >
> > Command changes current log level
> > ---
> > man/systemctl.xml | 8
> > src/systemctl/systemctl.c | 48
> > +++
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/man/systemctl.xml b/man/systemctl.xml
> > index 9c3a5b0..af72972 100644
> > --- a/man/systemctl.xml
> > +++ b/man/systemctl.xml
> > @@ -1016,6 +1016,14 @@ kobject-uevent 1 systemd-udevd-kernel.socket
> > systemd-udevd.service
> >
> >
> >
> > +set-log-level
> > LEVEL
> > +
> > +
> > + Change current log level to LEVEL.
> > +
> > +
> > +
> > +
> > load
> > NAME...
> >
> >
> > diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> > index 0955f2c..e6e2f2b 100644
> > --- a/src/systemctl/systemctl.c
> > +++ b/src/systemctl/systemctl.c
> > @@ -4462,6 +4462,53 @@ finish:
> > return r;
> > }
> >
> > +static int set_log_level(DBusConnection *bus, char **args) {
> > +_cleanup_dbus_error_free_ DBusError error;
> > +_cleanup_dbus_message_unref_ DBusMessage *m = NULL, *reply = NULL;
> > +DBusMessageIter iter, sub;
> > +const char* property = "LogLevel";
> > +const char* interface = "org.freedesktop.systemd1.Manager";
> > +const char* value;
> > +
> > +assert(bus);
> > +assert(args);
> > +
> > +value = args[1];
> > +dbus_error_init(&error);
> > +
> > +if (!(m = dbus_message_new_method_call(
> > +"org.freedesktop.systemd1",
> > +"/org/freedesktop/systemd1",
> > +"org.freedesktop.DBus.Properties",
> > +"Set")))
> > +return log_oom();
>
>
> For new code we prefer this:
>
> m = foo();
> if (!m) { ...
I fixed that up before committing.
>
> rather than this:
>
> if (!(m = foo())) { ...
>
> > static int unit_is_enabled(DBusConnection *bus, char **args) {
> > _cleanup_dbus_error_free_ DBusError error;
> > int r;
> > @@ -5705,6 +5752,7 @@ static int systemctl_main(DBusConnection *bus, int
> > argc, char *argv[], DBusError
> > { "list-dependencies", LESS, 2, list_dependencies },
> > { "set-default", EQUAL, 2, enable_unit },
> > { "get-default", LESS, 1, get_default },
> > +{ "set-log-level", EQUAL, 2, set_log_level },
> > };
>
> Shouldn't this be listed in --help, too?
This too, iirc.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add command set-log-level
On Tue, Jun 04, 2013 at 04:47:47PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > > Shouldn't this be listed in --help, too? > > This too, iirc. Actually I missed this (along with list-sockets :)). Fixed now. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] journalctl: Add support for showing messages from a previous boot
On Thu, 30.05.13 17:24, Jan Janssen (medhe...@web.de) wrote:
I like this idea!
> The format to specify the boot ID is inspired by git's ^n syntax
> and it even allows to look into the future.
>
> Unfortunately, to get a chronological list of boot IDs, we
> need search through the journal. sd_journal_enumerate_unique()
> doesn't help us here, because order of returned values is undefined.
>
> To make things less painful, an initial search for the reference
> boot ID is performed, which will either quickly fail so we don't have
> to needlessly walk the full journal or give us a cursor from which
> to start the slow lookup process.
Hmm, I think this should be implemented differently: we should define a
new message with a fixed message ID which is ussed once during boot,
which we then can search for. We already have
SD_MESSAGE_STARTUP_FINISHED which kinda does that, but is generated only
after startup finished. For this feature we should have a message that
is generated as early as possible in the boot process as possible
(i.e. right after the journal is up), and from PID1, and only once
during boot. We'd then simply search for this message ID in the
database, and this would return a nicely ordered list of boots. We then
pick the one we want and use it in an entirely new query.
> +-b
> ID
> +
> --boot=ID
> +
> --this-boot=ID
If --this-boot= becomes the old obsolete name here it shouldn't show up
in the man page.
>
> -Show data only from
> -current boot. This will add a match
> -for _BOOT_ID= for
> -the current boot ID of the
> -kernel.
> +Show messages from specified
> +boot ID. This will
> +add a match for
> _BOOT_ID=.
> +
> +The argument is a 128 bit ID
> +optionally followed by the ancestry
> identifier
> +^n, which identifies the
> +chronologically nth previous boot ID.
> Supplying
> +a negative value will look for the
> chronologically
> +next boot ID. n may be
> ommitted,
> +in which case 1 is assumed. A value of 0 is
> +equivalent to the current boot ID. If the
> ancestry
> +indentifier is supplied, the boot ID itself
> may be
> +ommited and the current boot is
> -assumed.
I am not sure I really like the "^" syntax. This after all is different
from git, as the "^" would works strictly by time, there is no real
"ancestral" information. (or in other words: the result of ^ differs
when you use different filters...).
Maybe we can use a different syntax? Something like "--boot=-5" or
"--boot=bd1b92058dd24e1eab573808e114f18b-5" or so?
> - " -b --this-boot Show data only from current boot\n"
> - " -k --dmesg Show kmsg log from current boot\n"
> + " -b --boot[=ID] Show data only from ID or current
> boot if unspecified\n"
> + " --this-boot Alias for --boot
> - (deprecated)\n"
Here too our rule is to not document the deprecated option, but simply
support it silently in our code...
> -arg_this_boot = true;
> +if (optarg)
> +arg_boot_id_descriptor = optarg;
> +else if (optind < argc && argv[optind][0] != '-') {
> +arg_boot_id_descriptor = argv[optind];
> +optind++;
> +}
> +arg_boot_id = true;
This needs to follow our coding sytle (i.e. 8char indenting).
> +static int get_ancestor_boot_id(sd_journal *j, sd_id128_t *boot_id,
> int degree)
degree should probably be an "unsigned" rather than an "int". We try to
use types that indicate the sensible range of the variable, and a
negative value here doesn't appear to make sense, so please use "unsigned".
> +{
> +int r;
> +sd_id128_t last_id;
> +bool boot_id_found = false;
> +char match[9+32+1] = "_BOOT_ID=";
> +_cleanup_free_ char *cursor = NULL;
Indenting/coding style...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: cleanup agetty command line
On Tue, Jun 04, 2013 at 01:28:11PM +0200, Michal Schmidt wrote: > On 06/04/2013 10:57 AM, Karel Zak wrote: > >On Mon, Jun 03, 2013 at 06:00:45PM +0100, Colin Guthrie wrote: > >> From comment 1: > >>"Furthermore, I believe there's a bug in agetty. It attempts to detect > >>the distinction between the vc and a serial line and set TERM > >>accordingly, but it does not work as expected. I will send Karel a fix." > > > > ... hmm, I don't remember any discussion. > > The comment referred to the bug fixed by this util-linux commit: > > commit c13d60b291cfe3e2c094225195d967c9f195ca54 > Author: Michal Schmidt > Date: Mon Oct 29 23:33:01 2012 +0100 > > agetty: fix autodetection for TERM Ah, you're right. Thanks. Karel -- Karel Zak http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: cleanup agetty command line
On Mon, 03.06.13 14:28, Karel Zak (k...@redhat.com) wrote: > * baud rate is optional and unnecessary for virtual terminals > * term type is optional (default is 'linux' for virtual terminals >and 'vt102' for serial lines) > * long options are more user-friendly > > ... all this is supported since util-linux v2.20 (Aug 2011). Applied! Thanks. > Signed-off-by: Karel Zak We don't use S-o-b in systemd. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] implementation status of http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ ?
On Mon, 03.06.13 19:10, Colin Walters (walt...@verbum.org) wrote: > What's the implementation status of > http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ ? > > For example, do any patches exist for grub or syslinux to read > from /boot/loader (either at runtime or to generate a bootloader-native > config file statically?) > > I'm aware gummiboot does (and its wiki page should probably crosslink > with the above). But any others? The Grub patch I did (that Kay linked exists), but this isn't polished and fully integrated into Fedora yet. Syslinux does not support this scheme AFAIK. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: cleanup agetty command line
On 06/04/2013 10:57 AM, Karel Zak wrote: On Mon, Jun 03, 2013 at 06:00:45PM +0100, Colin Guthrie wrote: From comment 1: "Furthermore, I believe there's a bug in agetty. It attempts to detect the distinction between the vc and a serial line and set TERM accordingly, but it does not work as expected. I will send Karel a fix." ... hmm, I don't remember any discussion. The comment referred to the bug fixed by this util-linux commit: commit c13d60b291cfe3e2c094225195d967c9f195ca54 Author: Michal Schmidt Date: Mon Oct 29 23:33:01 2012 +0100 agetty: fix autodetection for TERM ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd fails to build with static kmod library
2013/6/4 Lennart Poettering :
> On Mon, 03.06.13 00:52, Stephan Raue (mailingli...@openelec.tv) wrote:
>
>>
>> Am 02.06.2013 19:36, schrieb Greg KH:
>> >On Sun, Jun 02, 2013 at 07:28:57PM +0200, Stephan Raue wrote:
>> >
>> >>i dont agree, i some cases it makes sense. since udev is included in
>> >>systemd and udev has now its own buildins for the modprobe stuff it
>> >>should be possible to use kmod statically linked, esp. if no other
>> >>installed program uses kmod (and for our usage the kmod userspace
>> >>binarys are not neccessary)
>> >
>> >If you are so worried about other programs / users calling kmod, then
>> >just build your needed kernel modules into the kernel and don't use any
>> >kernel modules at all.
>> >
>> i am not much worried about this, but more about the comment "Do not
>> use static linking, with systemd, ever, in fact do not use with any
>> other component.". Statically linking works for so many programs and
>> even kmod supports the "--enable-static" configure option. So
>> basically i tried to report this broken behavior, because i never
>> seen a statement like "dont link anything statically against
>> systemd"
>
> Static linking is broken for many reasons. One reason is the namespace
> issue you ran into.
I think that there is some misunderstanding of the complaint here,
caused by libtool. Basically, I think that the complaint is: you
provide the --enable-static option, so it should work, even though it
is not the default. Here is what really happens:
1. systemd's (and kmod's) configure.ac uses the LT_INIT macro that
comes from libtool. It is useful for building shared libraries.
2. That macro, among other things, teaches the configure script to
understand the --{en,dis}able-{static,shared} options.
3. Due to reasons already mentioned in this thread, static linking
should not be used for systemd and kmod.
4. The LT_INIT macro has a way to disable the build of static
libraries by default (but the user who runs the configure script can
override this default), and systemd does that.
5. This macro does not have a way to forcibly disable the build of
static libraries.
(5) is a bug in libtool. There is nothing systemd can do about it.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: cleanup agetty command line
On Mon, Jun 03, 2013 at 06:00:45PM +0100, Colin Guthrie wrote: > 'Twas brillig, and Karel Zak at 03/06/13 13:28 did gyre and gimble: > > * term type is optional (default is 'linux' for virtual terminals > >and 'vt102' for serial lines) > > It may no longer matter (especially if the fix mentioned by Michael in > comment 1 of the bug quoted below is now merged) but FYI the "linux" > term type was specified explicitly due to agetty not respecting TERM env > var: agetty has been never designed in this way > commit 2161de72c517d34d1ceb9b4c1a300f0b54ce5a9c > Author: Michal Schmidt > Date: Mon Oct 29 21:59:34 2012 +0100 > > units: agetty overrides TERM > > Environment=TERM=... has no effect on agetty who sets it by itself. To > really set TERM to a specified value, it has to be given on the command > line. > > https://bugzilla.redhat.com/show_bug.cgi?id=870622 > > > From comment 1: > "Furthermore, I believe there's a bug in agetty. It attempts to detect > the distinction between the vc and a serial line and set TERM > accordingly, but it does not work as expected. I will send Karel a fix." ... hmm, I don't remember any discussion. Add term name to the command line is very poor workaround, distinction between the vc and a serial line is critical thing for agetty as it modifies many settings on the line. Karel -- Karel Zak http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd fails to build with static kmod library
On Mon, 03.06.13 00:52, Stephan Raue (mailingli...@openelec.tv) wrote: > > Am 02.06.2013 19:36, schrieb Greg KH: > >On Sun, Jun 02, 2013 at 07:28:57PM +0200, Stephan Raue wrote: > > > >>i dont agree, i some cases it makes sense. since udev is included in > >>systemd and udev has now its own buildins for the modprobe stuff it > >>should be possible to use kmod statically linked, esp. if no other > >>installed program uses kmod (and for our usage the kmod userspace > >>binarys are not neccessary) > > > >If you are so worried about other programs / users calling kmod, then > >just build your needed kernel modules into the kernel and don't use any > >kernel modules at all. > > > i am not much worried about this, but more about the comment "Do not > use static linking, with systemd, ever, in fact do not use with any > other component.". Statically linking works for so many programs and > even kmod supports the "--enable-static" configure option. So > basically i tried to report this broken behavior, because i never > seen a statement like "dont link anything statically against > systemd" Static linking is broken for many reasons. One reason is the namespace issue you ran into. If you want to make static linking work for you, then I recommend working on binutils to fix the namespacing issues (i.e. introduce private visibility to static libraries, good luck). To make this very clear: we will continue to use *private* symbols in systemd that are not namespaced. We will not rename these symbols just because some other library has similarly named *private* symbols. Staticially linking means creating a universal namespace for symbols, and that's just impossible and broken... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] implementation status of http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ ?
On Tue, Jun 4, 2013 at 1:10 AM, Colin Walters wrote: > What's the implementation status of > http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ ? > > For example, do any patches exist for grub or syslinux to read > from /boot/loader (either at runtime or to generate a bootloader-native > config file statically?) > > I'm aware gummiboot does (and its wiki page should probably crosslink > with the above). But any others? It has broken path configurations in it, but a patch exists: http://pkgs.fedoraproject.org/cgit/grub2.git/tree/0362-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
