Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-14 Thread Martin Pitt
Hello all,

Ulrich Windl [2019-05-14  8:35 +0200]:
> I knew that. It doesn't answer _why_ /var/run is obsolete.

The short reason is that /var can be on a separate partition, so it's not
available during early mount or late shutdown, or in a rescue environment with
only the root fs mounted. Some adventurous people even have it on NFS.

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

Re: [systemd-devel] Permanently Ban for Dovecot

2019-03-10 Thread Martin Pitt
Hello Onno,

Onno Verbeek [2019-03-10 14:52 +0100]:
> I’ve setup my firewalls pretty tight, I just run into a problem with the 
> firewall for dovecot.
> When someone is trying to login, they get blocked after 5 try’s. I would like 
> to ban the ip permanently, for now the ban seems to be cancelled after 4 
> hours. 

This sounds like fail2ban.

> Does anyone know how to ban the ip permanently?

This depends on  which firewall software you use (which is for permanent
configuration, not temporary like fail2ban).

This is totally unrelated to systemd, so please rather consult the
documentation or ask on the mailing lists/forum of  your firewall software.

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

Re: [systemd-devel] Graphical session targets as standard

2018-07-04 Thread Martin Pitt
Hello Alberto,

Alberto Salvia Novella [2018-07-04  1:56 +0200]:
> Requested on:
> - gitlab.gnome.org/GNOME/gdm/issues/396
> - github.com/CanonicalLtd/lightdm/issues/29
> - github.com/sddm/sddm/issues/1044
> - bugs.freedesktop.org/show_bug.cgi?id=107107

These are invalid, please see my previous reply on the list.
Also, please don't cut away the https:// from links, this makes it impossible
to click on them.

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


Re: [systemd-devel] Graphical session targets as standard

2018-06-30 Thread Martin Pitt
Hello Alberto,

Alberto Salvia Novella [2018-06-28  6:33 +0200]:
> Currently many Linux Distributions don't activate graphical-session.target
> and graphical-session-pre.target during login.
> 
> I liked to know which software should ideally be in charge of that. So I can
> inform their developers about it, and have that behavior widely adopted.

These should never be enabled or started directly. It is merely an abstract
alias for any concrete X session such as {gnome,xfce,kde}-session.target.
Please see the following for more information:

  * man systemd.special
  * https://github.com/systemd/systemd/commit/c92fcc4f4375b0
  * My talk about it: https://www.youtube.com/watch?v=hq18daxTkLA
  * Slides for the talk: 
https://people.debian.org/~mpitt/systemd.conf-2016-graphical-session.pdf

Martin


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Apparmor and ureadhead failed to start

2018-01-11 Thread Martin Pitt
Hello Dorian,

Dorian ROSSE [2018-01-10  9:35 +]:
> Since I have kernel 4.14.12 I have two errors :
> 
> apparmor failed because It failed to start LSB the status exit code is 123 
> and there is a error by program /etc/apparmor.d/usr.lib.snapd-confine.real in 
> line 11 unable to open /var/lib/snapd/apparmor/snap-confine.d (skipping 
> profile in /etc/apparmor.d/disable : usr.sbin.rsyslogd
> 
> For ureadahead It is more easy I have nor wrote in red but It is answered 
> that need file that status exit code is five not installed which main PID 4039

Please contact the Ubuntu bug tracker about this. These issues are not at all
related to upstream systemd development.

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


[systemd-devel] ANN: CI now tests meson and rebases

2017-04-27 Thread Martin Pitt
Hello all,

quick announcement for things to watch out for in PR integration tests.

After Zbigniew's meson build system work landed two days ago [1], I now set up
our CI so that the "xenial-s390x" test builds using meson, while i386 and amd64
continue to run the classic autotools build. I initially set it up for amd64,
but that causes reboot failures in the "boot-smoke" test which need some time
to get investigated, as this doesn't reproduce in QEMU.

Semaphore also still runs autotools. I just backported the necessary
ninja/meson packages and I'll look at setting up another job for meson in the
next days.

While I was at it, I also fixed the "xenial-*" tests to rebase a PR to current
master before building/testing. Until now they tested the literal PR code,
which was an oversight. Now what is being built and tested reflects what will
be landed much more closely, and this will also avoid the current PRs to
suddenly fail because they weren't done against meson yet. But this rebase step
also introduces a new failure mode, although github should already detect
un-mergeability in most cases.

I test-drived this in my old guinea pig [2] PR, which is ancient. I. e. that it
succeeds proves that rebasing worked, and that the downstream packaging works
correctly (enough) with meson. However, it currently fails with some linker
errors [3], these still need to get fixed. Once they do, we'll have CI for the
meson build and from then on hopefully don't break it any more.

Thanks,

Pitti

[1] https://github.com/systemd/systemd/pull/5704
[2] https://github.com/systemd/systemd/pull/4611
[3] 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-systemd-semaphore/xenial/s390x/s/systemd-upstream/20170427_101741_d8343@/log.gz
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Disabling 'Predictable Network Interface Names'

2017-03-07 Thread Martin Pitt
Hello Lucas,

Lucas Ventura Carro [2017-03-07  9:25 +0100]:
> (1) Creating a symlink
> (2) Changing a kernel boot parameter
> 
> But, using option (1) doesn't work, and I'm still having predictable names.

Did you rebuild the initrd after that? Without that, it won't work indeed.

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


Re: [systemd-devel] [PATCH] add LIB_ARCH_TUPLE for tilegx-linux-gnu

2017-02-27 Thread Martin Pitt
Helmut Grohne [2017-02-27 16:51 +0100]:
> The following changes since commit 3c3fff44b2c46818bc240e3237925ad927b2831e:
> 
>   man: fix typo (#5468) (2017-02-27 13:59:11 +0100)
> 
> are available in the git repository at:
> 
>   git://git.subdivi.de/~helmut/systemd.git tilegx
> 
> for you to fetch changes up to c05c6e9cedf20b64b22249f88af514a70b6edd4b:
> 
>   add LIB_ARCH_TUPLE for tilegx-linux-gnu (2017-02-27 16:21:06 +0100)

Imported into https://github.com/systemd/systemd/pull/5474

Thanks!

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


Re: [systemd-devel] systemd-networkd in initrd

2016-12-25 Thread Martin Pitt
Hello Thijs,

Thijs Cramer [2016-12-23 17:26 +0100]:
> I've already done that, and at the time the hook is executed i'm
> printing the contents of /etc/passwd (inside the initrd) and it prints
> the entries just fine.
> Could it be the lack of dbus? Maybe it tries to gather more
> information from the user other than /etc/passwd?

No, networkd works fine without D-Bus (of course you can't use D-Bus specific
functionality then, mostly transient hostnames and DHCP-acquired timezones).
I've tried it myself in a Debian initramfs-tools context (which has no systemd
nor D-Bus nor much other bells and whistles aside from busybox and udev) and it
works fine.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-timesyncd with read-only root filesystem

2016-12-10 Thread Martin Pitt
Hello André,

André Hartmann [2016-12-09 10:46 +0100]:
> To sum up again what I actually want to achive:
> 
> I want to use NTP after bootup by default, but in case no NTP is available,
> the user should be able to set the date and time by hand
> with timedatectl. But timedatectl refuses to do so, if "NTP is enabled".
> 
> And this is my main problem: I don't know how timedatectl decides
> if NTP is enabled or not.

It checks whether systemd-timesyncd.service is enabled. Likewise,
enabling/disabling NTP with "timedatectl set-ntp" is just a frontend
for "systemctl enable/disable systemd-timesyncd.service".

Again this requires /etc/systemd/system/ to be writable, of course --
but if you want to allow users to configure the system
(/etc/systemd/system/ or /etc/timezone etc.) you need to have at least
these directories writable.

> > > # systemctl status systemd.timesyncd
> > > *  systemd.timesyncd.service
> > >Loaded: not-found (Reason: No such file or directory)
> > >Active: inactive (dead)

It's systemd-timesyncd (dash, not dot).

Viele Grüße,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-timesyncd with read-only root filesystem

2016-12-09 Thread Martin Pitt
Hello André,

André Hartmann [2016-12-08  9:28 +0100]:
> My main problem is that I cannot disable NTP by setting
> the link to /dev/null as the root partition is read-only.

Well, of course you can't change the image configuration after
building it -- you need to disable the service in the image build
process. If you don't have any writable files you can naturally not
change the unit configuration. Maybe I'm missing something here, but
this in no way timedated or even systemd specific?

> And till now I don't understand how timedatectl decides
> "NTP enabled: yes/no". I need a possibility to disable NTP
> in case the user will set the date by hand (also enabling
> it again if the user decides otherwise).

This actually sounds like you do want to keep at least parts of /etc/
writable, as otherwise there is no place to store things like
"disabled services" or "changed time zone".

> Which confuses me is the inconsistency between
> "systemctl status systemd.timesyncd" and "timedatectl status":
> 
> # systemctl status systemd.timesyncd
> *  systemd.timesyncd.service
>Loaded: not-found (Reason: No such file or directory)
>Active: inactive (dead)
> 
> # timedatectl status
>   Local time: Wed 2016-12-07 16:18:06 UTC
>   Universal time: Wed 2016-12-07 16:18:06 UTC
> RTC time: n/a
>Time zone: Universal (UTC, +)
>  NTP enabled: yes
> NTP synchronized: no
>  RTC in local TZ: no
>   DST active: n/a

I don't see an inconsistency? If timedated is not running then
timedatectl can't actualy talk to it and just shows values which it
can make up by itself.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-timesyncd with read-only root filesystem

2016-12-04 Thread Martin Pitt
Hello André,

André Hartmann [2016-12-01 11:20 +0100]:
> In other words: once this symlink is valid, you cannot invalidate it by
> make it a dangling symlink, you have to remove it. Can somebody confirm this
> observation?

Not a dangling one, but you should be able to make a symlink in /etc
pointing to /dev/null. This is called "masking" and what "systemctl
mask" does, and is sort of a stronger version of "disable" (in the
sense that it will also not be started any more through Requires= and
friends).

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

2016-12-02 Thread Martin Pitt
Kai Krakow [2016-12-02  8:47 +0100]:
> Am Thu, 17 Nov 2016 18:53:53 +0100
> schrieb Lennart Poettering <lenn...@poettering.net>:
> > I now added a small extension to this line: "(to the level the
> > firmware permits this)" ot clarify that we are bound by firmware
> > limitations for this.
> I think this should be pointed out better. In the common case, with
> usual firmwares out there, names change in unpredictable ways if you
> swap hardware. This, of course, totally reverses what the man page says
> about "even when hardware is added/removed"...

It does not *totally* reverse it -- existing interface names remain
stable in a lot of cases actually, just not with your case where the
firmware decides to rearrange the numbering completely (which should
hopefully not be the majority of cases, given how few reports we get
about it). So IMHO the "(to the level the firmware permits this)"
qualification seems to adequately address that?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-timesyncd with read-only root filesystem

2016-12-01 Thread Martin Pitt
Hello André,

André Hartmann [2016-12-01  9:50 +0100]:
> So I naively created the following link structure (which works):
> 
> /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service ->
> /mnt/writeable/systemd-timesyncd ->
> /lib/systemd/system/systemd-timesyncd.service
> 
> But if I remove /mnt/writeable/systemd-timesyncd and reboot,
> the command 'timedatectl status' still reports enabled, which is unexpected.

This is because systemd only really looks at the foo.wants/bar.service
symlink itself -- it's actually okay for that to point into
nothingness. I think this is mostly due to the fact that the actual
units can be in /etc, /usr, or /run, and even move between those.

For example, you might have

  /usr/lib/systemd/system/foo.service
  /usr/lib/systemd/system/multi-user.target.wants/foo.service → ../foo.service

and then override this with

  /etc/systemd/system/foo.service

Then multi-user.target will still use the unit from /etc, *not* the
one from  /usr, even though that's where the symlink points to. In
this case this is pretty obviously the correct behaviour; in your case
it's admittedly confusing.

I'm not entirely sure if dangling symlinks should be counted as
"enabled", but this should least explain your observation.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Promoting a pull request

2016-11-22 Thread Martin Pitt
Hello Jouke,

Jouke Witteveen [2016-11-22 11:44 +0100]:
> I see no way of (trying to) removing the reviewed/needs-rework label
> in the PR interface.

I click on the cog next to "Labels" on the right, there I can "untick"
labels. I've done so for #4259.

So maybe it's just UI obfuscation, but perhaps label setting/removing
is limited to project members?

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to make udev not touch my device?

2016-11-04 Thread Martin Pitt
Hello Michal,

Michal Privoznik [2016-11-04  8:47 +0100]:
> That means that whenever a VM is being started up, libvirtd (our
> daemon we have) relabels all the necessary paths that QEMU process
> (representing VM) can touch.

Does that mean it's shipping an udev rule that does that? Or actually
listens to uevents by itself (possibly via libudev) and applies the
labels?

> However, I'm facing an issue that I don't know how to fix. In some cases
> QEMU can close & reopen a block device. However, closing a block device
> triggers an event and hence if there is a rule that sets a security
> label on a device the QEMU process is unable to reopen the device again.

Is that triggering the above libvirtd action (in the daemon via
libudev or via an udev rule), or is that something else?

> My question is, whet we can do to prevent udev from mangling with our
> security labels that we've set on the devices?

Sorry for my ignorance, but my question in return is: What's the udev
rule that mangles with it in the first place? I don't see any such
rule in upstream systemd or in Debian/Ubuntu, but it's of course
possible that Fedora ships such a rule via another package.

> One of the ideas our lead developer had was for libvirt to set some kind
> of udev label on devices managed by libvirt (when setting up security
> labels) and then whenever udev sees such labelled device it won't touch
> it at all (this could be achieved by a rule perhaps?). Later, when
> domain is shutting down libvirt removes that label. But I don't think
> setting an arbitrary label on devices is supported, is it?

It actually is -- they are called "tags" (TAG+=) and "properties"
(ENV{PROPNAME}="foo"), see udev(7). So indeed the most straightforward
way would be to tag or set a property on those devices which you want
to handle in libvirtd yourself, and then add something like

   TAG=="libvirtd", GOTO="skip_selinux_context"
   [... original rule that changes context goes here ..]
   LABEL="skip_selinux_context"

But for further details I need to understand the actual rules
involved.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] getting systemd 232 ready

2016-10-21 Thread Martin Pitt
Hello Zbigniew, Lennart, all,

Zbigniew Jędrzejewski-Szmek [2016-10-20  4:00 +]:
> Open bugs with v232 milestone [1]:
> [2] 
> https://github.com/systemd/systemd/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20milestone%3Av232%20-label%3Aresolve%20-label%3Ahas-pr

None of those are a regression from 231, so we could easily move them
to 233. Should we?

Thanks for pushing this!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] "dev-xxx.device" is trying to start indefinitely long

2016-09-20 Thread Martin Pitt
Hello Anton,

please reply on the list too.

Anton Gerasimov [2016-09-20 10:22 +0200]:
> yes, I think it can be due to missing udev rules. But if the device node
> is actually there, doesn't it mean that it was noticed by systemd?

No, only devices with a "systemd" udev tag get represented in systemd;
this is to avoid unnecessary overhead with creating dozens or hundreds
of device units and having to follow their states, so the udev rules
only pick out those which we want to actually use.

> And I still can't get what happens when dev-hda.device is started.

Block device units are mostly being used to know when the
corresponding mount units get started.

Anton Gerasimov [2016-09-20 11:37 +0200]:
> Yes, just adding 'KERNEL=="hda" TAGS+="systemd"' to udev rules did the
> trick. Thank you!

That means you are missing /lib/udev/rules.d/99-systemd.rules for some
reason.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] "dev-xxx.device" is trying to start indefinitely long

2016-09-19 Thread Martin Pitt
Hello Anton,

Anton Gerasimov [2016-09-19 18:08 +0200]:
> I'm trying to make some custom initramfs image with systemd and I
> encounter very strange behaviour. Namely, when I boot into it with
> "root=/dev/hda" kernel command line option the boot process stops right
> after "Reached target Basic System" trying to start dev-hda.device, i.e
> I see "A start job is running for dev-hda.device (1min 8s / no limit)"
> forever.
> 
> However, if I break the boot process on an early stage and run the
> rescue shell, I can see /dev/hda and it can also be mounted without any
> problem. But if I 'systemctl start dev-hda.device' manually it also
> waits forever.
> 
> Have anyone here encountered something similar and what dev-hda.device
> unit is actually trying to do? Could you give me any tips for debugging
> this?

Actually yes. Occasionally our upstream CI fails with a similar
problem where it indefinitely hangs waiting for dev-ttyS0.device; and
just today I got a bug report with a similar symptom like your's [2].
Apparently udev sometimes misses to attach the "systemd" tag to that
device which causes systemd to never "see" it.  We don't understand
the bug at all yet, nor are able to reproduce it with reasonable
effort.

Does your problem happen at every boot, or only sometimes? In the
former case it might actually not be a race condition but a more
systematic error, such as missing some udev rules, or not
re-triggering all udev devices during boot, etc.

Martin

[1] 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-systemd-semaphore/xenial/i386/s/systemd-upstream/20160903_005404@/log.gz
[2] https://bugs.launchpad.net/bugs/1625217
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to override generators on debian (v215)?

2016-08-18 Thread Martin Pitt
Hello nusenu,

nusenu [2016-08-17 16:02 +]:
> according to the official documentation from upstream systemd [1] it is
> possible to override a package generator by placing a custom generator
> (with the same name) into  /etc/system/system-generator.

FWIW, this is a bad place -- binaries don't belong into /etc/ and
shouldn't be considered "configuration", this should rather go into
/usr/local/lib/systemd/system-generators (which is also supported).

But, this is tangential..

> Is there another workaround that one could apply?

You can remove the executable bit of the shipped generator:

  dpkg-statoverride --update --add root root 644 
/lib/systemd/system-generators/systemd-getty-generator

dpkg-statoverride instead of chmod will ensure that the next update of
the package that ships it will not set it back. Then just put your
generator into /lib/systemd/system-generators/ with a different name.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-07 Thread Martin Pitt
Andrei Borzenkov [2016-07-07 11:39 +0300]:
> Do not we already have "session" concept in logind? Is not session
> already stopped when user logs out?

Yes, but user systemd units don't "see" the system logind scopes, so
you can't relate to them. And the user systemd instance continues to
run after you log out of the graphical session, as long as that user
still has some other (non-graphical) session open.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-07 Thread Martin Pitt
Zbigniew Jędrzejewski-Szmek [2016-07-04 22:20 +]:
> I think we should instead enhance target units to provide missing
> functionality. The most important thing would be to have something
> like PartOf, but more nicely configured. PartOf=graphical-kde.target
> would do the trick, but it would need to be configured in each
> unit separately, which would mean that we'd need to duplicate each
> unit for each target, which is unacceptable. I don't see a nice
> way to achieve this with the current set of options. What about
> adding DependenciesPartOf=yes|no on the target unit, with "yes"
> meaning that we automatically add PartOf= dependencies to any service
> which has a Wants= or Requires= dependency to the target.

This would still not be sufficient, AFAICS. The top-level targets will
only have relatively few direct dependencies. Let's suppose
gnome-session.target has
"Requires=mutter.service gnome-settings-daemon.service"
and mutter.service then has a "Wants=at-spi2.service". We still want
to stop at-spi2.service together with the session.

DependenciesPartOf=yes in gnome.target would not achieve that (or it
would need to apply transitively, and to Wants= as well, which sounds
quite strange). OTOH adding "PartOf=graphical-session.target" to all
graphical session specific user services works fine and works with the
existing systemd model and dependencies.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-07 Thread Martin Pitt
Martin Pitt [2016-07-07  9:29 +0200]:
> I'll go ahead and create a PR with the unit and a manpage, using
> graphical-session.target for now. Then the name bikeshedding can be
> continued there.

https://github.com/systemd/systemd/pull/3678

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-07 Thread Martin Pitt
Hello Jóhann,

Jóhann B. Guðmundsson [2016-07-06 16:22 +]:
> It's more about people will be have hard time distinguish between two or
> more type units with the same name but serve two different purposes.

I was thinking graphical.target would be nicely symmetrical to the
system-level one, but there's the confusion potential, yes. So if we
call the "real" sessions like gnome-session.target, then IMHO that
generic "alias" target should have the same form;
graphical-session.target would be reasonable.

> One way to solve them is with type target units as you proposed (
> user-graphical.target could serve that purpose ) but back in the day Lennart
> was against introducing generic type targets like webserver.target,
> database.target etc

Oh, I wasn't aware of this. I guess we'll let him have the last word
about that then? :-)

I'll go ahead and create a PR with the unit and a manpage, using
graphical-session.target for now. Then the name bikeshedding can be
continued there.

BTW, I updated http://people.canonical.com/~pitti/tmp/session.sh to
have a kde.target as well, to demonstrate that this works with two
independent sessions.

Thanks everyone for their input!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Hello Jóhann,

Jóhann B. Guðmundsson [2016-07-06 15:23 +]:
> What I'm ( poorly ) trying to say is that you will need to make a clear
> distinction of naming on the type units for the desktop environment and the
> type units for the desktop environment user

I don't understand the distinction between these two.

> and potentially other existing type units on the system to avoid
> confusions and conflicting naming scheme,

system and user units are completely unrelated to each other. Of
course naming them poorly could cause some confusion. This was the
main reason for proposing some sort of prefix or suffix, like
graphical-$SESSION.target or $SESSION-session.target or so. This does
not need to be firmly defined, and systemd itself does not need to
know about it, but it might still be useful to give a recommendation
so that the various desktop sessions have some naming consistency.

> since Desktop Environments will need to have their own targets so based on
> my comments on this and for Gnome ( on Fedora ) and on the type units you
> are creating in your script ( that all have to reside in
> ~/.config/systemd/user/ directory for all the desktop environment user type
> units right )

I just used ~/.config/systemd/user/ for my test script. Obviously
actual packages would ship them in /usr/lib/systemd/user/.

> so this would become something along the lines of
> 
> # gnome.target
> 
> [Unit]
> Description=Gnome Desktop Environment
> Documentation=https://wiki.gnome.org/
> Requires=multi-user.target
> Wants=gdm.service
> Conflicts=rescue.service rescue.target
> After=multi-user.target rescue.service rescue.target gdm.service
> AllowIsolate=yes

I still think you are confusing user and system units here.
*Everything* in this thread (like gnome.target) is about *user*
systemd units. The above are all system units -- the user instance
does not know about gdm, rescue.service, etc. So this unit wouldn't
work at all.

Or asked the other way around, why do you need a gnome.target on the
system side? There might very well be reasons why you want to split
the system graphical.target into DE specific ones, to make it easier
to start the correct DM. However, this is unrelated to how to start
stuff *in* the graphical session.

> # gnome-user-graphical.target
> 
> [Unit]
> Description=User systemd services for graphical session
> StopWhenUnneeded=yes

So this is just another name for "my"
gnome.target/gnome-session.target. As I said I'm not too fussed about
how we name those, we should just decide about some convention.

> In your script you had an conflicting naming scheme (
> gnome.target/graphical.target ) and a colliding one ( graphical.target with
> systemd default and potentially other DE's as well ) if multiple desktop
> environments where installed.

I don't see a conflict. These are all per-user units, so if user A
runs kde-session.target and user B runs gnome-session.target that's
fine -- the two user systemd instances don't even know about each
other.

> And you also might need to add something like an Alias ( like for example
> "Alias=user-graphical.target" ) directive to the DE-user-graphical.target
> unit so that someapp.service can be made PartOf an generic directive
> (PartOf=user-graphical.target) to make it DE agnostic ( should it be
> required to be so ) if it's not DE specific. ( if you follow me here ).

I do follow. However, there is no such thing as a "runtime alias" for
units, TTBOMK. There is Alias= in the [Install] section, but this
cannot really be used for this purpose -- we don't want to change
the /usr/lib/systemd/user/user-graphical.target symlink every time
that we start a user session in a DM.

Hence my idea of a graphical.target user unit which would act like an
alias, as it starts and stops together with whatever-session.target.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Jóhann B. Guðmundsson [2016-07-06 14:02 +]:
> Martin is proposing changes to and dependency's on the graphical.target

I'm not changing anything. graphical.target as it exists in systemd
today is for the *system* instance. I'm talking about the *user*
instance, which has no graphical.target at all right now. You could
also call it graphical-session.target.

> trying to make it act as the abstraction layer ( since there does not exist
> a single DM solution that serves all DE properly ) which will never work
> since each desktop environment will need it's own target which can be
> isolated to so applications/administrators and end users can switch desktop
> environments

Correct, every desktop environment will need its own target. This plus
the generic graphical.target are precisely for supporting multiple
parallel session types.

> If you only have a single DE environment installed you could just make that
> DE the default target of the installment and skip entirely the graphical
> target if everything gets correctly implemented

No, even that wouldn't work. default.target is also run for
non-graphical user sessions, such as ssh, VT, or even cron. These must
*not* try to start graphical stuff like gnome-session.

> however if you try to use a DM that belongs to an single desktop environment
> ( as opposed to one DM to rule them all ) with multiple desktop environments
> you will always end up with a mess on your hand.

This is all fairly unrelated to DMs really.

> In anycase none of the desktop environment targets should ever be shipped
> with systemd upstream and depend on graphical.target but only be as a part
> of their relevant desktop environment, shipped with it and depend on it's
> own target.

Correct, and that's what I proposed. But we need the graphical.target
so that we can sanely make graphical user services get stopped with
the graphical session without having to update them all the time.

This was explained in several other parts of the thread, but suppose
you have gnome-settings-daemon.service: With just "gnome.target" this
would need a "PartOf=gnome.target", so that stopping gnome.target also
stops gnome-settings-daemon.service.

Now suppose we add a mate.target for a MATE session, which also
happens to use g-s-d. We would now need to modify
gnome-settings-daemon.service to add "PartOf=mate.target", and do the
same to all other session services that are shared between multiple
desktop session types. This is a combinatorial explosion and pointless
update exercise. We can assume that we only have (at most) *one*
graphical session running (that's dbus-user-session's building
principle) and so we can insert this "graphical.target" in the middle
to mean "the current graphical session", so that
gnome-settings-daemon.service and friends only need
"PartOf=graphical.target" and they never need to be updated for
new session types.

This /usr/lib/systemd/user/graphical.target (and only that) *does*
belong in to systemd, as it cannot sensibly be in any
gnome-session/mate-session/kde-session/etc. package -- it's a shared
resource/synchronization point between all of those. Having a unit
structure which actually works and is reasonably easy to extend and
maintain is AFAICS the main blocker why systemd isn't being used for
desktop environments at all yet.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Martin Pitt [2016-07-06 13:47 +0200]:
> Simon McVittie [2016-07-05 10:27 +0100]:
> > Could this be done by having the .desktop file in /usr/share/xsessions
> > or /usr/share/wayland-sessions start an appropriate systemd user unit
> > directly, and wait for it to terminate?
> 
> There is currently no command (other than a polling loop) to wait
> until a particular unit gets stopped. I.  e.
> 
>   Exec=gnome-session --session=gnome
> 
> would need to be replaced with something like
> 
>   Exec=/bin/sh -c "systemctl start gnome-session.target; 
> wait-until-service-stopped gnome-session.service; systemctl stop 
> gnome-session.target"

[...]

> I have a gut feeling that this should be expressible with systemd
> dependencies -- i. e. "if gnome-session.service stops, then stop
> gnome-session.target".

The v3 approach now does this, so the above would reduce to something
like

  Exec=/bin/sh -c 'systemctl start gnome-session.target; systemctl wait-unit 
gnome-session.target'

for a hypothetical "wait-unit" verb which blocks until the given unit
stops. Or perhaps even

  Exec=systemctl start --wait-until-stopped gnome-session.target

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Hello Jan,

Jan Alexander Steffens [2016-07-06 11:57 +]:
> Note that systemd makes a difference between "gnome-session.service became
> inactive" and "gnome-session.service gets stopped". A service terminating
> by itself is the former.
> 
> Requires= and PartOf= will only propagate the latter. BindsTo= also stops
> on the former (besides acting like Requires=).
> 
> So, if gnome-session.target BindsTo=gnome-session.service,
> gnome-session.target requires gnome-session.service and will be stopped
> when the service exits.
> 
> There's also StopWhenUnneeded=, which might useful on the targets.

Indeed. The version 3 approach now uses that, and this finally works
as intended. Thanks for pointing out!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units -- version 3, now working!

2016-07-06 Thread Martin Pitt
Andrei Borzenkov [2016-07-06 14:44 +0300]:
> On Wed, Jul 6, 2016 at 2:25 PM, Martin Pitt <martin.p...@ubuntu.com> wrote:
> >$ cat .config/systemd/user/gnome-session.target
> >[Unit]
> >Description=User systemd services for GNOME graphical session
> >Requires=graphical.target
> >PartOf=graphical.target
> >
> 
> Is not this redundant? Requires=graphical.target already stops
> gnome-session.target when graphical.target is stopped (by any mean).

Yes, but at the same time Requires= isn't strong enough, it needs
BindsTo=.

> > The only glitch is that "systemctl --user stop gnome-session.target"
> > only stops that target itself. I would have expected it to stop
> > graphical.target too (and someapp along with it), as it has
> > PartOf=graphical.target. This might be a bug in systemd, or some
> > semantics of PartOf with targets that I don't understand.
> 
> You probably do not understand. If foo.service is PartOf=bar.target,
> then stopping bar.target stops foo.service. State of foo.service
> itself has no impact of bar.target.

Indeed, thanks. This needs another BindsTo=.

I now created a script which sets up the units and exercises various
start/stop scenarios to ensure that we get the behaviour that we want.
This now introduces a (fake) gnome-session.service that we consider
the "session leader", and renames gnome-session.target to just
gnome.target to make it less likely to be mixed up with
gnome-session.service:

  http://people.canonical.com/~pitti/tmp/session.sh

This makes it much easier to mess around with the units and check that
stuff still works. This is now as simple as I could get it without
breaking the desired behaviour:

 * Starting gnome.target starts gnome-session.service,
   someapp.service, and graphical.target.

 * Stopping gnome.target OR graphical.target stops the services.

 * Stopping or killing gnome-session.target stops everything else.

 * someapp.service starts along with the session but can be
   stopped/restarted independently.

So we still have the requirement of an abstract "graphical.target"
that particular session services can be PartOf=, so that we avoid
having to change every service whenever a new session type arrives.

This works on systemd 230 as-is, without the need to change anything.

Note that this writes units into ~/.config/systemd/user, so if you run
this you need to clean up that dir afterwards.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Simon McVittie [2016-07-05 10:27 +0100]:
> On 04/07/16 21:01, Martin Pitt wrote:
> > A session type like "GNOME" or "KDE" then defines which top-level
> > servcies it wants.
> 
> Could this be done by having the .desktop file in /usr/share/xsessions
> or /usr/share/wayland-sessions start an appropriate systemd user unit
> directly, and wait for it to terminate?

There is currently no command (other than a polling loop) to wait
until a particular unit gets stopped. I.  e.

  Exec=gnome-session --session=gnome

would need to be replaced with something like

  Exec=/bin/sh -c "systemctl start gnome-session.target; 
wait-until-service-stopped gnome-session.service; systemctl stop 
gnome-session.target"

and gnome-session.target pulls in gnome-session.service (which then
runs the actual gnome-session program).

Note the difference between the target (which is the whole GNOME
session) and the service (which is just the gnome-session program itself).

> > Ideally we could hook the startup of graphical.slice into the system
> > logind scope; but as the user systemd does not "see" the
> > systemd users, this isn't possible. So for now pretty much the only
> > way is to go via an /X11/xinit/xinitrc.d (Fedora) or
> > /etc/X11/Xsession.d/ (Debian) script
> 
> These scripts are a necessary evil for X11, but in the Wayland future,
> the plan (at least in GNOME) seems to be for them not to be replicated;
> if gdm is told to launch a session from /usr/share/wayland-sessions, it
> doesn't execute X11 startup script snippets. (It does have a
> gdm-specific way to set environment variables, and I'm planning to
> extend pam_env to support systemd-style .d drop-in directories to
> generalize that.) A more declarative session startup seems like a better
> session startup.

Agreed. In my original proposal I said that it might be better to let
the DMs start/stop $SESSION.target/graphical.target directly, but
indeed that's harder to change/see. Creating a nice wrapper/helper for
the above horrible Exec= line and using that in the session .desktop
file sounds better. That wrapper needs the target to start and the
"session leader unit" on whose stopping the target gets stopped as
well.

I have a gut feeling that this should be expressible with systemd
dependencies -- i. e. "if gnome-session.service stops, then stop
gnome-session.target". Naïvely this would be
"PartOf=gnome-session.target" in gnome-session.service, but this does
not currently work (that might be the same bug I mentioned in my other
reply).

> I'm not sure what you do for Mir in Ubuntu, but I'd advocate a similar
> approach - sourcing a couple of dozen Turing-complete shell script
> fragments during session startup makes it rather difficult to reason about.

Yes, this makes sense. Mir doesn't have the Xsession.d shell scriptery
either, just the .desktop file interface.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-06 Thread Martin Pitt
Martin Pitt [2016-07-06 13:47 +0200]:
> I have a gut feeling that this should be expressible with systemd
> dependencies -- i. e. "if gnome-session.service stops, then stop
> gnome-session.target". Naïvely this would be
> "PartOf=gnome-session.target" in gnome-session.service, but this does
> not currently work (that might be the same bug I mentioned in my other
> reply).

Sorry, wrong way around according to how PartOf= works: I meant
"PartOf=gnome-session.service" in gnome-session.target. (But that
doesn't work either).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units -- version 2

2016-07-06 Thread Martin Pitt
Hello all,

Colin, Jan, Zbigniew, thanks for your input! Based on that I have an
updated proposal.

Jan Alexander Steffens [2016-07-06  9:44 +]:
> On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie <gm...@colin.guthr.ie> wrote:
> > Not commenting on the general approach (which I did read and broadly
> > agree with without giving it too much thought!), but could you use
> > PartOf= here to make the target approach work? It might be more hacky as
> > each user .service would have to declare themselves to be PartOf the
> > corresponding .target. This does mean that if the target is stopped, the
> > units are stopped too.
> >
> > I'm not sure how this would work regarding things like g-s-d which you
> > want in multiple DEs.. perhaps the gnome.target would have to be split
> > up into gnome-base.target and gnome.target to allow for this use case?
> > Or perhaps g-s-d could just become bus activated and not need any direct
> > starting?
> >
> 
> How about a top-level, generic graphical.target that defines no
> dependencies itself, but is Required by anything graphical. Then stopping
> graphical.target would terminate the desktop, no matter which environment
> was set up.

This indeed mostly works. So this would have three parts:

 * systemd ships a new user unit "graphical.target", symmetric to the
   system unit:

   $ cat .config/systemd/user/graphical.target
   [Unit]
   Description=User systemd services for graphical session

   This isn't enabled anywhere, so it's completely inert on servers,
   ssh/VT sessions, etc.


 * gnome-session and friends, which currently ship e. g.
   /usr/share/xsessions/gnome.desktop, ship a corresponding
   gnome-session.target:

   $ cat .config/systemd/user/gnome-session.target
   [Unit]
   Description=User systemd services for GNOME graphical session
   Requires=graphical.target
   PartOf=graphical.target

 * Applications ship services which are PartOf=graphical.target,  so
   that they go down with the graphical session:

   cat .config/systemd/user/someapp.service
   [Unit]
   Description=example graphical app
   PartOf=graphical.target
   [Service]
   ExecStart=/bin/sleep infinity

   graphical.target is the thing we set/ship in systemd, so it's not
   dependent on which particular DE/session you use.

 * The GNOME session package (which ships gnome.desktop and
   gnome-session.target) depends on the things it needs (like
   gnome-session, mutter, etc.) and also ships the top-level
   enablement symlinks:

   .config/systemd/user/gnome-session.target.wants/someapp.service -> 
../someapp.service

   This also retains the option that an app auto-starts itself in all
   graphical sessions by shipping a graphical.target.wants/ symlink to
   themselves (but this shouldn't be a common case).

Now "systemctl --user start gnome-session.target" starts
graphical.target (through g-s.t's Requires) and myapp.service (via
gnome-session.target.wants/). And "systemctl --user stop graphical.target"
stops all three (via the PartOf=).

The only glitch is that "systemctl --user stop gnome-session.target"
only stops that target itself. I would have expected it to stop
graphical.target too (and someapp along with it), as it has
PartOf=graphical.target. This might be a bug in systemd, or some
semantics of PartOf with targets that I don't understand. However,
always stopping graphical.target when the session stops seems safer
anyway.

(The XSession.d/xinit.d bits to actually start/stop the targets are
unaffected by this change; I'll follow up to Simon's reply about that).

So again, the only change we should do in systemd is to ship the
graphical.target user unit.

WDYT?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Standardizing names for graphical session units

2016-07-04 Thread Martin Pitt
Hello Jóhann,

Jóhann B. Guðmundsson [2016-07-04 20:53 +]:
> Shipping an predefined desktop units arguably does not belong upstream since
> it's just catering to one ( desktop ) out of three (
> embedded/server/desktop) target user base.

Right, embedded/server would never start this new unit. But we also
ship a graphical.target on the system side, even though that doesn't
apply to servers either. This is just an extra two-line unit.

Also, if that is really an issue, we do not *need* to ship an actual
unit file for that -- we merely need to define what its name is, so
that we can start shipping such units in upstream desktop projects.

> It might result in other two target user base having to patch things
> out in the environment.

What would you need to patch out? Having an extra unused unit on them
isn't going to cause any harm, other than the extra microsecond to
read the unit file (but we already parse plenty).

> Why would you call it graphical-<$DE>.slice as opposed to simply <$DE>.slice
> which is part of the <$DE>.target and graphical target is link to that
> <$DE>.target  ( if shipped upstream it needs to be generic enough to cater
> whatever is out there right )

target units don't work well as they don't stop their dependencies on
stop, as I explained -- unless there's a trick which I'm missing?

If you just make it a top-level slice like "gnome.slice", then you
don't have a parent like "graphical.slice" any more which you can
refer to in units. We certainly don't want to use the root slice
(-.slice) as we don't want to kill *all* the user services on
graphical logout.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] how to use per-user systemd --user services / how to replace /etc/xdg/autostart/app.desktop?

2016-06-24 Thread Martin Pitt
Mantas Mikulėnas [2016-06-16 16:03 +0300]:
> So I would create a separate graphical.target and manually `systemctl
> start` it via .xprofile or such. (Don't forget, also, that graphical
> programs usually need $DISPLAY, and this is only imported to the --user
> manager /after/ default.target has already started.)

That's in fact my current schema too. We want to convert the Ubuntu
user session from (session) upstart to (per-user) systemd units, and
my current prototype [1] defines a "graphical.slice", the actual
services hook into that (or perhaps into a subslice like
graphical-xfce.slice), and the whole Xsession gets wrapped into
starting/stopping the per-session-type slice [2].

It's still a prototype (work on this is postponed until end of July on
a sprint), but so far this works reasonably well.

Martin

[1] https://git.launchpad.net/~pitti/+git/systemd-graphical-session/tree/
[2] 
https://git.launchpad.net/~pitti/+git/systemd-graphical-session/tree/usr/share/systemd-graphical-session/session-wrapper
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] When System is Degraded

2016-06-06 Thread Martin Pitt
Hey Aaron,

aaron_wri...@selinc.com [2016-06-06 10:27 -0700]:
> I'm using systemd in an embedded device that some some LEDs. I'd like to 
> make an LED red when the system starts up degraded, and green when 
> everything is working normally.
> I'm having a hard time figuring out where to fit this in.
> I tried using a service that runs "systemctl is-system-running" after I've 
> reached my target, but that command returns "starting", obviously.
> What's a better way to run a command when the system is "running" vs 
> "degraded"?

Try adding a .service with "Type=idle" and add it to your default
target (usually multi-user.target). This should run the unit after the
system is booted (i. e. running or degraded).

(Tested here with systemd 230)

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

2016-06-06 Thread Martin Pitt
Andrei Borzenkov [2016-06-06 14:56 +0300]:
> Sorry I had to be more clear. What is advantage of shipping them in
> systemd? Systemd has well defined early boot services that are always
> needed. Why they are shipped as links instead of actually expressing
> those mandatory dependencies in unit definitions themselves?

I didn't mean links in the systemd package itself, but other packages
which want to hook into targets or services. E. g. the network-manager
package could ship a
network-online.target.wants/network-manager.service symlink.

Of course it could also just do the usual WantedBy= in the unit and
call systemctl enable on installation (that's what the Debian package
does), but there are cases where you don't really want to make the
enablement configurable by the admin.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

2016-06-06 Thread Martin Pitt
Andrei Borzenkov [2016-06-06 13:55 +0300]:
> What is advantage in having static *.wants etc directories in
> /usr/lib/systemd vs. Wants etc directives directly in unit definition?
> They complicate troubleshooting (you no more have complete definition
> by looking just at unit source), they complicate building (extra steps
> to install them); what are they good for?

These are much simpler to ship in packages than shipping a
foo.service.d/mywants.conf with "Wants=". In both cases the .service
isn't completely self-contained but extended with an external file,
but the symlinks are structurally simpler.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

2016-05-28 Thread Martin Pitt
Chris Friesen [2016-05-27  9:14 -0600]:
> The reason why I'm poking at this is that the old scheme worked "good
> enough" for us for several years.  Now of course the new scheme is better,
> but it breaks backwards compatibility.  This makes it difficult to
> automatically upgrade an existing system to an OS using the new scheme since
> all the names would change.  (And we've got the old interfaces stored in
> databases and such in our management software.)

FTR, Debian/Ubuntu do not use the new schema on upgrades for existing
interfaces, just for new installs, for precisely this reason.
Specifically, if you already have an existing
/etc/udev/rules.d/70-persistent-net.rules, this will still be present
(and trump ifnames). But we also disable it for VM upgrades where the
previous persistent-net-generator was blacklisted.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

2016-05-26 Thread Martin Pitt
Chris Friesen [2016-05-26 12:28 -0600]:
> So I've been playing with this a bit, but I've run into another snag.  It
> seems that on initial boot even with "net.ifnames=0" the ethernet interface
> ordering isn't consistent.

"even with" → "because of" :-)

However, the ordering isn't really influenced by udev/systemd/ifnames,
that's entirely dependent on the hardware and kernel drivers.

> I assume this is due to parallel network device initialization from udev?

udev (or userspace in general) has no business in detecting physical
network devices, that's exclusively the kernel.

> Is there a way to serialize this at the cost of slower system
> initialization?  I don't really care what the ordering is, as long as it is
> consistent on identical hardware.

I'm not aware of such a method. You can of course hack the kernel to
do anything..  This is why we have needed to come up with
ways to rename interfaces in userspace.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] restart vs. stop/start

2016-05-22 Thread Martin Pitt
Christian Boltz [2016-05-22 16:18 +0200]:
> "start" means loading the profiles and applying the confinement to _newly 
> started_ profiles.
> 
> This also means that _already running_ processes won't be (re)confined [1], 
> which translates a small typo done by the admin ("systemctl restart 
> apparmor" instead of "systemctl reload apparmor") to leaving lots of 
> processes unconfined and turns that accidential use of "restart" into a 
> security risk.
> 
> This is why I need to override the "restart" behaviour so that it 
> reloads the profiles while keeping running processes confined.
> 
> The easiest solution would be an ExecRestart= directive in the service 
> file, but unfortunately this isn't available.

But ExecReload= is available, isn't that enough?

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Shutdown a specific service in systemd shutdown

2016-05-19 Thread Martin Pitt
Hello Bao,

Bao Nguyen [2016-05-19 15:52 +0700]:
> When the system is shutdown, systemd will terminate all services in
> parallel manner, could you let me know if there is any ways to tell systemd
> to shutdown a specific service first, then shutdown all remaining services?

The concept of "first"/"last" has no well-defined meaning in any
non-serial init systems (not even SysV init with insserv, only with
classic SysV init with manually set priorities). I've heard requests
like "but this needs to be started as the last thing" a lot in the
recent years, and there's no way all the services can simultaneously
be "last" :-)

You should put sufficient After= properties into your service, so that
it gets started after and stopped before the ones you specify. See
man systemd.unit for details.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

2016-05-16 Thread Martin Pitt
Michael Biebl [2016-05-16  4:24 +0200]:
> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ ?
> Could we move more common functionality into a shared, private library
> to counter the constant growth?

Building src/shared/ into a private libsystemd-internal.so (which
doesn't have a SONAME and shipped development headers, so that we
continue to be able to change the API freely) should help a great deal
there. Is that something that would be accepted upstream?

I wouldn't like to split out things like systemd-analyze just because
of being a big binary. It's useful for all sorts of things even on a
non-developer machine: temporarily raise log levels, check
admin-provided units, and check why your machine takes too much time
to boot, etc.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Using systemd --user to manage graphical sessions?

2016-05-11 Thread Martin Pitt
Hello Mantas,

thanks for your reply!

Mantas Mikulėnas [2016-05-11 19:54 +0300]:
> AFAIK, the general idea of --user is that there's at most one graphical
> session (per user) at a time, so things like $DISPLAY naturally become per
> user.

Right, I understand that. But that doesn't mean that *always* have a
$DISPLAY. So simply having user units that start with systemd --user
does not work: If the first login is on a VT or through ssh these
would all fail, and if you then actually login on the DM nothing would
restart them.

That could be helped a bit with a ConditionHasEnvironment=DISPLAY or
something such, and an xinit.d script that restarts them. But this can
all be achieved through some good/bad hacks, my main issue is still
that you can't bind those to the system unit with the correct
lifecycle -- session-*.scope.

> I can start this with "systemctl --user start xeyes@${XDG_SESSION_ID}",
> > but this will hang off user@1000.service instead of session-*.scope
> > and thus it will not be stopped once the X session gets logged out.
> >
> 
> Most X11 clients will exit as soon as the X server goes away, no?

They do, but you get failed units and scary error messages, and this
happens *after* the X session is already gone -- thus no way for them
to gracefully shut down.

> `systemctl --user import-environment DISPLAY` seems to work well enough.

Right, that part works fine, that's not the problem.

> In stock GNOME, I already have a bunch of bus-activated apps running off
> the user bus (dbus.service), such as gedit, nautilus, or gnome-terminal;
> the latter finally got its own gnome-terminal.service in 3.20.2.

gnome-terminal is what I looked at too, and what I referred to in the
bug report: https://bugzilla.gnome.org/show_bug.cgi?id=744736 -- this
is pretty broken right now :-( This is essentially one program trying
to work around (and failing) the fundamental issue that a lot of
things don't make sense to start with the first non-X login and keep
around until after the X session ends.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Using systemd --user to manage graphical sessions?

2016-05-11 Thread Martin Pitt
Hello all,

I've been experimenting with systemd --user as a possible replacement
for bringing up graphical user sessions. We currently bring up most of
that using upstart jobs (simple auto-restart on crashes, rate
limiting, per-job logging, fine-grained startup condition control).
There is one upstart process per session, so this is reasonably
straightforward.

But I still can't wrap my head around the mental model of how this is
supposed to work with the user D-Bus and systemd instance. This works
fine for some services which are not specific to a session, such as
gvfs or pulseaudio, but it's not at all appropriate for user-facing
applications or desktop components, such as gnome-terminal[1],
gnome-session, the window manager, indicators, etc. They are
necessarily per-session, and sometimes even need to be keyed off the
session type (gnome, LXDE, XFCE, etc.). I. e. they should be started
on the first graphical session (not on VT logins) and should be
stopped when stopping the graphical session.

There are some existing discussions [2][3] and while the latter has a
lot of patches and some good direction, it does not really touch the
subject of the mail at all -- how do I get something from a user unit
into the session-*.scope session of logind?

I. e. if I have some ~/.config/systemd/user/xeyes@.service with

   [Unit]
   Description=Xeyes on session %I
   [Service]
   ExecStart=/usr/bin/xeyes

I can start this with "systemctl --user start xeyes@${XDG_SESSION_ID}",
but this will hang off user@1000.service instead of session-*.scope
and thus it will not be stopped once the X session gets logged out.

One idea was to add PartOf=session-*.scope, but that's a system-level
unit and thus the session process does not know about that. There also
is no Scope= option for a service to make that run in a different
scope. We can certainly hook something into xinit.d/ to *start* a
"master stub" service which then launches the components, but there is
no way to tell it to stop with the logind session.

Is this all in vain, and we need to make the *entire* world of free
software shift over to the new model of "user-wide services" before we
can use systemd --user for graphical stuff? (Colin's patch list is
already impressively long and it is by far not complete)

Or is someone actually using systemd --user for graphical sessions
already and found a trick that I missed?

Thanks,

Martin


[1] https://bugzilla.gnome.org/show_bug.cgi?id=744736
[2] 
https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html
[3] https://lists.freedesktop.org/archives/systemd-devel/2013-August/012517.html

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Network Interface Names: solution for a desktop OS

2016-04-12 Thread Martin Pitt
Xen [2016-04-12  3:37 +0200]:
> The trick to turn it off on the website doesn't work:
> 
> ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

It does (at least on Debian, Ubuntu, and Fedora), but you need to
rebuild your initrd after doing this.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

2016-04-11 Thread Martin Pitt
Reindl Harald [2016-04-10 17:44 +0200]:
> >Because we had a mechanism for stable (but not predictable) interfaces
> >names, the 75-persistent-net-generator.rules thingy. Without either,
> >the first time you plugged in a second card/USB dongle/add an ibmveth
> >etc., chaos would start.
> 
> that worked perfectly

Hahahahno. :/

It had an inherent race condition of renaming devices to the same
namespace than the kernel uses (thus creating collisions), and did not
work at all in virtualized environments (see the long and ever-growing
MAC blacklist).

Apart from that it had several design problems: it was not predictable
(names changed across reinstalls), prevented the ability of creating
one OS image and installing it on many pieces of hardware (as the MAC
addresses are device specific) and needed constant writability of
/etc.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

2016-04-10 Thread Martin Pitt
Andrei Borzenkov [2016-04-10 11:31 +0300]:
> It had been working out of the box for quite a lot of users actually.

Because we had a mechanism for stable (but not predictable) interfaces
names, the 75-persistent-net-generator.rules thingy. Without either,
the first time you plugged in a second card/USB dongle/add an ibmveth
etc., chaos would start.

> Again - configuring location based naming was pretty easy in the past.

Again -- nothing changed wrt. manually configuring interface names if
you desire so.

> You need to explain why your new naming scheme is better than that.

See "Why" on
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Also, it's not "my" schema, but I do think it's a fairly good
compromise between all the bad options how to do interface naming.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

2016-04-10 Thread Martin Pitt
Hello,

Xen [2016-04-09 20:29 +0200]:
> 1. I believe most users do not like the "enp5s0" scheme
> 2. I do not think there are any good reasons for making it the default.

There are very good reasons for having a mechanism for stable names by
default. Most importantly, to keep your machine actually
booting/working .. when names suddenly move around and your server is
suddenly not online any more, or your firewall silently stops working,
this is a tad bad. :-)

> "Finally, many distributions support renaming interfaces to user-chosen
> names (think: "internet0", "dmz0", ...) keyed off their MAC addresses or
> physical locations as part of their networking scripts. This is a very
> good choice but does have the problem that it implies that the user is
> willing and capable of choosing and assigning these names."

This isn't true -- having the option of customizing the names doesn't
mean that you *have* to do it. That's precisely why we must provide
some schema for stable names by default -- because the majority of
users does not care and should not *have* to care.

> What is really the amount of systems or proportion thereof that have
> multiple NICs?

I actually think "most" (at least an ethernet and a wifi card), but
this question is also fairly irrelenvant -- even if it's just 5% we
still want those to function correctly.

> Any user running a system with multiple NICs should be willing and
> capable of choosing and assigning these names.

To be frank, this is the attitude of the 90's when you had to sit down
with a thick book and spend a week until your Linux system was up and
running.

If a user wants to customize the names, nothing stops them, and it's
well-documented how to do that. But that doesn't mean that we aren't
responsible for being correct and safe by default.

> The new biosdev scheme is so meaningless that mostly any user WILL want
> to change this scheme to become something meaningful, but the obstacles
> to it are too great currently for the regular user.

From my POV of a desktop-oriented developer and distro engineer who
sees a lot of bug reports -- "most users" don't care. It's totally
irrelevant on a desktop where the network is usually configured
dynamically (NetworkManager) and it's mostly irrelevant for virtual
environments which most of the time only have one network card which
the OS installer sets up by default. It is highly relevant for
embedded setups (think RasPi board) and servers with multiple NICs,
and there a location-based naming matches people's intuition a lot
better than the old MAC-based enumeration from
persistent-net-generator.

> So we may have 5% or less of all systemd/linux networking users that
> actually requires this.
> The 5% or less that does require it is not the type of user that would
> not be able to adjust the naming scheme.

That's a rather strong assumption, and IMHO it's unnecessary to make.

> Now you are causing 95% of users that really need to turn it off.

This is not true, and a dangerous piece of advice to give to anybody.

> At the very least create a configuration file where this is a simple
> named option. And then, at the very least, don't turn it on by default.

All of this is very easy to configure.

In the end, the root cause of this is that Linux' handling of network
devices is so completely different than just about every other device.
For the latter (nodes in /dev) we can easily have aliases so that we
can provide suitable names for every use case (by-serial, by-uuid,
by-label, etc.), but this is impossible with network devices
unfortunately. So there simply is no naming schema that fits
everybody's needs, and every default that we pick will have to be
changed in some circumstance. But I believe that the current one is a
fairly safe, reasonable, and most importantly, *working* default, at
the price of having to adjust to slighly "odd" names.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?

2016-04-05 Thread Martin Pitt
Hello,

Lennart Poettering [2016-04-04 21:28 +0200]:
> We already bypass PK if the client is privileged. See
> bus_verify_polkit_async() in src/shared/bus-util.c, the calls for
> sd_bus_query_sender_privilege(). Are you saying that bypass doesn't
> work for you?

Right, it still calls Polkit as root normally. But if it's not really
meant to do that, then let's just treat it as a bug and track it in
https://github.com/systemd/systemd/issues/2748, I'll look into that.

Thanks!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Avoid polkit queries from systemctl in package maintainer scripts/when running as root?

2016-04-04 Thread Martin Pitt
Hello all,

a recent (mostly cosmetical) bug report [1] made me aware that we
currently query polkit for a lot of systemctl
enable/daemon-reload/etc. calls from package maintainer scripts. At
least in Debian, installing a package with a .service usually does
something like "systemctl enable/start foo", and installing a package
with a SysV script runs "systemctl daemon-reload" to pick up the new
init script.

In all those cases systemctl is guaranteed to run as root, and any
potential interactive PK prompt would be totally unexpected -- because
of root, and because package installation is supposed to be
non-interactive and not hang. So this introduces a potentially
unreliable moving part and also assumes that polkit actually works all
the time (cf. package upgrades).

My initial response was to propose some patches that all "systemctl"
commands from maintainer scripts will be done with --no-ask-password.
However, this would require rebuilding a lot of packages, and I would
guess this affects other distribuions in some way too?

A more upstreamable approach would be to not query polkit at all if
geteuid() == 0. Is there any legit scenario where root would be denied
running systemctl directly, but a polkit rule would allow it
nevertheless? In such a scenario, is it really legit to get an
interactive PK auth prompt for something like "systemctl enable foo"
when installing package foo?

Thanks for opinions,

Martin

[1] https://launchpad.net/bugs/1565617

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Issues with docker systemd cgroups integration

2016-03-15 Thread Martin Pitt
Michal Sekletar [2016-03-15 16:06 +0100]:
> We had similar problem in the past with libvirtd and it got solved by
> introducing Delegate option (man systemd.resource-control).

docker.io did that too three weeks ago:

  https://github.com/docker/docker/commit/65820132

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] FYI: github PRs run tests on IBM zSystems now

2016-03-01 Thread Martin Pitt
Hello all,

We have a second architecture besides x86_64 for github PR integration
tests now: IBM zSeries (aka s390x, fka zSeries or System Z).  So we
now have coverage of big-endian as well.

We can only run a few integration tests there though, as on this
architecture we don't have real QEMU yet, so we are limited to
container tests. But we still at least run make check, booting, and
networkd. https://github.com/systemd/systemd/pull/2777 is an example PR.

I'll continue to monitor the PRs to check for flakiness or
infrastructure problems. Once that stabilizes, we can also consider
adding x86 so that we cover 32 bit too.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

2016-02-18 Thread Martin Pitt
Martin Pitt [2016-02-18  9:01 +0100]:
> However, an awful lot of the runs currently fail with a linker error.
> I filed [2] and will investigate.

Thanks to Filipe that got fixed quickly (it was a recent bug in the
build system indeed). Fun thing is that I didn't actually intend to do
that "--disable-all" variant build, this was an unintended side effect
of GitHub modifying the test request URL. (This got worked around
now).

So all of the glue is in place, and these work now. I went through the
PRs that got opened since we enabled the new tests, and they all have
(mostly) successful runs now.

Two tests (journal getting a log and backtrace of a bash crash, and
networkd handling a hotplugged IPv6 interface) fail very often when
running against upstream for some reason; I disabled these two for now
as we don't want to have all PRs have red flags because of known
issues which already existed before (i. e. they are not regressions
from that PR). I'll investigate these.

I'll watch incoming over the next days, and sort out the remaining
fallout (I'm sure there will be something :) ).

This test is currently being triggered on x86_64 only (amd64 in
Debianspeak). In principle we can also trigger them on i386, or more
exotically, IBM System Z (aka S/390x). We don't have QEMU on the
latter and thus can only run a relatively small subset of integration
tests (those that can run in containers). But it would at least give
us the build and unit test, and a little bit of real-life testing. Is
there any interest in enabling those? (Not right away, but maybe in a
few weeks when things settle down with x86_84).

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

2016-02-18 Thread Martin Pitt
Jóhann B. Guðmundsson [2016-02-18 11:35 +]:
> Arguably not if upstream test do not detect these things then they should be
> fixed to do so

The upstream tests are mostly unit tests which cover isolated logic.
Of course having more coverage there would be great, but that's not
the point here. systemd is not an isolated project, but it lives in an
operating system, controlling services like dbus, gdm, NetworkManager, etc.

So saying "fix them to do so" in an email is easy, but did you
actually think about *how* this should look like? We do have some QEMU
tests upstream which cover a little bit of "does this VM boot", but
not much else -- there is no integration testing with other
components. So for doing proper integration testing you need to take
an actual OS, with actual packages, and check that they still work. If
that's Fedora or Debian or whatnot is not that important in the end,
and ideally we test them all.

But it's certainly not practical for the upstream systemd tests to
pull and build glib, X/wayland, gdm, NetworkManager, evemu-tools, etc.
and construct their own synthetic OS into a VM. That would be a
huge maintenance burden, take awfully long, and this synthetic
mini-distro isn't actually being used by any any real person.

So, is it possible that these tests will fail because of a downstream
issue? Absolutely, yes, and I'm sure they will do that at some point.
I'm looking at those failures, and they are a problem that needs
fixing anyway (and if it's a downstream issue, I'm no less on the hook
for that than now). But experience has shown that almost all test
failures which aren't due to actual regressions are due to either bugs
in the tests or infrastructure failure -- and both of these will apply
equally to so-called "upstream tests".

So integrating these into PRs instead of running them every other day
on master makes it much simpler and cheaper to identify the cause of a
regrssion. You can also always compare against other PRs or a
test against master.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

2016-02-18 Thread Martin Pitt
Hello all,

you might already have noticed, but from now on PRs will not only
trigger the semaphore checks (which are essentially a "make
distcheck"), but also trigger more comprehensive integration tests on
Ubuntu's autopkgtest infrastructure. These build actual binary .deb
packages, install them in an actual OS, and cover things like
networkd, bootchart, that crucial services like NetworkManager or
window manager come up, timedatectl and friends, cryptsetup,
systemd-sysv-install (with various combinations of SysV+systemd
units), and the "boot-smoke" test where the whole thing has to boot
successfully 20 times [2].

This new test can be seen at e. g.
https://github.com/systemd/systemd/pull/2641 or /2650 which now also
have a second "ubuntu-ci" test.

I now wrote all the glue between github and autopkgtest.ubuntu.com,
running into gory details like firewall issues, three different ways
to authenticate, and my own hilarious incompetence when it comes to
web programming (but I'm learning :) ). Thanks to Daniel for his great
help with kickstarting me into GitHub webhooks!

However, an awful lot of the runs currently fail with a linker error.
I filed [2] and will investigate.

So please don't put too much attention to these results yet. I want to
to enable them to see how the testing and communication holds up in
practice, but before this we definitively need to sort out [2] first.

Please bear with me!

Thanks,

Martin


[1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/tests
[2] https://github.com/systemd/systemd/issues/2651
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Moving systemd-bootchart to a standalone repository

2016-02-17 Thread Martin Pitt
Daniel Mack [2016-02-17 18:09 +0100]:
> Barely anyone of the people working on systemd uses that tool, so it
> sees little testing.

For the record, I have automatic integration tests for that to ensure
that it stays working in principle, i. e. it boots and produces an
.svg file. Of course the test does not "look" at the SVG to figure if
the information in there is correct. But it's certainly far from
bitrotting, and occasionally I check the .svg result too.

This is of course rather orthogonal wrt. where the code lives, we want
to continue testing it in both cases. I'd say the "split or not"
question mostly depends on how much of shared/ needs to be duplicated
and whether that will make the future maintenance easier or harder.
"This repository contains a stripped down set of the utility functions
we have in src/shared and src/basic in systemd" certainly doesn't
sound promising in that regard -- if an external
systemd-bootchart would just link against the official libsystemd.so
and not use any internal API, then splitting it out would be perfectly
justifiable, but as long as it depends on a code copy that smells a
bit questionable?

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [RFC] the chopping block

2016-02-11 Thread Martin Pitt
Martin Pitt [2016-02-11 21:59 +0100]:
> This would apply if you boot with systemd, then install sysvinit, and
> want to reboot the machine (using SysV's /sbin/reboot), right? Or the
> other way around?
> 
> This is still somewhat relevant for Debian, but maybe there's
> something simpler that can be done for that case? If there's any other
> way to reboot the machine in that situation, it can also become
> documentation.

... I figure "systemctl reboot" should do?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] CODENAME field in /etc/os-release

2016-01-13 Thread Martin Pitt
Unknown [2016-01-13 14:23 +0100]:
> You shouldn't ask yourself where can i find the codename, but rather
> what do I want to do with it?
>  - display it to the user or otherwise describe it in human readable
> text? use PRETTY_NAME if the distribution isn't obvious, or VERSION if
> it is.
>  - anything else? are you sure the codename is fit for the job?

On deb-based distributions the code name is used for specifying the
package sources. For example,

  deb http://archive.ubuntu.com/ubuntu/ xenial main

where "xenial" is the code name of the distribution. For Debian those
are "wheezy", "jessie", "unstable", and so on.

The request to add a code name to os-release has come up several times
on our side too, and right now we add it as "UBUNTU_CODENAME=", as per
os-release(5). Standardizing to "CODENAME" would be preferrable,
obviously.

> and what would you do on systems not using a codename? for example
> archlinux?

Nothing at all would change for them, as the field wouldn't be
mandatory. Other fields like "VARIANT" don't make sense in a lot of
use cases either, after all.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to add startup delay?

2016-01-12 Thread Martin Pitt
Hello Masanari,

Masanari Iida [2016-01-12 22:07 +0900]:
> My question is How can I add 30sec delay for squid.service startup ?

The simplest thing would be to add a drop-in
/etc/systemd/system/squid.service/delay.conf with

  [Service]
  ExecStartPre=/bin/sleep 30

systemd has timer units too, but setting those up is probably not
worth the effort for this.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] "StandardOutput=console" don't work as expected

2015-12-30 Thread Martin Pitt
Reindl Harald [2015-12-30 11:10 +0100]:
> i just want systemd *not to touch* the stdout behavior when asked to do so -
> it don't need to know anything about ssh ptys, just don't touch stdout
> 
> i am asking for StandardOutput=console get piped to the terminal systemctl
> was called - the rest is done by crond as all the years before

This isn't how systemd works -- systemctl does *not* run any jobs by
itself, it just asks pid 1 [1] to run a job. Thus the stdout/err of
systemctl are completely irrelevant here.

To do what you want to do, don't put the code that you want to run
into a systemd unit, just run it straight away. Then you don't have
the indirection, and whatever you run will just output straight to
stdout/err.

Martin

[1] Or the user's systemd instance, but in this context it's really
the same thing
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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


Re: [systemd-devel] "StandardOutput=console" don't work as expected

2015-12-30 Thread Martin Pitt
Reindl Harald [2015-12-30 11:35 +0100]:
> in the first mail i wrote: "migrate cronjobs to systemd-units for using
> ReadOnlyDirectory and other security otpions"

OK, I suggest to use systemd-run -t then, like Michael Chapman already
suggested. This should give you both, direct stdout/err and the
possibility of additional security restrictions.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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


Re: [systemd-devel] Trouble building v225 on Ubuntu 15.10

2015-12-16 Thread Martin Pitt
Hello Tabor,

Tabor Kelly [2015-12-16 20:34 -0800]:
> I'm trying to get systemd v225 building on Ubuntu 15.10. When I run
> autogen.sh I get the following output:
> 
> configure.ac:686: warning: macro 'AM_PATH_LIBGCRYPT' not found in library

Missing libgcrypt20-dev. It's easiest if you just do

  sudo apt-get build-dep systemd

to install all build dependencies of systemd than trying to discover
them one by one.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] about systemd build

2015-11-29 Thread Martin Pitt
yan...@iscas.ac.cn [2015-11-30 11:26 +0800]:
> 
> when I build systemd219 in ubuntu 14.04.and I have install util-linux(2.27 
> form ubuntu 15.04) and  it also report "configure: error: *** libmount 
> support required but libraries not found"  How to do that? Thank you! 

You need libmount-dev, not ubuntu 15.04.

However, please take this word of warning: You are sending dozens of
questions to the upstream and now this mailing list with very little
contents, and they show that you do not fully understand what you are
doing. If you hack up a system that way, building your own systemd,
installing it on your 15.04 Ubuntu etc., you are entirely on your own,
and things *will* break (see your trouble with libsystemd-pam and
logind sessions breaking).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [packaging] split of systemd package

2015-11-12 Thread Martin Pitt
Lennart Poettering [2015-11-12  9:46 +0100]:
> > Another reason is to make it easy to enable/disable a particular
> > feature (e. g.  libnss-myhostname).
> 
> I don't see why one would ever disable this feature... I doubt this
> makes senseto split out really.

We have to do that because it's a shared library and needs to be
multi-arch compatible (i. e. you might have more than one architecture
installed at the same time); so this was a bad example wrt. feature
enablement indeed. libnss-mymachines and libnss-resolved might be
better ones (but we don't have a choice to not split them out anyway).

> > > systemd-networkd (maybe also with resolved?)
> > 
> > We currently keep that in the "systemd" package as splitting it out
> > now is a bit of an upgrade pain, but we discussed doing this.
> 
> As mentioned I wouldn't split this out either.

I'm reluctant to do it too. At the moment there's little reason
because we still have the iptables support disabled. Both because the
iptables vs. nftables question isn't decided yet, and also because it
would mean another set of heavy dependencies in the default install
for a relatively little used feature. libnftnl is much smaller, so
if/once we switch to that, this is much less of a concern.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [packaging] split of systemd package

2015-11-12 Thread Martin Pitt
Lennart Poettering [2015-11-12  9:59 +0100]:
> THere's no point in shipping the non-binary version of the hwdb. The
> hwdb isn't a cache, it's a compiled version of the hwdb, and you don't
> the sources around for this.

Won't you need it for udevadm hwdb --update, after you add a new
hwdb.d/ file? Or can we now have multiple compiled dbs, one shipped by
the package and one built dynamically by hwdb --update?

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [packaging] split of systemd package

2015-11-12 Thread Martin Pitt
Lennart Poettering [2015-11-12 10:01 +0100]:
> > However, the gain through the extra dependencies is nontrivial: On a
> > minimal system, installing systemd-container pulls in some 20 extra
> > packages (libldap, sasl2-modules, libkrb5, libssh, ca-certificates
> > etc.)
> 
> ldap, sasl, kerberos, libssh and the certificates? That sounds very wrong.

systemd-container depends on libcurl3-gnutls, which is the thing we
desperately want to keep out of a minimal install as it has this huge
list of dependencies.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [packaging] split of systemd package

2015-11-12 Thread Martin Pitt
Lennart Poettering [2015-11-12 11:15 +0100]:
> > Won't you need it for udevadm hwdb --update, after you add a new
> > hwdb.d/ file? Or can we now have multiple compiled dbs, one shipped by
> > the package and one built dynamically by hwdb --update?
> 
> Well, if you do add those locally. But that's not a typical usecase really.

I meant that the udev package isn't the only thing shipping hdwb.d/
files -- at least libmtp, libgphoto, and media-player-info ship some
as well, and cause the hdwb to be rebuilt on package
installation/removal.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [packaging] split of systemd package

2015-11-11 Thread Martin Pitt
Hello all,

in case it's useful, this is how we split them in Debian.

However, is this even a topic for upstream, apart from giving
recommendations? I. e. do you actually consider putting this kind of
split into the upstream build system à la "make install-"?

Lukáš Nykrýn [2015-11-11 11:47 +0100]:
> Personally I don't think it makes sense to split the package to get a
> smaller core package. Most of our binaries are just few KBs.

They are actually fairly big, 100 kB to 1.5 MB for systemd itself. I
think the main reason for that is that they all statically link
libsystemd instead of dynamically linking to libsystemd.so.0. Is there
a particular reason for that?

> Other aspect would be minimizing external dependencies.

That is one important reason why we split them in Debian; e. g. the
machined/nspawn/importd group pulls in a number of rather heavy
dependencies. udev (including hwdb) is something which you don't need
in containers, so we split that out too.

Another reason is to make it easy to enable/disable a particular
feature (e. g.  libnss-myhostname).

And then of course the infamous "need to run with sysvinit/upstart",
which other distros don't need to be concerned about :-)

> So I suggest following scheme

FTR, this isn't too far away what we already do in Debian/Ubuntu:

> systemd

check

> systemd-libs
> systemd-devel

They are called a bit differently for distro policy, upgrade safety,
consistency, and multi-arch support reasons; we need separate binary
packages for every lib*.so. But in spirit, "check".

> systemd-journal-remote (so gatewayd,remote,upload)

Check, we have exactly this package name.

> systemd-networkd (maybe also with resolved?)

We currently keep that in the "systemd" package as splitting it out
now is a bit of an upgrade pain, but we discussed doing this.

> systemd-machine (machined,nspawn,importd)

We call that package "systemd-container", but it has exactly those, so
"check".

> systemd-firstboot (firstboot,sysusers?,factory stuff?)

We don't have a separate package for that.

> systemd-hwdb

We split out the entire udev, including hwdb. This nicely reduces the
footprint in containers and also allows us to use udev with
sysvinit/upstart.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [packaging] split of systemd package

2015-11-11 Thread Martin Pitt
Hello Zbigniew,

Zbigniew Jędrzejewski-Szmek [2015-11-12  6:39 +]:
> Installed size of systemd-udev is 6.5MB, systemd-container is 3.5MB,
> systemd is 19MB, so the gain is modest. We also lose some dependencies.

To compare with Debian: systemd: 17.5 MB, s-container 2.4 MB, udev 6.6
MB, so this is comparable.

However, the gain through the extra dependencies is nontrivial: On a
minimal system, installing systemd-container pulls in some 20 extra
packages (libldap, sasl2-modules, libkrb5, libssh, ca-certificates
etc.) and will take an extra 18.3 MB space. s-journal-remote by itself
is an extra 16.7 MB; but there's of course a lot of overlap with
s-container, installing both together are +19.3 MB.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] about Authorization

2015-11-11 Thread Martin Pitt
Hello yankun,

yan...@iscas.ac.cn [2015-11-12  9:25 +0800]:
> Hey  guys:
>I try install systemd(219) in linux-mint17 .the deb package is from 
> Ubuntu15.04.except for I can not auto-mount  my U disk and  can configure the 
> network parametric.But when I use root to login, there is no problem.

These sound related to udisks and NetworkManager, not systemd itself.
This sounds like there's a problem with your policykit setup. But
without further details/logs (error messages, output of udisksctl
mount -d /dev/...) it's rather impossible to diagnose.

Also, this ML isn't the right forum for this.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] ip forwarding

2015-11-06 Thread Martin Pitt
Johannes Ernst [2015-11-05 23:11 -0800]:
> This makes my point. The default = 0 is counter intuitive and costs much time 
> for the lucky ones among us who can figure it out. The rest will just give 
> up...

It's less counter-intuitive, but the problem is that it breaks a lot
of existing tools that expect that the global kernel settings actually
work.

Note that this was discussed recently already here, but rejected:
https://github.com/systemd/systemd/issues/1411

Thus at least CoreOS and Ubuntu now change the default to "kernel",
which pretty much DTRT. (I'm still pondering doing that in Debian
too). If you don't explicitly configure it in your .network then the
global setting is applied, and as that defaults to 0 the "secure by
default" aspect is also satisfied.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] about libmount

2015-11-05 Thread Martin Pitt
Hello yankun,

yan...@iscas.ac.cn [2015-11-05 14:03 +0800]:
> I try to build the Systemd219 and get this " configure: error: *** libmount 
> support required but libraries not found"
>  what I  do  is “./configure”  and when I use "dpkg -s libmount " ,I get this 
> "Source: util-linux
> Version: 2.25.2-4ubuntu3" . So   where is the problem? thanks!

try "sudo apt-get build-dep systemd" to install all the development
packages you need.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] about libmount

2015-11-05 Thread Martin Pitt
Hello Yankun,

yan...@iscas.ac.cn [2015-11-05 23:24 +0800]:
> I can not find a available uri for systemd in china

Sorry, but I don't understand at all what this means.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 208 VS 219

2015-10-20 Thread Martin Pitt
Helo yankun,

yan...@iscas.ac.cn [2015-10-21  9:29 +0800]:
> hello guys,Systemd 208 VS Systemd219 ,Do they have many changes  that can 
> improve boot time??

Newer systemd versions provide a lot more functionality. There might
be some boot speed changes too, but not really because of targetted
work but more "accidentally". The general principles of the ordering
and parallelization of services haven't changed since pretty much the
beginning of systemd, so in general you shouldn't expect to see
dramatic changes in boot speed between versions.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

2015-10-16 Thread Martin Pitt
Hey Olaf,

Olaf Hering [2015-10-16 14:21 +0200]:
> My copy of /usr/lib/udev/hwdb.d/60-keyboard.hwdb has (at least) three
> issues:
> 
> This advice fails, bugreporting is disabled, perhaps just for me?
> # If your changes are generally applicable, open a bug report on
> #   http://bugs.freedesktop.org/enter_bug.cgi?product=systemd

Thanks for pointing out! This should point to github issues now, I'll
adjust this with my next keymap PR (presumably one to fix your key).

> The wildcard does not work for me, but using /dev/input/event5 works.
> #   udevadm hwdb --update
> #   udevadm trigger /dev/input/eventXX
> # where /dev/input/eventXX is the keyboard in question. If in
> # doubt, simply use /dev/input/event* to reload all input rules.

Kay, is this supposed to work (and udevadm fixed for that)? If not,
this certainly does work:

  udevadm trigger --sysname-match=event*

> And finally, this new entry to let th 'Earth' icon start the web browser
> instead of sending XF86HomePage, which is ignored.
> 
> # HP ProBook 6555b, icon earth, sends home, should send www
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard:pnHPProBook6555b:*
>  KEYBOARD_KEY_b2=www

This looks similar to this already existing rule for this model:
# HDX9494nr
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHDX9494NR:pvr*
 KEYBOARD_KEY_b2=www# Fn+F3
 KEYBOARD_KEY_d8=!f23   # touchpad off
 KEYBOARD_KEY_d9=!f22   # touchpad on

Do you have touchpad on/off keys? Do they already work?

As for the new entry being ignored, is that still the case after "udevadm
control --reload", or just rebooting? (I've heard that this sometimes is
necessary). If so, can you please pastebin "udevadm info --export-db"
somewhere, so that we can verify the DMI names and whether the hwdb
entry actually matches?

Finally, which systemd version are you running? (The 60-keyboard.hwdb
syntax changed in 220).

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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


Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

2015-10-16 Thread Martin Pitt
Hello Olaf,

Olaf Hering [2015-10-16 15:22 +0200]:
> I just noticed that there is a catch al, which looks very odd:
> 
> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*:pvr*

How does it look odd?

> Why would such a wildcard be correct?

As inconsistent as scan code assignments are between different
vendors, the big ones at least sem to have some internal consistency,
like HP, the "ThinkPad Extra Buttons", or the "Acer WMI hotkeys". We
just found over time that a large number of different HP models all
have the same keymap and it seems logical to factor out the common
keys and then just add a few model specific adjustments.

The common map does not set b2 BTW, so disabling it won't change
anything.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

2015-10-16 Thread Martin Pitt
Olaf Hering [2015-10-16 15:14 +0200]:
> > As for the new entry being ignored, is that still the case after "udevadm
> > control --reload", or just rebooting? (I've heard that this sometimes is
> > necessary). If so, can you please pastebin "udevadm info --export-db"
> > somewhere, so that we can verify the DMI names and whether the hwdb
> > entry actually matches?
> 
> http://pastebin.com/raw.php?i=Y5NJWJGF

OK, so that has

P: /devices/platform/i8042/serio0/input/input4/event5
[...]
E: KEYBOARD_KEY_b2=www

which means that your hwdb match worked. Can you please copy the
output of

  udevadm test-builtin keyboard 
/devices/platform/i8042/serio0/input/input4/event5

? Does that give any error message wrt. assigning the www key? Can you
please double-check in evtest that you really still get KEY_HOMEPAGE
after that?

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

2015-10-16 Thread Martin Pitt
Olaf Hering [2015-10-16 16:21 +0200]:
> root@probook:~ # udevadm test-builtin keyboard
> /devices/platform/i8042/serio0/input/input4/event5
> calling: test-builtin
> === trie on-disk ===
> tool version:  224
> file size: 7049404 bytes
> header size 80 bytes
> strings1762740 bytes
> nodes  5286584 bytes
> Load module index
> timestamp of '/usr/lib/systemd/network' changed
> Parsed configuration file /usr/lib/systemd/network/99-default.link
> Created link configuration context.
> Unload module index
> Unloaded link configuration context.

That didn't work -- so apparently the device path has changed over a
reboot.

> My entry from the initial mail works, no worries.

Oh! I misunderstood you that it did *not* work, and you asked for
debugging why. I submitted a pull request:

  https://github.com/systemd/systemd/pull/1586

> # If your changes are generally applicable, open a bug report on
> #   http://bugs.freedesktop.org/enter_bug.cgi?product=systemd

This was already updated a while ago.

I didn't change the trigger comment, as the manpage also indicates
that triggering multiple path arguments is supposed to work. So let's
rather fix that.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] failed to change interface name (systemd-networkd)

2015-10-15 Thread Martin Pitt
Lennart Poettering [2015-10-14 18:15 +0200]:
> My educated guess is that DEbian's ifupdown scripts are responsible for
> this... IIRC they install a unit file that is pulled in on hotplug,
> and might keep the device busy...

Yes, /lib/udev/net.agent. It calls ifup or ifdown if the interface is
configured in /etc/network/interfaces, i. e. with ifupdown. But if it
does not appear in "ifquery -l" the script doesn't touch the
interface.

To be 100% sure you can temporarily move away /lib/udev/net.agent and
see if it still happens?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] RFC: removing initctl support

2015-09-24 Thread Martin Pitt
Hello all,

sorry for the late reply, I've been swamped with other stuff recently.

Lennart Poettering [2015-09-22  2:31 +0200]:
> a) there's support in systemctl to reboot the system by sending the
>right bytes to /dev/initctl as fallback, so that you can reboot a
>sysvinit system with "systemctl reboot".

We indeed need this for upgrades: If you e. g. install Ubuntu 14.04
LTS (with upstart), or Debian Jessie (with SysV init) and install the
systemd packages during the upgrade, you need to be able to reboot
into the upgraded system (while upstart/sysvinit is still running). So
indeed it's only needed exactly once, but we need to keep this around
until at least April 2016 when Ubuntu 16.04 LTS will release (and then
we can reasonably assume that systemd will be running for any further
upgrades).

On Debian it's much harder to give a precise time line as the official
project decision is still to support multiple init systems. But if
there's a documented workaround, that'd also suffice.

> b) There's a mini-daemon "systemd-initctl.service" that is
>fifo-activated on /dev/initctl, and forwards reboot requests from
>old sysvinit clients to systemd.

This direction seems much less important to me -- you can always call
"systemctl reboot" while systemd is pid 1, no?

> We never even really used this stuff on Fedora properly (since we
> actually transitioned from Upstart, not sysvinit, and we never had the
> same level of compat for that...).

You should run into the same problem if you upgrade an upstart system
to systemd, no? You can't possibly exec systemd over upstart in a
running system.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What I think is really wrong with systemd

2015-09-16 Thread Martin Pitt
Thanks Colin for your reply!

Colin Guthrie [2015-09-16 11:30 +0100]:
> > Normally, you have a major version and a minor version. If the major
> > version changes, it is an alarm to do throught testing to see if
> > everything works wellon the new one. Minor changes are minor, so they
> > require less testing.
> 
> Minor, major etc., this doesn't matter. Even minor changes can introduce
> major bugs. The fact that someone arbitrarily decided "this is a minor
> change" doesn't make the change safe in any way. Testing of such key
> components should be the same regardless. Adopting such a scheme in a
> project like systemd serves no purpose but to create a fake illusion of
> "safeness".

I just want to emphasize this. We've seen the smallest bug fixes cause
trouble in totally unexpected corners. Major new features are actually
less risky, as nobody is relying on them yet. :-)

Especially on desktops/phones/customer devices etc. the software world
has pretty much moved from these "major new release every year"
towards a continous delivery of features and fixes, together with
continuous integration testing of those. The latter ensures that we
don't break stuff no matter how big the change is (in theory at least,
we all know practice..), and it tremendously helps to take pressure
off developers to cram their feature into next week's deadline for
feature freezes.

I think in the server world stable releases with bug-fix only
microreleases (backporting from trunk) are still much more common.
This environment is rightfully more conservative, but I daresay that
we'll see a shift towards continuous integration and delivery of new
features as well.

While systemd lives on both servers and clients, it's still being
developed rather fast, and I don't think splitting it up into "new and
shiny, but totally untested in the world out there" vs. "stable bug
fix only releases which are missing features people are asking for"
would make sense at this point.

TL;DR: Version numbers become more and more meaningless. :-)

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What I think is really wrong with systemd

2015-09-16 Thread Martin Pitt
Michał Zegan [2015-09-16 14:41 +0200]:
> I actually believe that debian does some splitting, for example pam-systemd
> module is in a separate package. Actually I feel that particular case is
> wrong, but it happens there. I mean debian jessie, of course.

FYI, this is required for supporting Multi-Arch, it's not wrong.

Debian does split the package quite a bit, yes. All libraries, their
-dev packages, and libnss*/libpam* need to be separate binaries, and
udev and systemd-sysv need to be separate for supporting other init
systems still. We also recently split out "systemd-container" for
nspawn/machinectl/importd etc. so that we can enable all features
without introducing big new dependencies into minimal systems.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Backport git notes

2015-08-27 Thread Martin Pitt
Hey Lennart, all,

Lennart Poettering [2015-08-27 18:02 +0200]:
 I used to add Backport: bugfix style git notes to systemd commits
 I deemed backport-worthy. These headers have not been added to any
 commits since we moved to github (primarily, because the notes weren't
 ported over for quite some time). Nobody complained about this. Which
 makes me wonder if anyone actually cares.

TL;DR: I don't.

 Zbigniew, Michael, Martin, Lukasz, Michal, do you actually care for
 these git notes? Did you ever use them? Did you even know about them?

I did know about them, and back in the days when we had much longer
release cycles I (that is, Debian/Ubuntu) mostly consumed them via the
-stable branches, and just slurped them in wholesale into our packages
for the current development series. Now that we have frequent release
cycles and a much better CI both upstream and downstream I almost
entirely stopped (having to) backport stuff. We used to have a dozen
up to ~ 50 backported patches in the package, now it's usually 0 to 2.

For packages in our stable releases we've never used them, but always
just cherry-picked individual (and very few) patches.

So in summary: Carefully marking patches for backporting has been
obsoleted by CI and frequent releases for us. Which is infinitely
better in just every way -- we now have great releases which we can
more or less just use. :-)

Thank you for checking!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] About github repo and release tarball change

2015-07-09 Thread Martin Pitt
Armin K. [2015-07-09 14:42 +0200]:
 Still, man pages and html docs issue exists.

That's by design. They are built from the docbook sources.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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


Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

2015-07-07 Thread Martin Pitt
Hey David,

David Herrmann [2015-07-07 18:31 +0200]:
  Revert login: re-use VT-sessions if they already exist - commit 0204c4b
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b
 
 Can someone elaborate what exactly lightdm does here? We really want
 to prevent multiple sessions on the same VT. This is just nasty and
 never made any sense. So I'm really interested why lightdm doesn't
 kill it's manager-session before it starts the new session. Any
 particular reason here?

I'll let Robert answer with the details, but something I noticed:

It's not that simple to reproduce, but sometimes it seems the lightdm
greeter session (running as user lightdm, where you select user/type
password and so on) doesn't completely terminate, but some processes
stay around in it. Thus the greeter session stays around in state
Closing, and then the real session starts on the same VT.

I asked the reporter of https://launchpad.net/bugs/1472259 to attach
systemd-cgls, so that we can see what's running in the session.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

2015-07-07 Thread Martin Pitt
Hello poma,

poma [2015-07-07 18:14 +0200]:
 Revert login: re-use VT-sessions if they already exist - commit 0204c4b
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b

Thanks for analyzing this! As it happens I got a bug report today
about the same regression from a user who uses my daily trunk builds
PPA: https://launchpad.net/bugs/1472259

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

2015-07-07 Thread Martin Pitt
Hello David,

David Herrmann [2015-07-07 19:10 +0200]:
 On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt martin.p...@ubuntu.com wrote:
  It's not that simple to reproduce, but sometimes it seems the lightdm
  greeter session (running as user lightdm, where you select user/type
  password and so on) doesn't completely terminate, but some processes
  stay around in it. Thus the greeter session stays around in state
  Closing, and then the real session starts on the same VT.
 
  I asked the reporter of https://launchpad.net/bugs/1472259 to attach
  systemd-cgls, so that we can see what's running in the session.

Got that now:

 └─user-110.slice
├─user@110.service
│ ├─996 /lib/systemd/systemd --user
│ └─997 (sd-pam)
└─session-c1.scope
  ├─1149 /usr/bin/pulseaudio --start --log-target=syslog
  └─1168 /usr/lib/pulseaudio/pulse/gconf-helper

So indeed some leaked processes which don't terminate along with
gnome-session. As it happens I get that on my system as well, but the
leaked session just lasts for a few seconds after logging in and
then goes away.

 So it might indeed just be a race in lightdm.

Right, it's IMHO a lightdm greeter bug that the session doesn't
properly terminate.

 Anyway, this patch here should also fix the issue (if it does, I'll
 commit something proper).

Thanks, looks good! It's surely a workaround, but indeed this might
not be the only case that's affected, so thanks for this safety net.
I'll build a package with that and ask the reporter for testing.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] sd 221 regression: login - nonexistent sessions via lightdm

2015-07-07 Thread Martin Pitt
Hello again,

Martin Pitt [2015-07-07 20:56 +0200]:
 Thanks, looks good! It's surely a workaround, but indeed this might
 not be the only case that's affected, so thanks for this safety net.
 I'll build a package with that and ask the reporter for testing.

That happened now, all good for the record.

Thanks!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Fwd: sd 221 regression: login - nonexistent sessions via lightdm

2015-07-07 Thread Martin Pitt
Hey Robert, all,

Robert Ancell [2015-07-07 23:53 +]:
 1. LightDM starts up
 2. LightDM starts an X server on a free VT (e.g. 7)
 3. LightDM starts a greeter process which connects to the X server. Via
 libpam-systemd a logind session is opened.
 4. User logs in via greeter.
 5. LightDM stops the greeter by sending a SIGTERM to it.  The greeter
 closes the PAM session which closes the logind session.
 6. LightDM starts the user session. The existing X server is used so this
 session is on the same VT as the greeter session was.
 
 The issue is that after step 5 LightDM considers the greeter session to be
 completely closed. However, it appears that closing the PAM session only
 cases the logind session to be put into the closing state.

Indeed. But it's the actual session's job (gnome-session?) to ensure
that all child processes actually get killed. I usually get some stray
pulseaudio processes, other people reported more processes.

We don't currently enable KillUserProcesses where logind would
actually kill the remaining processes in the greeter cgroup, as we
don't want to do this by default for real user sessions (that would
break screen or other background services). Perhaps it would make
sense to enable this for class == SESSION_GREETER?

 As pointed out we have an issue where Unity Greeter isn't waiting
 for some of its child processes before exiting and that is keeping
 the logind session open for a short time. I think there's still a
 race here in any case because the display manager just has no idea
 when the session is really closed.

Synchronously waiting for the leftover processes sounds like a bad
idea. They take some half a minute here, and for Christopher in LP
#1472259 they don't seem to terminate by themselves at all. So you'd
actually need to actively kill them. lightdm could be more foreful by
using KillSession() instead of TerminateSession(), or maybe logind
itself should imply killing with class == SESSION_GREETER (as I
mentioned above)?

 So the correct solution might be to just to ignore logind sessions in the
 closing state when checking if a VT is used more than once.

That indeed also sounds good; David, WDYT? It seems the current patch
caused a regression in gdm, so maybe that is a better workaround for
222 until this gets fixed properly?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

2015-07-01 Thread Martin Pitt
Hey Johannes,

Johannes Ernst [2015-07-01 11:02 -0700]:
 My container is degraded because systemd-tmpfiles-setup.service
 failed. My understanding is that it should not run in the container
 anyway. (Right?)

It should run in a container; its purpose is both necessary, and I
don't see why a container would have any difficulty with it. It runs
just fine in both system and even unprivileged user containers here.

 How do I find out why it was started?

$ systemctl list-dependencies --reverse systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service
● └─sysinit.target

systemctl status systemd-tmpfiles-setup.service will say that it's
statically enabled, and the list-dependencies says where. I. e. you
should have a symlink
/usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service

(could also be in /lib/systemd/, depending on your distro)

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Weird udev issue: char device replaced by regular file on suspend

2015-06-25 Thread Martin Pitt
Hello Johannes,

Johannes Bauer [2015-06-25 21:15 +0200]:
 I'm seeing a very odd issue with udev and I'm not really sure which
 component could/would be responsible -- udev is pretty much my only hope.

Unlikely, I'm afraid.

 Now the odd thing: When I put my computer into suspend-to-RAM, I'm
 seeing something very odd when the thing wakes back up (about 3 in 4
 times this happens, nondeterministically). The character device
 /dev/ttyUSB0 is replaced by a regular file with 0644 permissions which
 is owned by root:root:

This sounds like a script or program that runs for suspend tries to
apply an atomically update file contents approach (write data into a
file.new, then mv file.new file) to a /dev node, which would result in
this situation. This is sometimes hidden in some API like
g_file_set_contents().

Can you reproduce this with a direct

  echo mem | sudo tee /sys/power/state

? This will circumvent any suspend etc. hooks that you might have:
pm-utils, /usr/lib/systemd/system-sleep/ hooks, or something an
inhibitor might do. I. e. it could be that NetworkManager sets a
suspend inhibitor, tries to stop modemmanager before suspend and
restart it after, and that might mis-handle /dev/ttyUSB0. (We didn't
get any report about this so far, so I doubt it's actually
modemmanager -- it just illustrates how this could happen in
principle).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] no tar balls at release time

2015-06-23 Thread Martin Pitt
Kay Sievers [2015-06-23  1:21 +0200]:
 Please test these setups locally if that model will work in your
 setups, and what would possibly need to be fixed in the git tree to
 make that easier for you.

Fine for Debian/Ubuntu. We've always rebuilt the autoconfiscation
anyway, and our build system also handles package builds straight from
a git checkout (for CI).

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Is SystemCallFilter working for you?

2015-06-10 Thread Martin Pitt
Hello again,

Martin Pitt [2015-06-09 13:00 +0200]:
 I was about to (re-)enable seccomp support in our systemd packages,
 and to write an integration test for it. However, it seems that this
 currently does not seem to work at all.

For the archives: Not sure what went wrong yesterday, today it works
like a charm. I enabled it in the Debian/Ubuntu packages and wrote an
integration test for it.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Is SystemCallFilter working for you?

2015-06-09 Thread Martin Pitt
Hello all,

I was about to (re-)enable seccomp support in our systemd packages,
and to write an integration test for it. However, it seems that this
currently does not seem to work at all.

config.h has HAVE_SECCOMP==1, and systemctl --version shows +SECCOMP,
kernel has CONFIG_SECCOMP=y, CONFIG_HAVE_ARCH_SECCOMP_FILTER=y, and
CONFIG_SECCOMP_FILTER=y, and I'm running on x86-64, so that all seems
fine.

But if I have a unit like

| [Unit]
| Description=seccomp test
| 
| [Service]
| ExecStart=/bin/cat /etc/machine-id
| SystemCallFilter=access

(which really ought to fail) it just succeeds. Also, running
./test-execute as root fails in test_exec_systemcallfilter():

| exec-systemcallfilter-failing.service
|   UMask: 0022
|   WorkingDirectory: /home/martin
|   RootDirectory: /
|   NonBlocking: no
|   PrivateTmp: no
|   PrivateNetwork: no
|   PrivateDevices: no
|   ProtectHome: no
|   ProtectSystem: no
|   IgnoreSIGPIPE: yes
|   StandardInput: null
|   StandardOutput: inherit
|   StandardError: inherit
| This should not be seen
|   PID: 16439
|   Start Timestamp: Tue 2015-06-09 12:56:51 CEST
|   Exit Timestamp: Tue 2015-06-09 12:56:51 CEST
|   Exit Code: exited
|   Exit Status: 0
| Assertion 'service-main_exec_status.status == status_expected' failed at 
src/test/test-execute.c:57, function check(). Aborting.

This is with libseccomp 2.2.1, I tested kernel 3.19 and 4.0. Is that
working for anyone else? In particular, could you check if you have
HAVE_SECCOMP and test-execute succeeds (as root) for you?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [ANNOUNCE] Git development moved to github

2015-06-09 Thread Martin Pitt
Filipe Brandenburger [2015-06-09 12:55 -0700]:
 I think a more productive advice would be for reviewers to avoid using
 line comments for anything that is wanted for posterity and instead
 only use them to say typo or comment here or to point out what
 exactly in the code the comment on the main thread is making reference
 to. Wouldn't you think that would be preferrable?

FWIW, I don't like it that much either, but so far I still find this
the best compromise. Creating and keeping track of multiple PRs and
issues even for simple patches where there's a typo or a small style
bugs is more unwieldy than losing the line comments IMHO.

That said, I'll abide to Lennart's final decision to that of course.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [ANNOUNCE] Git development moved to github

2015-06-03 Thread Martin Pitt
Hello Krzesimir,

Krzesimir Nowak [2015-06-03 10:39 +0200]:
 I see that some patches from mailing list were imported as issues to
 github.com (like this one - https://github.com/systemd/systemd/pull/16).
 There's a problem with that - I can't update the PR anymore with followup
 fixes and whatnot. What's the workflow in this case? File a new PR and ask
 nicely for old one to be deleted?

That will do indeed; we already cleaned up some duplicates, it's not a
big deal. This is just a transitional issue to mop up the pending
patches on the ML, so nothing that will cause this kind of paperwork
for a long time.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 0/2] Using XML entities for paths in manpages

2015-06-02 Thread Martin Pitt
Hello Daniel,

Daniel Mack [2015-05-29 11:05 +0200]:
 Could you try the attached patch?
 
 I had to introduce a new entity in custom-entites.ent, because with
 --with-rootprefix=/, rootprefix;/lib resolves to //lib, and with
 the default behaviour of configure, rootprefix;lib becomes /usrlib.
 
 That is solved with a subsitiution in Makefile.am now, which cleans up
 all double slashes in custom-entites.ent.

FTR, this works fine here, using --with-rootprefix= (to avoid the
extra slashes). This spawned a long thread and multiple followup
patches, and TBH I lost track which patches got proposed and which are
superseded; but this one looks good to me. Thank you!

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [ANNOUNCE] Git development moved to github

2015-06-02 Thread Martin Pitt
David Herrmann [2015-06-02 13:06 +0200]:
 Our preferred way to send future patches is the github way. This
 means sending pull-requests to the github repo. Furthermore, all
 feature patches should go through pull-requests and should get
 reviewed pre-commit. This applies to everyone. Exceptions are
 non-controversial patches like typos and obvious bug-fixes.

Makes sense. On the operational level, should we use the
automatically merge feature of git hub once approving? On the plus
side it's very convenient, but you'll get one Merge commit for every
PR (which is often just one commit), so we'd almost double the entries
in git log. Or can github be told to not do that?

Merging manually is quite a bit of work, as you have to add a new
remote every time, fetch that, and pull from it. But it does keep a
cleaner git log history.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [ANNOUNCE] Git development moved to github

2015-06-02 Thread Martin Pitt
Dimitri John Ledkov [2015-06-02 15:58 +0100]:
 And I think this is _good_, because the submitter's commit ids will be
 preserved (together with the signed gpg commits) and the maintainers
 are discouraged to fix-up and/or adjust commits upon rebase /
 git-am. Instead fix-ups from reviewer should go as separate commits or
 as part of the merge commit.

Please don't commit them separately. Not only would that make the
history even bigger and harder to read, but it's simply not good
practice to have known-broken commits in the tree. Every commit should
be good, which is particulary important for bisecting and
cherry-picking.

Personally I like a flat history with rebasing, as it's a lot clearer
to read, and bisect through; and TBH we aren't interested in keeping
the whole history of bad commits in trunk which are fixed up later.

So, reporters using git push -f to amend fixups to their original
commits after review is fine. But please let's not clutter trunk with
the entire history of what should be a single commit?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] bcache broke in udev 220

2015-06-01 Thread Martin Pitt
Hey David,

David Mohr [2015-05-31 15:57 -0600]:
 udev 220 arrived in Debian sid and this update broke bcache support [1]: no
 /dev/disk/by-uuid/ symlink is being created for the filesystem on top of
 /dev/bcache*. That's because 60-persistent-storage now uses a whitelist
 instead of blacklist. The simple attached patch fixes this, could you please
 apply it?

Applied, thank you!

  http://cgit.freedesktop.org/systemd/systemd/commit/?id=19672f1e5f

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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


  1   2   3   4   5   >