[systemd-devel] Per session systemd?

[Yuxuan Shui]

Hi,

This mail might be a little bit later for the topic, but I would like
to share my thoughts anyway.

Before systemd 206 was released, there are a few users (I don't know
how many of them are there, but there's a page about it on archlinux's
wiki. So I guess it's a well-known use case.) who use systemd to
manage their sessions. For example, they will exec systemd in their
~/.xinitrc, and have systemd start all their X applications.

I know this kind of use case has never been explicitly supported by
systemd, but it was a really nice _accidental_ feature. However, after
the cgroup changes made in the systemd 206 release, it became
impossible to use systemd in such way.

I saw some user complaints, but the systemd developers seemed unmoved.
Maybe because the original purpose of systemd --user is to start
per-user systemd instances. There're hacks to make systemd usable
under a X session. But that's very complicated, and contains many
pitfalls (User have to set a lot of environmental variables, and this
makes logind unhappy since the systemd user instance is not in the
same session as X). Besides, there're reasonable use cases which can't
be covered by a per-user systemd instance, like periodically starting
a graphic application.

So, I wrote a very dirty hack for my systemd, and have been using it
till today. I add a 'User=' property to a session, and have systemd
chown the cgroup to the given user, so I can start systemd in my
.xinitrc as I used to. I admit this is probably a very bad hack, and
I'm not sure if it will still work after the soon coming cgroup
rework.

That's why I'm writing this mail. I want to point out the reason
behind use systemd as a session manager, so you will probably
understand why I want to do this and help me. Since I can't get this
done by myself with my limited systemd knowledge.

Any help will be appreciated. It will be better if you can convince me
that I'm stupid and this feature is totally useless.

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

[systemd-devel] Compilation with gcc-4.9 fails

[Jan Engelhardt]

Just informing you…

When building with GCC 4.9.0 [svn r208221], then the following happens:

$ make
[...]
make --no-print-directory all-recursive
Making all in .
  CC   src/libsystemd/sd-bus/libsystemd_la-sd-bus.lo
  CC   src/libsystemd/sd-bus/libsystemd_la-bus-control.lo
  CC   src/libsystemd/sd-bus/libsystemd_la-bus-error.lo
[...]

$ nm src/libsystemd/sd-bus/.libs/libsystemd_la-sd-bus.o 
0001 C __gnu_lto_slim
0001 C __gnu_lto_v1

systemd enables -flto by default, but the actual symbols are no
longer generated with gcc-4.9. They were in gcc-4.8, but perhaps LTO
was not effective in that version.

As a result, the "-export-symbols-regex" option passed to libtool
(see Makefile.am for it) yields no results as it relies on nm output.
Therefore, file .libs/libgudev-1.0.ver that is generated by
"-export-symbols-regex" is empty and causes further linker errors
down the road.

$ make
  CCLD libgudev-1.0.la
/usr/bin/ld.gold: error: .libs/libgudev-1.0.ver:2:1: syntax error, unexpected 
LOCAL, expecting STRING or QUOTED_STRING or EXTERN
/usr/bin/ld.gold: fatal error: unable to parse version script file 
.libs/libgudev-1.0.ver
collect2: error: ld returned 1 exit status

(Problem 2 (which has been reported): libtool should have warned about
an empty .ver, but it does not, leading to an undescriptive error.)

Further down one may spot, but that is just a result of the previous ones.

  CCLD systemd-cgls
src/cgls/cgls.c:131: error: undefined reference to 'log_parse_environment'
src/cgls/cgls.c:132: error: undefined reference to 'log_open'
src/cgls/cgls.c:214: error: undefined reference to 'pager_close'
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink

[Michael Biebl]

2014-03-03 5:37 GMT+01:00 Mike Gilbert :
> The symlink is created in bindir (/usr/bin), and points to a binary
> which lives in rootlibexecdir (/lib/systemd or /usr/lib/systemd). A
> relative symlink does not work here.
> ---
>  Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 38445fb..e7134a2 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -1978,7 +1978,7 @@ systemd_bus_proxyd_LDADD = \
>
>  bus-proxyd-install-hook:
> $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(bindir)
> -   $(AM_V_LN)$(LN_S) -f ../lib/systemd/systemd-bus-proxyd 
> $(DESTDIR)$(bindir)/systemd-stdio-bridge
> +   $(AM_V_LN)$(LN_S) -f $(rootlibexecdir)/systemd-bus-proxyd 
> $(DESTDIR)$(bindir)/systemd-stdio-bridge
>
>  bus-proxyd-uninstall-hook:
> rm -f $(DESTDIR)$(bindir)/systemd-stdio-bridge
> --
> 1.9.0
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Applied, thanks

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink

[Mike Gilbert]

The symlink is created in bindir (/usr/bin), and points to a binary
which lives in rootlibexecdir (/lib/systemd or /usr/lib/systemd). A
relative symlink does not work here.
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 38445fb..e7134a2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1978,7 +1978,7 @@ systemd_bus_proxyd_LDADD = \
 
 bus-proxyd-install-hook:
$(AM_V_at)$(MKDIR_P) $(DESTDIR)$(bindir)
-   $(AM_V_LN)$(LN_S) -f ../lib/systemd/systemd-bus-proxyd 
$(DESTDIR)$(bindir)/systemd-stdio-bridge
+   $(AM_V_LN)$(LN_S) -f $(rootlibexecdir)/systemd-bus-proxyd 
$(DESTDIR)$(bindir)/systemd-stdio-bridge
 
 bus-proxyd-uninstall-hook:
rm -f $(DESTDIR)$(bindir)/systemd-stdio-bridge
-- 
1.9.0

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

Re: [systemd-devel] StartLimitAction Feature

[Usman]

Thanks Lenart. Will give it a shot.

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

Re: [systemd-devel] Process Manager?

[David Farning]

I am approaching the situation from a slightly different perspective.

The recent acceptance of systemd as the default init system in Debian
and the statement by Canonical that Ubuntu will default to systemd,
possibly as soon as 14.10, means that there will be an influx of new
developers and administrators with an interest in systemd.

One way to help them is to provide a high quality funnel of
documentation to guide them through the learning curve. The people
that get lost or frustrated along the way, the more high quality
people will use and contribute to the project.

On Sun, Mar 2, 2014 at 8:29 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Sun, Mar 02, 2014 at 07:48:26PM -0600, David Farning wrote:
>> I would would be happy to work on upstream wiki site to help with
>> communication But I want to be careful not to overstep.
> Hi,
>
> quite a few people work on the documentation, but there still are
> extensive gaps. The TODO list includes the new sd_bus_* functions,
> examples in manpages (service file examples, udev rules examples,
> tmpfiles snippets examples), error code enumerations (newer manpages
> describe them, but older ones usually don't), and crosslinking various
> parts of documentation. If you want to work on the docs, those would
> be good areas to hack on, and we're generally very happy to take patches.
> The introductory texts were probably more important when systemd was
> less popular.
>
> Zbyszek
___
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 08:40 AM, Lennart Poettering wrote:
> On Fri, 28.02.14 20:45, WaLyong Cho (walyong@samsung.com) wrote:
> 
>> On 02/28/2014 06:16 PM, Thomas Bächler wrote:
>>> Am 28.02.2014 10:02, schrieb WaLyong Cho:
 systemd is already provide a special unit. If the type of unit is
 service then that is 'basic.target'. Additionally default extra
 dependency can be listed in system.conf and then other service unit will
 have "After=" dependency implicitly.
 In config directory /etc/systemd/default-extra-dependencies, if a
 service unit is listed ignore-units or exist symlink in ignore-units.d
 then the service units can be launched before extra dependencies.
>>>
>>> I am confused about the motivation here. This change adds several extra
>>> configuration primitives - one in system.conf, a new directory, and a
>>> mechanism to opt out of the new configuration. This is quite a lot for
>>> something that I find marginally useful at best. I think this
>>> functionality even enables an administrator to unwillingly break his
>>> system - setting this option likely has many unforeseen consequences,
>>> depending on the installed services.
>>>
>> This is just for optimizing boot up speed extremely. systemd said
>> "systemd provides aggressive parallelization capabilities," and
>> according to this too many service could race each on boot up time. This
>> functionality may be useless in desktop environment. However, it is
>> different in the embedded environment. Generally, in embedded, system is
>> made up with lower performance hardware. But User want to boot up his
>> device in short time. Actually, the boot up may be continued after some
>> of service(what listed config). But if the others are not important to
>> user then this functionality will be useful.
>>
>> As we are concerned, this functionality can break boot order.
>> But, unlike desktop, additional package will rarely NOT be installed
>> after product in embedded device. So in embedded environment,
>> administrator(s) will try to rearrange service launching order (like
>> me). If some of services wants be started before others then this
>> functionality can be useful. If not, that service should list others on
>> "Before=".
> 
> 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.

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

Re: [systemd-devel] StartLimitAction Feature

[Lennart Poettering]

On Sun, 02.03.14 18:00, Usman (deser...@yahoo.com) wrote:

> So actually i want to listen on dbus and somehow get a message when an
> application has restarted N number of times within time T and will not
> be started anymore. How do I differentiate this case from normal
> application Release message that I do get each time it restarts?

Application "Release" message? what are you referring to? There is no
such thing.

To watch the state of a unit, make sure to invoke Subscribe() on the
main manager object, and then simply watch standard PropertyChanged()
messages on that unit, and look for the "State" property.

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 Manager?

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 02, 2014 at 07:48:26PM -0600, David Farning wrote:
> I would would be happy to work on upstream wiki site to help with
> communication But I want to be careful not to overstep.
Hi,

quite a few people work on the documentation, but there still are
extensive gaps. The TODO list includes the new sd_bus_* functions,
examples in manpages (service file examples, udev rules examples,
tmpfiles snippets examples), error code enumerations (newer manpages
describe them, but older ones usually don't), and crosslinking various
parts of documentation. If you want to work on the docs, those would
be good areas to hack on, and we're generally very happy to take patches.
The introductory texts were probably more important when systemd was
less popular.

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

Re: [systemd-devel] StartLimitAction Feature

[Usman]

So actually i want to listen on dbus and somehow get a message when an 
application has restarted N number of times within time T and will not be 
started anymore. How do I differentiate this case from normal application 
Release message that I do get each time it restarts?

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

Re: [systemd-devel] Process Manager?

[Samuli Suominen]

On 03/03/14 03:48, David Farning wrote:
> Over the last couple of weeks I have been looking over and testing the
> systemd. Thanks for all the hard work and interesting ideas.
>
> One issue that has come to mind is the quality and structure of the
> documentation. The quality and clarity of the documentation can be as
> important as the quality and clarity of the code.  As a relatively
> young project the scope and implementation has shifted as new ideas
> have been tested.
>
> This has resulted in two areas of mis-communication:
> 1. What is systemd?
> 2. What is systemd... now?
>
> One suggestion would be to refer to systemd as a 'process manager.'

well, sys-apps/systemd is part of the virtual/service-manager in Gentoo,
so we call it 'service manager'

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

[systemd-devel] Process Manager?

[David Farning]

Over the last couple of weeks I have been looking over and testing the
systemd. Thanks for all the hard work and interesting ideas.

One issue that has come to mind is the quality and structure of the
documentation. The quality and clarity of the documentation can be as
important as the quality and clarity of the code.  As a relatively
young project the scope and implementation has shifted as new ideas
have been tested.

This has resulted in two areas of mis-communication:
1. What is systemd?
2. What is systemd... now?

One suggestion would be to refer to systemd as a 'process manager.'
Calling it a system manager seems a bit heavy handed... and results in
unnecessary pushback. Calling it an service manager understates the
scope of the project.

Something like 'systemd manages and optimizes the life cycle of all
processes from start up to shut down' might be a good one sentence
blurb.

I would would be happy to work on upstream wiki site to help with
communication But I want to be careful not to overstep.

Thanks
___
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

[Lennart Poettering]

On Fri, 28.02.14 20:45, WaLyong Cho (walyong@samsung.com) wrote:

> On 02/28/2014 06:16 PM, Thomas Bächler wrote:
> > Am 28.02.2014 10:02, schrieb WaLyong Cho:
> >> systemd is already provide a special unit. If the type of unit is
> >> service then that is 'basic.target'. Additionally default extra
> >> dependency can be listed in system.conf and then other service unit will
> >> have "After=" dependency implicitly.
> >> In config directory /etc/systemd/default-extra-dependencies, if a
> >> service unit is listed ignore-units or exist symlink in ignore-units.d
> >> then the service units can be launched before extra dependencies.
> > 
> > I am confused about the motivation here. This change adds several extra
> > configuration primitives - one in system.conf, a new directory, and a
> > mechanism to opt out of the new configuration. This is quite a lot for
> > something that I find marginally useful at best. I think this
> > functionality even enables an administrator to unwillingly break his
> > system - setting this option likely has many unforeseen consequences,
> > depending on the installed services.
> > 
> This is just for optimizing boot up speed extremely. systemd said
> "systemd provides aggressive parallelization capabilities," and
> according to this too many service could race each on boot up time. This
> functionality may be useless in desktop environment. However, it is
> different in the embedded environment. Generally, in embedded, system is
> made up with lower performance hardware. But User want to boot up his
> device in short time. Actually, the boot up may be continued after some
> of service(what listed config). But if the others are not important to
> user then this functionality will be useful.
> 
> As we are concerned, this functionality can break boot order.
> But, unlike desktop, additional package will rarely NOT be installed
> after product in embedded device. So in embedded environment,
> administrator(s) will try to rearrange service launching order (like
> me). If some of services wants be started before others then this
> functionality can be useful. If not, that service should list others on
> "Before=".

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?

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

-- 
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:

> 
> On Thu, Feb 20, 2014 at 02:53:28AM +0100, Jason A. Donenfeld wrote:
> > Ever since the seccomp trick, this is no longer an issue.
> > ---
> >  README | 7 ---
> >  1 file changed, 7 deletions(-)
> > 
> > diff --git a/README b/README
> > index b918132..df04cc9 100644
> > --- a/README
> > +++ b/README
> > @@ -83,13 +83,6 @@ REQUIREMENTS:
> >CONFIG_EFI_VARS
> >CONFIG_EFI_PARTITION
> >  
> > -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.

Also, it's still broken on i386, where we the seccomp trick doesn't work
on socket(), due to the i386 specific madness that is socketcall(). It
works fine on all other archs though, including x86-64.

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] StartLimitAction Feature

[Lennart Poettering]

On Fri, 28.02.14 09:15, Usman (deser...@yahoo.com) wrote:

> Thanks Lennart. Just a follow up question, can we get the "result"
> from the Agent Released message on the dbus somehow? Or which message
> should I be listening on dbus for this?

Sorry, for which message? I don't follow?

Why would you listen to any message? I am missing something here?

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] TODO: Simple conditionals in tmpfiles

[Lennart Poettering]

On Fri, 28.02.14 06:36, Josh Triplett (j...@joshtriplett.org) wrote:

> ---
> 
> Strawman proposal, open to suggestions.  A change like this would make
> tmpfiles flexible enough to detect what permission configuration an
> admin wants to use and go along with that.  In general, "set a
> directory's permissions based on the set{u,g}id status of the binary"
> seems common enough to want to support; tmpfiles can implement this with
> a simple stat and comparison.
> 
> Could potentially be more configurable, by capturing the mode, user, and
> group of the item listed as the conditional path, and making them
> available as placeholders within the subitem, but that seems like
> overkill for the most common cases.

> 
>  TODO | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/TODO b/TODO
> index 6cac3e2..988f855 100644
> --- a/TODO
> +++ b/TODO
> @@ -570,6 +570,10 @@ Features:
>  * tmpfiles:
>- check systemd-tmpfiles for selinux context hookup for mknod(), symlink() 
> and similar
>- apply "x" on "D" too (see patch from William Douglas)
> +  - Simple conditionals: "C path mode user group - (tmpfiles-line)" does 
> tmpfiles-line if path has mode, user, and group:
> +C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775 root utmp
> +C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755 root utmp
> +C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777 root utmp


Hmm, I don't really grok the use case here. /usr/bin/screen is not owned
by the admin, but by the OS/packager. It really doesn't sound like
asking to much if the OS/packer ships a tmpfiles snippet that's in sync
with the mode of the binary file... Or alternatively, if the admin
really chooses to override the package manager here, then he can also
just drop-in another tmpfiles snippet that overrides the shipped one?

It sounds really strange to add a hook to make something configurable
depending on something else that is not really configuration...

Lennart

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

Re: [systemd-devel] [RFC/PATCH] tmpfiles: implement --transform=rpm

[Lennart Poettering]

On Sun, 02.03.14 15:38, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Sun, Mar 02, 2014 at 06:14:58AM +0100, Kay Sievers wrote:
> > On Sun, Mar 2, 2014 at 3:06 AM, Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > +   " --transform=rpm   Create files list suitable 
> > > for RPM %%files section\n"
> > 
> > Hmm, can't we maybe come up with something that isn't specific to rpm
> > or dpkg, something that is easily parsed but not bound to the
> > internals of the format of the files?
> > 
> > It sounds like the-wrong-way-around to encode packaging formats into
> > high-level systemd tools. In the end, both formats are really a blast
> > from the past, and represent the status quo, but are surely not the
> > future of how packaging of of a modern Linux system should look like,
> > so it might be nicer to make it generic?
> 
> Something like this would certainly work too:
> output from systemd-tmpfiles would be just
> /some/file
> /some/dir/
> ...
> 
> and it would be used as
> 
> %install
> systemd-tmpfiles --transform=list ... | sed 's|.*/$|%dir \0|;
> s|^/|%ghost /;' > .tmpfiles.list

This could even be turned into a shell read loop I figure... I do like
the general concept.

> This makes the "consumer" side slightly more complex, but I guess we could
> wrap this is in a macro too.

I am pretty sure that whatever we end up adding here, it should come
with an RPM macro from day 1, so that we have some freedom to change
around later on should we need it.

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] binding tmpfiles.d to unit startup

[Lennart Poettering]

On Sat, 01.03.14 21:01, Colin Walters (walt...@verbum.org) wrote:

> On Sat, Mar 1, 2014 at 2:46 PM, Colin Walters 
> wrote:
> >
> >RuntimeDirectory=/run/mydaemon
> >PersistentStateDirectory=/var/lib/mydaemon
> >
> Btw, see also this thread:
> 
> https://lists.fedoraproject.org/pipermail/server/2014-February/000843.html
> 
> Putting these together (and how about we just go ahead and mandate
> /run and /var/lib), we could have something like:
> 
> RuntimeDirectory=yes
> 
> That would auto-instantiate /run/$SYSTEMD_UNIT_NAME.

Would $SYSTEMD_UNIT_NAME according to your suggestion map to %n or to %p
or to %i, followign systemd's specifier notation? (see systemd.unit(5)).

> Notably, this would help administrators move away from the package
> being the central naming unit and more towards systemd being the
> basis for names.
> 
> (It is confusing that one has to deal with package names, systemd
> unit names, and process names, which can all be the same, closely
> related, or wildly different)

So far we stayed out of the business of being normative on how to name
things. Which I figure is something we can get away with as long as we
focus on building an OS. I wonder though whether unit files like this
would be the right place to start enforcing naming rules for 3rd party
apps...

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] binding tmpfiles.d to unit startup

[Lennart Poettering]

On Sat, 01.03.14 19:46, Colin Walters (walt...@verbum.org) wrote:

> Certainly it magnifies the pain for the RPM world in that there's
> nothing that scans the build directory and says "hey you installed
> something that looks like a tmpfiles.d snippet, let me auto-generate
> some postinst shell script".

But that is fixable. RPM could do that. The same way it scans .so files
and creates deps from it.

> I think any postinsts like this are still pretty ugly though.  It
> means the directories are created when the daemon is *installed*,
> not when it's run.  Which is odd and against the generally dynamic
> nature of systemd.

Well, but /var and /etc are by their very nature non-volatile,
non-dynamic. We shouldnt set up more during runtime then we really have
to...

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] binding tmpfiles.d to unit startup

[Lennart Poettering]

On Sat, 01.03.14 20:18, Tom Gundersen (t...@jklm.no) wrote:

> 
> On Sat, Mar 1, 2014 at 8:04 PM, Michael Biebl  wrote:
> > 2014-03-01 19:47 GMT+01:00 Colin Walters :
> >> On Sat, Mar 1, 2014 at 1:44 PM, Michael Biebl  wrote:
> >>
> >> I vaguely remember that we exactly had this discussion a while ago.
> >>
> >>
> >> Argh, yes, possibly. The dangers of getting older...
> >>
> >> Unfortunately I'm not able to find it in the archives right now.
> >
> > Found it: 
> > http://lists.freedesktop.org/archives/systemd-devel/2013-July/011956.html
> 
> And a bit further down that thread there was this proposal from Lennart
> (which doesn't seem far from what Colin wants):
> .

I am still open for this btw. If somebody wants to hack on that, I
figure this should simply be addded to ExecContext, as a strv of
directory names. In exec_spawn() we'd then just create all those dirs,
right after resolving the UID/GID. When running in system mode we'd then
create the dirs in /run, when running user mode in $XDG_RUNTIME_DIR.

Should be a ~20 line patch or so...

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] binding tmpfiles.d to unit startup

[Lennart Poettering]

On Sat, 01.03.14 14:46, Colin Walters (walt...@verbum.org) wrote:

Hi!

> So for OSTree I am trying to move to a model where services populate
> the contents of /var on *start*.  See previous discussion here:
> 
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg07859.html
> 
> The really great part about this is that one is then able to totally
> reset OS state at any time by simply just doing a shutdown of
> services, then "rm -rf /var/*", then  reboot.  (You can also reset
> /etc, that's a separate discussion)

There has been this long-time TODO list item of ours to create something
we called "provisioning" (though the name might be misleading, but
that's the keyword we are currently using for it). The provisioning
scheme would basically consist of another directory in /usr/lib that
contains snippets that are inspired by tmpfiles.d/, but are
different. These files would describe what to do if /etc or /var are
found empty at boot. The would not only list files and directories to
create or copy, but also contain information so that we can reconstruct
/etc/passwd and /etc/group to match UIDs and GIDs used in /usr already.

Maybe something like this:

u root 0
g mail /usr/bin/procmail
g tty /usr/bin/write
d /var/lib/foobar 664 root root
c /etc/sudoers /usr/share/sudo/sudoers.default

This snippet would create one user with UID and call it "root". It would
create a group "mail" with a GID that matches the current gid owner of
/usr/bin/procmail, and one "tty" with the GID that matches the current
gid owner of /usr/bin/write. Then, it would also create a dir in
/var/lib. Finally it would copy a sudoers file into place from some
source in /usr (though maybe we should not allow copying files with
this, so that people don't get too lazy, and instead just provide
symlinks).

Then, we'd add a generator that checks for the existance of
/etc/machine-id or so (which we simply use as a flag file for
uninitialized systems here). If it is missing we boot into a special
boot target "provision.target" or so, which runs our provisioning tool
that simply reconstructs everything according to these files, and then
continues booting into default.target. There could even be a kernel
cmdline option that results in this being executed called
"systemd.provision=1" or so. Since "privision.target" is a target like
any other packages could even pull in their own code snippets from this
target if they really want to, but of course this would be quite
contrary to the entire goal which is to have a declarative description
of the system rather than one in code.

These snippets could then also be hooked up with RPM, so that RPM adds
the files listed therein automatically to its file list, and they can be
executed at package installation time with some RPM macro.

The provisioning tool that applies these files could of course also be
run manually on the command line, and much like tmpfiles support a
scheme to only reconstruct a subset of the file system hierarchy (for
example only /var).

For a container usecase this would allow us to have an OS /usr tree
somewhere which we then can mount into hundreds of containers, and on
their first start-up they would get a fully populated /var and /etc.

Colin, when you ask for doing this setup for /var right before starting
up a service, wouldn't it be nicer if we just did that on package
installation if we can, and on boot if /var is empty? Wouldn't this
"provisioning" concept work for you?

> Thoughts?  Should be a pretty easy patch.

I am not convinced that'd would be a good idea to place information
about this into the unit files. The unit files have been designed to be
something we only read on demand, when referenced. However, such
reconstruction logic is this kind of static thing where such an
on-demand concept would be really inappropriate.  This makes it "feel" a
bit incomptible, I'd say.

Also, it just sounds wrong to make changes to persistent file systems
during runtime, when they could be done at install time already... 

Another problem is the one of NSS. We cannot resolve user names from
PID1, since we cannot block on the network, we cannot be client to other
services and we cannot have dynamic NSS modules loaded into PID 1. Thus
creating files from PID 1 is difficult. (Though not impossible. That's
where the restriction like RuntimeDirectory= would be nice btw, since we
know that at least the backing fs isn't blocking, and we could add this
into the preparation step for executing processes, i.e. right after the
fork() in the child, before we exec() the daemon to start. Or we could
even introduce a new service state that is done before ExecStartPre= and
that to doesn't execute any external binaries, but simply does the NSS
stuff and fs access in a forked off process that does what it needs to
do and quickly exits, and never does exec(). -- but anyway, the
take-away here is probably that it is harder thatn it might sound...)

Lennart

-- 
Lennart Po

Re: [systemd-devel] How to build systemd with statically linking

[Lennart Poettering]

On Sun, 02.03.14 12:05, Samuli Suominen (ssuomi...@gentoo.org) wrote:

> > Why would you do something like that? That's just broken.
> >
> > Also the API between udevd and libudev is not stable, you should never
> > mix different implementations.
> >
> > Lennart
> >
> 
> Well, believe it or not, there are people using udev with alternate
> service managers
> like runit or openrc with a crypted / and a sep. /usr, without initramfs
> And such an setup takes quite a knowledge to setup, so the same people
> capable
> of doing that, are well aware of the pitfall of mandatory recompile of
> the static
> binaries in case of an upgrade
> I've talked about this with cryptsetup upstream ever since the
> configure.ac snippet
> was added to systemd, and even cryptsetup upstream *wants* to support such
> configuration and sees no reason to remove the support for it
> As in, their configure.ac is specifically designed to support building
> --enable-static-binaries,
> or similar
> Same goes for LVM2
> Ie. their configure.ac's have calls to `pkg-config --static --libs
> libudev $any other package required`
> and result ends up in vars like CRYPTSETUP_STATIC_LIBS= or LVM2_STATIC_LIBS=
> 
> So, if it's possible, even with some hackery, someone will for sure do it :)

Well, if the answer to "why would you do that" is simply "because we
can", then I really don't see why we should bother supporting something
like that. It's so pointless...

But anyway, this is Free Software, so you are welcome to do with it
whatever you want, just know that we think this is really non-sensical
and don't expect us to support this upstream.

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] Set environment for user@.service

[Lennart Poettering]

On Sun, 02.03.14 11:22, subi.the.dream.wal...@gmail.com 
(subi.the.dream.wal...@gmail.com) wrote:

> 
> Hi,
> 
> Before systemd 209, I put 'Environment=ENV=%h/.somedir' in
> /etc/user@.service.d/env.conf to set some variables. Now since %h is not
> available for system units anymore, I take the workaround by adding a
> user unit set-my-env.service:
> -
> [Unit]
> Description=Set systemd environment
> Before=default.target
> 
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=-/usr/bin/systemctl --user set-environment ENV=%h/.somedir
> 
> [Install]
> WantedBy=basic.target
> 
> 
> The problem is that set-my-env.service may not affect the early units
> pulled in by default.target. I wonder how we can execute
> set-my-env.service as soon as user@.service is started. Thanks.

You can use DefaultEnvironment in user.conf, and place that either in
/etc/systemd/user.conf, or in ~/.config/systemd/user.conf. Do you need
anything else?

Alternatively you can use pam_env for this?

Lennart

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

[systemd-devel] [PATCH] metadata: use the subjective cred of current

[Djalal Harouni]

In kdbus_meta_append_*() we want to get the subjective context, so
instead of using __task_cred() which reference the objective cred,
use current_cred() to access the subjective cred.

Signed-off-by: Djalal Harouni 
---
Compile tested and make check

 metadata.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/metadata.c b/metadata.c
index df05b43..75fc819 100644
--- a/metadata.c
+++ b/metadata.c
@@ -292,21 +292,18 @@ static int kdbus_meta_append_cmdline(struct kdbus_meta 
*meta)
 
 static int kdbus_meta_append_caps(struct kdbus_meta *meta)
 {
-   const struct cred *cred;
struct caps {
u32 cap[_KERNEL_CAPABILITY_U32S];
} cap[4];
unsigned int i;
+   const struct cred *cred = current_cred();
 
-   rcu_read_lock();
-   cred = __task_cred(current);
for (i = 0; i < _KERNEL_CAPABILITY_U32S; i++) {
cap[0].cap[i] = cred->cap_inheritable.cap[i];
cap[1].cap[i] = cred->cap_permitted.cap[i];
cap[2].cap[i] = cred->cap_effective.cap[i];
cap[3].cap[i] = cred->cap_bset.cap[i];
}
-   rcu_read_unlock();
 
/* clear unused bits */
for (i = 0; i < 4; i++)
@@ -341,15 +338,8 @@ static int kdbus_meta_append_cgroup(struct kdbus_meta 
*meta)
 static int kdbus_meta_append_audit(struct kdbus_meta *meta)
 {
struct kdbus_audit audit;
-   const struct cred *cred;
-   uid_t uid;
 
-   rcu_read_lock();
-   cred = __task_cred(current);
-   uid = from_kuid(cred->user_ns, audit_get_loginuid(current));
-   rcu_read_unlock();
-
-   audit.loginuid = uid;
+   audit.loginuid = from_kuid(current_user_ns(), 
audit_get_loginuid(current));
audit.sessionid = audit_get_sessionid(current);
 
return kdbus_meta_append_data(meta, KDBUS_ITEM_AUDIT,
-- 
1.8.5.3

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

Re: [systemd-devel] [RFC/PATCH] tmpfiles: implement --transform=rpm

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 02, 2014 at 06:14:58AM +0100, Kay Sievers wrote:
> On Sun, Mar 2, 2014 at 3:06 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > +   " --transform=rpm   Create files list suitable for 
> > RPM %%files section\n"
> 
> Hmm, can't we maybe come up with something that isn't specific to rpm
> or dpkg, something that is easily parsed but not bound to the
> internals of the format of the files?
> 
> It sounds like the-wrong-way-around to encode packaging formats into
> high-level systemd tools. In the end, both formats are really a blast
> from the past, and represent the status quo, but are surely not the
> future of how packaging of of a modern Linux system should look like,
> so it might be nicer to make it generic?

Something like this would certainly work too:
output from systemd-tmpfiles would be just
/some/file
/some/dir/
...

and it would be used as

%install
systemd-tmpfiles --transform=list ... | sed 's|.*/$|%dir \0|; s|^/|%ghost /;' > 
.tmpfiles.list

This makes the "consumer" side slightly more complex, but I guess we could
wrap this is in a macro too.

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

Re: [systemd-devel] How to build systemd with statically linking

[Samuli Suominen]

On 01/03/14 22:07, Lennart Poettering wrote:
> On Sat, 01.03.14 20:36, Samuli Suominen (ssuomi...@gentoo.org) wrote:
>
>> On 01/03/14 20:11, Lennart Poettering wrote:
>>> On Sat, 01.03.14 17:46, Ȳ�翵 (j-zero.hw...@samsung.com) wrote:
>>>
 Hello,

 I've tried to build systemd(v43) with statically linking.

 I revised Makefile.am and spec file but it was not built statically.
>>> We do not support static linking. We probably should turn this off
>>> entirely in the build system if there is a way, to make sure people get
>>> a clean error.
>> configure.ac already has:
>>
>> AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static
>> is not supported by systemd])])
>>
>> as the user was trying to build version 43, that'd explain why he didn't
>> see it, as that snippet wasn't added
>> at that time yet.
>> in any case, please don't make the building of libudev.a any more harder
>> than it is now, i know it has it's
>> pitfalls, and it shouldn't be officially supported in any way, but if
>> you know what you are doing, you can,
>> by removing this snippet from configure.ac, get a semi-working libudev.a
>> which is a prerequisite for
>> building static lvm2/cryptsetup binaries
> Why would you do something like that? That's just broken.
>
> Also the API between udevd and libudev is not stable, you should never
> mix different implementations.
>
> Lennart
>

Well, believe it or not, there are people using udev with alternate
service managers
like runit or openrc with a crypted / and a sep. /usr, without initramfs
And such an setup takes quite a knowledge to setup, so the same people
capable
of doing that, are well aware of the pitfall of mandatory recompile of
the static
binaries in case of an upgrade
I've talked about this with cryptsetup upstream ever since the
configure.ac snippet
was added to systemd, and even cryptsetup upstream *wants* to support such
configuration and sees no reason to remove the support for it
As in, their configure.ac is specifically designed to support building
--enable-static-binaries,
or similar
Same goes for LVM2
Ie. their configure.ac's have calls to `pkg-config --static --libs
libudev $any other package required`
and result ends up in vars like CRYPTSETUP_STATIC_LIBS= or LVM2_STATIC_LIBS=

So, if it's possible, even with some hackery, someone will for sure do it :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel