Re: [systemd-devel] [PATCH] systemd-run: extend bash completion
On Tue, Mar 11, 2014 at 4:52 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 05.03.14 23:48, Thomas H.P. Andersen (pho...@gmail.com) wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com --system -H --host -M --machine --service-type (options: simple forking oneshot dbus notify idle) --uid --gid --nice --setenv -p --property (options read from bus_append_unit_property_assignment) Looks good as far as I grok the completion things. Zbigniew, you know this better than I do, can you OK this? I was mostly looking for a verification that the list of options make are correct: --service-type: simple forking oneshot dbus notify idle --property: CPUAccounting MemoryAccounting BlockIOAccounting SendSIGHUP SendSIGKILL MemoryLimit CPUShares BlockIOWeight User Group DevicePolicy KillMode DeviceAllow BlockIOReadBandwidth BlockIOWriteBandwidth BlockIODeviceWeight Nice Environment KillSignal Some of the properties take e.g. a boolean value and we could go on to suggest an on/off value but I did not go that far. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd: powerd initctl support
2014-03-11 4:30 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Fri, 07.03.14 14:32, Hannes Reinecke (h...@suse.de) wrote: + THE POWER IS FAILED! SYSTEM GOING DOWN! PLEASE LOG OFF NOW!); Hmm, this is incorrect english, isn't it? it should be The power *has* failed, no? why not just power failure? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd][cgroup in container] problem with cgroup hierarchy in container
On 10.03.2014 22:50, Lennart Poettering wrote: Which version of systemd is this? any chance you can reproduce this with systemctl compiled fresh from current git? Or could you run gdbus introspect --system --dest org.freedesktop.systemd1 --object-path /org/freedesktop/systemd1 and see if any of the props (and in partciular the Controlgroup one look weird? I can't reproduce this on systemd 210 compiled from commit: a7b1c3971a30546fe633e320d45033aba8b2ca3c README: document that we still encourage people to turn off audit when they want to use containers systemctl works properly -- Dariusz Michaluk Samsung RD Institute Poland Samsung Electronics d.micha...@samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] service: don't create extra cgroup for control process when reloading SysV service
On 03/11/2014 09:05 AM, Michael Biebl wrote: 2014-03-10 15:25 GMT+01:00 Lukas Nykryn lnyk...@redhat.com: Unfortunately common practice in initscripts is to have reload as an alias for restart (https://fedoraproject.org/wiki/Packaging:SysVInitScript). In that case the newly started process will be killed immediately after the reload process ends and its cgroup is destroyed. Interesting. The Debian/Ubuntu packaging policies are quite contrary in that regard. LSB/SysV init scripts only have the reload option, if the daemon actually supports it. There is a force-reload action though, which is mapped to reload, if the daemon supports reload and to restart, if not. Given that, I wonder if this should be maintained as a Fedora specific patch? Debian is getting it right in this regard since LSB defines the behavior of reload to be [1] *reload* cause the configuration of the service to be reloaded without actually stopping and restarting the service In anycase systemd should follow LSB in this regard leaving any downstream distribution having to patch their own common practices in initscripts by themselves. JBG 1. http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: properly detect reference to unexisting part of PROGRAM's result
On Mon, Feb 24, 2014 at 5:06 PM, Lukas Nykryn lnyk...@redhat.com wrote: --- src/udev/udev-event.c | 2 ++ 1 file changed, 2 insertions(+) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] kernel panic
I have strange kernel panic Kernel 3.13.3 vanilla root is mounted via 9p virtfs (readonly). virsh --version 1.2.1 qemu --version QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard systemd version 210 Domain config: domain type='kvm' namebuild/name uuid328891df-b3c3-aee9-eb5d-7e7934f7/uuid memory unit='MiB'512/memory currentMemory unit='MiB'512/currentMemory vcpu placement='static'2/vcpu resource partition/machine/partition /resource os type arch='x86_64' machine='pc-1.0'hvm/type boot dev='hd'/ kernel/boot/vmlinuz-3.13.3/kernel initrd/boot/initrd-3.13.3/initrd cmdlinero root=virtfs:root console=tty0 console=ttyS0,115200n8 /cmdline /os features acpi/ apic/ pae/ /features clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootdestroy/on_reboot on_crashdestroy/on_crash devices emulator/usr/bin/qemu-system-x86_64/emulator filesystem type='mount' accessmode='squash' driver type='path' wrpolicy='immediate'/ source dir='/home/vtolstov/devel/vtolstov/lb/fs/x86_64'/ target dir='root'/ readonly/ /filesystem filesystem type='mount' accessmode='squash' driver type='path' wrpolicy='immediate'/ source dir='/home/vtolstov/devel/vtolstov/lb/fs/var/log'/ target dir='var/log'/ /filesystem filesystem type='mount' accessmode='squash' driver type='path' wrpolicy='immediate'/ source dir='/home/vtolstov/devel/vtolstov/lb/fs/var/cache/paludis'/ target dir='var/cache/paludis'/ /filesystem filesystem type='mount' accessmode='squash' driver type='path' wrpolicy='immediate'/ source dir='/home/vtolstov/devel/vtolstov/lb/fs/var/db/paludis'/ target dir='var/db/paludis'/ /filesystem controller type='virtio-serial' index='0' alias name='virtio-serial0'/ address type='pci' domain='0x' bus='0x00' slot='0x06' function='0x0'/ /controller controller type='pci' index='0' model='pci-root' alias name='pci0'/ /controller controller type='ide' index='0' alias name='ide0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='network' mac address='52:54:00:00:02:4c'/ source network='mighost'/ model type='virtio'/ alias name='net0'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' source path='/dev/pts/8'/ target port='0'/ alias name='serial0'/ /serial console type='pty' tty='/dev/pts/8' source path='/dev/pts/8'/ target type='serial' port='0'/ alias name='serial0'/ /console channel type='spicevmc' target type='virtio' name='com.redhat.spice.0'/ alias name='channel0'/ address type='virtio-serial' controller='0' bus='0' port='1'/ /channel channel type='unix' source mode='bind' path='/var/lib/libvirt/qemu/build.agent'/ target type='virtio' name='org.mighost.agent.0'/ alias name='channel1'/ address type='virtio-serial' controller='0' bus='0' port='2'/ /channel input type='mouse' bus='ps2'/ graphics type='vnc' port='5905' autoport='yes' listen='0.0.0.0' listen type='address' address='0.0.0.0'/ /graphics video model type='vga' vram='9216' heads='1'/ alias name='video0'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' alias name='balloon0'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /memballoon /devices seclabel type='none'/ /domain Sometimes i get error like: [ OK ] Reached target Initrd File Systems. Starting dracut mount hook... [ 14.326081] FDC 0 is a S82078B [ 14.644148] PANIC: double fault, error_code: 0x0 [ 14.640174] PANIC: double fault, error_code: 0x0 [ 14.640174] CPU: 0 PID: 130 Comm: systemd-udevd Not tainted 3.13.3 #2 [ 14.640174] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 14.640174] task: 88001faf ti: 88001faee000 task.ti: 88001faee000 [ 14.640174] RIP: 0010:[81109df8] [81109df8] file_read_actor+0x58/0x160 [ 14.640174] RSP: 0018:88001faefd60 EFLAGS: 00010206 [ 14.640174] RAX: RBX: 88001faefe10 RCX: 100f [ 14.640174] RDX: RSI: ea70ebc0 RDI: 7f94d60b3037 [ 14.640174] RBP: 88001faefd90 R08: 0002 R09: ea70ebdc [ 14.640174] R10: 0023 R11: R12: 1000 [ 14.640174] R13: 0001f000 R14: 88001f9d5e00 R15: 1000 [ 14.640174] FS: 7f94d60dc7c0() GS:88001f40() knlGS: [ 14.640174] CS: 0010 DS: ES: CR0: 80050033 [ 14.640174] CR2: CR3: 1fad9000 CR4: 06f0 [
Re: [systemd-devel] Suspending access to opened/active /dev/nodes during application runtime
Hi On Fri, Mar 7, 2014 at 7:45 PM, Lukasz Pawelczyk hav...@gmail.com wrote: Problem: Has anyone thought about a mechanism to limit/remove an access to a device during an application runtime? Meaning we have an application that has an open file descriptor to some /dev/node and depending on *something* it gains or looses the access to it gracefully (with or without a notification, but without any fatal consequences). Example: LXC. Imagine we have 2 separate containers. Both running full operating systems. Specifically with 2 X servers. Both running concurrently of course. Both need the same input devices (e.g. we have just one mouse). This creates a security problem when we want to have completely separate environments. One container is active (being displayed on a monitor and controlled with a mouse) while the other container runs evtest /dev/input/something and grabs the secret password user typed in the other. Solutions: The complete solution would comprise of 2 parts: - a mechanism that would allow to temporally hide a device from an open file descriptor. - a mechanism for deciding whether application/process/namespace should have an access to a specific device at a specific moment Let's focus on the first problem only, as it would need to be solved first anyway. I haven't found anything that would allow me to do it. There are a lot mechanisms that make it possible to restrict an access during open(): - DAC - ACL (controlled by hand or with uaccess) - LSM (in general) - device cgroups But all of those can't do a thing when the device is already opened and an application has a file descriptor. I don't see such mechanism in kernel sources either. I do imagine that it would not be possible for every device to handle such a thing (dri comes to mind) without breaking something (graphics card state in dri example). But there is class of simple input/output devices that would handle this without problems. I did implement some proof-of-concept solution for an evdev driver by allowing or disallowing events that go to evdev_client structure using some arbitrary condition. But this is far from a generic solution. My proof-of-concept is somewhat similar to this (I just found it): http://www.spinics.net/lists/linux-input/msg25547.html Though a little bit wider in scope. But neither is flawless nor generic. Has anyone had any thoughts about a similar problem? Lennart and Greg have already answered most of this, few notes from me: * EVIOCREVOKE and DRM_SET_MASTER/DROP_MASTER are real. We use them. They solve your problem for gfx and input devices. * EVIOCMUTE is *bad*. It is a privileged ioctl compared to EVIOCREVOKE, so we've never merged it. It neither has major advantages over revoke. So use EVIOCREVOKE. * A generic frevoke() syscall would solve all is, but is unlikely to ever appear upstream. Cheers David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-run: extend bash completion
On Tue, Mar 11, 2014 at 08:05:48AM +0100, Thomas H.P. Andersen wrote: On Tue, Mar 11, 2014 at 4:52 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 05.03.14 23:48, Thomas H.P. Andersen (pho...@gmail.com) wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com --system -H --host -M --machine --service-type (options: simple forking oneshot dbus notify idle) --uid --gid --nice --setenv -p --property (options read from bus_append_unit_property_assignment) Looks good as far as I grok the completion things. Zbigniew, you know this better than I do, can you OK this? I was mostly looking for a verification that the list of options make are correct: --service-type: simple forking oneshot dbus notify idle Yes. --property: CPUAccounting MemoryAccounting BlockIOAccounting SendSIGHUP SendSIGKILL MemoryLimit CPUShares BlockIOWeight User Group DevicePolicy KillMode DeviceAllow BlockIOReadBandwidth BlockIOWriteBandwidth BlockIODeviceWeight Nice Environment KillSignal Isn't this missing the rlimit stuff (LimitCPU, LimitFSIZE, LimitDATA, LimitSTACK, LimitCORE, LimitRSS, LimitNOFILE, LimitAS, LimitNPROC, LimitMEMLOCK, LimitLOCKS, LimitSIGPENDING LimitMSGQUEUE, LimitNICE, LimitRTPRIO, LimitRTTIME)? It would be great to generate this list programatically, but I don't see an immediate way. Some of the properties take e.g. a boolean value and we could go on to suggest an on/off value but I did not go that far. Yeah, I think one has to read what the available options mean anyway, and most values cannot be completed anyway, so completion for the *values* is less important. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kernel panic
El 11/03/14 09:24, Vasiliy Tolstov escribió: I have strange kernel panic Kernel 3.13.3 vanilla root is mounted via 9p virtfs (readonly). virsh --version 1.2.1 qemu --version QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard systemd version 210 [ 14.640174] Kernel panic - not syncing: Machine halted. [ 14.644148] CPU: 1 PID: 126 Comm: systemd-udevd Not tainted 3.13.3 #2 This is quite obviously not a systemd/udev problem, post your problem in the kernel mailing list instead. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kernel panic
2014-03-11 17:13 GMT+04:00 Cristian Rodríguez crrodrig...@opensuse.org: This is quite obviously not a systemd/udev problem, post your problem in the kernel mailing list instead. Thanks! -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-run: extend bash completion
On Tue, 11.03.14 08:05, Thomas H.P. Andersen (pho...@gmail.com) wrote: On Tue, Mar 11, 2014 at 4:52 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 05.03.14 23:48, Thomas H.P. Andersen (pho...@gmail.com) wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com --system -H --host -M --machine --service-type (options: simple forking oneshot dbus notify idle) --uid --gid --nice --setenv -p --property (options read from bus_append_unit_property_assignment) Looks good as far as I grok the completion things. Zbigniew, you know this better than I do, can you OK this? I was mostly looking for a verification that the list of options make are correct: --service-type: simple forking oneshot dbus notify idle Corrct. --property: CPUAccounting MemoryAccounting BlockIOAccounting SendSIGHUP SendSIGKILL MemoryLimit CPUShares BlockIOWeight User Group DevicePolicy KillMode DeviceAllow BlockIOReadBandwidth BlockIOWriteBandwidth BlockIODeviceWeight Nice Environment KillSignal Some of the properties take e.g. a boolean value and we could go on to suggest an on/off value but I did not go that far. Given that there is --user= and --group= it's a bit pointless to ever specify User= and Group= with --property, but then again, it will work. There are also the LimitCORE=, LimitCPU=, ... props settable now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] hostnamectl: read pretty_name and cpe_name from remote
On Tue, Mar 11, 2014 at 05:01:33AM +0100, Lennart Poettering wrote: On Tue, 04.03.14 23:01, Djalal Harouni (tix...@opendz.org) wrote: The other two patches look fine (well, this one needs updating, if the prop names change as proposed in the other mail...) Please rebase, and repost, will merge then! OK, I've done all the changes that you have suggested. New patches will follow as a v2 BTW what about the kernel version? I mean the uname() is still local. should it be exposed as a bus property on the manager of PID 1? Thanks a lot! Thanks! -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/3] hostnamed: minor improvements in context_write_data_other()
Prepare context_write_data_other() and rename it to
context_write_data_machine_info()
---
src/hostname/hostnamed.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 6aa08ca..fab0601 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -258,7 +258,7 @@ static int context_write_data_static_hostname(Context *c) {
return write_string_file_atomic_label(/etc/hostname,
c-data[PROP_STATIC_HOSTNAME]);
}
-static int context_write_data_other(Context *c) {
+static int context_write_data_machine_info(Context *c) {
static const char * const name[_PROP_MAX] = {
[PROP_PRETTY_HOSTNAME] = PRETTY_HOSTNAME,
@@ -275,7 +275,7 @@ static int context_write_data_other(Context *c) {
if (r 0 r != -ENOENT)
return r;
-for (p = 2; p _PROP_MAX; p++) {
+for (p = PROP_PRETTY_HOSTNAME; p = PROP_CHASSIS; p++) {
char *t, **u;
assert(name[p]);
@@ -510,7 +510,7 @@ static int set_machine_info(Context *c, sd_bus *bus,
sd_bus_message *m, int prop
c-data[prop] = h;
}
-r = context_write_data_other(c);
+r = context_write_data_machine_info(c);
if (r 0) {
log_error(Failed to write machine info: %s, strerror(-r));
return sd_bus_error_set_errnof(error, r, Failed to write
machine info: %s, strerror(-r));
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/3] hostnamed: expose OperatingSystemPrettyName and OperatingSystemCPEName on the bus
---
src/hostname/hostnamed.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index fab0601..3b19d43 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -40,6 +40,8 @@ enum {
PROP_PRETTY_HOSTNAME,
PROP_ICON_NAME,
PROP_CHASSIS,
+PROP_OS_PRETTY_NAME,
+PROP_OS_CPE_NAME,
_PROP_MAX
};
@@ -89,6 +91,13 @@ static int context_read_data(Context *c) {
if (r 0 r != -ENOENT)
return r;
+r = parse_env_file(/etc/os-release, NEWLINE,
+ PRETTY_NAME, c-data[PROP_OS_PRETTY_NAME],
+ CPE_NAME, c-data[PROP_OS_CPE_NAME],
+ NULL);
+if (r 0 r != -ENOENT)
+return r;
+
return 0;
}
@@ -546,6 +555,8 @@ static const sd_bus_vtable hostname_vtable[] = {
SD_BUS_PROPERTY(PrettyHostname, s, NULL, offsetof(Context, data) +
sizeof(char*) * PROP_PRETTY_HOSTNAME, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(IconName, s, property_get_icon_name, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(Chassis, s, property_get_chassis, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+SD_BUS_PROPERTY(OperatingSystemPrettyName, s, NULL,
offsetof(Context, data) + sizeof(char*) * PROP_OS_PRETTY_NAME,
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(OperatingSystemCPEName, s, NULL, offsetof(Context,
data) + sizeof(char*) * PROP_OS_CPE_NAME, SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_METHOD(SetHostname, sb, NULL, method_set_hostname,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD(SetStaticHostname, sb, NULL,
method_set_static_hostname, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD(SetPrettyHostname, sb, NULL,
method_set_pretty_hostname, SD_BUS_VTABLE_UNPRIVILEGED),
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 3/3] hostnamectl: read OS pretty_name and cpe_name from remote
---
src/hostname/hostnamectl.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 94b4243..326f371 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,8 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *os_pretty_name;
+char *os_cpe_name;
char *virtualization;
char *architecture;
} StatusInfo;
@@ -74,7 +76,6 @@ typedef struct StatusInfo {
static void print_status_info(StatusInfo *i) {
sd_id128_t mid = {}, bid = {};
int r;
-_cleanup_free_ char *pretty_name = NULL, *cpe_name = NULL;
struct utsname u;
assert(i);
@@ -105,18 +106,11 @@ static void print_status_info(StatusInfo *i) {
if (!isempty(i-virtualization))
printf(Virtualization: %s\n, i-virtualization);
-r = parse_env_file(/etc/os-release, NEWLINE,
- PRETTY_NAME, pretty_name,
- CPE_NAME, cpe_name,
- NULL);
-if (r 0)
-log_warning(Failed to read /etc/os-release: %s,
strerror(-r));
-
-if (!isempty(pretty_name))
-printf( Operating System: %s\n, pretty_name);
+if (!isempty(i-os_pretty_name))
+printf( Operating System: %s\n, i-os_pretty_name);
-if (!isempty(cpe_name))
-printf( CPE OS Name: %s\n, cpe_name);
+if (!isempty(i-os_cpe_name))
+printf( CPE OS Name: %s\n, i-os_cpe_name);
assert_se(uname(u) = 0);
printf(Kernel: %s %s\n, u.sysname, u.release);
@@ -162,6 +156,8 @@ static int show_all_names(sd_bus *bus) {
{ PrettyHostname, s, NULL, offsetof(StatusInfo,
pretty_hostname) },
{ IconName, s, NULL, offsetof(StatusInfo, icon_name)
},
{ Chassis,s, NULL, offsetof(StatusInfo, chassis) },
+{ OperatingSystemPrettyName, s, NULL,
offsetof(StatusInfo, os_pretty_name) },
+{ OperatingSystemCPEName,s, NULL,
offsetof(StatusInfo, os_cpe_name) },
{}
};
@@ -195,6 +191,8 @@ fail:
free(info.pretty_hostname);
free(info.icon_name);
free(info.chassis);
+free(info.os_pretty_name);
+free(info.os_cpe_name);
free(info.virtualization);
free(info.architecture);
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: fix argv[0] for getent
---
src/nspawn/nspawn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index cd31bd4..489dbde 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2264,8 +2264,8 @@ static int spawn_getent(const char *database, const char
*key, pid_t *rpid) {
reset_all_signal_handlers();
close_all_fds(NULL, 0);
-execle(/usr/bin/getent, getenv, database, key, NULL,
empty_env);
-execle(/bin/getent, getenv, database, key, NULL,
empty_env);
+execle(/usr/bin/getent, getent, database, key, NULL,
empty_env);
+execle(/bin/getent, getent, database, key, NULL,
empty_env);
_exit(EXIT_FAILURE);
}
--
1.9.rc1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nspawn: fix argv[0] for getent
On Tue, 11.03.14 18:00, Mantas Mikulėnas (graw...@gmail.com) wrote:
Applied! Thanks!
---
src/nspawn/nspawn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index cd31bd4..489dbde 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -2264,8 +2264,8 @@ static int spawn_getent(const char *database, const
char *key, pid_t *rpid) {
reset_all_signal_handlers();
close_all_fds(NULL, 0);
-execle(/usr/bin/getent, getenv, database, key, NULL,
empty_env);
-execle(/bin/getent, getenv, database, key, NULL,
empty_env);
+execle(/usr/bin/getent, getent, database, key, NULL,
empty_env);
+execle(/bin/getent, getent, database, key, NULL,
empty_env);
_exit(EXIT_FAILURE);
}
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartTransientService problems
On Wed, 05.03.14 09:55, Barry Scott (barry.sc...@onelan.co.uk) wrote: On Wed 05 Mar 2014 04:47:13 Lennart Poettering wrote: On Tue, 25.02.14 17:59, Barry Scott (barry.sc...@onelan.co.uk) wrote: Which should make them available via the bus for transient units. If you need other props like this, just let me know and I'll add them too... I just tried to set LimitCORE and that was rejected. Can you add this and the other related LimitXXX items please? Done, in git. Thanks. I did not find detailed docs on how to call StartTransientUnit() I have been reading the systemd sources to figure out the signatures of the call and its parameters. Did I miss API documentation? There's terse documentation on http://www.freedesktop.org/wiki/Software/systemd/dbus/ http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ While this describes the method call parameters roughly it doesn't describe the precise encoding within the properties array. We should add that of course. For now: it's mostly identical to how these things are exposed as bus properties on the objects, however there are exceptions... I would like to test these changes but I have failed to update a F20 system to newer code drops. Do you plan to have a F20 build of the newer systemd at least for testing? No. This will be available in Rawhide shortly however. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] bus: add sd_bus_emit_object_{added, removed}()
On Tue, 18.02.14 00:02, David Herrmann (dh.herrm...@gmail.com) wrote:
Sorry for the late review!
However, on object_removed() I cannot do that as node_vtable_get_userdata() is
very likely to return 0 for all these objects. So there is no way to figure
out which interfaces actually existed on that thing. We would require users to
call it *before* destroying/unlinking the actual object. I don't know whether
that's ok to assume?
I would assume that it is OK to assume that. People should call this
function before half-destroying their object. I mean we are not reading
the properties after all, just the interfaces and I think that should be
quite OK to require.
Certainly something to document though one day...
+static int object_added_append_all_prefix(
+sd_bus *bus,
+sd_bus_message *m,
+Set *s,
+const char *prefix,
+const char *path,
+bool require_fallback) {
+
+if (!streq_ptr(c-interface, previous_interface)) {
+/* interface already handled by a previous run? */
+if (set_get(s, c-interface))
+continue;
We actually allow multiple vtables with the same interface, and order
them together in the vtable list, so that we can iterate through them
easily with trivial duplicate reduction. Keeping a Set object here
appears unnecessary? Or did I miss something here?
Otherwise looks good!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] bus: add sd_bus_emit_object_{added, removed}()
Hi
On Tue, Mar 11, 2014 at 7:27 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 18.02.14 00:02, David Herrmann (dh.herrm...@gmail.com) wrote:
Sorry for the late review!
However, on object_removed() I cannot do that as node_vtable_get_userdata()
is
very likely to return 0 for all these objects. So there is no way to figure
out which interfaces actually existed on that thing. We would require users
to
call it *before* destroying/unlinking the actual object. I don't know whether
that's ok to assume?
I would assume that it is OK to assume that. People should call this
function before half-destroying their object. I mean we are not reading
the properties after all, just the interfaces and I think that should be
quite OK to require.
Certainly something to document though one day...
Yepp, will add docs once I commit it.
+static int object_added_append_all_prefix(
+sd_bus *bus,
+sd_bus_message *m,
+Set *s,
+const char *prefix,
+const char *path,
+bool require_fallback) {
+
+if (!streq_ptr(c-interface, previous_interface)) {
+/* interface already handled by a previous run? */
+if (set_get(s, c-interface))
+continue;
We actually allow multiple vtables with the same interface, and order
them together in the vtable list, so that we can iterate through them
easily with trivial duplicate reduction. Keeping a Set object here
appears unnecessary? Or did I miss something here?
A single call to object_added_append_all_prefix() doesn't need Set
*s as it's ordered (as you said). The problem is more subtle, see
object_added_append_all(), where I do this:
+r = object_added_append_all_prefix(bus, m, s, path, path, false);
+if (r 0)
+return r;
+if (bus-nodes_modified)
+return 0;
+
+prefix = alloca(strlen(path) + 1);
+OBJECT_PATH_FOREACH_PREFIX(prefix, path) {
+r = object_added_append_all_prefix(bus, m, s, prefix,
path, true);
+if (r 0)
+return r;
+if (bus-nodes_modified)
+return 0;
+}
First I call append_all_prefix() with the exact path, which cannot
ever fire the if (set_get()) protection, as it's the first run.
However, the prefix-runs which I do afterwards will traverse the
parents, which might *also* implement the interface. They use
require_fallback == true, so usually we're fine. However, if you
implement an interface explicitly on a child, but as fallback on the
parents, I _must_ avoid adding the interface twice. At least that's my
understanding of the vtable API, or should these be merged?
I looked at interfaces_added_append_one(), which skips parents if the
node already implements the interface. Therefore, I assumed I have to
skip parents, too. But I still need to traverse the parents, because
they might implement different interfaces that I haven't found, yet.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
Hi, From: systemd-devel-boun...@lists.freedesktop.org [systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Lennart Poettering [lenn...@poettering.net] Sent: Tuesday, March 04, 2014 2:38 PM To: Umut Tezduyar Cc: systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink On Tue, 04.03.14 12:00, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, Stable version of some distros (Debian Wheezy nor Ubuntu LTS 12.04) still don't have support for this. Is it not possible to solve it in another way. I'd be happy to merge a patch that adds an autoconf check for this and then falls back to absolute symlinks if the relative ones don't work. Is this something you would be interested: http://lists.openembedded.org/pipermail/openembedded-core/2014-March/090162.html Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir
Since we now use ln -s --relative, using this sed statement is redundant and causes broken symlinks to be installed. --- Makefile.am | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 182eca6..bd78f44 100644 --- a/Makefile.am +++ b/Makefile.am @@ -207,9 +207,8 @@ define move-to-rootlibdir if test $(libdir) != $(rootlibdir); then \ $(MKDIR_P) $(DESTDIR)$(rootlibdir) \ so_img_name=$$(readlink $(DESTDIR)$(libdir)/$$libname) \ - so_img_rel_target_prefix=$$(echo $(libdir) | sed 's,\(^/\|\)[^/][^/]*,..,g') \ rm -f $(DESTDIR)$(libdir)/$$libname \ - $(LN_S) --relative -f $$so_img_rel_target_prefix$(rootlibdir)/$$so_img_name $(DESTDIR)$(libdir)/$$libname \ + $(LN_S) --relative -f $(DESTDIR)$(rootlibdir)/$$so_img_name $(DESTDIR)$(libdir)/$$libname \ mv $(DESTDIR)$(libdir)/$$libname.* $(DESTDIR)$(rootlibdir); \ fi endef -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir
On Tue, Mar 11, 2014 at 6:14 PM, Mike Gilbert flop...@gentoo.org wrote: Since we now use ln -s --relative, using this sed statement is redundant and causes broken symlinks to be installed. Actually, I think the the symlinks are not broken under normal circumstances (rootlibdir = /lib). However, they end up with a duplicate prefix, like this: /usr/lib64/libsystemd.so - ../../../../lib64/libsystemd.so.0.0.2 This seems to trigger a quirk in Gentoo's package manger (Portage) when the symlink points outside of DESTDIR. Either way, this code should get cleaned up, and I would like to see it tagged as a bugfix if possible. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Tue, 11.03.14 22:04, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Is this something you would be interested: http://lists.openembedded.org/pipermail/openembedded-core/2014-March/090162.html Well, this is implemented in python, and we don't want a python dependency for the build system... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir
On Tue, 11.03.14 18:14, Mike Gilbert (flop...@gentoo.org) wrote: Since we now use ln -s --relative, using this sed statement is redundant and causes broken symlinks to be installed. Hmm, wouldn't it be nicer to just drop the --relative here? Quite honestly, I don't grok the code, neither the old nor the new one... --- Makefile.am | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index 182eca6..bd78f44 100644 --- a/Makefile.am +++ b/Makefile.am @@ -207,9 +207,8 @@ define move-to-rootlibdir if test $(libdir) != $(rootlibdir); then \ $(MKDIR_P) $(DESTDIR)$(rootlibdir) \ so_img_name=$$(readlink $(DESTDIR)$(libdir)/$$libname) \ - so_img_rel_target_prefix=$$(echo $(libdir) | sed 's,\(^/\|\)[^/][^/]*,..,g') \ rm -f $(DESTDIR)$(libdir)/$$libname \ - $(LN_S) --relative -f $$so_img_rel_target_prefix$(rootlibdir)/$$so_img_name $(DESTDIR)$(libdir)/$$libname \ + $(LN_S) --relative -f $(DESTDIR)$(rootlibdir)/$$so_img_name $(DESTDIR)$(libdir)/$$libname \ mv $(DESTDIR)$(libdir)/$$libname.* $(DESTDIR)$(rootlibdir); \ fi endef Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir
On Tue, Mar 11, 2014 at 6:42 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 11.03.14 18:14, Mike Gilbert (flop...@gentoo.org) wrote: Since we now use ln -s --relative, using this sed statement is redundant and causes broken symlinks to be installed. Hmm, wouldn't it be nicer to just drop the --relative here? Quite honestly, I don't grok the code, neither the old nor the new one... I'm having a hard time understanding the original code myself, but I think it is supposed to create a relative symlink without using ln --relative. It would probably break if rootlibdir is not a directory immediately under the root directory (/). I think the newer method is probably more robust, but obviously requires newer coreutils. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir
On Tue, Mar 11, 2014 at 6:53 PM, Mike Gilbert flop...@gentoo.org wrote: On Tue, Mar 11, 2014 at 6:42 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 11.03.14 18:14, Mike Gilbert (flop...@gentoo.org) wrote: Since we now use ln -s --relative, using this sed statement is redundant and causes broken symlinks to be installed. Hmm, wouldn't it be nicer to just drop the --relative here? Quite honestly, I don't grok the code, neither the old nor the new one... I'm having a hard time understanding the original code myself, but I think it is supposed to create a relative symlink without using ln --relative. It would probably break if rootlibdir is not a directory immediately under the root directory (/). Scratch that last sentence; it should work fine so long as rootlibdir begins with a slash. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir
On Tue, Mar 11, 2014 at 11:42 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 11.03.14 18:14, Mike Gilbert (flop...@gentoo.org) wrote: Since we now use ln -s --relative, using this sed statement is redundant and causes broken symlinks to be installed. Hmm, wouldn't it be nicer to just drop the --relative here? Quite honestly, I don't grok the code, neither the old nor the new one... The output of tree after the patch with the split-usr mode looks fine here. Applied it. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: Rewrite in_charset to use strspn
On Wed, Mar 12, 2014 at 12:49:08AM +0100, Lennart Poettering wrote: Can you turn this into an inline function please? If it's that simple it sounds better to just make it an inline function in the .h file, instead of the .c file... Sure. Mind if I do that as a two-patch series? I prefer to avoid simultaneously changing code and moving it, since it makes the change diff less obvious. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: Rewrite in_charset to use strspn
On Tue, 11.03.14 18:33, Josh Triplett (j...@joshtriplett.org) wrote: On Wed, Mar 12, 2014 at 12:49:08AM +0100, Lennart Poettering wrote: Can you turn this into an inline function please? If it's that simple it sounds better to just make it an inline function in the .h file, instead of the .c file... Sure. Mind if I do that as a two-patch series? I prefer to avoid simultaneously changing code and moving it, since it makes the change diff less obvious. Sure, I don't mind either way... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: Rewrite in_charset to use strspn
On Tue, 11.03.14 16:45, Josh Triplett (j...@joshtriplett.org) wrote:
Can you turn this into an inline function please? If it's that simple it
sounds better to just make it an inline function in the .h file, instead
of the .c file...
This simplifies in_charset down to a one-liner, and allows for possible
optimizations of strspn in libc.
---
src/shared/util.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index d28caae..82326df 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -921,16 +921,9 @@ char *delete_chars(char *s, const char *bad) {
}
bool in_charset(const char *s, const char* charset) {
-const char *i;
-
assert(s);
assert(charset);
-
-for (i = s; *i; i++)
-if (!strchr(charset, *i))
-return false;
-
-return true;
+return s[strspn(s, charset)] == '\0';
}
char *file_in_same_dir(const char *path, const char *filename) {
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: Make in_charset a static inline in util.h
With in_charset now reduced to a one-liner (plus asserts), make it a
static inline.
---
This applies on top of the previous patch simplifying in_charset.
src/shared/util.c | 6 --
src/shared/util.h | 6 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 82326df..9f79409 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -920,12 +920,6 @@ char *delete_chars(char *s, const char *bad) {
return s;
}
-bool in_charset(const char *s, const char* charset) {
-assert(s);
-assert(charset);
-return s[strspn(s, charset)] == '\0';
-}
-
char *file_in_same_dir(const char *path, const char *filename) {
char *e, *r;
size_t k;
diff --git a/src/shared/util.h b/src/shared/util.h
index c2bc977..0c8eb4b 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -529,7 +529,11 @@ char *strjoin(const char *x, ...) _sentinel_;
bool is_main_thread(void);
-bool in_charset(const char *s, const char* charset) _pure_;
+static inline bool _pure_ in_charset(const char *s, const char* charset) {
+assert(s);
+assert(charset);
+return s[strspn(s, charset)] == '\0';
+}
int block_get_whole_disk(dev_t d, dev_t *ret);
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 211
Heya! Many bugfixes, and a number of new features: http://www.freedesktop.org/software/systemd/systemd-211.tar.xz As before kdbus support requires --enable-kdbus on the configure command line. We now have a bit of kdbus policy support in place. Enough to see how it will look like in the end, but nothing you want to rely on yet. So, if you turn on kdbus you void your warranty (not that there was any warranty in the first place, so you just voided the warranty you never had...), and you lose all guarantees on API stability. So don't do this, unless you are curious and know what you are doing. At this point most of the instabilities we introduced with the massive 209 release should be fixed. That said, we try to keep up the pace and look forward to bring you the next release in two weeks or so, with even more bugfixes, more documentation and a couple of new features. Stay tuned! CHANGES WITH 211: * A new unit file setting RestrictAddressFamilies= has been added to restrict which socket address families unit processes gain access to. This takes address family names like AF_INET or AF_UNIX, and is useful to minimize the attack surface of services via exotic protocol stacks. This is built on seccomp system call filters. * Two new unit file settings RuntimeDirectory= and RuntimeDirectoryMode= have been added that may be used to manage a per-daemon runtime directories below /run. This is an alternative for setting up directory permissions with tmpfiles snippets, and has the advantage that the runtime directory's lifetime is bound to the daemon runtime and that the daemon starts up with an empty directory each time. This is particularly useful when writing services that drop priviliges using the User= or Group= setting. * The DeviceAllow= unit setting now supports globbing for matching against device group names. * The systemd configuration file system.conf gained new settings DefaultCPUAccounting=, DefaultBlockIOAccounting=, DefaultMemoryAccounting= to globally turn on/off accounting for specific resources (cgroups) for all units. These settings may still be overridden individually in each unit though. * systemd-gpt-auto-generator is now able to discover /srv and root partitions in addition to /home and swap partitions. It also supports LUKS-encrypted partitions now. With this in place automatic discovery of partitions to mount following the Discoverable Partitions Specification (http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec) is now a lot more complete. This allows booting without /etc/fstab and without root= on the kernel command line on appropriately prepared systems. * systemd-nspawn gained a new --image= switch which allows booting up disk images and Linux installations on any block device that follow the Discoverable Partitions Specification (see above). This means that installations made with appropriately updated installers may now be started and deployed using container managers, completely unmodified. (We hope that libvirt-lxc will add support for this feature soon, too.) * systemd-nspawn gained a new --network-macvlan= setting to set up a private macvlan interface for the container. Similar, systemd-networkd gained a new Kind=macvlan setting in .netdev files. * systemd-networkd now supports configuring local addresses using IPv4LL. * A new tool systemd-network-wait-online has been added to synchronously wait for network connectivity using systemd-networkd. * The sd-bus.h bus API gained a new sd_bus_track object for tracking the life-cycle of bus peers. Note that sd-bus.h is still not a public API though (unless you specify --enable-kdbus on the configure command line, which however voids your warranty and you get no API stability guarantee). * The $XDG_RUNTIME_DIR runtime directories for each user are now individual tmpfs instances, which has the benefit of introducing separate pools for each user, with individual size limits, and thus making sure that unprivileged clients can no longer negatively impact the system or other users by filling up their $XDG_RUNTIME_DIR. A new logind.conf setting RuntimeDirectorySize= has been introduced that allows controlling the default size limit for all users. It
[systemd-devel] [PATCH 1/2] backlight: Fix copy/paste error printing an unrelated error code
udev_device_get_sysattr_value returns NULL on failure, but doesn't
provide an error code; thus, when printing an error from it, don't print
an unrelated error code from a previous call.
---
src/backlight/backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 86f10cc..81470b3 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -322,7 +322,7 @@ int main(int argc, char *argv[]) {
value = udev_device_get_sysattr_value(device, brightness);
if (!value) {
-log_error(Failed to read system attribute: %s,
strerror(-r));
+log_error(Failed to read system attribute);
return EXIT_FAILURE;
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level
Some systems turn the backlight all the way off at the lowest levels.
Clamp saved brightness to at least 1 or 5% of max_brightness. This
avoids preserving an unreadably dim screen, which would otherwise force
the user to disable state restoration.
---
src/backlight/backlight.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 81470b3..b776ab5 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -292,6 +292,7 @@ int main(int argc, char *argv[]) {
if (streq(argv[1], load) shall_restore_state()) {
_cleanup_free_ char *value = NULL;
+const char *max_brightness_str;
if (!validate_device(udev, device))
return EXIT_SUCCESS;
@@ -306,6 +307,44 @@ int main(int argc, char *argv[]) {
return EXIT_FAILURE;
}
+/* Some systems turn the backlight all the way off at the
+ * lowest levels. Clamp saved brightness to at least 1 or 5%
+ * of max_brightness. This avoids preserving an unreadably dim
+ * screen, which would otherwise force the user to disable
+ * state restoration.
+ */
+max_brightness_str = udev_device_get_sysattr_value(device,
max_brightness);
+if (!max_brightness_str) {
+log_warning(Failed to read max_brightness attribute;
not checking saved brightness);
+} else {
+unsigned long long brightness, max_brightness,
new_brightness;
+
+r = safe_atollu(value, brightness);
+if (r 0) {
+log_error(Failed to parse brightness \%s\:
%s, value, strerror(-r));
+return EXIT_FAILURE;
+}
+
+r = safe_atollu(max_brightness_str, max_brightness);
+if (r 0) {
+log_error(Failed to parse max_brightness
\%s\: %s, max_brightness_str, strerror(-r));
+return EXIT_FAILURE;
+}
+
+new_brightness = MAX3(brightness, 1,
max_brightness/20);
+if (new_brightness != brightness) {
+_cleanup_free_ char *old_value = value;
+
+value = asprintf(%llu, new_brightness);
+if (!value) {
+log_oom();
+return EXIT_FAILURE;
+}
+
+log_warning(Saved brightness %s too low;
increasing to %s, old_value, value);
+}
+}
+
r = udev_device_set_sysattr_value(device, brightness, value);
if (r 0) {
log_error(Failed to write system attribute: %s,
strerror(-r));
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 211 journal getting created with different permissions
Hi all, With systemd 211, a new journal file is getting created with permissions of root:root instead of root:systemd-journal like previously (210 and prior). I looked at the git log and can't see anything obvious that would have caused this. Is this intentional? Or something on my end with my system's configuration? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] util: Rewrite in_charset to use strspn
This simplifies in_charset down to a one-liner, and allows for possible
optimizations of strspn in libc.
---
src/shared/util.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index d28caae..82326df 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -921,16 +921,9 @@ char *delete_chars(char *s, const char *bad) {
}
bool in_charset(const char *s, const char* charset) {
-const char *i;
-
assert(s);
assert(charset);
-
-for (i = s; *i; i++)
-if (!strchr(charset, *i))
-return false;
-
-return true;
+return s[strspn(s, charset)] == '\0';
}
char *file_in_same_dir(const char *path, const char *filename) {
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 211 journal getting created with different permissions
On Wed, Mar 12, 2014 at 3:46 AM, Greg KH gre...@linuxfoundation.org wrote: Hi all, With systemd 211, a new journal file is getting created with permissions of root:root instead of root:systemd-journal like previously (210 and prior). I looked at the git log and can't see anything obvious that would have caused this. Is this intentional? Or something on my end with my system's configuration? Normally the journal files just inherit the group of /var/log/journal, which has the setgid bit (and the correct group) set by /usr/lib/tmpfiles.d/systemd.conf. If you ran `make install`, however, it would chown /var/log/journal to 0:0 until the next time systemd-tmpfiles ran. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level
On Tue, 11.03.14 18:55, Josh Triplett (j...@joshtriplett.org) wrote:
+/* Some systems turn the backlight all the way off at the
+ * lowest levels. Clamp saved brightness to at least 1 or 5%
+ * of max_brightness. This avoids preserving an unreadably
dim
+ * screen, which would otherwise force the user to disable
+ * state restoration.
+ */
+max_brightness_str = udev_device_get_sysattr_value(device,
max_brightness);
+if (!max_brightness_str) {
+log_warning(Failed to read max_brightness
attribute; not checking saved brightness);
+} else {
We try to avoid unnnecessary {} for single-line if blocks, if we can...
Hmmm, could you maybe move the entire clamping thing into a function of
its own? Maybe clamp_brightness(struct udev_device *d, char
**brightness) or so, that simply patches the brightness string if it
feels like it, otherwise leaves it unmodified?
+unsigned long long brightness,
max_brightness, new_brightness;
Wow, you expect a lot of brightness levels! ;-)
I'd just stick to unsigned here... Keeps it more readable...
+
+r = safe_atollu(value, brightness);
+if (r 0) {
+log_error(Failed to parse brightness
\%s\: %s, value, strerror(-r));
+return EXIT_FAILURE;
+}
+
+r = safe_atollu(max_brightness_str, max_brightness);
+if (r 0) {
+log_error(Failed to parse max_brightness
\%s\: %s, max_brightness_str, strerror(-r));
+return EXIT_FAILURE;
+}
Hmm, I'd prefer if the whole clamping business would be
non-fatal. i.e. it clamps if it can read the files and parse them, but
if it can't it won't do anything...
+
+new_brightness = MAX3(brightness, 1,
max_brightness/20);
+if (new_brightness != brightness) {
+_cleanup_free_ char *old_value = value;
+
+value = asprintf(%llu,
new_brightness);
asprintf() works differently... r = asprintf(value, %llu, new_brightness)...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 211 journal getting created with different permissions
On Wed, Mar 12, 2014 at 04:21:55AM +0200, Mantas Mikulėnas wrote: On Wed, Mar 12, 2014 at 3:46 AM, Greg KH gre...@linuxfoundation.org wrote: Hi all, With systemd 211, a new journal file is getting created with permissions of root:root instead of root:systemd-journal like previously (210 and prior). I looked at the git log and can't see anything obvious that would have caused this. Is this intentional? Or something on my end with my system's configuration? Normally the journal files just inherit the group of /var/log/journal, which has the setgid bit (and the correct group) set by /usr/lib/tmpfiles.d/systemd.conf. I thought so, and this worked on 210, and the permissions of /var/log/journal/ is correct: drwxr-sr-x 2 root systemd-journal 4096 Mar 12 01:36 0da484f8dee497fee9585ba9531fb7f1 If you ran `make install`, however, it would chown /var/log/journal to 0:0 until the next time systemd-tmpfiles ran. This gets created by the ebuild (this is on CoreOs), and the 210 ebuild worked, so what is different here? confused, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level
On Wed, Mar 12, 2014 at 03:32:47AM +0100, Lennart Poettering wrote:
On Tue, 11.03.14 18:55, Josh Triplett (j...@joshtriplett.org) wrote:
+/* Some systems turn the backlight all the way off at the
+ * lowest levels. Clamp saved brightness to at least 1 or
5%
+ * of max_brightness. This avoids preserving an
unreadably dim
+ * screen, which would otherwise force the user to disable
+ * state restoration.
+ */
+max_brightness_str = udev_device_get_sysattr_value(device,
max_brightness);
+if (!max_brightness_str) {
+log_warning(Failed to read max_brightness
attribute; not checking saved brightness);
+} else {
We try to avoid unnnecessary {} for single-line if blocks, if we can...
Even when the else block *does* need the braces? (Note that kernel
style says to avoid braces on single-line blocks but always use braces
on all branches of an if/else-if/else if any branch needs them.)
Hmmm, could you maybe move the entire clamping thing into a function of
its own? Maybe clamp_brightness(struct udev_device *d, char
**brightness) or so, that simply patches the brightness string if it
feels like it, otherwise leaves it unmodified?
Sure.
+unsigned long long brightness,
max_brightness, new_brightness;
Wow, you expect a lot of brightness levels! ;-)
I'd just stick to unsigned here... Keeps it more readable...
It's just two words (long long) and a couple of lls later, but OK.
+
+r = safe_atollu(value, brightness);
+if (r 0) {
+log_error(Failed to parse brightness
\%s\: %s, value, strerror(-r));
+return EXIT_FAILURE;
+}
+
+r = safe_atollu(max_brightness_str,
max_brightness);
+if (r 0) {
+log_error(Failed to parse max_brightness
\%s\: %s, max_brightness_str, strerror(-r));
+return EXIT_FAILURE;
+}
Hmm, I'd prefer if the whole clamping business would be
non-fatal. i.e. it clamps if it can read the files and parse them, but
if it can't it won't do anything...
I thought about that, but it would have complicated the logic, and those
kernel files should always be numbers anyway. However, with a move to a
separate function, this gets easier with early return, so sure.
+new_brightness = MAX3(brightness, 1,
max_brightness/20);
+if (new_brightness != brightness) {
+_cleanup_free_ char *old_value = value;
+
+value = asprintf(%llu,
new_brightness);
asprintf() works differently... r = asprintf(value, %llu,
new_brightness)...
Gah, I fixed that and then managed to send the wrong patch, sorry.
- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2 1/2] backlight: Fix copy/paste error printing an unrelated error code
udev_device_get_sysattr_value returns NULL on failure, but doesn't
provide an error code; thus, when printing an error from it, don't print
an unrelated error code from a previous call.
---
v2: Patch 1/2 unchanged from v1.
src/backlight/backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 86f10cc..81470b3 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -322,7 +322,7 @@ int main(int argc, char *argv[]) {
value = udev_device_get_sysattr_value(device, brightness);
if (!value) {
-log_error(Failed to read system attribute: %s,
strerror(-r));
+log_error(Failed to read system attribute);
return EXIT_FAILURE;
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level
Some systems turn the backlight all the way off at the lowest levels.
Clamp saved brightness to at least 1 or 5% of max_brightness. This
avoids preserving an unreadably dim screen, which would otherwise force
the user to disable state restoration.
---
v2: Send the right patch this time. Factor clamping into a separate
function. Make failures in clamping non-fatal. Use unsigned rather
than unsigned long long.
src/backlight/backlight.c | 44
1 file changed, 44 insertions(+)
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 81470b3..44308e0 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -192,6 +192,48 @@ static bool validate_device(struct udev *udev, struct
udev_device *device) {
return true;
}
+/* Some systems turn the backlight all the way off at the lowest levels.
+ * clamp_brightness clamps the saved brightness to at least 1 or 5% of
+ * max_brightness. This avoids preserving an unreadably dim screen, which
+ * would otherwise force the user to disable state restoration. */
+static void clamp_brightness(struct udev_device *device, char **value) {
+int r;
+const char *max_brightness_str;
+unsigned brightness, max_brightness, new_brightness;
+
+max_brightness_str = udev_device_get_sysattr_value(device,
max_brightness);
+if (!max_brightness_str) {
+log_warning(Failed to read max_brightness attribute; not
checking saved brightness);
+return;
+}
+
+r = safe_atou(*value, brightness);
+if (r 0) {
+log_warning(Failed to parse brightness \%s\: %s, *value,
strerror(-r));
+return;
+}
+
+r = safe_atou(max_brightness_str, max_brightness);
+if (r 0) {
+log_warning(Failed to parse max_brightness \%s\: %s,
max_brightness_str, strerror(-r));
+return;
+}
+
+new_brightness = MAX3(brightness, 1U, max_brightness/20);
+if (new_brightness != brightness) {
+char *old_value = *value;
+
+r = asprintf(value, %u, new_brightness);
+if (r 0) {
+log_warning(Failed to format new brightness: %s,
strerror(-r));
+return;
+}
+
+log_warning(Saved brightness %s too low; increasing to %s,
old_value, *value);
+free(old_value);
+}
+}
+
int main(int argc, char *argv[]) {
_cleanup_udev_unref_ struct udev *udev = NULL;
_cleanup_udev_device_unref_ struct udev_device *device = NULL;
@@ -306,6 +348,8 @@ int main(int argc, char *argv[]) {
return EXIT_FAILURE;
}
+clamp_brightness(device, value);
+
r = udev_device_set_sysattr_value(device, brightness, value);
if (r 0) {
log_error(Failed to write system attribute: %s,
strerror(-r));
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 211 journal getting created with different permissions
On Tue, Mar 11, 2014 at 08:38:58PM -0700, Greg KH wrote: On Wed, Mar 12, 2014 at 04:21:55AM +0200, Mantas Mikulėnas wrote: On Wed, Mar 12, 2014 at 3:46 AM, Greg KH gre...@linuxfoundation.org wrote: Hi all, With systemd 211, a new journal file is getting created with permissions of root:root instead of root:systemd-journal like previously (210 and prior). I looked at the git log and can't see anything obvious that would have caused this. Is this intentional? Or something on my end with my system's configuration? Normally the journal files just inherit the group of /var/log/journal, which has the setgid bit (and the correct group) set by /usr/lib/tmpfiles.d/systemd.conf. I thought so, and this worked on 210, and the permissions of /var/log/journal/ is correct: drwxr-sr-x 2 root systemd-journal 4096 Mar 12 01:36 0da484f8dee497fee9585ba9531fb7f1 If you ran `make install`, however, it would chown /var/log/journal to 0:0 until the next time systemd-tmpfiles ran. This gets created by the ebuild (this is on CoreOs), and the 210 ebuild worked, so what is different here? Apologies, I can now reproduce this on systemd 210, so this isn't a 211 issue from what I can tell just yet, sorry for the noise. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd 211 journal getting created with different permissions
On Tue, Mar 11, 2014 at 09:41:50PM -0700, Greg KH wrote: On Tue, Mar 11, 2014 at 08:38:58PM -0700, Greg KH wrote: On Wed, Mar 12, 2014 at 04:21:55AM +0200, Mantas Mikulėnas wrote: On Wed, Mar 12, 2014 at 3:46 AM, Greg KH gre...@linuxfoundation.org wrote: Hi all, With systemd 211, a new journal file is getting created with permissions of root:root instead of root:systemd-journal like previously (210 and prior). I looked at the git log and can't see anything obvious that would have caused this. Is this intentional? Or something on my end with my system's configuration? Normally the journal files just inherit the group of /var/log/journal, which has the setgid bit (and the correct group) set by /usr/lib/tmpfiles.d/systemd.conf. I thought so, and this worked on 210, and the permissions of /var/log/journal/ is correct: drwxr-sr-x 2 root systemd-journal 4096 Mar 12 01:36 0da484f8dee497fee9585ba9531fb7f1 If you ran `make install`, however, it would chown /var/log/journal to 0:0 until the next time systemd-tmpfiles ran. This gets created by the ebuild (this is on CoreOs), and the 210 ebuild worked, so what is different here? Apologies, I can now reproduce this on systemd 210, so this isn't a 211 issue from what I can tell just yet, sorry for the noise. In looking at this further, the /usr/lib/tmpfiles.d/systemd.conf will not change the permissions on the journald file, only the directory: m /var/log/journal 2755 root systemd-journal - - m /var/log/journal/%m 2755 root systemd-journal - - m /run/log/journal 2755 root systemd-journal - - m /run/log/journal/%m 2755 root systemd-journal - - So what is supposed to set the permissions on the journal file(s) that live in /var/log/journal/%m/ ? Let me do a build with 207 and see how that handles this issue... thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
