Re: [systemd-devel] [210] logind bypasses polkit? bug or new feature?

[Djalal Harouni]

On Sun, Mar 09, 2014 at 08:00:22PM -0300, Gerardo Exequiel Pozzi wrote:
> Hello
> 
> To do tests I made a new Arch Linux (x86_64) base installation running
> in qemu/kvm with systemd-210-3 and polkit-0.112-1 to discard any weird
> thing on my system.
> 
> I can reboot/poweroff/suspend/hibernate the system with a normal user
> logged from a local VT or remote SSH does not care. I can not disable
> this even with a set of polkit rules.
> I am sure that this works fine before (maybe systemd-204 age?)
Yes! I did notice that, normally it should return 'challenge' ?!

I was working on a fix for hostnamed and then noticed logind. Currently
I'm not sure if it is the correct fix! some methodes are accessible...


> The weird thing here, is that If I ask to login1 about "Can*" methods it
> returns 'no'. Also system can be rebooted or poweroff if other users are
> logged on the system (i.e root on tty1).
I confirm this, I'm attaching a patch that will just disable this, but
I'm not sure about the inhibitor logic here did not have time to test
it.

-- 
Djalal Harouni
http://opendz.org
From: Djalal Harouni 
Subject: [PATCH] logind: remove the SD_BUS_VTABLE_UNPRIVILEGED flag from 
sensitive methods

This patch removes the SD_BUS_VTABLE_UNPRIVILEGED flag. The flag was
preventing check_access() from doing the capability check.
---
 src/login/logind-dbus.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index c9c58f3..31a09df 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -1887,14 +1887,14 @@ const sd_bus_vtable manager_vtable[] = {
 SD_BUS_METHOD("TerminateSession", "s", NULL, method_terminate_session, 
SD_BUS_VTABLE_CAPABILITY(CAP_KILL)),
 SD_BUS_METHOD("TerminateUser", "u", NULL, method_terminate_user, 
SD_BUS_VTABLE_CAPABILITY(CAP_KILL)),
 SD_BUS_METHOD("TerminateSeat", "s", NULL, method_terminate_seat, 
SD_BUS_VTABLE_CAPABILITY(CAP_KILL)),
-SD_BUS_METHOD("SetUserLinger", "ubb", NULL, method_set_user_linger, 
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD("AttachDevice", "ssb", NULL, method_attach_device, 
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD("FlushDevices", "b", NULL, method_flush_devices, 
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD("PowerOff", "b", NULL, method_poweroff, 
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD("Reboot", "b", NULL, method_reboot, 
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD("Suspend", "b", NULL, method_suspend, 
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD("Hibernate", "b", NULL, method_hibernate, 
SD_BUS_VTABLE_UNPRIVILEGED),
-SD_BUS_METHOD("HybridSleep", "b", NULL, method_hybrid_sleep, 
SD_BUS_VTABLE_UNPRIVILEGED),
+SD_BUS_METHOD("SetUserLinger", "ubb", NULL, method_set_user_linger, 0),
+SD_BUS_METHOD("AttachDevice", "ssb", NULL, method_attach_device, 0),
+SD_BUS_METHOD("FlushDevices", "b", NULL, method_flush_devices, 0),
+SD_BUS_METHOD("PowerOff", "b", NULL, method_poweroff, 0),
+SD_BUS_METHOD("Reboot", "b", NULL, method_reboot, 0),
+SD_BUS_METHOD("Suspend", "b", NULL, method_suspend, 0),
+SD_BUS_METHOD("Hibernate", "b", NULL, method_hibernate, 0),
+SD_BUS_METHOD("HybridSleep", "b", NULL, method_hybrid_sleep, 0),
 SD_BUS_METHOD("CanPowerOff", NULL, "s", method_can_poweroff, 
SD_BUS_VTABLE_UNPRIVILEGED),
 SD_BUS_METHOD("CanReboot", NULL, "s", method_can_reboot, 
SD_BUS_VTABLE_UNPRIVILEGED),
 SD_BUS_METHOD("CanSuspend", NULL, "s", method_can_suspend, 
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

Re: [systemd-devel] [PATCH] core: add default extra dependency option

[WaLyong Cho]

On 03/03/2014 11:43 PM, Lennart Poettering wrote:
> On Mon, 03.03.14 11:52, WaLyong Cho (walyong@samsung.com) wrote:
> 
>>> But if you do this on an embedded system you can do
>>> DefaultDependencies=no for all services where you want this and place
>>> them manually?
>>>
>> Almost I can. Actually I can request to the package manager in our
>> system. But, I don't want to put DefaultDependencies=no to all of
>> services. Then all of services should consider which mount, socket, path
>> and more units are needed to launch itself. I don't want this. I just
>> wants they launch after basic.target and some of special services what
>> should be per-processed before than others to optimize boot speed
>> extremely. (Those pre-processed services will be listed in config with
>> DefaultExtraDependencies=)
>>>
>>> Also, are you sure that you really want to solve this with manual deps?
>>> I mean, the kernel already has a CPU scheduler and an IO
>>> scheduler. Maybe it would be better to simply dump all the scheduling
>>> work on the kernel as far as that is possible, start everything in
>>> parallel, but then also tell the kernel what matters more, and what
>>> matters less.
>>>
>>> We already expose CPUShares= and BlockIOWeight= for services. Maybe we
>>> should duplicate these as StartupCPUShares= and StartupBlockIOWeight=
>>> which could set different values to apply only while the boot process is
>>> not complete yet. Or something like that. 
>>>
>>> Lennart
>>>
>> Parallel is good and by this, systemd is very flexible to suit our
>> product. But I(our product) want to some of services occupy most of
>> system resources at the head of boot sequence. (don't confuse that will
>> after basic.target) Some more detail, we play some of animation during
>> boot and we call that boot-animation(similar with splash animation).
>> During that time, we launch essential services and idle screen with this
>> functionality. At this time, we don't want any other services are using
>> system resources.
>>
>> StartupCPUShares= and StartupBlockIOWeight= maybe good idea. But should
>> be considered it really OK, lower or higher CPUShares and BlockIOWeight
>> during whole boot time.
> 
> Yes, precisely, that is what I want StartupCPUShares= to be: an
> alternative to CPUShares= that is applied only while the system is
> booting up.
> 
> A service with this configuration:
> 
> CPUShares=1024
> StartupCPUShares=10
> 
> Would be scheduled at a very low priority during startup, but as soon as
> startup is complete would be bumped to normal levels.
> 
> Lennart
> 

I sent new patch with new subject "core: add startup resource control
option".

Thank you,
WaLyong
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

[Michael Olbrich]

On Sun, Mar 09, 2014 at 08:49:58PM +0100, Michael Biebl wrote:
> 2014-03-08 8:52 GMT+01:00 Samuli Suominen :
> > If eg. setcap is in /sbin and user is building as a normal user without
> > $PATH having /sbin, the build system
> > will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
> > fail during the build with 'setcap: command not found'
> >
> > For example, my $PATH as normal user:
> >
> > $ echo $PATH
> > /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2
> >
> > I see Debian and Ubuntu carries a patch that changes these hardcoded
> > paths to what they have, but that's equally
> > unwise.
> 
> We do patch those defaults so we don't have to actually build-depend
> on all those packages.
> Your patch doesn't really help with that.

You don't need a patch for that. Just set the corresponding configure cache
value:
export ac_cv_path_QUOTAON=/sbin/quotaon
[...]
./configure ...

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

[Samuli Suominen]

On 10/03/14 13:23, Michael Olbrich wrote:
> On Sun, Mar 09, 2014 at 08:49:58PM +0100, Michael Biebl wrote:
>> 2014-03-08 8:52 GMT+01:00 Samuli Suominen :
>>> If eg. setcap is in /sbin and user is building as a normal user without
>>> $PATH having /sbin, the build system
>>> will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
>>> fail during the build with 'setcap: command not found'
>>>
>>> For example, my $PATH as normal user:
>>>
>>> $ echo $PATH
>>> /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2
>>>
>>> I see Debian and Ubuntu carries a patch that changes these hardcoded
>>> paths to what they have, but that's equally
>>> unwise.
>> We do patch those defaults so we don't have to actually build-depend
>> on all those packages.
>> Your patch doesn't really help with that.
> You don't need a patch for that. Just set the corresponding configure cache
> value:
> export ac_cv_path_QUOTAON=/sbin/quotaon
> [...]
> ./configure ...
>
>

I'm aware of the possibility for exporting ac_cv_ values (those that are
present in eg. config.log after ./configure)

But the problem for what the patch was submitted remains, when setcap
is in /sbin/setcap instead of /usr/sbin/setcap, and the build system lacks
the capability of checking sbin directories, it will set it to wrong value,
and then try to *use it* during the build:
Makefile.am:-$(SETCAP) cap_dac_override,cap_sys_ptrace=ep
$(DESTDIR)$(bindir)/systemd-detect-virt
resulting in a 'command not found' message, however because it's
prefixed with -
it's non-fatal, but that's how you miss it to begin with.

Why not search sbin directories, if the patch is this easy?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 1/2] zsh completion: Install _sd_machines with _machinectl

[Wieland Hoffmann]

_machinectl uses _sd_machines to provide a list of all available
machines.
---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 2db58a9..2775c99 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4030,7 +4030,8 @@ dist_dbuspolicy_DATA += \
src/machine/org.freedesktop.machine1.conf
 
 dist_zshcompletion_DATA += \
-   shell-completion/zsh/_machinectl
+   shell-completion/zsh/_machinectl \
+   shell-completion/zsh/_sd_machines
 
 SYSTEM_UNIT_ALIASES += \
systemd-machined.service dbus-org.freedesktop.machine1.service
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Fix machinectls machine completion

[Wieland Hoffmann]

Hi,

the following two patches fix machinectls machine name completion by
actually installing the required _sd_machines file using machinectls
--no-legend switch to prevent bogus entries from appearing in the list
of machines.

-- 
Wieland

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 2/2] _sd_machines: Use machinectl --no-legend

[Wieland Hoffmann]

Otherwise bogus entries from the header and footer would show up in the
completion list.
---
 shell-completion/zsh/_sd_machines | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/shell-completion/zsh/_sd_machines 
b/shell-completion/zsh/_sd_machines
index 1d64d13..a0039ee 100644
--- a/shell-completion/zsh/_sd_machines
+++ b/shell-completion/zsh/_sd_machines
@@ -1,6 +1,6 @@
 #autoload
 __get_machines () {
-machinectl --full --no-pager list | {while read -r a b; do echo $a; 
done;};
+machinectl --full --no-legend --no-pager list |  {while read -r a b; 
do echo $a; done;};
 }
 
 local -a _machines
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] service: don't create extra cgroup for control process when reloading SysV service

[Lukas Nykryn]

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.
---
 src/core/service.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/core/service.c b/src/core/service.c
index 121ddec..16d7ae0 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -2272,7 +2272,15 @@ static void service_enter_reload(Service *s) {
   !s->root_directory_start_only,
   false,
   false,
+#ifdef HAVE_SYSV_COMPAT
+  /* Don't create extra cgroup for SysV 
services.
+   * Unfortunately common practice was to have 
reload as an alias
+   * for restart and we are killing the new 
main process, when destroying
+   * cgroup for the control process*/
+  !s->is_sysv,
+#else
   true,
+#endif
   &s->control_pid);
 if (r < 0)
 goto fail;
@@ -3082,7 +3090,10 @@ static void service_sigchld_event(Unit *u, pid_t pid, 
int code, int status) {
 /* Immediately get rid of the cgroup, so that the
  * kernel doesn't delay the cgroup empty messages for
  * the service cgroup any longer than necessary */
-service_kill_control_processes(s);
+#ifdef HAVE_SYSV_COMPAT
+if (!s->is_sysv)
+#endif
+service_kill_control_processes(s);
 
 if (s->control_command &&
 s->control_command->command_next &&
-- 
1.8.5.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] device state UNKNOWN

[arnaud gaboury]

Hi,

No idea why my bridge device, br0, has a state unknown.

$ ip addr
3: br0:  mtu 1500 qdisc noqueue state
UNKNOWN group default
link/ether 66:73:a3:0a:44:f9 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.94/24 brd 192.168.1.255 scope global br0
   valid_lft forever preferred_lft forever
inet6 fe80::6473:a3ff:fe0a:44f9/64 scope link
   valid_lft forever preferred_lft forever

$ systemctl status systemd-networkd
Mar 10 14:32:25 hortensia systemd-networkd[335]: Failed to save link
data /run/systemd/network/links/3: No such file or directory
Mar 10 14:32:25 hortensia systemd-networkd[335]: br0: netdev ready
Mar 10 14:32:25 hortensia systemd-networkd[335]: br0: link is up
Mar 10 14:32:25 hortensia systemd-networkd[335]: br0: carrier on
Mar 10 14:32:25 hortensia systemd-networkd[335]: br0: link configured
Mar 10 14:32:25 hortensia systemd[1]: Started Network Service.

$ ls -al /run/systemd/network/links
drwxr-xr-x 2 root root 60 Mar 10 14:32 ./
drwxr-xr-x 3 root root 80 Mar 10 14:32 ../
-rw-r--r-- 1 root root 55 Mar 10 14:32 3

$ cat /run/systemd/network/links/3
# This is private data. Do not parse.
STATE=configured

**
$ cat /etc/systemd/network/bridge.link
[Match]
Name=br0

[Link]
NamePolicy=database onboard slot path
MACAddressPolicy=persistent

$ cat /etc/systemd/network/bridge.netdev
[Match]
Host=hortensia

[NetDev]
Name=br0
Kind=bridge

$ cat /etc/systemd/network/30-bridge.network
[Match]
Name=br0

[Network]
Description="bridge connection"
DHCP=no
Address=192.168.1.87/24
Gateway=192.168.1.254
DNS=192.168.1.254

**

It seems to me that this device is configured, so why is its state
unknown  and not UP ? Shall I use a netctl profile to bring it UP,
like I do for enp7s0 ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

[Michael Olbrich]

On Mon, Mar 10, 2014 at 02:13:38PM +0200, Samuli Suominen wrote:
> On 10/03/14 13:23, Michael Olbrich wrote:
> > On Sun, Mar 09, 2014 at 08:49:58PM +0100, Michael Biebl wrote:
> >> 2014-03-08 8:52 GMT+01:00 Samuli Suominen :
> >>> If eg. setcap is in /sbin and user is building as a normal user without
> >>> $PATH having /sbin, the build system
> >>> will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
> >>> fail during the build with 'setcap: command not found'
> >>>
> >>> For example, my $PATH as normal user:
> >>>
> >>> $ echo $PATH
> >>> /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2
> >>>
> >>> I see Debian and Ubuntu carries a patch that changes these hardcoded
> >>> paths to what they have, but that's equally
> >>> unwise.
> >> We do patch those defaults so we don't have to actually build-depend
> >> on all those packages.
> >> Your patch doesn't really help with that.
> > You don't need a patch for that. Just set the corresponding configure cache
> > value:
> > export ac_cv_path_QUOTAON=/sbin/quotaon
> > [...]
> > ./configure ...
> >
> >
> 
> I'm aware of the possibility for exporting ac_cv_ values (those that are
> present in eg. config.log after ./configure)
> 
> But the problem for what the patch was submitted remains, when setcap
> is in /sbin/setcap instead of /usr/sbin/setcap, and the build system lacks
> the capability of checking sbin directories, it will set it to wrong value,
> and then try to *use it* during the build:
> Makefile.am:-$(SETCAP) cap_dac_override,cap_sys_ptrace=ep
> $(DESTDIR)$(bindir)/systemd-detect-virt
> resulting in a 'command not found' message, however because it's
> prefixed with -
> it's non-fatal, but that's how you miss it to begin with.
> 
> Why not search sbin directories, if the patch is this easy?

I was talking about the Debian patch, not your patch.

Regards.

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] synchronizing user service

[Colin Guthrie]

'Twas brillig, and Alec Leamas at 07/03/14 19:45 did gyre and gimble:
> Sorry for not being clear. The priob
> 
> On 3/7/14, Lennart Poettering  wrote:
>> On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote:
>>
>>> Dear list,
>>>
>>> Being a systemd dummie, I have a problem. It's a about running a
>>> service as a user, which needs to synchronize with a systemd service.
>>
>> What do you mean by "synchronize"?
>>
>>> Since the service needs to be part of the session, I presume that a
>>> /systemd/user service isn't really the way to go (?): This leaves me
>>> with the problem to start a service e. .g,, using a desktop file in
>>> the autostart dir. The service needs a socket created by a systemd
>>> service.
>>
>> You can simply order your system service before
>> systemd-user-sessions.service. All user sessions are only started after
>> that, hence ordering your service before that makes sure for users it is
>> always accesssible.
>>
>>> As of now, I simply poll for the socket creation in a shell script.
>>> It's just that my gut feeling is that this is not  really the way to
>>> do this. Is there a better approach?
>>
>> Well, you can make it socket activated, but otherwise just order it like
>> suggested above...
> 
> Sorry for not being clear...
> 
> I can't make it socket activated, nor can I order it. My user service
> is *not* a systemd service since it needs to be part  of the session.
> As of now, it's started as a desktop service using a desktop file.
> 
> So the question is: is there any "good" way for a non-systemd user
> service to to things that systemd services does, like waiting on a
> socket or somehow become part  of the ordering scheme?

So I guess one question is, do you have a "systemd --user" instance
running? Typically this happens automatically via PAM with most
reasonably recent systemds.

So you *could* write a user systemd unit (or combo of units -
socket+service) that would start your service. This might or might not
really help tho' as whatever consumes your service would still need to
block/wait I guess (even if it was socket activated in the user session
I'm not sure you currently have any guarantees that non-systemd stuff is
started after systemd stuff - would need a full conversion to
systemd-based user sessions for that). You could use "systemctl --user
is-active foo.socket" to do the polling which might or might not seem
nicer to you.


Another option which may work if you have a simple setup and control
over the machine, is to write a *system* service but put User=+Group=
directives in it to start as your user+group. You can order that before
systemd-user-sessions.service and that will allow you to login confident
that your service will already have started. This falls down quite
royally when you have multiple users tho'!

Hope that helps a bit.

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

Re: [systemd-devel] [210] logind bypasses polkit? bug or new feature?

[Gerardo Exequiel Pozzi]

On 03/10/2014 06:48 AM, Djalal Harouni wrote:
> On Sun, Mar 09, 2014 at 08:00:22PM -0300, Gerardo Exequiel Pozzi wrote:
>> Hello
>>
>> To do tests I made a new Arch Linux (x86_64) base installation running
>> in qemu/kvm with systemd-210-3 and polkit-0.112-1 to discard any weird
>> thing on my system.
>>
>> I can reboot/poweroff/suspend/hibernate the system with a normal user
>> logged from a local VT or remote SSH does not care. I can not disable
>> this even with a set of polkit rules.
>> I am sure that this works fine before (maybe systemd-204 age?)
> Yes! I did notice that, normally it should return 'challenge' ?!

Yes. Except if you change it as I did to "NO" per custom rule.

Thanks.


-- 
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1



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] systemd.netdev & kind=sit

[Anthony Messina]

On Monday, March 10, 2014 09:11:05 AM you wrote:
> On 10 Mar 2014 02:08, "Anthony Messina"  wrote:
> > I've been watching the development and looking forward to testing out the
> > systemd-networkd features that are coming out.
> > 
> > One of the things I haven't seen yet is the ability to configure a SIT
> > device via systemd.netdev for IPv6 in IPv4 tunneling, for example with
> > he.net/tunnelbroker.net.
> > 
> > Unfortunately, many ISPs (including my own) don't yet provide any usable
> > native IPv6 connectivity and I'll be bound to tunneling for a while.
> > 
> > I am just wondering if "kind=sit" is in the future for systemd.netdev?
> 
> Yes, we are likely to support sit. However, I'm not aware of anyone working
> on it, so don't know when.
> 
> Cheers,
> 
> Tom

Thanks for the info Tom.

Have a good day.  -A

-- 
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E


signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [210] logind bypasses polkit? bug or new feature?

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 10, 2014 at 11:41:52AM -0300, Gerardo Exequiel Pozzi wrote:
> On 03/10/2014 06:48 AM, Djalal Harouni wrote:
> > On Sun, Mar 09, 2014 at 08:00:22PM -0300, Gerardo Exequiel Pozzi wrote:
> >> Hello
> >>
> >> To do tests I made a new Arch Linux (x86_64) base installation running
> >> in qemu/kvm with systemd-210-3 and polkit-0.112-1 to discard any weird
> >> thing on my system.
> >>
> >> I can reboot/poweroff/suspend/hibernate the system with a normal user
> >> logged from a local VT or remote SSH does not care. I can not disable
> >> this even with a set of polkit rules.
> >> I am sure that this works fine before (maybe systemd-204 age?)
> > Yes! I did notice that, normally it should return 'challenge' ?!
> 
> Yes. Except if you change it as I did to "NO" per custom rule.

Could you check if current git behaves as expected?

Zbyszek

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer

[Lennart Poettering]

On Sat, 08.03.14 20:33, Josh Triplett (j...@joshtriplett.org) wrote:

> avoid_cleanup also returns a copy of the pointer, making it convenient
> to use at the point where initialization completes, to hand the constructed
> object off somewhere without freeing it.
> 
> Change all NULL assignments tagged with /* avoid cleanup */ to use this
> instead.
> ---
> 
> Seems like a common pattern, and this makes it more self-documenting.
> In particular, the use in systemctl.c's list_timers function now feels
> like a single logical operation of "hand ownership of this object off to
> something else and don't clean it up".

Hmmm, I am all for synctactic sugar, but I don't see the benefit of this
one really... Especially given that that disabling cleanup is done
different for different types... For example, disabling cleanup for an
fd is by assigning -1...

I would see benefit in this if we could maybe make this
type-sensitive... not sure though if C would allow that? I at least
cannot think of a way to do that?

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] synchronizing user service

[Alec Leamas]

On 3/10/14, Colin Guthrie  wrote:
> 'Twas brillig, and Alec Leamas at 07/03/14 19:45 did gyre and gimble:
>> Sorry for not being clear. The priob
>>
>> On 3/7/14, Lennart Poettering  wrote:
>>> On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote:
>>>
 Dear list,

 Being a systemd dummie, I have a problem. It's a about running a
 service as a user, which needs to synchronize with a systemd service.
>>>
>>> What do you mean by "synchronize"?
>>>
 Since the service needs to be part of the session, I presume that a
 /systemd/user service isn't really the way to go (?): This leaves me
 with the problem to start a service e. .g,, using a desktop file in
 the autostart dir. The service needs a socket created by a systemd
 service.

[cut]
>> I can't make it socket activated, nor can I order it. My user service
>> is *not* a systemd service since it needs to be part  of the session.
>> As of now, it's started as a desktop service using a desktop file.
>>
>> So the question is: is there any "good" way for a non-systemd user
>> service to to things that systemd services does, like waiting on a
>> socket or somehow become part  of the ordering scheme?
>
> So I guess one question is, do you have a "systemd --user" instance
> running? Typically this happens automatically via PAM with most
> reasonably recent systemds.
>
> So you *could* write a user systemd unit (or combo of units -
> socket+service) that would start your service. This might or might not
> really help tho' as whatever consumes your service would still need to
> block/wait I guess (even if it was socket activated in the user session
> I'm not sure you currently have any guarantees that non-systemd stuff is
> started after systemd stuff - would need a full conversion to
> systemd-based user sessions for that). You could use "systemctl --user
> is-active foo.socket" to do the polling which might or might not seem
> nicer to you.
>
>
> Another option which may work if you have a simple setup and control
> over the machine, is to write a *system* service but put User=+Group=
> directives in it to start as your user+group. You can order that before
> systemd-user-sessions.service and that will allow you to login confident
> that your service will already have started. This falls down quite
> royally when you have multiple users tho'!
>
> Hope that helps a bit.
>
> Col
>
Thanks for taking time to reply. That said, it seems hard to get the
message through on this list: systemd doesn't always fit the bill :).

Again: My service is not a systemd service, neither system nor user.
And it can't be, since it needs to be part of the session, accessing
the display and similar stuff. As I understand it , systemd only runs
processes outside the session, be it system or user ones(?) The
obvious approach for such a service is then to start it using a
desktop file in the .config/autostart directory (freedesktop specs).

However, this service started outside of systemd still need a socket
provided by a another  systemd service. Actually, I have worked around
my problem using socket activation which means that the socket is
there. But I have a gut feeling that there will be more of these
problems, synchronizing session services started by e. g., gnome and
systemd services running outside the session.

Perhaps I just got it all wrong, and systemd will (does?) also handle
the session services running within the session? Or is there a
reasonable robust way for a system user service started outside the
session to join it? Or, my first thought, is there a way (API/tool)
for non-systemd services to wait for a systemd service being started
or so?

"confused"

--alec

I
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] synchronizing user service

[Mantas Mikulėnas]

On Mon, Mar 10, 2014 at 5:46 PM, Alec Leamas  wrote:
> […]
> Perhaps I just got it all wrong, and systemd will (does?) also handle
> the session services running within the session? Or is there a
> reasonable robust way for a system user service started outside the
> session to join it? Or, my first thought, is there a way (API/tool)
> for non-systemd services to wait for a systemd service being started
> or so?

Currently, there is `systemctl --user import-environment` that the
xprofile script can run, to make $DISPLAY and $XAUTHORITY accessible
to `systemd --user` services. In the future, the entire session might
be started through `systemd --user`.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer

[Josh Triplett]

On Mon, Mar 10, 2014 at 04:44:02PM +0100, Lennart Poettering wrote:
> On Sat, 08.03.14 20:33, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > avoid_cleanup also returns a copy of the pointer, making it convenient
> > to use at the point where initialization completes, to hand the constructed
> > object off somewhere without freeing it.
> > 
> > Change all NULL assignments tagged with /* avoid cleanup */ to use this
> > instead.
> > ---
> > 
> > Seems like a common pattern, and this makes it more self-documenting.
> > In particular, the use in systemctl.c's list_timers function now feels
> > like a single logical operation of "hand ownership of this object off to
> > something else and don't clean it up".
> 
> Hmmm, I am all for synctactic sugar, but I don't see the benefit of this
> one really... Especially given that that disabling cleanup is done
> different for different types... For example, disabling cleanup for an
> fd is by assigning -1...

As far as I can tell, that's the *only* differing case.  Everything else
is a pointer and uses NULL.

> I would see benefit in this if we could maybe make this
> type-sensitive... not sure though if C would allow that? I at least
> cannot think of a way to do that?

C11 allows it using _Generic, if you're willing to rely on that.
__builtin_types_compatible_p and some casts could work too.  But again,
I think the only two cases are "int" and "pointer".

- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] synchronizing user service

[Alec Leamas]

On 3/10/14, Mantas Mikulėnas  wrote:
> On Mon, Mar 10, 2014 at 5:46 PM, Alec Leamas  wrote:
>> […]
>> Perhaps I just got it all wrong, and systemd will (does?) also handle
>> the session services running within the session? Or is there a
>> reasonable robust way for a system user service started outside the
>> session to join it? Or, my first thought, is there a way (API/tool)
>> for non-systemd services to wait for a systemd service being started
>> or so?
>
> Currently, there is `systemctl --user import-environment` that the
> xprofile script can run, to make $DISPLAY and $XAUTHORITY accessible
> to `systemd --user` services. In the future, the entire session might
> be started through `systemd --user`.

Ah... that's it! Perhaps not the most elegant solution, being
all-services-or-none. But absolutely a reasonable approach... will
test. Thanks!

--alec
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] synchronizing user service

[Colin Guthrie]

'Twas brillig, and Alec Leamas at 10/03/14 15:46 did gyre and gimble:
> On 3/10/14, Colin Guthrie  wrote:
>> 'Twas brillig, and Alec Leamas at 07/03/14 19:45 did gyre and gimble:
>>> Sorry for not being clear. The priob
>>>
>>> On 3/7/14, Lennart Poettering  wrote:
 On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote:

> Dear list,
>
> Being a systemd dummie, I have a problem. It's a about running a
> service as a user, which needs to synchronize with a systemd service.

 What do you mean by "synchronize"?

> Since the service needs to be part of the session, I presume that a
> /systemd/user service isn't really the way to go (?): This leaves me
> with the problem to start a service e. .g,, using a desktop file in
> the autostart dir. The service needs a socket created by a systemd
> service.
> 
> [cut]
>>> I can't make it socket activated, nor can I order it. My user service
>>> is *not* a systemd service since it needs to be part  of the session.
>>> As of now, it's started as a desktop service using a desktop file.
>>>
>>> So the question is: is there any "good" way for a non-systemd user
>>> service to to things that systemd services does, like waiting on a
>>> socket or somehow become part  of the ordering scheme?
>>
>> So I guess one question is, do you have a "systemd --user" instance
>> running? Typically this happens automatically via PAM with most
>> reasonably recent systemds.
>>
>> So you *could* write a user systemd unit (or combo of units -
>> socket+service) that would start your service. This might or might not
>> really help tho' as whatever consumes your service would still need to
>> block/wait I guess (even if it was socket activated in the user session
>> I'm not sure you currently have any guarantees that non-systemd stuff is
>> started after systemd stuff - would need a full conversion to
>> systemd-based user sessions for that). You could use "systemctl --user
>> is-active foo.socket" to do the polling which might or might not seem
>> nicer to you.
>>
>>
>> Another option which may work if you have a simple setup and control
>> over the machine, is to write a *system* service but put User=+Group=
>> directives in it to start as your user+group. You can order that before
>> systemd-user-sessions.service and that will allow you to login confident
>> that your service will already have started. This falls down quite
>> royally when you have multiple users tho'!
>>
>> Hope that helps a bit.
>>
>> Col
>>
> Thanks for taking time to reply. That said, it seems hard to get the
> message through on this list: systemd doesn't always fit the bill :).
> 
> Again: My service is not a systemd service, neither system nor user.

Yes, it's not *currently* a systemd service. My first suggestion was to
make it into one.

FYI, when systemd in the user session is fully supported, it will likely
enumerate the .desktop files (whether they are XDG autostart or just
regular .desktop files) and they *will* be systemd (user) services.

> And it can't be, since it needs to be part of the session, accessing
> the display and similar stuff.

Yeah, fair enough, this certainly rules out the second option I
suggested (User=+Group=), but eventually this shouldn't be a problem
overall when the whole session is also managed by systemd, so you're not
too far away from making it all work as a systemd (user) service.

> As I understand it , systemd only runs
> processes outside the session, be it system or user ones(?) The
> obvious approach for such a service is then to start it using a
> desktop file in the .config/autostart directory (freedesktop specs).

At present, I'd say yes, this is likely the case.

> However, this service started outside of systemd still need a socket
> provided by a another  systemd service. Actually, I have worked around
> my problem using socket activation which means that the socket is
> there. But I have a gut feeling that there will be more of these
> problems, synchronizing session services started by e. g., gnome and
> systemd services running outside the session.

During this early "systemd in the user session" stage, yes I agree, but
longer term, these kind of things will be addressed by probably starting
the whole session via systemd --user (and perhaps with systemctl --user
import-environment too).


> Perhaps I just got it all wrong, and systemd will (does?) also handle
> the session services running within the session? Or is there a
> reasonable robust way for a system user service started outside the
> session to join it? Or, my first thought, is there a way (API/tool)
> for non-systemd services to wait for a systemd service being started
> or so?

It will, but it's all still a little early but people are making good
progress here (the whole concept of a "session" verses a "user" is a
little blurry these days - many "services" are per-user already (as user
activity is very much tied into device access etc.) rat

Re: [systemd-devel] device state UNKNOWN

[arnaud gaboury]

>
> It seems to me that this device is configured, so why is its state
> unknown  and not UP ? Shall I use a netctl profile to bring it UP,
> like I do for enp7s0 ?


Yes.
# netctl enable "profile" made the br0 UP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] device state UNKNOWN

[Zbigniew Jędrzejewski-Szmek]

On Mon, Mar 10, 2014 at 06:36:27PM +0100, arnaud gaboury wrote:
> >
> > It seems to me that this device is configured, so why is its state
> > unknown  and not UP ? Shall I use a netctl profile to bring it UP,
> > like I do for enp7s0 ?
> 
> 
> Yes.
> # netctl enable "profile" made the br0 UP
Maybe 58b129170ca6acacffd8?

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/07/2014 07:26 PM, Lennart Poettering wrote:
> Heya!
> 
> Since yesterday systemd in git can now discover root, /home, /srv and
> swap partitions automatically based on GPT type GUIDs, thus making
> /etc/fstab unnecessary for simple setups.
> 
> I have now put together something like a spec describing the logic
> behind that, and what it is good for:

> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
> 

Form the FAQ:

[...] What about automatic mounting of btrfs subvolumes to /var, /home and so 
on?

Doing a similar automatic discovery of btrfs subvolumes and mounting them 
automatically to the appropriate places is certainly desirable. We are waiting 
for the btrfs designers to add a per-subvolume type UUID to their disk format 
to make this possible. [...]


Instead of relying on the subvolume UUID, why not relying to the subvolume 
name: it would be more simple and flexible to manage them.

For example supposing to use '@' as prefix for a subvolume name:

@   -> root filesystem
@etc-> etc
@home   -> home
[...]

If you want multiple OS on the same filesystem we can use the following 
convention

@home   -> home of all the systems
@srv-> srv  of all the systems
@fedora_-> root of a fedora system
@fedora_etc -> etc of the fedora system
@fedora2_   -> root of a fedora2 system
@fedora2_etc-> etc of the fedora2 system

Or in another way we could group the different systems in subdirectories:

@home   -> home of all the systems
@srv-> srv  of all the systems
fedora/@-> root of a fedora system
fedora/@etc -> etc of the fedora system
fedora2/@   -> root of a fedora2 system
fedora2/@etc-> etc of the fedora2 system



-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Kay Sievers]

On Mon, Mar 10, 2014 at 7:34 PM, Goffredo Baroncelli  wrote:
> On 03/07/2014 07:26 PM, Lennart Poettering wrote:

>> Since yesterday systemd in git can now discover root, /home, /srv and
>> swap partitions automatically based on GPT type GUIDs, thus making
>> /etc/fstab unnecessary for simple setups.
>>
>> I have now put together something like a spec describing the logic
>> behind that, and what it is good for:
>
>> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
>>
>
> Form the FAQ:
> 
> [...] What about automatic mounting of btrfs subvolumes to /var, /home and so 
> on?
>
> Doing a similar automatic discovery of btrfs subvolumes and mounting them 
> automatically to the appropriate places is certainly desirable. We are 
> waiting for the btrfs designers to add a per-subvolume type UUID to their 
> disk format to make this possible. [...]
> 
>
> Instead of relying on the subvolume UUID, why not relying to the subvolume 
> name: it would be more simple and flexible to manage them.

As a general rule: human-readable names should be left to the
administrator, provide an identifier for humans, and should not be
overloaded with magic machine behavior.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

Hi Kay
On 03/10/2014 07:53 PM, Kay Sievers wrote:
[...]
>>
>> Instead of relying on the subvolume UUID, why not relying to the subvolume 
>> name: it would be more simple and flexible to manage them.
> 
> As a general rule: human-readable names should be left to the
> administrator, provide an identifier for humans, and should not be
> overloaded with magic machine behavior.

In general I agree with you. 
But using "a name" you can manage multiple system on the same filesystem. This 
is impossible with the UUID.

> 
> KayGoffredo-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] nspawn: Fix a race condition

[Joel Teichroeb]

If the master process registers the child before the child
has initialized, when the child tries to setup /dev/console
it gets "operation not permitted".
---
 src/nspawn/nspawn.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 92b6728..a83d1f3 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1776,7 +1776,7 @@ finish:

 int main(int argc, char *argv[]) {

-_cleanup_close_ int master = -1, kdbus_fd = -1, sync_fd = -1;
+_cleanup_close_ int master = -1, kdbus_fd = -1, sync_fd = -1,
sync_fd2 = -1;
 _cleanup_close_pipe_ int kmsg_socket_pair[2] = { -1, -1 };
 _cleanup_free_ char *kdbus_domain = NULL;
 _cleanup_fdset_free_ FDSet *fds = NULL;
@@ -1925,9 +1925,11 @@ int main(int argc, char *argv[]) {

 for (;;) {
 siginfo_t status;
+eventfd_t x;

 sync_fd = eventfd(0, EFD_CLOEXEC);
-if (sync_fd < 0) {
+sync_fd2 = eventfd(0, EFD_CLOEXEC);
+if (sync_fd < 0 || sync_fd2 < 0) {
 log_error("Failed to create event fd: %m");
 goto finish;
 }
@@ -1964,7 +1966,6 @@ int main(int argc, char *argv[]) {
 NULL
 };
 char **env_use;
-eventfd_t x;

 envp[n_env] = strv_find_prefix(environ, "TERM=");
 if (envp[n_env])
@@ -2201,6 +2202,9 @@ int main(int argc, char *argv[]) {
 goto child_fail;
 }
 }
+eventfd_write(sync_fd2, 1);
+close_nointr_nofail(sync_fd2);
+sync_fd2 = -1;

 eventfd_read(sync_fd, &x);
 close_nointr_nofail(sync_fd);
@@ -2256,6 +2260,10 @@ int main(int argc, char *argv[]) {
 _exit(EXIT_FAILURE);
 }

+eventfd_read(sync_fd2, &x);
+close_nointr_nofail(sync_fd2);
+sync_fd2 = -1;
+
 fdset_free(fds);
 fds = NULL;

-- 
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Chris Murphy]

On Mar 10, 2014, at 12:34 PM, Goffredo Baroncelli  wrote:

> On 03/07/2014 07:26 PM, Lennart Poettering wrote:
>> Heya!
>> 
>> Since yesterday systemd in git can now discover root, /home, /srv and
>> swap partitions automatically based on GPT type GUIDs, thus making
>> /etc/fstab unnecessary for simple setups.
>> 
>> I have now put together something like a spec describing the logic
>> behind that, and what it is good for:
> 
>> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
>> 
> 
> Form the FAQ:
> 
> [...] What about automatic mounting of btrfs subvolumes to /var, /home and so 
> on?
> 
> Doing a similar automatic discovery of btrfs subvolumes and mounting them 
> automatically to the appropriate places is certainly desirable. We are 
> waiting for the btrfs designers to add a per-subvolume type UUID to their 
> disk format to make this possible. [...]
> 
> 
> Instead of relying on the subvolume UUID, why not relying to the subvolume 
> name: it would be more simple and flexible to manage them.


We have a problem the instant the user snapshots any subvolume being mounted in 
this fashion. The resulting snapshot presumably would inherit the same 
"subvolumetypeGUID" as the parent, and it's now ambiguous which should be 
automounted, or how to fail.



Chris Murphy

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Lennart Poettering]

On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:

Heya,

> Instead of relying on the subvolume UUID, why not relying to the subvolume 
> name: it would be more simple and flexible to manage them.
> 
> For example supposing to use '@' as prefix for a subvolume name:
> 
> @ -> root filesystem
> @etc  -> etc
> @home -> home
> [...]

Well, the name is property of the admin really. There needs to be a way
how the admin can label his subvolumes, with a potentially localized
name. This makes it unsuitable for our purpose, we cannot just take
possession of this and leave the admin with nothing.

On GPT there are also gpt partition labels and partition types. The
former are property of the admin, he can place there whatever he wants,
in whatever language he chooses... The latter however is how we make
sense of it on a semantical level.

> Or in another way we could group the different systems in subdirectories:
> 
> @home -> home of all the systems
> @srv  -> srv  of all the systems
> fedora/@  -> root of a fedora system
> fedora/@etc   -> etc of the fedora system
> fedora2/@ -> root of a fedora2 system
> fedora2/@etc  -> etc of the fedora2 system

I am pretty sure automatic discovery of mount points should not cover
the usecase where people install multiple distributions into the same
btrfs volume. THe automatic logic should cover the simple cases only,
and it sounds way over the top to support installing multiple OSes into
the same btrfs... I mean, people can do that, if they want to, they just
have to write a proper fstab, which I think is not too much too ask...

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] The Bridge on the River PID EINS

[Umut Tezduyar]

Hi,

I tried out a similar configuration and couldn't get the bridge up. I
tried it on Arch with systemd 210.

bridge.netdev
[NetDev]
Name=bridge0
Kind=bridge

u.network
[NetDev]
Name=bridge0
Kind=bridge

Further debugging, seems like networkd never receives the RTM_NEWLINK
for the bridge. Since bridge is never considered up, u.network never
gets enslaved.

ip a
3: enp0s8:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 08:00:27:e2:95:20 brd ff:ff:ff:ff:ff:ff
4: bridge0:  mtu 1500 qdisc noop state DOWN group default
link/ether 0a:4c:02:c2:2a:09 brd ff:ff:ff:ff:ff:ff

On Sun, Mar 9, 2014 at 5:58 AM, poma  wrote:
>
> %
>
> STATIC OK!
>
> $ ll /etc/systemd/network/
> ... enp3s0.network
>
> $ cat /etc/systemd/network/enp3s0.network
> [Match]
> Name=enp3s0
>
> [Network]
> Address=192.168.2.2/24
> Gateway=192.168.2.1
> DNS=192.168.2.1
>
> # journalctl -b -u systemd-networkd
> -- Logs begin at ...
> ... systemd-networkd[630]: enp3s0: carrier on
> ... systemd-networkd[630]: enp3s0: link configured
>
> $ ifconfig enp3s0
> enp3s0: flags=...
> inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
> inet6 ...
> ether ...
> ...
>
> %
>
> BRIDGED !?
>
> $ ll /etc/systemd/network/
> ... bridge0.netdev
> ... enp3s0.network
>
> $ cat /etc/systemd/network/enp3s0.network
> [Match]
> Name=enp3s0
>
> [Network]
> Address=192.168.2.2/24
> Gateway=192.168.2.1
> DNS=192.168.2.1
> Bridge=bridge0
>
> $ cat /etc/systemd/network/bridge0.netdev
> [NetDev]
> Name=bridge0
> Kind=bridge
>
> # journalctl -b -u systemd-networkd.service
> -- Logs begin at ...
>
> $ ifconfig enp3s0
> enp3s0: flags=...
> ether ...
> ...
>
> $ brctl show
> bridge name bridge id   STP enabled interfaces
> bridge0 8000.   no
>
> %
>
> /var/log/messages
> Mar  2 11:58:23 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 12:17:48 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 15:30:22 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 15:43:30 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 16:20:23 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 16:59:46 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 17:07:11 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 17:21:28 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 17:25:10 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 17:31:31 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 17:45:50 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:01:00 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:04:25 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:07:43 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:13:41 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:16:01 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:18:01 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:22:34 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  2 22:26:21 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 12:41:36 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 14:00:57 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 14:05:28 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 14:11:01 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 14:13:55 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 19:13:29 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 22:50:51 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 23:13:24 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 23:49:55 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 23:55:36 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  3 23:55:36 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  4 00:01:02 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  4 01:30:19 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  4 02:01:35 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  4 10:53:55 localhost systemd-udevd: Could not apply link config to
> bridge0
> Mar  4 10:57:12 localhost systemd-udevd: Could not apply link config t

Re: [systemd-devel] [PATCH] nspawn: Fix a race condition

[Lennart Poettering]

On Mon, 10.03.14 12:15, Joel Teichroeb (j...@teichroeb.net) wrote:

> If the master process registers the child before the child
> has initialized, when the child tries to setup /dev/console
> it gets "operation not permitted".

Thanks for tracking this down!

I have now applied a different patch which uses /dev/null as source for
the major/minor to use. Given that the code in question simply needs to
create a valid device node to bind mount over, the actual major/minor
used for it doesn't matter. Since creating additional /dev/null
instances in the container (in contrast to creating additional
/dev/console instances) is permitted anyway, this should be a safe thing
to do, and doesn't require additional syncronization between the
container and nspawn.

Please check if this works for you!

Thanks,

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] [HEADS-UP] Discoverable Partitions Spec

[Chris Murphy]

On Mar 10, 2014, at 2:21 PM, Chris Mason  wrote:

> On 03/10/2014 04:02 PM, Lennart Poettering wrote:
>> On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
>> 
>> Heya,
>> 
>>> Instead of relying on the subvolume UUID, why not relying to the subvolume 
>>> name: it would be more simple and flexible to manage them.
>>> 
>>> For example supposing to use '@' as prefix for a subvolume name:
>>> 
>>> @   -> root filesystem
>>> @etc-> etc
>>> @home   -> home
>>> [...]
>> 
>> Well, the name is property of the admin really. There needs to be a way
>> how the admin can label his subvolumes, with a potentially localized
>> name. This makes it unsuitable for our purpose, we cannot just take
>> possession of this and leave the admin with nothing.
>> 
>> On GPT there are also gpt partition labels and partition types. The
>> former are property of the admin, he can place there whatever he wants,
>> in whatever language he chooses... The latter however is how we make
>> sense of it on a semantical level.
>> 
>>> Or in another way we could group the different systems in subdirectories:
>>> 
>>> @home   -> home of all the systems
>>> @srv-> srv  of all the systems
>>> fedora/@-> root of a fedora system
>>> fedora/@etc -> etc of the fedora system
>>> fedora2/@   -> root of a fedora2 system
>>> fedora2/@etc-> etc of the fedora2 system
>> 
>> I am pretty sure automatic discovery of mount points should not cover
>> the usecase where people install multiple distributions into the same
>> btrfs volume. THe automatic logic should cover the simple cases only,
>> and it sounds way over the top to support installing multiple OSes into
>> the same btrfs... I mean, people can do that, if they want to, they just
>> have to write a proper fstab, which I think is not too much too ask...
> 
> Thinking more about this, using the UUIDs does make it harder for the admin 
> to roll back and forth between snapshots.  This is similar to the multiple 
> install idea, but the goal would be easily jumping back to the old one if an 
> update failed.

Since it's not a given whether a parent or child subvolume is the one being 
updated, it's ambiguous which one to use/automount if there is inheritance of 
the proposed subvolumetypeGUID at snapshot time. Inheritance of the proposed 
GUID at snapshot time sounds untenable.

Failsafe for rootfs is to snapshot, mount it, apply updates to the snapshot in 
a chroot. That way a failed update means the snapshot can be immediately 
deleted. And the OS is overall more stable by not having running binaries 
modified or yanked out from under it. Here, using the current subvolume at 
reboot is the rollback; changing to the snapshot is the upgrade.

Whereas for home, rebooting to the snapshot is a rollback, which I certainly 
don't want by default.

I don't see the right way to handle this automatically or by default.

> I'm not against anything that makes us more flexible here, just trying to 
> nail down the use case a little bit more.

Faster mounts, before the fstab would otherwise be read and parsed? OS X has 
deprecated fstab entirely in favor of autodiscovery/automounting. The 
/etc/fstab is no longer present (but is honored if created).


Chris Murphy

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Lennart Poettering]

On Mon, 10.03.14 14:53, Chris Murphy (li...@colorremedies.com) wrote:

> Since it's not a given whether a parent or child subvolume is the one
> being updated, it's ambiguous which one to use/automount if there is
> inheritance of the proposed subvolumetypeGUID at snapshot
> time. Inheritance of the proposed GUID at snapshot time sounds
> untenable.
> 
> Failsafe for rootfs is to snapshot, mount it, apply updates to the
> snapshot in a chroot. That way a failed update means the snapshot can
> be immediately deleted. And the OS is overall more stable by not
> having running binaries modified or yanked out from under it. Here,
> using the current subvolume at reboot is the rollback; changing to the
> snapshot is the upgrade.
> 
> Whereas for home, rebooting to the snapshot is a rollback, which I
> certainly don't want by default.
> 
> I don't see the right way to handle this automatically or by default.

I am in no way bound to the idea of having subvolume type UUIDs for
this. There are other options. For example, there's already the concept
of having "default" subvolumes ("btrfs subvolume set-default"...), maybe
we can extend that a little bit, and allow different kinds of default
subvolumes, one "default /home subvolume", one "default /srv subvolume",
and so on, plus one "default root subvolume", and so on. The vocabulary
for the available "default" subvolumes could be a free-form string where
the empty string would be the existing default subvolume. Or so...

When people play games with subvolumes and snapshots we could then
simply ask them to update where these "default" subvolumes point... Of
course this simply exports to the admin the problem of combining
subvolumes properly.

Another option would be to introduce a high level concept of a
"subvolume set" or so, which binds subvolumes together, and of which
there could be a "default subvolume set". Within such a subvolume set
could then use type uuids or so to mount things properly. Or something
like that...

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] synchronizing user service

[Lennart Poettering]

On Fri, 07.03.14 20:45, Alec Leamas (leamas.a...@gmail.com) wrote:

> 
> Sorry for not being clear. The priob
> 
> On 3/7/14, Lennart Poettering  wrote:
> > On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote:
> >
> >> Dear list,
> >>
> >> Being a systemd dummie, I have a problem. It's a about running a
> >> service as a user, which needs to synchronize with a systemd service.
> >
> > What do you mean by "synchronize"?
> >
> >> Since the service needs to be part of the session, I presume that a
> >> /systemd/user service isn't really the way to go (?): This leaves me
> >> with the problem to start a service e. .g,, using a desktop file in
> >> the autostart dir. The service needs a socket created by a systemd
> >> service.
> >
> > You can simply order your system service before
> > systemd-user-sessions.service. All user sessions are only started after
> > that, hence ordering your service before that makes sure for users it is
> > always accesssible.
> >
> >> As of now, I simply poll for the socket creation in a shell script.
> >> It's just that my gut feeling is that this is not  really the way to
> >> do this. Is there a better approach?
> >
> > Well, you can make it socket activated, but otherwise just order it like
> > suggested above...
> 
> Sorry for not being clear...
> 
> I can't make it socket activated, nor can I order it. My user service
> is *not* a systemd service since it needs to be part  of the session.
> As of now, it's started as a desktop service using a desktop file.
> 
> So the question is: is there any "good" way for a non-systemd user
> service to to things that systemd services does, like waiting on a
> socket or somehow become part  of the ordering scheme?

I really don't grok this?

Do you have a system systemd service and a non-systemd session service?

Or do you have a user systemd service and a non-systemd session service?

The former should a non-issue, as pointed above, as you can just order
your system systemd service before systemd-user-session.service. Since
user sessions are only started after that barrier you don't have to
synchronize for anything else...

The latter doesn't make much sense to me... 

Anyway, really not grokking what you are trying to do...

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] Process ordering within a 'dependency level'

[Lennart Poettering]

On Fri, 07.03.14 10:52, Allmeroth, Robert (robert.allmer...@harman.com) wrote:

> Hi,
> 
> I tried to optimize my embedded configuration but I stumbled over the 
> following problem:
> 
> Let's assume systemd identified 10 processes on 'dependency level
> 0'. They all can/should be started first/immediately.  Since they
> cannot be started at the same time - they start sequential with some
> little delay.
> 
> But one of that processes is in the critical chain in the meaning that
> half of the system depends on it.  So.. that process must be started
> first (instead of being started at pos 10 of 10) to avoid all the
> little start delays + data loading of the already started 9 processes.
> 
> Is there a way to express / force an ordering of unit files within one
> dependency level?  Means: I would like to tell systemd the order in
> which processes have to be started without using a forced wait like
> 'After' (that causes often idle CPU and I/O)

If multiple units are runnable at the same time it is undefined which
one is started first. Note however, that PID 1 fork()s off those
processes and doesn't wait for them to respond before going on to the
next one. The work done within PID 1 there is hence very cheap.

Note that for cases where only Type=simple services are used you can
declare the fork() order by simple After=/Before= dependencies. However,
as soon as you use any other Type= this will also delay the units until
after the forked off processes responded back to PID 1.

I'd be willing to merge a patch that adds RunPriority= or so, which
takes some numeric priority value and which could influence which unit
is processed first if multiple are runnable. But I'd prefer some
performance data with it that shows that this actually makes a
measurable difference.

Did you see the StartupCPUShares= patches recently posted on the ML? To
me they appear much more useful to optimize specific boot processes as
they simply pass all ordering logic into the kernel CPU and IO
schedulers as quickly as possible and let the kernel figure things out
which should normally be better at these things than us.

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] The Bridge on the River PID EINS

[poma]

On 10.03.2014 21:12, Umut Tezduyar wrote:
> Hi,
> 
> I tried out a similar configuration and couldn't get the bridge up. I
> tried it on Arch with systemd 210.
> 
> bridge.netdev
> [NetDev]
> Name=bridge0
> Kind=bridge
> 
> u.network
> [NetDev]
> Name=bridge0
> Kind=bridge
...

You want to bridge the bridge? :)
man 8 systemd-networkd

BTW we haven't yet received info whether die brücke über den fluss zwei
ever kicked.


poma


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [patch] Fix AC_PATH_PROG usage in configure.ac for systems with (still) bin vs. sbin distiction

[Lennart Poettering]

On Sat, 08.03.14 10:17, Samuli Suominen (ssuomi...@gentoo.org) wrote:

> This version of the patch is likely more agreeable. No reason to add
> /usr/bin:/bin again to $PATH as it should be safe to expect at least
> they are there,
> or otherwise the system is really *broken*. :-)

Thanks. Applied.

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] The Bridge on the River PID EINS

[Umut Tezduyar]

On Mon, Mar 10, 2014 at 9:12 PM, Umut Tezduyar  wrote:
> Hi,
>
> I tried out a similar configuration and couldn't get the bridge up. I
> tried it on Arch with systemd 210.
>
> bridge.netdev
> [NetDev]
> Name=bridge0
> Kind=bridge
>
> u.network
> [NetDev]
> Name=bridge0
> Kind=bridge
Ops, copy pase mistake. Should have been,
[Match]
Name=enp0s8

[Network]
Bridge=bridge0
>
> Further debugging, seems like networkd never receives the RTM_NEWLINK
> for the bridge. Since bridge is never considered up, u.network never
> gets enslaved.
>
> ip a
> 3: enp0s8:  mtu 1500 qdisc noop state DOWN group
> default qlen 1000
> link/ether 08:00:27:e2:95:20 brd ff:ff:ff:ff:ff:ff
> 4: bridge0:  mtu 1500 qdisc noop state DOWN group default
> link/ether 0a:4c:02:c2:2a:09 brd ff:ff:ff:ff:ff:ff
>
> On Sun, Mar 9, 2014 at 5:58 AM, poma  wrote:
>>
>> %
>>
>> STATIC OK!
>>
>> $ ll /etc/systemd/network/
>> ... enp3s0.network
>>
>> $ cat /etc/systemd/network/enp3s0.network
>> [Match]
>> Name=enp3s0
>>
>> [Network]
>> Address=192.168.2.2/24
>> Gateway=192.168.2.1
>> DNS=192.168.2.1
>>
>> # journalctl -b -u systemd-networkd
>> -- Logs begin at ...
>> ... systemd-networkd[630]: enp3s0: carrier on
>> ... systemd-networkd[630]: enp3s0: link configured
>>
>> $ ifconfig enp3s0
>> enp3s0: flags=...
>> inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
>> inet6 ...
>> ether ...
>> ...
>>
>> %
>>
>> BRIDGED !?
>>
>> $ ll /etc/systemd/network/
>> ... bridge0.netdev
>> ... enp3s0.network
>>
>> $ cat /etc/systemd/network/enp3s0.network
>> [Match]
>> Name=enp3s0
>>
>> [Network]
>> Address=192.168.2.2/24
>> Gateway=192.168.2.1
>> DNS=192.168.2.1
>> Bridge=bridge0
>>
>> $ cat /etc/systemd/network/bridge0.netdev
>> [NetDev]
>> Name=bridge0
>> Kind=bridge
>>
>> # journalctl -b -u systemd-networkd.service
>> -- Logs begin at ...
>>
>> $ ifconfig enp3s0
>> enp3s0: flags=...
>> ether ...
>> ...
>>
>> $ brctl show
>> bridge name bridge id   STP enabled interfaces
>> bridge0 8000.   no
>>
>> %
>>
>> /var/log/messages
>> Mar  2 11:58:23 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 12:17:48 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 15:30:22 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 15:43:30 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 16:20:23 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 16:59:46 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 17:07:11 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 17:21:28 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 17:25:10 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 17:31:31 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 17:45:50 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:01:00 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:04:25 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:07:43 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:13:41 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:16:01 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:18:01 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:22:34 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  2 22:26:21 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 12:41:36 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 14:00:57 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 14:05:28 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 14:11:01 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 14:13:55 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 19:13:29 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 22:50:51 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 23:13:24 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 23:49:55 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 23:55:36 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  3 23:55:36 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> Mar  4 00:01:02 localhost systemd-udevd: Could not apply link config to
>> bridge0
>> M

Re: [systemd-devel] [systemd][cgroup in container] problem with cgroup hierarchy in container

[Lennart Poettering]

On Thu, 06.03.14 10:51, Dariusz Michaluk (d.micha...@samsung.com) wrote:

> Program received signal SIGSEGV, Segmentation fault.
> sd_bus_message_unref (m=0x8000) at
> ../src/libsystemd/sd-bus/bus-message.c:800
> 800   m->n_ref--;
> (gdb) bt
> #0  sd_bus_message_unref (m=0x8000) at
> ../src/libsystemd/sd-bus/bus-message.c:800
> #1  0x80043950 in sd_bus_message_unrefp (p=0xbfffedd8) at
> ../src/libsystemd/sd-bus/bus-util.h:141
> #2  show_one.3172 (verb=, bus=bus@entry=0x80098880,
> path=path@entry=0x8007548e "/org/freedesktop/systemd1",
> show_properties=show_properties@entry=true,
> new_line=new_line@entry=0xb18a,
> ellipsized=ellipsized@entry=0xb18b) at
> ../src/systemctl/systemctl.c:3672
> #3  0x8005957b in show (bus=0x80098880, args=0xb458) at
> ../src/systemctl/systemctl.c:3965
> #4  0x80007dbb in systemctl_main (bus_error=,
> argv=0xb454, argc=2, bus=0x80098880) at
> ../src/systemctl/systemctl.c:6167
> #5  main (argc=2, argv=0xb454) at ../src/systemctl/systemctl.c:6422

I#d still be curious to track down this issue. It doesn't make sense to
me I must say though... Appears to be some misparsing resulting in
memory corruption somewhere...

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?

Thanks!

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] rules: mark loop device as SYSTEMD_READY=0 if no file is attached

[Lennart Poettering]

On Thu, 06.03.14 09:16, Peter Rajnoha (prajn...@redhat.com) wrote:

> Hi!
> 
> Based on SYSTEMD_READY definition, I think we should also mark loop
> devices with no file attached as not ready:
> 
> rules: mark loop device as SYSTEMD_READY=0 if no file is attached
> 
> Check existence of loop/backing_file in sysfs and mark loop
> devices with SYSTEMD_READY if missing. Such loop files is
> uninitialized and it's not ready for use yet (there's no file
> attached).

Looks good!

Applied!

Thanks!

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] synchronizing user service

[Alec Leamas]

On 3/10/14, Lennart Poettering  wrote:
> On Fri, 07.03.14 20:45, Alec Leamas (leamas.a...@gmail.com) wrote:
>
>>
>> Sorry for not being clear. The priob
>>
>> On 3/7/14, Lennart Poettering  wrote:
>> > On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote:
>> >
>> >> Dear list,
>> >>
>> >> Being a systemd dummie, I have a problem. It's a about running a
>> >> service as a user, which needs to synchronize with a systemd service.

[cut]

>> So the question is: is there any "good" way for a non-systemd user
>> service to to things that systemd services does, like waiting on a
>> socket or somehow become part  of the ordering scheme?
>
> I really don't grok this?
>
> Do you have a system systemd service and a non-systemd session service?
Yup

> Or do you have a user systemd service and a non-systemd session service?
No

> The former should a non-issue, as pointed above, as you can just order
> your system systemd service before systemd-user-session.service. Since
> user sessions are only started after that barrier you don't have to
> synchronize for anything else...

Now, it was some time i really stumbled into this together with other
lirc users.. But it really was (is?) the case that the session service
was started ahead of the system, systemd service. Or to be more
precise, before that service had created it's pipe. A shellscript
polling for the pipe during startup solved it, but left a bad taste in
the mouth.

As I said, I have walked around the problem using socket activation.
So this discussion is somewhat academic. But I''m still a little
curious. And confused, although on a higher level. ;)

--alec
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/10/2014 09:02 PM, Lennart Poettering wrote:
> On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
> 
> Heya,
> 
>> Instead of relying on the subvolume UUID, why not relying to the subvolume 
>> name: it would be more simple and flexible to manage them.
>>
>> For example supposing to use '@' as prefix for a subvolume name:
>>
>> @-> root filesystem
>> @etc -> etc
>> @home-> home
>> [...]
> 
> Well, the name is property of the admin really. There needs to be a way
> how the admin can label his subvolumes, with a potentially localized
> name. This makes it unsuitable for our purpose, we cannot just take
> possession of this and leave the admin with nothing.

Instead of the name we can use the xattr to store these information.


> On GPT there are also gpt partition labels and partition types. The
> former are property of the admin, he can place there whatever he wants,
> in whatever language he chooses... The latter however is how we make
> sense of it on a semantical level.
> 
>> Or in another way we could group the different systems in subdirectories:
>>
>> @home-> home of all the systems
>> @srv -> srv  of all the systems
>> fedora/@ -> root of a fedora system
>> fedora/@etc  -> etc of the fedora system
>> fedora2/@-> root of a fedora2 system
>> fedora2/@etc -> etc of the fedora2 system
> 
> I am pretty sure automatic discovery of mount points should not cover
> the usecase where people install multiple distributions into the same
> btrfs volume. THe automatic logic should cover the simple cases only,
> and it sounds way over the top to support installing multiple OSes into
> the same btrfs... I mean, people can do that, if they want to, they just
> have to write a proper fstab, which I think is not too much too ask...

In your specification, you referred the use case of "container" (via nspawn / 
libvrt-lxc). which have to boot "a disk image". Why you don't mind to use a 
container on a btrfs snapshot ? I think that it will be reasonable to have 
different containers on a snapshots of the same filesystem-tree.


> 
> Lennart
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli]

On 03/10/2014 09:21 PM, Chris Mason wrote:
> On 03/10/2014 04:02 PM, Lennart Poettering wrote:
>> On Mon, 10.03.14 19:34, Goffredo Baroncelli (kreij...@libero.it) wrote:
[...]
>> I am pretty sure automatic discovery of mount points should not cover
>> the usecase where people install multiple distributions into the same
>> btrfs volume. THe automatic logic should cover the simple cases only,
>> and it sounds way over the top to support installing multiple OSes into
>> the same btrfs... I mean, people can do that, if they want to, they just
>> have to write a proper fstab, which I think is not too much too ask...
> 
> Thinking more about this, using the UUIDs does make it harder for the
> admin to roll back and forth between snapshots. This is similar to
> the multiple install idea, but the goal would be easily jumping back
> to the old one if an update failed.
> 
> I'm not against anything that makes us more flexible here, just
> trying to nail down the use case a little bit more.>

We can store the mount point in a xattr. Also we can store the snapshots 
relation (parent/child or real/rollback) in a xattr. During the boot a 
"systemd-btrfs-fstab-generator" could generate on the fly the right mounts list.



 
> -chris
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [210] logind bypasses polkit? bug or new feature?

[Gerardo Exequiel Pozzi]

On 03/10/2014 12:10 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Mar 10, 2014 at 11:41:52AM -0300, Gerardo Exequiel Pozzi wrote:
>> On 03/10/2014 06:48 AM, Djalal Harouni wrote:
>>> On Sun, Mar 09, 2014 at 08:00:22PM -0300, Gerardo Exequiel Pozzi wrote:
 Hello

 To do tests I made a new Arch Linux (x86_64) base installation running
 in qemu/kvm with systemd-210-3 and polkit-0.112-1 to discard any weird
 thing on my system.

 I can reboot/poweroff/suspend/hibernate the system with a normal user
 logged from a local VT or remote SSH does not care. I can not disable
 this even with a set of polkit rules.
 I am sure that this works fine before (maybe systemd-204 age?)
>>> Yes! I did notice that, normally it should return 'challenge' ?!
>>
>> Yes. Except if you change it as I did to "NO" per custom rule.
> 
> Could you check if current git behaves as expected?
> 
> Zbyszek
> 
> 

Perfecto, thanks you. :)
Aplying 055d4066 (logind: fix policykit checks) fixed the issue.


Now works as expected:

(with polkit rule to deny)
[djgera@host322 ~]$ systemctl reboot
Failed to execute operation: Access denied
Failed to start reboot.target: Access denied
[djgera@host322 ~]$

Without polkit installed at all:
[djgera@host322 ~]$ systemctl reboot
Failed to execute operation: The name org.freedesktop.PolicyKit1 was not
provided by any .service files
Must be root.
[djgera@host322 ~]$


-- 
Gerardo Exequiel Pozzi
\cos^2\alpha + \sin^2\alpha = 1



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] The Bridge on the River PID EINS

[poma]

On 10.03.2014 22:47, Umut Tezduyar wrote:
> On Mon, Mar 10, 2014 at 9:12 PM, Umut Tezduyar  wrote:
>> Hi,
>>
>> I tried out a similar configuration and couldn't get the bridge up. I
>> tried it on Arch with systemd 210.
>>
>> bridge.netdev
>> [NetDev]
>> Name=bridge0
>> Kind=bridge
>>
>> u.network
>> [NetDev]
>> Name=bridge0
>> Kind=bridge
> Ops, copy pase mistake. Should have been,
> [Match]
> Name=enp0s8
> 
> [Network]
> Bridge=bridge0

Keep in mind some options are compulsory i.e. mandatory.
However if 'networkd' doesn't bridge for us, the configuration per se is
worthless.
If we need an external tool to do so, what's the point anyway. :)
So leave it for now.


poma


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Lennart Poettering]

On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@libero.it) wrote:

> > Well, the name is property of the admin really. There needs to be a way
> > how the admin can label his subvolumes, with a potentially localized
> > name. This makes it unsuitable for our purpose, we cannot just take
> > possession of this and leave the admin with nothing.
> 
> Instead of the name we can use the xattr to store these information.

Ah, using xattrs for this is indeed an option. That way we should be able
attach any kind of information we like to a subvolume.

Hmm, I figure though that there is no way currently to read xattrs off a
subvolume without first mounting them individually? Having to mount all
subvolumes before we can make sense of them and mount them to the right
place certainly sounds less than ideal...

> > On GPT there are also gpt partition labels and partition types. The
> > former are property of the admin, he can place there whatever he wants,
> > in whatever language he chooses... The latter however is how we make
> > sense of it on a semantical level.
> > 
> >> Or in another way we could group the different systems in subdirectories:
> >>
> >> @home  -> home of all the systems
> >> @srv   -> srv  of all the systems
> >> fedora/@   -> root of a fedora system
> >> fedora/@etc-> etc of the fedora system
> >> fedora2/@  -> root of a fedora2 system
> >> fedora2/@etc   -> etc of the fedora2 system
> > 
> > I am pretty sure automatic discovery of mount points should not cover
> > the usecase where people install multiple distributions into the same
> > btrfs volume. THe automatic logic should cover the simple cases only,
> > and it sounds way over the top to support installing multiple OSes into
> > the same btrfs... I mean, people can do that, if they want to, they just
> > have to write a proper fstab, which I think is not too much too ask...
> 
> In your specification, you referred the use case of "container" (via
> nspawn / libvrt-lxc). which have to boot "a disk image". Why you don't
> mind to use a container on a btrfs snapshot ? I think that it will be
> reasonable to have different containers on a snapshots of the same
> filesystem-tree.

Hmm, dunno, you might have a point there...

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] [HEADS-UP] Discoverable Partitions Spec

[Alex Elsayed]

Lennart Poettering wrote:

> On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@libero.it) wrote:
> 
>> > Well, the name is property of the admin really. There needs to be a way
>> > how the admin can label his subvolumes, with a potentially localized
>> > name. This makes it unsuitable for our purpose, we cannot just take
>> > possession of this and leave the admin with nothing.
>> 
>> Instead of the name we can use the xattr to store these information.
> 
> Ah, using xattrs for this is indeed an option. That way we should be able
> attach any kind of information we like to a subvolume.
> 
> Hmm, I figure though that there is no way currently to read xattrs off a
> subvolume without first mounting them individually? Having to mount all
> subvolumes before we can make sense of them and mount them to the right
> place certainly sounds less than ideal...

Well, you can always mount subvol=. aka subvolid=0 - the 'root subvolume' 
since they are strictly hierarchical. 'btrfs subvolume list' can then give 
you every subvol in the FS.

>> > On GPT there are also gpt partition labels and partition types. The
>> > former are property of the admin, he can place there whatever he wants,
>> > in whatever language he chooses... The latter however is how we make
>> > sense of it on a semantical level.
>> > 
>> >> Or in another way we could group the different systems in
>> >> subdirectories:
>> >>
>> >> @home -> home of all the systems
>> >> @srv  -> srv  of all the systems
>> >> fedora/@  -> root of a fedora system
>> >> fedora/@etc   -> etc of the fedora system
>> >> fedora2/@ -> root of a fedora2 system
>> >> fedora2/@etc  -> etc of the fedora2 system
>> > 
>> > I am pretty sure automatic discovery of mount points should not cover
>> > the usecase where people install multiple distributions into the same
>> > btrfs volume. THe automatic logic should cover the simple cases only,
>> > and it sounds way over the top to support installing multiple OSes into
>> > the same btrfs... I mean, people can do that, if they want to, they
>> > just have to write a proper fstab, which I think is not too much too
>> > ask...
>> 
>> In your specification, you referred the use case of "container" (via
>> nspawn / libvrt-lxc). which have to boot "a disk image". Why you don't
>> mind to use a container on a btrfs snapshot ? I think that it will be
>> reasonable to have different containers on a snapshots of the same
>> filesystem-tree.
> 
> Hmm, dunno, you might have a point there...

I can confirm that I _currently_ do btrfs-subvol based containers with 
libvirt-lxc and it's quite useful... and in terms of on-disk hierarchy, each 
machine is a subvol at the toplevel in subvolid=0. Equal to the host.

i.e.:
subvol=.
  virt-host
  postgres
  powerdns
  ...etc...

Where postgres and powerdns are LXC container filesystems.

> Lennart
> 

___
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

[Lennart Poettering]

On Fri, 07.03.14 14:32, Hannes Reinecke (h...@suse.de) wrote:

> Old versions of powerd will be using the initctl fifo to signal
> state changes. To maintain backward compability systemd should
> be interpreting these messages, too.

Yuck. Can't say I am particularly enthusiastic adding compat kludges for
age old sw that so far nobody even noticed was broken with systemd. I'd
much rather get rid of systemd-initctl entirely...

But anyway, let's get this over with:

> +static int send_shutdownd(unsigned delay, char mode, const char *message) {
> +usec_t t = now(CLOCK_REALTIME) + delay * USEC_PER_MINUTE;

Nitpicking: we try to avoid mixing variable declaration and function calls. 
It's OK
to initialize variables when you declare them with some fixed value, but
please keep variable declarations and function infocations separate.

>  case INIT_CMD_POWERFAIL:
> +r = send_shutdownd(2, SD_SHUTDOWN_POWEROFF,
> +   "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?

Do we really have to make this ALL CAPS? I REALLY DON'T LIKE BEING
YELLED AT ALL THE TIME! ;-)

> +if (r < 0) {
> +log_warning("Failed to talk to shutdownd, shutdown 
> cancelled: %s", strerror(-r));
> +}

Hmm, please remove redundant {} for one-line if blocks, like here. 

> +return;
>  case INIT_CMD_POWERFAILNOW:
> +r = send_shutdownd(0, SD_SHUTDOWN_POWEROFF,
> +   "THE POWER IS FAILED! LOW BATTERY - 
> EMERGENCY SYSTEM SHUTDOWN!");
> +if (r < 0) {
> +log_warning("Failed to talk to shutdownd, proceeding 
> with immediate shutdown: %s", strerror(-r));
> +reboot(RB_ENABLE_CAD);
> +reboot(RB_POWER_OFF);

I'd prefer if we'd simply send SIGRTMIN+14 to PID 1. This triggers a
"medium clean" shutdown. It will kill all daemons immediately by force,
but it will still be putting all file systems into a clean state. It's
quick but still quite safe.

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 2/2] [V4] systemctl: for switch-root check, if we switch to a systemd init

[Lennart Poettering]

On Thu, 06.03.14 16:35, har...@redhat.com (har...@redhat.com) wrote:

> From: Harald Hoyer 
> 
> If "systemctl switch-root" is called with a specific "INIT" or
> /proc/cmdline contains "init=", then systemd would not serialize
> itsself.
> 
> Let systemctl check, if the new init is in the standard systemd
> installation path and if so, clear the INIT parameter,
> to let systemd serialize itsself.

Merged with some modifications to make the memory allocation
unnecessary.

I didn't test this though, could you have a closer look if everything
still works as intended with my changes?

Thanks!

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] systemd-run: extend bash completion

[Lennart Poettering]

On Wed, 05.03.14 23:48, Thomas H.P. Andersen (pho...@gmail.com) wrote:

> From: Thomas Hindoe Paaboel Andersen 
> 
> --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?

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-backlight and backlight level 0

[Lennart Poettering]

On Wed, 05.03.14 11:31, Josh Triplett (j...@joshtriplett.org) wrote:

> On restore, I'd suggest reading max_brightness, and if the stored value
> falls under a threshold of ceil(max_brightness/SOME_DIVISOR), restore it
> to that value instead.  (Ideally there should be some way to ask the
> driver "what level of brightness will produce a non-zero value in
> actual_brightness", but no such mechanism seems to exist.)
> 
> Does that sound reasonable?

I'd be willing to merge that on ignore put the brightness to at least
1 or 5% of the full range, for whatever is larger. i.e. MAX(1, 
max_brightness/20).

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 2/3] hostnamed: expose PrettyName and CpeName as bus properties

[Lennart Poettering]

On Tue, 04.03.14 23:01, Djalal Harouni (tix...@opendz.org) wrote:

> ---
>  src/hostname/hostnamed.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
> index fab0601..f8aea78 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,

Hmm, this really needs to carry "OS" or so in the name, since this is
not really a property of the host, but of the OS.

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_PRETTY_NAME],
> +   "CPE_NAME", &c->data[PROP_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("PrettyName", "s", NULL, offsetof(Context, data) + 
> sizeof(char*) * PROP_PRETTY_NAME, 0),
> +SD_BUS_PROPERTY("CpeName", "s", NULL, offsetof(Context, data)
>  + sizeof(char*) * PROP_CPE_NAME, 0),

The propery should probably be OperatingSystemPrettyName and
OperatingSystemCPEName or soo..

Also, please mark these as 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),


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

[Lennart Poettering]

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!

Thanks a lot!

> ---
>  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..ad359d6 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 *pretty_name;
> +char *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->pretty_name))
> +printf("  Operating System: %s\n", i->pretty_name);
>  
> -if (!isempty(cpe_name))
> -printf("   CPE OS Name: %s\n", cpe_name);
> +if (!isempty(i->cpe_name))
> +printf("   CPE OS Name: %s\n", i->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) 
> },
> +{ "PrettyName", "s", NULL, offsetof(StatusInfo, 
> pretty_name) },
> +{ "CpeName","s", NULL, offsetof(StatusInfo, 
> cpe_name) },
>  {}
>  };
>  
> @@ -195,6 +191,8 @@ fail:
>  free(info.pretty_hostname);
>  free(info.icon_name);
>  free(info.chassis);
> +free(info.pretty_name);
> +free(info.cpe_name);
>  free(info.virtualization);
>  free(info.architecture);
>  


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] core: add startup resource control option

[Lennart Poettering]

On Wed, 05.03.14 17:41, WaLyong Cho (walyong@samsung.com) wrote:

> Similar to CPUShares= and BlockIOWeight= respectively. However only
> assign the specified weight during startup. Each control group
> attribute is re-assigned as weight by CPUShares=weight and
> BlockIOWeight=weight after startup.  If not CPUShares= or
> BlockIOWeight= be specified, then the attribute is re-assigned to each
> default attribute value. (default cpu.shares=1024, blkio.weight=1000)
> If only CPUShares=weight or BlockIOWeight=weight be specified, then
> that implies StartupCPUShares=weight and StartupBlockIOWeight=weight.

Looks good, though there appears to be missing that we refresh all
cgroup props when we finished booting?

Before I merge this I'd like to add a system-wide state enum that can
export over the bus, that formalizes the startup/running/shutdown state
machine we can make use of for this.

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] Do not cache use_smack() value unless /sys is mounted

[Lennart Poettering]

On Fri, 28.02.14 17:09, Łukasz Stelmach (l.stelm...@samsung.com) wrote:

> use_smack() is called very early via mkdir_p_label(). This happens
> before /sys is mounted and hence before the authoritative information
> about smack is even available. To prevent caching of the invalid value
> check whether /sys/fs exists.

Hmm, it appears to me that we probably shouldn't invoke mkdir_p_label()
that early? Do you know which invocation this is?

It sounds really wrong trying to relabel a dir before the policy is
actually loaded...

> ---
>  src/shared/smack-util.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/shared/smack-util.c b/src/shared/smack-util.c
> index df194e0..96f365c 100644
> --- a/src/shared/smack-util.c
> +++ b/src/shared/smack-util.c
> @@ -33,6 +33,9 @@ bool use_smack(void) {
>  #ifdef HAVE_SMACK
>  static int use_smack_cached = -1;
>  
> +if (use_smack_cached < 0 && access("/sys/fs/", F_OK) < 0)
> +return false;
> +
>  if (use_smack_cached < 0)
>  use_smack_cached = access("/sys/fs/smackfs/", F_OK) >= 0;
>  


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] [BUG] debug logging is disabled at early stage

[Lennart Poettering]

On Fri, 28.02.14 15:19, Łukasz Stelmach (l.stelm...@samsung.com) wrote:

> Hello All,
> 
> I am debugging some problems around mount_setup_early() and find that
> systemd, with log_max_level set to LOG_INFO in log.c and configured
> hundred lines below in main.c, is unable to tell me things I'd like to
> know. Just for today I can change log_max_level to LOG_DEBUG but it
> seems this single throb should be configurable before anything may fail.
> 
> RFC?

It's difficult pulling this earlier. We want to keep a specific override
order in place between kernel cmdline, configuration file, env vars and
argv. However, at the same time not all of that is available at all the
time, and some things (like policy loading) need to take place before we
open an new fd...

So far when it came to debugging something this early in the code i just
recompiled the thing with a higher debug level, even if that sucks...

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] Setting cgroup properties on systemd --user

[Lennart Poettering]

On Mon, 24.02.14 19:48, Thomas Bächler (tho...@archlinux.org) wrote:

> I am trying to set properties on scopes or services of my user instance,
> for example:
> 
>  systemctl --user set-property --runtime foobar.scope CPUShares=150
> 
> This command returns without error, but in the journal, I get messages
> like this:
> 
> systemd[5054]: Failed to set cpu.shares on
> /user.slice/user-1000.slice/user@1000.service: No such file or directory
> 
> followed by a similar message for each unit that is active under my user
> instance.
> 
> What's going on here? Is this supposed to work?

Nope.

The perms logic for this hasn't been hashed out with Tejun yet. What I'd
like to see is that we can open up certain "safe" cgroup props for
unpriviliged systemd instances, like the ones for CPU shares. But this
hasn't been hashed out in all detail yet. For now, cgroup resource
control is only really available for system services.

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] commas vs spaces in config syntax

[Lennart Poettering]

On Tue, 25.02.14 23:08, Jason A. Donenfeld (ja...@zx2c4.com) wrote:

> Hey folks,
> 
> Just came across this section in the systemd-sleep.conf man page:
> 
> "More than one value can be specified by separating multiple values
> with commas."
> 
> But then I remember seeing in 99-default.link the line,
> "NamePolicy=database onboard slot path".
> 
> It seems like our configuration syntax is a bit inconsistent. Which is
> better? Should things change?

The documentation of sleep.conf is simply incorrect, we always use
whitespace as separator in our .conf files. 

Thanks for the pointer. Corrected in git.

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] systemctl: fix description of --after/--before

[Lennart Poettering]

On Fri, 21.02.14 20:44, Andrey Borzenkov (arvidj...@gmail.com) wrote:

> It was backward - --after fetches After property, so units shown really
> come *before* unit given as argument. Same for --before.

Applied! Thanks!

(I figure the whole paragraph could use some more comprehensive
rewording, doesn't sound like correct english...)

> 
> ---
>  man/systemctl.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/man/systemctl.xml b/man/systemctl.xml
> index 355cd11..fef9578 100644
> --- a/man/systemctl.xml
> +++ b/man/systemctl.xml
> @@ -148,8 +148,8 @@ along with systemd; If not, see 
> .
>  --before
>  
>  
> -  Show which units are started after or before
> -  with list-dependencies, respectively.
> +  Show after (before) which units the specified unit is started
> +  with list-dependencies.
>
>  
>


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] logind: add a debug message in case the session already exists

[Lennart Poettering]

On Wed, 19.02.14 23:17, Djalal Harouni (tix...@opendz.org) wrote:

Applied! Thanks!

> If the session already exists then the only way to log it is to set the
> debug option of pam_systemd. There are no debug messages in the login
> service that permits to log if the session already exists.
> 
> So just add it, and while we are it add the "uid" field to the debug
> message that indicates that the session was created.
> ---
>  src/login/logind-dbus.c | 11 +++
>  src/login/logind-session-dbus.c |  4 +++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
> index bd0de33..f9662a9 100644
> --- a/src/login/logind-dbus.c
> +++ b/src/login/logind-dbus.c
> @@ -594,6 +594,17 @@ static int method_create_session(sd_bus *bus, 
> sd_bus_message *message, void *use
>  if (!path)
>  return -ENOMEM;
>  
> +log_debug("Sending reply about an existing session: "
> +  "id=%s object_path=%s uid=%u runtime_path=%s "
> +  "session_fd=%d seat=%s vtnr=%u",
> +  session->id,
> +  path,
> +  (uint32_t) session->user->uid,
> +  session->user->runtime_path,
> +  fifo_fd,
> +  session->seat ? session->seat->id : "",
> +  (uint32_t) session->vtnr);
> +
>  return sd_bus_reply_method_return(
>  message, "soshusub",
>  session->id,
> diff --git a/src/login/logind-session-dbus.c b/src/login/logind-session-dbus.c
> index f9305dd..d5d7c24 100644
> --- a/src/login/logind-session-dbus.c
> +++ b/src/login/logind-session-dbus.c
> @@ -677,9 +677,11 @@ int session_send_create_reply(Session *s, sd_bus_error 
> *error) {
>  return -ENOMEM;
>  
>  log_debug("Sending reply about created session: "
> -  "id=%s object_path=%s runtime_path=%s session_fd=%d 
> seat=%s vtnr=%u",
> +  "id=%s object_path=%s uid=%u runtime_path=%s "
> +  "session_fd=%d seat=%s vtnr=%u",
>s->id,
>p,
> +  (uint32_t) s->user->uid,
>s->user->runtime_path,
>fifo_fd,
>s->seat ? s->seat->id : "",


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] README: audit no longer breaks container

[Lennart Poettering]

On Thu, 20.02.14 05:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> > -Note that kernel auditing is broken when used with systemd's
> > -container code. When using systemd in conjunction with
> > -containers, please make sure to either turn off auditing at
> > -runtime using the kernel command line option "audit=0", or
> > -turn it off at kernel compile time using:
> > -  CONFIG_AUDIT=n
>
> Only for kernel >= 3.14. I think we should say that.

I added a short text there now that clarifies that you don not have to
turn off audit if you are on an arch that does not require socketcall()
and that is supported by seccomp, and compiled your systemd with seccomp
enabled and run kernel 3.14...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel