Re: [systemd-devel] [PATCH 0/5] Coverity fixes
On Wed, Sep 10, 2014 at 11:20 AM, wrote: > From: Philippe De Swert > > Hi, > > Yesterday I finally got to revive the systemd Coverity project on > scan.coverity.org Unfortunately to see the errors reported you need > to sign up, but I will make sure to approve requests for seeing the > "bugs" whenever they show up. Hi Philippe, I was wondering if it is possible to enable selinux for the scans? We have a lot of reports of "Logically dead code". They are mostly due to selinux_unit_access_check() being defined as #define selinux_unit_access_check(unit, message, permission, error) 0 when HAVE_SELINUX is not set. See e.g. CID#1237573 I can of course just mark them as false positive but it would be better to have those code paths covered as well. > Also I quickly made some quick fixes (although since it was late at night > yesterday there might be a few that were too quick ;) ) > There is a lot of work to do reviewing the error reports (as some are > probably false positives) and fixing them. About 500 errors and an error > defect density of 2.5 atm. > > Cheers, > > Philippe > > Philippe De Swert (5): > [use after free] Avoid using m->kdbus after freeing it. > [use after free] pattern is already freed, so do not dereference it in > the error print > [uninitialized] No need to check if num is < 0 > [memleak] Do not leak mmapped area when other memory allocations fail. > [memleak] Actually unref the buscreds on failure. > > src/journal/coredumpctl.c | 4 ++-- > src/journal/mmap-cache.c| 10 +++--- > src/libsystemd-terminal/idev-keyboard.c | 3 --- > src/libsystemd/sd-bus/bus-message.c | 6 +++--- > src/libsystemd/sd-bus/sd-bus.c | 4 +++- > 5 files changed, 15 insertions(+), 12 deletions(-) > > -- > 1.8.3.2 > > ___ > 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] [RFC] [WIP] [kdbus] Attempt to recursively pass fd
Hi Alban, Sorry for the long delay on this. On 08/14/2014 01:21 PM, Alban Crequy wrote: > Before Linux commit 25888e (from 2.6.37-rc4, Nov 2010), fd-passing on Unix > sockets could recursively be stacked, allowing a process to exhaust the open > files limit (/proc/sys/fs/file-max) on the system without restriction from > ulimit -n. > > This DoS on Unix sockets was fixed by commit: > >> commit 25888e30319f8896fc656fc68643e6a078263060 >> Author: Eric Dumazet >> Date: Thu Nov 25 04:11:39 2010 + >> >> af_unix: limit recursion level > > But that commit introduced a bug in dbus: > https://bugs.freedesktop.org/show_bug.cgi?id=80163 > > kdbus does not use fd-passing on Unix sockets so it is not affected by this. > > However, it allows fd-passing similarly. This patch shows it is possible to > recursively pass file descriptors in kdbus and stack them without keeping them > attached to the initial process. I could stack passed fds 256 times, probably > because of the limit KDBUS_USER_MAX_CONN: I finally found some time to look into this, and added a patch that disallows passing kdbus handles over kdbus handles. Such an attempt now returns -ELOOP. We might eventually allow this once we have a generic GC implementation for file descriptors (currently, there's only one, and that one only works for unix domain sockets). For now, we'll also need something that disallows passing kdbus handles over UDS. I also added a test to the suite to check for this behaviour. I borrowed some code from you test case for this. Care to check wheter that seems alright to you? Many thanks for the heads-up! Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Should user mode linux register with machined?
Hi, I wrote a small patch for user-mode linux to register with machined by calling "CreateMachine". Is this a good idea to do so? I think machined gives you a nice overview over all running UML instances, also you get the scope unit and the control groups with above registration to machined. anything else on the plus side? The user-mode-mailing list did ask why exactly my patch is needed. So what do you think? with kind regards thomas PS: I wonder what happens when I write a service unit file that starts an user mode linux instance and that instance will register with machined? won't both control groups overlap, i.e. the scope unit and the service unit? or is this not a problem? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] terminal: sd_bus_error_get_errno returns positive errno
From: Thomas Hindoe Paaboel Andersen
The 3 calls to sd_bus_error_get_errno appear to expect a negative
return value.
This patch negates the returned value so it matches the other error
cases in the 3 functions where sd_bus_error_get_errno is used.
---
src/libsystemd-terminal/sysview.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/libsystemd-terminal/sysview.c
b/src/libsystemd-terminal/sysview.c
index 2083f5a..fde87d1 100644
--- a/src/libsystemd-terminal/sysview.c
+++ b/src/libsystemd-terminal/sysview.c
@@ -263,7 +263,7 @@ static int session_take_control_fn(sd_bus *bus,
log_debug("sysview: %s: TakeControl failed: %s: %s",
session->name, e->name, e->message);
-error = sd_bus_error_get_errno(e);
+error = -sd_bus_error_get_errno(e);
} else {
session->has_control = true;
error = 0;
@@ -1195,7 +1195,7 @@ static int context_ld_list_seats_fn(sd_bus *bus,
log_debug("sysview: ListSeats on logind failed: %s: %s",
error->name, error->message);
-return sd_bus_error_get_errno(error);
+return -sd_bus_error_get_errno(error);
}
r = sd_bus_message_enter_container(reply, 'a', "(so)");
@@ -1247,7 +1247,7 @@ static int context_ld_list_sessions_fn(sd_bus *bus,
log_debug("sysview: ListSessions on logind failed: %s: %s",
error->name, error->message);
-return sd_bus_error_get_errno(error);
+return -sd_bus_error_get_errno(error);
}
r = sd_bus_message_enter_container(reply, 'a', "(susso)");
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] sd-bus: sd_bus_message_get_errno should only return positive errno
From: Thomas Hindoe Paaboel Andersen
sd_bus_message_get_errno can currently return either a number of
different poitive errno values (from bus-error-mapping), or a negative
EINVAL if passed null as parameter.
The check for null parameter was introduced in
40ca29a1370379d43e44c0ed425eecc7218dcbca
at the same as the function was renamed from bus_message_to_errno and
made public API. Before becoming public the function used to return
only negative values.
It is weird to have a function return both positive and negative errno
and it generally looks like a mistake. The function is guarded by the
--enable-kdbus flags so I wonder if we still have time to fix it up?
It does not have any documentation yet. However, except for a few details
it is just a convenient way to call sd_bus_error_get_errno which is documented
to return only positive errno.
This patch makes it return only positive errno and fixes up the two
calls to the function that tried to cope with both positive and negative
values.
---
src/libsystemd/sd-bus/bus-message.c | 2 +-
src/libsystemd/sd-bus/sd-bus.c | 2 --
src/network/networkd-link.c | 2 --
3 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-message.c
b/src/libsystemd/sd-bus/bus-message.c
index bfb14fc..1fa3ad2 100644
--- a/src/libsystemd/sd-bus/bus-message.c
+++ b/src/libsystemd/sd-bus/bus-message.c
@@ -5337,7 +5337,7 @@ int bus_header_message_size(struct bus_header *h, size_t
*sum) {
}
_public_ int sd_bus_message_get_errno(sd_bus_message *m) {
-assert_return(m, -EINVAL);
+assert_return(m, EINVAL);
if (m->header->type != SD_BUS_MESSAGE_METHOD_ERROR)
return 0;
diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
index 33b65ab..28b993b 100644
--- a/src/libsystemd/sd-bus/sd-bus.c
+++ b/src/libsystemd/sd-bus/sd-bus.c
@@ -349,8 +349,6 @@ static int hello_callback(sd_bus *bus, sd_bus_message
*reply, void *userdata, sd
assert(reply);
r = sd_bus_message_get_errno(reply);
-if (r < 0)
-return r;
if (r > 0)
return -r;
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 9bf1a81..427f695 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -725,8 +725,6 @@ static int set_hostname_handler(sd_bus *bus, sd_bus_message
*m, void *userdata,
return 1;
r = sd_bus_message_get_errno(m);
-if (r < 0)
-r = -r;
if (r > 0)
log_warning_link(link, "Could not set hostname: %s",
strerror(r));
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: use the escape for "-" in example instead of space.
This sentence can be misread to mean that "\x20" is the escape code for "-" which is the only character explicitly mentioned. This lead to at least one user loosing hair over why a mount unit for "/foo/bar-baz" didn't work. The example escape is arbitrary so lets prevent hair loss. --- man/systemd.unit.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 6ea552e..67d46ed 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -226,7 +226,7 @@ result is usable as part of a filename. Basically, given a path, "/" is replaced by "-", and all unprintable characters and the "-" are replaced by -C-style "\x20" escapes. The root directory "/" is +C-style "\x2d" escapes. The root directory "/" is encoded as single dash, while otherwise the initial and ending "/" is removed from all paths during transformation. This escaping is reversible. -- 1.8.5.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabling automatic activation of swap on GPT
I made an incorrect diagnosis. systemd-gpt-auto-generator is not auto-activating this GPT swap partition. It's actually the live media's init script in the initramfs. When I use 'noswap' boot parameter the swap isn't activated; I assume systemd doesn't look for 'noswap'. So the behavior I'm seeing is consistent with 'man systemd-gpt-auto-generator' which says: "It will only look for the other partitions on the same physical disk the root file system is located on." Which of course is not true when booting a live system from cd/dvd/usb/image. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
> From: Andrei Borzenkov > At least, it is impossible to achieve what the goal of OP was - > attempt to automount device exactly once on system boot and give up if > it was not successful. Which had been semantic of /etc/fstab for quite > some time. I don't have a need to "automount device exactly once", only that after a certain period of time, systemd would cease trying to mount the device. I'm guessing that a reasonable place to specify this would be in a special option in the /etc/fstab line. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabling automatic activation of swap on GPT
On 09/15/2014 04:30 PM, Chris Murphy wrote: The issue is when booting live media (e.g. for OS installs), the autoactivation is causing some installer confusion. Should be fixed downstream in Anaconda/Live script. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Disabling automatic activation of swap on GPT
Is there a way to inhibit the systemd automatic activation of swap on GPT disks that use the linux swap partition type GUID? The desire to do this has come up in these two bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1141700 clone of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1114786 The issue is when booting live media (e.g. for OS installs), the autoactivation is causing some installer confusion. I'm inclined to say that this swap partition is not user domain, the fact it's marked as linux swap makes it systemd/kernel domain. (Hopefully if there's a latent valid hibernate image on the partition, then swap is not activated so that the hibernate image isn't stepped on.) If the user instructed an OS installer they want to usurp control over this swap partition, then the installer should swapoff, and plan to wipefs this partition making the space once again user domain. But maybe there's a good reason here to not enable swap by default when booting live media? Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] shared/pty: remove unused pty_signal
Hi,
On 15 September 2014 16:59, David Herrmann wrote:
> Hi
>
> On Mon, Sep 15, 2014 at 3:29 PM, Emil Renner Berthing
> wrote:
>> ---
>> src/shared/pty.c | 8
>> src/shared/pty.h | 1 -
>> 2 files changed, 9 deletions(-)
>>
>> diff --git a/src/shared/pty.c b/src/shared/pty.c
>> index 2863da4..a3332dd 100644
>> --- a/src/shared/pty.c
>> +++ b/src/shared/pty.c
>> @@ -541,14 +541,6 @@ int pty_write(Pty *pty, const void *buf, size_t size) {
>> return 0;
>> }
>>
>> -int pty_signal(Pty *pty, int sig) {
>> -assert_return(pty, -EINVAL);
>> -assert_return(pty_is_open(pty), -ENODEV);
>> -assert_return(pty_is_parent(pty), -ENODEV);
>> -
>> -return ioctl(pty->fd, TIOCSIG, sig) < 0 ? -errno : 0;
>> -}
>> -
>
> The main user of shared/pty.c (systemd-consoled) is still being worked
> on. The pty implementation was just one of the early works, so I'd
> prefer if we keep unused functions for now.
Ah, I see. Sorry for the noise then ;)
/Emil
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] remove unneeded error.h includes
Hi On Mon, Sep 15, 2014 at 3:29 PM, Emil Renner Berthing wrote: > These are the only two places where this glibc-specific > header is included. However none of the definitions in it > seem to be used, so just remove the includes. Looks good. I think we used error() in the past, but that's long gone. Applied! Thanks David > --- > src/notify/notify.c | 1 - > src/path/path.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/src/notify/notify.c b/src/notify/notify.c > index 6f1c52e..33933e4 100644 > --- a/src/notify/notify.c > +++ b/src/notify/notify.c > @@ -21,7 +21,6 @@ > > #include > #include > -#include > #include > #include > #include > diff --git a/src/path/path.c b/src/path/path.c > index 347921a..37f2571 100644 > --- a/src/path/path.c > +++ b/src/path/path.c > @@ -21,7 +21,6 @@ > > #include > #include > -#include > #include > #include > #include > -- > 2.1.0 > > ___ > 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 1/2] shared/pty: remove unused pty_signal
Hi
On Mon, Sep 15, 2014 at 3:29 PM, Emil Renner Berthing wrote:
> ---
> src/shared/pty.c | 8
> src/shared/pty.h | 1 -
> 2 files changed, 9 deletions(-)
>
> diff --git a/src/shared/pty.c b/src/shared/pty.c
> index 2863da4..a3332dd 100644
> --- a/src/shared/pty.c
> +++ b/src/shared/pty.c
> @@ -541,14 +541,6 @@ int pty_write(Pty *pty, const void *buf, size_t size) {
> return 0;
> }
>
> -int pty_signal(Pty *pty, int sig) {
> -assert_return(pty, -EINVAL);
> -assert_return(pty_is_open(pty), -ENODEV);
> -assert_return(pty_is_parent(pty), -ENODEV);
> -
> -return ioctl(pty->fd, TIOCSIG, sig) < 0 ? -errno : 0;
> -}
> -
The main user of shared/pty.c (systemd-consoled) is still being worked
on. The pty implementation was just one of the early works, so I'd
prefer if we keep unused functions for now.
Thanks
David
> int pty_resize(Pty *pty, unsigned short term_width, unsigned short
> term_height) {
> struct winsize ws;
>
> diff --git a/src/shared/pty.h b/src/shared/pty.h
> index a87ceb5..251a99d 100644
> --- a/src/shared/pty.h
> +++ b/src/shared/pty.h
> @@ -71,7 +71,6 @@ int pty_attach_event(Pty *pty, sd_event *event, pty_event_t
> event_fn, void *even
> void pty_detach_event(Pty *pty);
>
> int pty_write(Pty *pty, const void *buf, size_t size);
> -int pty_signal(Pty *pty, int sig);
> int pty_resize(Pty *pty, unsigned short term_width, unsigned short
> term_height);
>
> pid_t pty_fork(Pty **out, sd_event *event, pty_event_t event_fn, void
> *event_fn_userdata, unsigned short initial_term_width, unsigned short
> initial_term_height);
> --
> 2.1.0
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add the CPU hotplug rule
Hi On Mon, Sep 15, 2014 at 4:22 PM, John Haxby wrote: > I really appreciate proper explanations, thank you. Quite simple: We want to avoid calling into udev and back into the kernel if we there's a way to skip this step. That is, the default should work without udev. Reasons: * We want init=/bin/bash or anything else to work. Or more precisely: I don't care for init=/bin/bash, but others do. Lets not make their life miserable, but make defaults work with init=/bin/bash if possible * You can use your new shiny kernel with CPU hotplugging together with an old udev user-space and the default will just work. Same is true for any other new bus type. But if we require udev rules for the _default_ to work, you need to install udev rules (or update udev respectively) just to make the default work. That already sounds backwards, doesn't it? Furthermore, this seems cumbersome and kinda makes it no longer the "default", right? * It is wasted time and wasted resources to call into user-space to trigger the default action. If something is the default, it should just happen and not require a bunch of messages between different services. Instead, the opposite should be true: If you don't want the default actions, tell the kernel about it and only then you should get hooked into the decision. Imagine all decisions made by the kernel go through udev. It would slow down systems considerably. So lets keep it down unless there's strong reason to send it through udev. * We want people to chose *sane* defaults. Everywhere. So if the kernel default is *sane*, why do we need an udev rule? Obviously, there're exceptions. Mostly backwards compatibility and interactions with totally backwards subsystems. But if there's a chance to reduce the amount of default udev rules, I bet you get praised for each and every properly removed rule. Does that make sense? Maybe Kay has additions/corrections, but I think this explanation should be fairly straightforward. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add the CPU hotplug rule
On 15/09/14 15:02, David Herrmann wrote:
> Hi
>
> On Mon, Sep 15, 2014 at 3:19 PM, John Haxby wrote:
>> On 12/09/14 16:03, Kay Sievers wrote:
>>> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby wrote:
When I think of changing the
behaviour of any removable hardware, udev is automatically where I look
first. So if I'm missing something here, I would really like some more
input.
>>>
>>> Udev does not decide which device show up, it just classifies stuff
>>> that processes events.
>>
>> That's what I don't understand.
>>
>> Let's say I plug in a USB printer. Looking through the udev rules on my
>> machine I see
>>
>> SUBSYSTEM=="printer", TAG+="systemd"
>>ENV{SYSTEMD_WANTS}+="printer.target"
>>
>> (line split for readability).A whileback I proposed
>>
>>ACTION==“add” KERNEL==“cpu[0-9]*” TAG+="systemd"
>>ENV{SYSTEMD_WANTS}+=“cpuadd.service”
>>
>> Aside from the obvious syntactic differences, what's the difference
>> between these?
>
> One is a target, the other is a service. There is a fundamental
> difference between both. A target does not cause an immediate action,
> a service does. The target just hooks up the udev event into systemd,
> it does not associate any default action. The cpuadd.service, on the
> other hand, does add a default action.
>
>> Does it make any difference if the default is not to bring online more
>> CPUs that the system booted with? Or some other clever default?
>>
>> Why does the kernel not bring CPUs online automatically? This must have
>> come up before, and what you have been saying seems to suggest that
>> there is something going on here that I am just missing.
>
> The idea is to add a kernel runtime option (like sysctl) which is
> named "cpu_auto_on" or something like that. Or make it a sysfs file in
> /sys/bus/cpu/ just like "drivers_autoprobe". This should be set to "1"
> by default, thus, all CPUs get activated without any udev interaction
> (if you want to avoid races during bootup, use the kernel
> command-line.. or a static kernel config option..).
> Everybody else is free to set this option to "0" and write their own
> udev rules. This way, udev does not have to bother with default
> actions.
>
> Is there anything wrong with this proposed solution? Or why do you
> insist on your solution?
Forgive me, I'm not insisting on anything. It was me that that said
"hang on, we need to push that fix upstream" a while ago precisely to
ensure that we got the right solution for the right reasons.
I really appreciate proper explanations, thank you.
>
> Thanks
> David
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add the CPU hotplug rule
Hi
On Mon, Sep 15, 2014 at 3:19 PM, John Haxby wrote:
> On 12/09/14 16:03, Kay Sievers wrote:
>> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby wrote:
>>> When I think of changing the
>>> behaviour of any removable hardware, udev is automatically where I look
>>> first. So if I'm missing something here, I would really like some more
>>> input.
>>
>> Udev does not decide which device show up, it just classifies stuff
>> that processes events.
>
> That's what I don't understand.
>
> Let's say I plug in a USB printer. Looking through the udev rules on my
> machine I see
>
> SUBSYSTEM=="printer", TAG+="systemd"
>ENV{SYSTEMD_WANTS}+="printer.target"
>
> (line split for readability).A whileback I proposed
>
>ACTION==“add” KERNEL==“cpu[0-9]*” TAG+="systemd"
>ENV{SYSTEMD_WANTS}+=“cpuadd.service”
>
> Aside from the obvious syntactic differences, what's the difference
> between these?
One is a target, the other is a service. There is a fundamental
difference between both. A target does not cause an immediate action,
a service does. The target just hooks up the udev event into systemd,
it does not associate any default action. The cpuadd.service, on the
other hand, does add a default action.
> Does it make any difference if the default is not to bring online more
> CPUs that the system booted with? Or some other clever default?
>
> Why does the kernel not bring CPUs online automatically? This must have
> come up before, and what you have been saying seems to suggest that
> there is something going on here that I am just missing.
The idea is to add a kernel runtime option (like sysctl) which is
named "cpu_auto_on" or something like that. Or make it a sysfs file in
/sys/bus/cpu/ just like "drivers_autoprobe". This should be set to "1"
by default, thus, all CPUs get activated without any udev interaction
(if you want to avoid races during bootup, use the kernel
command-line.. or a static kernel config option..).
Everybody else is free to set this option to "0" and write their own
udev rules. This way, udev does not have to bother with default
actions.
Is there anything wrong with this proposed solution? Or why do you
insist on your solution?
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] instantiated services set up
Jan Včelák wrote on 15/09/14 12:03: >>> > > 3.) In case of multiple instances, is there a way to control them all at >>> > > once? >>> > > >> > >> > Use PartOf= for this... > OK. Thanks. I will take a look at it! Just for a few more hints here: You would create a knot.target unit which is just a standard target unit, with a name and not much else, but it *would* have it's own [Install] section with "WantedBy=multi-user.target" In the knot@.service you would add: PartOf=knot.target and you would *replace* the WantedBy=multi-user.target with WantedBy=knot.target. This way, you can "systemctl enable knot@.service" and the default instance will be enabled. But in this context, enabling it just means it will start whenever knot.target starts, not multi-user.target. THis means an admin can easily disable all instances of knot@.service simply by doing: "systemctl disable knot.target" This approach gives you nice flexibility and control over instance units, but still gives you the ability to start/stop individual instances and control all of them at once too! HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] remove unneeded error.h includes
These are the only two places where this glibc-specific header is included. However none of the definitions in it seem to be used, so just remove the includes. --- src/notify/notify.c | 1 - src/path/path.c | 1 - 2 files changed, 2 deletions(-) diff --git a/src/notify/notify.c b/src/notify/notify.c index 6f1c52e..33933e4 100644 --- a/src/notify/notify.c +++ b/src/notify/notify.c @@ -21,7 +21,6 @@ #include #include -#include #include #include #include diff --git a/src/path/path.c b/src/path/path.c index 347921a..37f2571 100644 --- a/src/path/path.c +++ b/src/path/path.c @@ -21,7 +21,6 @@ #include #include -#include #include #include #include -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] shared/pty: remove unused pty_signal
---
src/shared/pty.c | 8
src/shared/pty.h | 1 -
2 files changed, 9 deletions(-)
diff --git a/src/shared/pty.c b/src/shared/pty.c
index 2863da4..a3332dd 100644
--- a/src/shared/pty.c
+++ b/src/shared/pty.c
@@ -541,14 +541,6 @@ int pty_write(Pty *pty, const void *buf, size_t size) {
return 0;
}
-int pty_signal(Pty *pty, int sig) {
-assert_return(pty, -EINVAL);
-assert_return(pty_is_open(pty), -ENODEV);
-assert_return(pty_is_parent(pty), -ENODEV);
-
-return ioctl(pty->fd, TIOCSIG, sig) < 0 ? -errno : 0;
-}
-
int pty_resize(Pty *pty, unsigned short term_width, unsigned short
term_height) {
struct winsize ws;
diff --git a/src/shared/pty.h b/src/shared/pty.h
index a87ceb5..251a99d 100644
--- a/src/shared/pty.h
+++ b/src/shared/pty.h
@@ -71,7 +71,6 @@ int pty_attach_event(Pty *pty, sd_event *event, pty_event_t
event_fn, void *even
void pty_detach_event(Pty *pty);
int pty_write(Pty *pty, const void *buf, size_t size);
-int pty_signal(Pty *pty, int sig);
int pty_resize(Pty *pty, unsigned short term_width, unsigned short
term_height);
pid_t pty_fork(Pty **out, sd_event *event, pty_event_t event_fn, void
*event_fn_userdata, unsigned short initial_term_width, unsigned short
initial_term_height);
--
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Forwarding to syslog missed XX messages
Am 15.09.2014 um 15:19 schrieb Umut Tezduyar Lindskog: > On Mon, Sep 15, 2014 at 2:34 PM, Reindl Harald wrote: >> >> >> Am 15.09.2014 um 14:23 schrieb Umut Tezduyar Lindskog: >>> On Mon, Sep 15, 2014 at 1:38 PM, David Herrmann >>> wrote: Hi On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald wrote: > anybody an idea why? The syslog daemon couldn't keep up with reading the log-messages. You might wanna increase the syslog receive-queue in your syslog daemon or make sure you don't flush that many messages to it. >>> You might want to take a look at the following thread too just to >>> increase the syslog limit: >>> http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html >> My workaround is adding SendBuffer=8M to systemd-journald-dev-log.socket >> >> well, there is already "ReceiveBuffer=8M" and using only >> the settings below as far as i understand is a pull from >> rsyslog and not a forward since without "$IMJournalStateFile" >> every time you restart rsyslog you got the same old log repeated > > Could both be enabled? As far as I can see from the code, "Forwarding > to ..." messages are part of forwarding messages to syslog code path > which is enabled by ForwardToSyslog=yes in /etc/systemd/journald.conf unlikely - in that case i would see messages twice been there by forgot to remove other modules and only add "$ModLoad imjournal" i really have the feeling it counts any message because on my admin machine there was all silent in journalctl and after connect with telnet to the sshd trigger the "closed connection" message it logged as expected and "missed 6 messages" again 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] Forwarding to syslog missed XX messages
On Mon, Sep 15, 2014 at 2:34 PM, Reindl Harald wrote: > > > Am 15.09.2014 um 14:23 schrieb Umut Tezduyar Lindskog: >> On Mon, Sep 15, 2014 at 1:38 PM, David Herrmann >> wrote: >>> Hi >>> >>> On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald >>> wrote: anybody an idea why? >>> >>> The syslog daemon couldn't keep up with reading the log-messages. You >>> might wanna increase the syslog receive-queue in your syslog daemon or >>> make sure you don't flush that many messages to it. >> You might want to take a look at the following thread too just to >> increase the syslog limit: >> http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html > >>> My workaround is adding SendBuffer=8M to >>> systemd-journald-dev-log.socket > > well, there is already "ReceiveBuffer=8M" and using only > the settings below as far as i understand is a pull from > rsyslog and not a forward since without "$IMJournalStateFile" > every time you restart rsyslog you got the same old log repeated Could both be enabled? As far as I can see from the code, "Forwarding to ..." messages are part of forwarding messages to syslog code path which is enabled by ForwardToSyslog=yes in /etc/systemd/journald.conf. Umut > > $ModLoad imjournal > $MainMsgQueueSize 3 > $WorkDirectory /var/lib/rsyslog > $IMJournalStateFile imjournal.state > ___ > > [Unit] > Description=Journal Socket > Documentation=man:systemd-journald.service(8) man:journald.conf(5) > DefaultDependencies=no > Before=sockets.target > > # Mount and swap units need this. If this socket unit is removed by an > # isolate request the mount and swap units would be removed too, > # hence let's exclude this from isolate requests. > IgnoreOnIsolate=yes > > [Socket] > ListenStream=/run/systemd/journal/stdout > ListenDatagram=/run/systemd/journal/socket > ListenDatagram=/dev/log > SocketMode=0666 > PassCredentials=yes > PassSecurity=yes > ReceiveBuffer=8M > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add the CPU hotplug rule
On 12/09/14 16:03, Kay Sievers wrote:
> On Fri, Sep 12, 2014 at 3:04 PM, John Haxby wrote:
>> On 02/09/14 16:42, Kay Sievers wrote:
> Either the kernel has to provide a mechanism for the userspace to
> control onlining, or do it itself and provide a mechanism to prevent
> automatic onlining. I think that the first option is actually
> cleaner. So yeah, let's add the original rule which does it
> unconditionally,
>>> No, as outlined already, we are not doing this. It is just wrong.
>>>
> and people who have too many cpus and have special
> needs can provide a custom udev rule which does something different.
>
> cpuadd.service or cpuadd@.service seem overkill, since the one we
> would provide would still do the exact same thing: unconditionally
> enable the CPU.
>>> Nothing wrong with that, if people need that. But this can for sure
>>> not live in systemd/udev, it is not the right place.
>>
>> Kay, I've worked on a case with Xen domUs which have only some of their
>> virtual CPUs online at any given time. This deployment has scripts which
>> only turn up extra CPUs when one of the applications has to do a
>> failover from one virtual machine to another. The point is that needed
>> CPU hotplug behaviour is not necessarily uniform to everyone.
>>
>> Even if the default, out of the box, behaviour is to turn up the CPUs
>> unconditionally, udev seems the best place to change this behaviour at
>> runtime. The fact that CPUs can be hotplugged at all should imply that
>> some users will need different behaviour than others. Here, the default
>> action is almost a trivial configuration... but not the only possible
>> desired configuration.
>>
>> Can I ask your reasoning for CPU hotplug behaviour not being the role of
>> udev to fulfill? If that's not the right place, where do you believe
>> would be the appropriate alternative?
>
> As explained several times, there is no point in mis-using udev to
> unconditionally react to kernel events to trigger things in the kernel
> again. That is not how driver/device binding works for all the other
> subsystems on Linux.
>
I can't find an explanation, just "this is not going to happen". Also,
we are proposing a mechanism by which a policy for deciding whether CPUs
should be placed on line can be implemented. Possible choices range
from "no, not yet" (more-or-less the above) through licensing
constraints, topological considerations all the way to "just give me
everything". We have to pick something for the default and probably the
least surprising for the end user is just to bring the CPU on line. The
present behaviour is perhaps the most surprising: completely ignore
hot-plugged CPUs.
>> I'm hoping you have another place in mind.
>
> The kernel itself or any other custom facility. This stuff has no
> place in default/upstream udev, it is the wrong way to do things in
> default setups.
So we need to introduce yet another mechanism for one particular class
of hotplug device? I must admit I'm at a loss to see why hotplug CPUs
are so different for everything else that can be hotplugged.
Could you explain why udev shouldn't do this and what makes hotplug CPUs
so different?I must be missing something really obvious here.
>
>> When I think of changing the
>> behaviour of any removable hardware, udev is automatically where I look
>> first. So if I'm missing something here, I would really like some more
>> input.
>
> Udev does not decide which device show up, it just classifies stuff
> that processes events.
That's what I don't understand.
Let's say I plug in a USB printer. Looking through the udev rules on my
machine I see
SUBSYSTEM=="printer", TAG+="systemd"
ENV{SYSTEMD_WANTS}+="printer.target"
(line split for readability).A whileback I proposed
ACTION==“add” KERNEL==“cpu[0-9]*” TAG+="systemd"
ENV{SYSTEMD_WANTS}+=“cpuadd.service”
Aside from the obvious syntactic differences, what's the difference
between these?
Does it make any difference if the default is not to bring online more
CPUs that the system booted with? Or some other clever default?
Why does the kernel not bring CPUs online automatically? This must have
come up before, and what you have been saying seems to suggest that
there is something going on here that I am just missing.
jch
PS I'm not (yet) subscribed to systemd-devel, please make sure you keep
the cc's.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Forwarding to syslog missed XX messages
Am 15.09.2014 um 14:23 schrieb Umut Tezduyar Lindskog: > On Mon, Sep 15, 2014 at 1:38 PM, David Herrmann wrote: >> Hi >> >> On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald >> wrote: >>> anybody an idea why? >> >> The syslog daemon couldn't keep up with reading the log-messages. You >> might wanna increase the syslog receive-queue in your syslog daemon or >> make sure you don't flush that many messages to it. > You might want to take a look at the following thread too just to > increase the syslog limit: > http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html >> My workaround is adding SendBuffer=8M to >> systemd-journald-dev-log.socket well, there is already "ReceiveBuffer=8M" and using only the settings below as far as i understand is a pull from rsyslog and not a forward since without "$IMJournalStateFile" every time you restart rsyslog you got the same old log repeated $ModLoad imjournal $MainMsgQueueSize 3 $WorkDirectory /var/lib/rsyslog $IMJournalStateFile imjournal.state ___ [Unit] Description=Journal Socket Documentation=man:systemd-journald.service(8) man:journald.conf(5) DefaultDependencies=no Before=sockets.target # Mount and swap units need this. If this socket unit is removed by an # isolate request the mount and swap units would be removed too, # hence let's exclude this from isolate requests. IgnoreOnIsolate=yes [Socket] ListenStream=/run/systemd/journal/stdout ListenDatagram=/run/systemd/journal/socket ListenDatagram=/dev/log SocketMode=0666 PassCredentials=yes PassSecurity=yes ReceiveBuffer=8M 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] Forwarding to syslog missed XX messages
Am 15.09.2014 um 14:10 schrieb Reindl Harald: > > Am 15.09.2014 um 14:05 schrieb David Herrmann: >> On Mon, Sep 15, 2014 at 1:43 PM, Reindl Harald >> wrote: >>> >>> Am 15.09.2014 um 13:38 schrieb David Herrmann: On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald wrote: > anybody an idea why? The syslog daemon couldn't keep up with reading the log-messages. You might wanna increase the syslog receive-queue in your syslog daemon or make sure you don't flush that many messages to it. >>> >>> i see that on any machine, even nearly idle ones >>> no idea where are "that many messages" below >>> >>> one reason more to keep the noise of informational >>> messages low (log-flood sessionmanager and so on) >>> >>> Sep 15 13:30:02 localhost sshd[5066]: Did not receive identification string >>> from *.*.*.* >>> Sep 15 13:34:45 localhost systemd-journal[4946]: Forwarding to syslog >>> missed 12 messages. >>> Sep 15 13:35:02 localhost sshd[5077]: Did not receive identification string >>> from *.*.*.* >>> Sep 15 13:36:06 localhost sshd[5085]: Accepted publickey for root from >>> *.*.*.* port 13108 ssh2 >>> Sep 15 13:36:06 localhost systemd-journal[4946]: Forwarding to syslog >>> missed 2 messages. >>> Sep 15 13:36:06 localhost systemd[1]: Starting Session 1458 of user root. >>> Sep 15 13:36:06 localhost systemd[1]: Started Session 1458 of user root. >>> Sep 15 13:36:06 localhost systemd-logind[384]: New session 1458 of user >>> root. >>> Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session >>> opened for user root by (uid=0) >>> Sep 15 13:36:06 localhost sshd[5085]: Received disconnect from *.*.*.*: 11: >>> disconnected by user >>> Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session >>> closed for user root >>> Sep 15 13:36:06 localhost systemd-logind[384]: Removed session 1458. >>> Sep 15 13:36:45 localhost sshd[5162]: Accepted publickey for root from >>> *.*.*.* port 13128 ssh2 >>> Sep 15 13:36:45 localhost systemd-journal[4946]: Forwarding to syslog >>> missed 8 messages. >> >> Can you compare the messages in journald with the syslog messages? >> It'd be interesting to see whether some messages are really dropped > > well, there are a lot of dropped intentionally by > ":msg, contains, "whatever" ~" and all wanted ones > are there - may journald whine because they are > ignored? that's pretty sure the count of total loglines and not missed ones * that's why on idle machines not all 30 seconds because sometimes there are minutes with no log at all * well, and the inbound mailserver for sue does not miss some hundret lines every 30 seconds * another rsyslog rule: :msg, contains, "Forwarding to syslog missed" ~ Sep 15 14:19:23 localhost systemd-journal[5880]: Forwarding to syslog missed 211 messages. Sep 15 14:19:53 localhost systemd-journal[5880]: Forwarding to syslog missed 253 messages. Sep 15 14:20:24 localhost systemd-journal[5880]: Forwarding to syslog missed 503 messages. 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] Forwarding to syslog missed XX messages
On Mon, Sep 15, 2014 at 1:38 PM, David Herrmann wrote: > Hi > > On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald wrote: >> anybody an idea why? > > The syslog daemon couldn't keep up with reading the log-messages. You > might wanna increase the syslog receive-queue in your syslog daemon or > make sure you don't flush that many messages to it. You might want to take a look at the following thread too just to increase the syslog limit: http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html Umut > > Thanks > David > ___ > 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] Forwarding to syslog missed XX messages
Am 15.09.2014 um 14:05 schrieb David Herrmann: > On Mon, Sep 15, 2014 at 1:43 PM, Reindl Harald wrote: >> >> Am 15.09.2014 um 13:38 schrieb David Herrmann: >>> On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald >>> wrote: anybody an idea why? >>> >>> The syslog daemon couldn't keep up with reading the log-messages. You >>> might wanna increase the syslog receive-queue in your syslog daemon or >>> make sure you don't flush that many messages to it. >> >> i see that on any machine, even nearly idle ones >> no idea where are "that many messages" below >> >> one reason more to keep the noise of informational >> messages low (log-flood sessionmanager and so on) >> >> Sep 15 13:30:02 localhost sshd[5066]: Did not receive identification string >> from *.*.*.* >> Sep 15 13:34:45 localhost systemd-journal[4946]: Forwarding to syslog missed >> 12 messages. >> Sep 15 13:35:02 localhost sshd[5077]: Did not receive identification string >> from *.*.*.* >> Sep 15 13:36:06 localhost sshd[5085]: Accepted publickey for root from >> *.*.*.* port 13108 ssh2 >> Sep 15 13:36:06 localhost systemd-journal[4946]: Forwarding to syslog missed >> 2 messages. >> Sep 15 13:36:06 localhost systemd[1]: Starting Session 1458 of user root. >> Sep 15 13:36:06 localhost systemd[1]: Started Session 1458 of user root. >> Sep 15 13:36:06 localhost systemd-logind[384]: New session 1458 of user root. >> Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session opened >> for user root by (uid=0) >> Sep 15 13:36:06 localhost sshd[5085]: Received disconnect from *.*.*.*: 11: >> disconnected by user >> Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session closed >> for user root >> Sep 15 13:36:06 localhost systemd-logind[384]: Removed session 1458. >> Sep 15 13:36:45 localhost sshd[5162]: Accepted publickey for root from >> *.*.*.* port 13128 ssh2 >> Sep 15 13:36:45 localhost systemd-journal[4946]: Forwarding to syslog missed >> 8 messages. > > Can you compare the messages in journald with the syslog messages? > It'd be interesting to see whether some messages are really dropped well, there are a lot of dropped intentionally by ":msg, contains, "whatever" ~" and all wanted ones are there - may journald whine because they are ignored? 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] Forwarding to syslog missed XX messages
Hi On Mon, Sep 15, 2014 at 1:43 PM, Reindl Harald wrote: > > > Am 15.09.2014 um 13:38 schrieb David Herrmann: >> On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald >> wrote: >>> anybody an idea why? >> >> The syslog daemon couldn't keep up with reading the log-messages. You >> might wanna increase the syslog receive-queue in your syslog daemon or >> make sure you don't flush that many messages to it. > > i see that on any machine, even nearly idle ones > no idea where are "that many messages" below > > one reason more to keep the noise of informational > messages low (log-flood sessionmanager and so on) > > Sep 15 13:30:02 localhost sshd[5066]: Did not receive identification string > from *.*.*.* > Sep 15 13:34:45 localhost systemd-journal[4946]: Forwarding to syslog missed > 12 messages. > Sep 15 13:35:02 localhost sshd[5077]: Did not receive identification string > from *.*.*.* > Sep 15 13:36:06 localhost sshd[5085]: Accepted publickey for root from > *.*.*.* port 13108 ssh2 > Sep 15 13:36:06 localhost systemd-journal[4946]: Forwarding to syslog missed > 2 messages. > Sep 15 13:36:06 localhost systemd[1]: Starting Session 1458 of user root. > Sep 15 13:36:06 localhost systemd[1]: Started Session 1458 of user root. > Sep 15 13:36:06 localhost systemd-logind[384]: New session 1458 of user root. > Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session opened > for user root by (uid=0) > Sep 15 13:36:06 localhost sshd[5085]: Received disconnect from *.*.*.*: 11: > disconnected by user > Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session closed > for user root > Sep 15 13:36:06 localhost systemd-logind[384]: Removed session 1458. > Sep 15 13:36:45 localhost sshd[5162]: Accepted publickey for root from > *.*.*.* port 13128 ssh2 > Sep 15 13:36:45 localhost systemd-journal[4946]: Forwarding to syslog missed > 8 messages. Can you compare the messages in journald with the syslog messages? It'd be interesting to see whether some messages are really dropped. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: always resolve correctly database names on 'change' event
On Sat, 13 Sep 2014 15:29:23 +0200
"Robert Milasan" wrote:
> Hello, I've found a lingering bug in udev since udev changed it's
> database name from long names to short names 'ex: b9:1'.
>
> The bug is more visible or reproducible on s390(x) has there, we can
> remove and add dasd disk/partitions.
>
> The outcome of the bug is that when removing and re-adding a
> disk/partition, most or some of the links are not removed correctly or
> at all. This leads to multiple UUID links for a single partition or
> stale links in /dev/disk/{by-uuid,by-id}.
>
> How to reproduce:
>
> dasdfmt -b 4096 -v -y -f /dev/dasdb
> fdasd -a /dev/dasdb
> mke2fs /dev/dasdb1
>
> repeat this again and you will notice that /dev/dasdb1 has 2 or more
> UUID links in /dev/disk/by-uuid.
>
> If you do not repeat this, just do 'dasdfmt -b 4096 -v -y
> -f /dev/dasdb' the UUID link to /dev/dasdb1 will be stale, just the
> same as /dev/disk/by-id links.
>
> NOTE: this bug might affect x86 machines too, but it might not be
> visible (not sure).
>
> The issue is due to when there is a change event before the remove
> event for dasdb/dasdb1, we are trying to resolve the database name
> into ':', but event->dev_db doesn't get fill-up
> with devnum (:) information, resulting in a database
> name "+block:dasdb1", which doesn't exist.
>
> I've attached the patch, please review it and push it if there is no
> complains :)
>
Will anybody be so kind and push the patch to systemd git.
--
Robert Milasan
L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: don't replace dots with slashes in prefix
David Herrmann writes:
> Hi
>
> On Mon, Sep 15, 2014 at 1:22 PM, Jan Synacek wrote:
>> David Herrmann writes:
>>> A path isn't necessarily a file-system path. With sysctl, we have to
>>> ways to specify entries:
>>>
>>> 1) You can specify them via legacy sysctl(2) names. These names use
>>> dots as separators
>>>
>>> 2) You can specify them via /proc paths. These use slashes as separators.
>>>
>>> The conversion between 1) and 2) (both ways) replaces dots by slashes
>>> and slashes by dots. However, you *always* have to convert both! That
>>> is, if a sysctl name is "root.some.weird/entry", then this becomes
>>> "root/some/weird.entry".
>>>
>>> Now, the systemd-sysctl --prefix argument says it takes "paths",
>>> however, it replaces dots with slashes, which made me assume it takes
>>> legacy names instead. Nevertheless, this conversion is definitely
>>> inconsistent, as it only replaces one part (dots->slashes), not both
>>> (it will convert the example above to "root/some/weird/entry", which
>>> is definitely wrong!). Hence, I suggested using normalize_sysctl(),
>>> which does this properly.
>>>
>>> Obviously, the result is compared against file-system paths. However,
>>> that does not mean the input of --prefix is a file-system path. In
>>> fact, given the current code it is very likely *NOT* a file-system
>>> path. Otherwise, we wouldn't do the conversion.
>>>
>>> The normalize_sysctl() helper uses some hack to allow both input
>>> types: It relies on the first part of the path/name to be
>>> alphanumeric. This is true for all sysctl nodes, therefore, we can
>>> simply look for the first dot or slash and deduce the format. If it's
>>> a slash, it's already a filesystem path, if it's a dot, it needs to be
>>> converted. Thus, using normalize_sysctl() will allow using either
>>> format with --prefix.
>>>
>>> Does that make sense? If yes, I can write a patch and apply it.
>>
>> Yes, I think it does.
>>
>> Perhaps my testing is somewhat limited. This is what I have in
>> /etc/sysctl.conf:
>>
>> net.ipv4.conf.ens3/1.rp_filter = 0
>>
>> In sysctl.c:94, there's "if (path_startswith(p, *i)) ...", where p
>> always starts with "/proc/sys", and *i is the prefix. My point was that
>> whatever you put in the prefix will never match, unless it starts with a
>> slash, therefore is NOT subject to normalize.
>
> I always assumed we add the /proc/sys prefix to --prefix arguments,
> too. But we clearly don't. Sorry, I totally missed that.. You're
> obviously right, it doesn't make sense to specify "--prefix
> /proc/sys/net.ipv6.conf.ens3/1.rp_filter".
>
> I don't think the intention was to require /proc/sys prefixes on the
> command line. This clearly doesn't make much sense. I'd rather expect
> something like this:
>
> char *p;
>
> p = normalize_sysctl(optarg);
> p = strappend("/proc/sys/", p);
> if (!p)
> return log_oom();
>
> r = strv_consume(&arg_prefixes, p);
> if (r < 0)
> return log_oom();
>
>
> Your original patch is right, too. But I'm not sure which one to
> prefer. Given that we export systemd-sysctl as rpm macro, I guess we
> have to go with your patch. Otherwise, we'd break ABI.
>
> Thanks and sorry for the confusion!
> David
Not requiring /proc/sys prefixes and normalizing them totally makes
sense. I'm glad we cleared the confusion!
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] centralized logs
Am 15.09.2014 um 13:47 schrieb Mihamina Rakotomandimby: > I currently manage several virtual machines which are not using systemd > because it's not default yet. > I've set them up to remote log to a RSyslog central point. > But, the future releases of my favorite distribution are going the systemd > way. > I must keep them logging to a central logging, as it is now. > Would you know how to? just install / start rsyslog as all the years before 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] centralized logs
On Mon, Sep 15, 2014 at 02:47:12PM +0300, Mihamina Rakotomandimby wrote: > Hi all > > I currently manage several virtual machines which are not using systemd > because it's not default yet. > > I've set them up to remote log to a RSyslog central point. > > But, the future releases of my favorite distribution are going the systemd > way. > > I must keep them logging to a central logging, as it is now. You can keep using rsyslog. It has journal-reading input modules. > Would you know how to? For native journal soulution, please evalute systemd-journal-upload. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] centralized logs
Hi all I currently manage several virtual machines which are not using systemd because it's not default yet. I've set them up to remote log to a RSyslog central point. But, the future releases of my favorite distribution are going the systemd way. I must keep them logging to a central logging, as it is now. Would you know how to? Note: I'm managing Debian & CentOS. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Forwarding to syslog missed XX messages
Am 15.09.2014 um 13:38 schrieb David Herrmann: > On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald wrote: >> anybody an idea why? > > The syslog daemon couldn't keep up with reading the log-messages. You > might wanna increase the syslog receive-queue in your syslog daemon or > make sure you don't flush that many messages to it. i see that on any machine, even nearly idle ones no idea where are "that many messages" below one reason more to keep the noise of informational messages low (log-flood sessionmanager and so on) Sep 15 13:30:02 localhost sshd[5066]: Did not receive identification string from *.*.*.* Sep 15 13:34:45 localhost systemd-journal[4946]: Forwarding to syslog missed 12 messages. Sep 15 13:35:02 localhost sshd[5077]: Did not receive identification string from *.*.*.* Sep 15 13:36:06 localhost sshd[5085]: Accepted publickey for root from *.*.*.* port 13108 ssh2 Sep 15 13:36:06 localhost systemd-journal[4946]: Forwarding to syslog missed 2 messages. Sep 15 13:36:06 localhost systemd[1]: Starting Session 1458 of user root. Sep 15 13:36:06 localhost systemd[1]: Started Session 1458 of user root. Sep 15 13:36:06 localhost systemd-logind[384]: New session 1458 of user root. Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session opened for user root by (uid=0) Sep 15 13:36:06 localhost sshd[5085]: Received disconnect from *.*.*.*: 11: disconnected by user Sep 15 13:36:06 localhost sshd[5085]: pam_unix(sshd:session): session closed for user root Sep 15 13:36:06 localhost systemd-logind[384]: Removed session 1458. Sep 15 13:36:45 localhost sshd[5162]: Accepted publickey for root from *.*.*.* port 13128 ssh2 Sep 15 13:36:45 localhost systemd-journal[4946]: Forwarding to syslog missed 8 messages. 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] Forwarding to syslog missed XX messages
Hi On Mon, Sep 15, 2014 at 1:20 PM, Reindl Harald wrote: > anybody an idea why? The syslog daemon couldn't keep up with reading the log-messages. You might wanna increase the syslog receive-queue in your syslog daemon or make sure you don't flush that many messages to it. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: don't replace dots with slashes in prefix
Hi
On Mon, Sep 15, 2014 at 1:22 PM, Jan Synacek wrote:
> David Herrmann writes:
>> A path isn't necessarily a file-system path. With sysctl, we have to
>> ways to specify entries:
>>
>> 1) You can specify them via legacy sysctl(2) names. These names use
>> dots as separators
>>
>> 2) You can specify them via /proc paths. These use slashes as separators.
>>
>> The conversion between 1) and 2) (both ways) replaces dots by slashes
>> and slashes by dots. However, you *always* have to convert both! That
>> is, if a sysctl name is "root.some.weird/entry", then this becomes
>> "root/some/weird.entry".
>>
>> Now, the systemd-sysctl --prefix argument says it takes "paths",
>> however, it replaces dots with slashes, which made me assume it takes
>> legacy names instead. Nevertheless, this conversion is definitely
>> inconsistent, as it only replaces one part (dots->slashes), not both
>> (it will convert the example above to "root/some/weird/entry", which
>> is definitely wrong!). Hence, I suggested using normalize_sysctl(),
>> which does this properly.
>>
>> Obviously, the result is compared against file-system paths. However,
>> that does not mean the input of --prefix is a file-system path. In
>> fact, given the current code it is very likely *NOT* a file-system
>> path. Otherwise, we wouldn't do the conversion.
>>
>> The normalize_sysctl() helper uses some hack to allow both input
>> types: It relies on the first part of the path/name to be
>> alphanumeric. This is true for all sysctl nodes, therefore, we can
>> simply look for the first dot or slash and deduce the format. If it's
>> a slash, it's already a filesystem path, if it's a dot, it needs to be
>> converted. Thus, using normalize_sysctl() will allow using either
>> format with --prefix.
>>
>> Does that make sense? If yes, I can write a patch and apply it.
>
> Yes, I think it does.
>
> Perhaps my testing is somewhat limited. This is what I have in
> /etc/sysctl.conf:
>
> net.ipv4.conf.ens3/1.rp_filter = 0
>
> In sysctl.c:94, there's "if (path_startswith(p, *i)) ...", where p
> always starts with "/proc/sys", and *i is the prefix. My point was that
> whatever you put in the prefix will never match, unless it starts with a
> slash, therefore is NOT subject to normalize.
I always assumed we add the /proc/sys prefix to --prefix arguments,
too. But we clearly don't. Sorry, I totally missed that.. You're
obviously right, it doesn't make sense to specify "--prefix
/proc/sys/net.ipv6.conf.ens3/1.rp_filter".
I don't think the intention was to require /proc/sys prefixes on the
command line. This clearly doesn't make much sense. I'd rather expect
something like this:
char *p;
p = normalize_sysctl(optarg);
p = strappend("/proc/sys/", p);
if (!p)
return log_oom();
r = strv_consume(&arg_prefixes, p);
if (r < 0)
return log_oom();
Your original patch is right, too. But I'm not sure which one to
prefer. Given that we export systemd-sysctl as rpm macro, I guess we
have to go with your patch. Otherwise, we'd break ABI.
Thanks and sorry for the confusion!
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: don't replace dots with slashes in prefix
David Herrmann writes:
> Hi
>
> On Mon, Sep 15, 2014 at 11:26 AM, Jan Synacek wrote:
>> David Herrmann writes:
>>> Hi
>>>
>>> On Mon, Sep 15, 2014 at 10:00 AM, Jan Synacek wrote:
David Herrmann writes:
> Nevertheless, the documentation should clearly state which input is
> expected and the current code is definitely wrong as it only performs
> one way conversions.
Could you please point me to the right documentation that I can update?
My guess would be sysctl.d(5), since systemd-sysctl(8) refers to it.
Also, should I make it a separate patch?
>>>
>>> I was referring to the --help text of the binary. There is no man-page
>>> for it, so no need to update any of them.
>>>
>>> Feel free to put me on CC on v2 and I'll apply the patch.
>>>
>>> Thanks a lot!
>>> David
>>
>> After tinkering with it for a while, I think that my original patch is
>> correct. The prefix is a path prefix that is matched against actual
>> paths, not variable names. That means that the prefix always has to
>> start with a slash, otherwise nothing matches, which also means that
>> normalizing would have no effect. And I think that the docstring doesn't
>> need an update either. It says "Only apply rules that apply to *paths
>> with the specified prefix*" (my emphasis added).
>
> A path isn't necessarily a file-system path. With sysctl, we have to
> ways to specify entries:
>
> 1) You can specify them via legacy sysctl(2) names. These names use
> dots as separators
>
> 2) You can specify them via /proc paths. These use slashes as separators.
>
> The conversion between 1) and 2) (both ways) replaces dots by slashes
> and slashes by dots. However, you *always* have to convert both! That
> is, if a sysctl name is "root.some.weird/entry", then this becomes
> "root/some/weird.entry".
>
> Now, the systemd-sysctl --prefix argument says it takes "paths",
> however, it replaces dots with slashes, which made me assume it takes
> legacy names instead. Nevertheless, this conversion is definitely
> inconsistent, as it only replaces one part (dots->slashes), not both
> (it will convert the example above to "root/some/weird/entry", which
> is definitely wrong!). Hence, I suggested using normalize_sysctl(),
> which does this properly.
>
> Obviously, the result is compared against file-system paths. However,
> that does not mean the input of --prefix is a file-system path. In
> fact, given the current code it is very likely *NOT* a file-system
> path. Otherwise, we wouldn't do the conversion.
>
> The normalize_sysctl() helper uses some hack to allow both input
> types: It relies on the first part of the path/name to be
> alphanumeric. This is true for all sysctl nodes, therefore, we can
> simply look for the first dot or slash and deduce the format. If it's
> a slash, it's already a filesystem path, if it's a dot, it needs to be
> converted. Thus, using normalize_sysctl() will allow using either
> format with --prefix.
>
> Does that make sense? If yes, I can write a patch and apply it.
Yes, I think it does.
Perhaps my testing is somewhat limited. This is what I have in
/etc/sysctl.conf:
net.ipv4.conf.ens3/1.rp_filter = 0
In sysctl.c:94, there's "if (path_startswith(p, *i)) ...", where p
always starts with "/proc/sys", and *i is the prefix. My point was that
whatever you put in the prefix will never match, unless it starts with a
slash, therefore is NOT subject to normalize.
If my example were to start with a slash, than, again, I will have to
begin the prefix with a slash, otherwise it would never match.
The question is, should p always start with "/proc/sys" before it's
matched against the prefix? If yes, than the second conversion is not
needed.
I'm sorry if I still don't fully understand. Maybe a counterexample that
would show where my reasoning fails would be useful.
I'm attaching a v2 patch with the normalization of the prefix, in case
it's really needed. Feel free to modify/rewrite it if it's still needed.
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
>From 8159821c1f253fde4132c08eb8a39507ce38fd03 Mon Sep 17 00:00:00 2001
From: Jan Synacek
Date: Fri, 12 Sep 2014 11:10:44 +0200
Subject: [PATCH v2] sysctl: correctly normalize prefix
---
src/sysctl/sysctl.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 8ce9870..4454c8f 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -256,12 +256,7 @@ static int parse_argv(int argc, char *argv[]) {
return 0;
case ARG_PREFIX: {
-char *p;
-
-for (p = optarg; *p; p++)
-if (*p == '.')
-*p = '/';
-
+optarg = normalize_sysctl(optarg);
if (strv_extend(&arg_prefixes, optarg) < 0)
return log_oom();
--
1.9.3
_
[systemd-devel] Forwarding to syslog missed XX messages
anybody an idea why? Sep 15 13:14:43 localhost systemd-journal[4650]: Forwarding to syslog missed 2 messages. Sep 15 13:15:13 localhost systemd-journal[4650]: Forwarding to syslog missed 196 messages. Sep 15 13:15:44 localhost systemd-journal[4650]: Forwarding to syslog missed 236 messages. Sep 15 13:16:14 localhost systemd-journal[4650]: Forwarding to syslog missed 180 messages. Sep 15 13:16:44 localhost systemd-journal[4650]: Forwarding to syslog missed 323 messages. Sep 15 13:17:15 localhost systemd-journal[4650]: Forwarding to syslog missed 232 messages. Sep 15 13:17:45 localhost systemd-journal[4650]: Forwarding to syslog missed 156 messages. 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] instantiated services set up
> After=syslog.target is redundant since a long time. Consider removing > this. And After=network.target usually doesn't do what one might thing > it does and with well written software that listens to rtnl or uses > IP_FREEBIND not even necessary... OK. I will remove the syslog. But I will have to keep network.target for now as we support non-Linux systems as well. Adding support for rtnl or IP_FREEBIND would mean duplicating a lot of code... probably. > > 1.) Is it valid to ship both knot.service and knot@.service file? > > Sure, but for the sake of simplicity and not confusing the user I would > avoid this. > > I'd just ship the templated version, and then maybe add > DefaultInstance=something to the [Install] section in order to make one > instance the "default" one... DefaultInstance sounds great. Will this get backported into systemd-stable at some time? Because I'm looking for a solution for RHEL 7. > > 2.) Is there a way to make knot.service and knot@.service units to > > conflict in a way that if one of these is running, the other will fail to > > start? > > > > I tried adding Conflicts=knot.service to Unit section of knot@.service, > > which makes the conflicting service to stop silently. That is fine, but > > may be confusing for the user. I would rather see systemctl to fail with > > an error message. Is that possible? > > Hmm, we currently don't support any dependency type like this. And I am > very conservative about adding new dep types, unless we have a very > strong reason for it... Fine. This is not that important. > > 3.) In case of multiple instances, is there a way to control them all at > > once? > > > > Use PartOf= for this... OK. Thanks. I will take a look at it! Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: don't replace dots with slashes in prefix
Hi On Mon, Sep 15, 2014 at 11:26 AM, Jan Synacek wrote: > David Herrmann writes: >> Hi >> >> On Mon, Sep 15, 2014 at 10:00 AM, Jan Synacek wrote: >>> David Herrmann writes: Nevertheless, the documentation should clearly state which input is expected and the current code is definitely wrong as it only performs one way conversions. >>> >>> Could you please point me to the right documentation that I can update? >>> My guess would be sysctl.d(5), since systemd-sysctl(8) refers to it. >>> Also, should I make it a separate patch? >> >> I was referring to the --help text of the binary. There is no man-page >> for it, so no need to update any of them. >> >> Feel free to put me on CC on v2 and I'll apply the patch. >> >> Thanks a lot! >> David > > After tinkering with it for a while, I think that my original patch is > correct. The prefix is a path prefix that is matched against actual > paths, not variable names. That means that the prefix always has to > start with a slash, otherwise nothing matches, which also means that > normalizing would have no effect. And I think that the docstring doesn't > need an update either. It says "Only apply rules that apply to *paths > with the specified prefix*" (my emphasis added). A path isn't necessarily a file-system path. With sysctl, we have to ways to specify entries: 1) You can specify them via legacy sysctl(2) names. These names use dots as separators 2) You can specify them via /proc paths. These use slashes as separators. The conversion between 1) and 2) (both ways) replaces dots by slashes and slashes by dots. However, you *always* have to convert both! That is, if a sysctl name is "root.some.weird/entry", then this becomes "root/some/weird.entry". Now, the systemd-sysctl --prefix argument says it takes "paths", however, it replaces dots with slashes, which made me assume it takes legacy names instead. Nevertheless, this conversion is definitely inconsistent, as it only replaces one part (dots->slashes), not both (it will convert the example above to "root/some/weird/entry", which is definitely wrong!). Hence, I suggested using normalize_sysctl(), which does this properly. Obviously, the result is compared against file-system paths. However, that does not mean the input of --prefix is a file-system path. In fact, given the current code it is very likely *NOT* a file-system path. Otherwise, we wouldn't do the conversion. The normalize_sysctl() helper uses some hack to allow both input types: It relies on the first part of the path/name to be alphanumeric. This is true for all sysctl nodes, therefore, we can simply look for the first dot or slash and deduce the format. If it's a slash, it's already a filesystem path, if it's a dot, it needs to be converted. Thus, using normalize_sysctl() will allow using either format with --prefix. Does that make sense? If yes, I can write a patch and apply it. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: don't replace dots with slashes in prefix
David Herrmann writes: > Hi > > On Mon, Sep 15, 2014 at 10:00 AM, Jan Synacek wrote: >> David Herrmann writes: >>> Nevertheless, the documentation should clearly state which input is >>> expected and the current code is definitely wrong as it only performs >>> one way conversions. >> >> Could you please point me to the right documentation that I can update? >> My guess would be sysctl.d(5), since systemd-sysctl(8) refers to it. >> Also, should I make it a separate patch? > > I was referring to the --help text of the binary. There is no man-page > for it, so no need to update any of them. > > Feel free to put me on CC on v2 and I'll apply the patch. > > Thanks a lot! > David After tinkering with it for a while, I think that my original patch is correct. The prefix is a path prefix that is matched against actual paths, not variable names. That means that the prefix always has to start with a slash, otherwise nothing matches, which also means that normalizing would have no effect. And I think that the docstring doesn't need an update either. It says "Only apply rules that apply to *paths with the specified prefix*" (my emphasis added). -- 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] Possible to add bind mounts without rebooting container?
We're currently running systemd-212. man doesn't seem to cover this. --bind=, --bind-ro= Bind mount a file or directory from the host into the container. Either takes a path argument -- in which case the specified path will be mounted from the host to the same path in the container --, or a colon-separated pair of paths -- in which case the first specified path is the source in the host, and the second path is the destination in the container. The --bind-ro= option creates read-only bind mounts. Hoping to avoid rebooting the container. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: don't replace dots with slashes in prefix
Hi On Mon, Sep 15, 2014 at 10:00 AM, Jan Synacek wrote: > David Herrmann writes: >> Nevertheless, the documentation should clearly state which input is >> expected and the current code is definitely wrong as it only performs >> one way conversions. > > Could you please point me to the right documentation that I can update? > My guess would be sysctl.d(5), since systemd-sysctl(8) refers to it. > Also, should I make it a separate patch? I was referring to the --help text of the binary. There is no man-page for it, so no need to update any of them. Feel free to put me on CC on v2 and I'll apply the patch. Thanks a lot! David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysctl: don't replace dots with slashes in prefix
David Herrmann writes:
> Hi
>
> On Fri, Sep 12, 2014 at 11:21 AM, Jan Synacek wrote:
>> The prefix is always tested against normalized property names.
>> ---
>> src/sysctl/sysctl.c | 6 --
>> 1 file changed, 6 deletions(-)
>>
>> diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
>> index 8ce9870..0cb0875 100644
>> --- a/src/sysctl/sysctl.c
>> +++ b/src/sysctl/sysctl.c
>> @@ -256,12 +256,6 @@ static int parse_argv(int argc, char *argv[]) {
>> return 0;
>>
>> case ARG_PREFIX: {
>> -char *p;
>> -
>> -for (p = optarg; *p; p++)
>> -if (*p == '.')
>> -*p = '/';
>> -
>
> Hm, are you sure this is right?
No, I was hoping that good people here would point me to the right
direction if I broke something and didn't know about it. Which you did,
thank you:)
> I mean, so far people could have just used the same format as they use
> in sysctl files (dots as separators). If we apply this, we break
> compatibility as we now expect filesystem paths. I think the better
> fix is to use normalize_sysctl() on the input. This allows both
> formats to be specified (relies on the fact that the root node does
> not contain dots or slashes in it's name).
Makes sense, I'll update the patch.
> Nevertheless, the documentation should clearly state which input is
> expected and the current code is definitely wrong as it only performs
> one way conversions.
Could you please point me to the right documentation that I can update?
My guess would be sysctl.d(5), since systemd-sysctl(8) refers to it.
Also, should I make it a separate patch?
> Thanks
> David
Thank you,
--
Jan Synacek
Software Engineer, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
