Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
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
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
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
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
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
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'
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
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
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
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
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
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
Kai Krakow [2016-12-02 8:47 +0100]: > Am Thu, 17 Nov 2016 18:53:53 +0100 > schrieb Lennart Poettering : > > 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
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
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?
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
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&q=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
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
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)?
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
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
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
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
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
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
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
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
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 -- version 3, now working!
Andrei Borzenkov [2016-07-06 14:44 +0300]: > On Wed, Jul 6, 2016 at 2:25 PM, Martin Pitt 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
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
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
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 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
Hello Zbigniew, 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. That sounds good to me, and indeed targets sound like a more natural way than slices. > > * You have to pre-define them, so we would need to have on-disk > > units for all session types like graphical-xfce.target, > > graphical-gnome.target, etc. > > I don't think this is such a big problem. After all it's going to be > a few (3? 5?) units, and a file is needed to provide Description= > and Documentation= anyway. Agreed. > I have to agree with Jóhann that "graphical-" part does not seem necessary. > I'd rather go for "kde-session.target", "gnome-session.target", etc. As predicted, let the bikeshedding begin. :-) I really don't mind much if we call it graphical-$TYPE.target or $TYPE-session.target. > And I don't think that the requirement for a unit file is a hurdle > for step-wise conversion. Once you want to convert, let's say, xfce, > you create xfce-session.target with some Description, and start linking > units to it through .wants or .requires dirs, and that's totally > independent of any other session. Right. The hurdle I meant was that right now every distro or home-grown solution calls the units differently. I. e. so far we had X11@$DISPLAY, graphical-$TYPE.slice, and now $TYPE-session.target. If this becomes a "first submitter wins" then we might miss improvements like the above for a nicer design. Thanks for your input, this is a nice idea! Let's hear a few more opinions before jumping to the implementation (of DependenciesPartOf= in particular). 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
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
[systemd-devel] Standardizing names for graphical session units
t other stuff
is being handled as dependencies (Requires=/Wants=) of those top-level
services: gnome-settings-daemon, gnome-panel, etc.
At some point gnome-session might go away entirely and its top-level
dependencies (mutter, nautilus, etc.) be replaced with enablement
symlinks. This then needs to model gnome-session's stages, but this
should translate to several successive targets naturally, just like
sysinit → multi-user → graphical on the system side.
Start/stop of graphical.scope
-
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 like:
| $ cat ./etc/X11/Xsession.d/98systemd-graphical-session
| if [ -x /usr/share/systemd-graphical-session/session-wrapper -a -e
/run/systemd/users/`id -u` ]; then
| STARTUP="/usr/share/systemd-graphical-session/session-wrapper $STARTUP"
| fi
| $ cat ./usr/share/systemd-graphical-session/session-wrapper
| #!/bin/sh
| systemctl --user restart graphical-${DESKTOP_SESSION}.slice
| $@
| systemctl --user stop graphical.slice
Due to the existing distro fragmentation these wrappers will have to
stay distro specific/downstream for the time being; but that's okay,
as graphical session units don't need to know about this mechanics at
all. Of course it'd be fine to ship the Fedora variant upstream,
together with xorg/50-systemd-user.sh. (My hope is that over time the
above wrappers will become obsolete and display managers start/stop
that unit directly, but that isn't a blocker.)
I'd like to drive this forward, so that we can put the necessary infra
(the X session wrapper and the top-level graphical.slice) into
upstream and our distro packages and then start submitting session
units to GNOME/KDE/Xfce/etc. At the moment nobody is doing this,
because this feels like some kind of chicken-egg problem.
We can (and will) of course bikeshed about the details, unit
types/names, etc., but I guess step one is to discuss/agree that we
want to start standardizing session services in systemd.
Feedback appreciated!
Thanks,
Martin
[1] https://lists.freedesktop.org/archives/systemd-devel/2016-May/036440.html
[2] https://git.launchpad.net/~pitti/+git/systemd-graphical-session/tree/
[3] https://lists.freedesktop.org/archives/systemd-devel/2016-May/036449.html
--
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] how to use per-user systemd --user services / how to replace /etc/xdg/autostart/app.desktop?
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
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
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
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?
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?
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
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
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?
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?
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?
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
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
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
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
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?
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?
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
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
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
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
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
Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs
Jóhann B. Guðmundsson [2016-02-18 10:08 +]: > Will failed tests or false positives start auto creating issues on github? > If so is that really the smart thing do to here? IMHO not. The idea is that raising the red flag on the PR should be enough, and that the point of the CI tests is to not land regressions in master in the first place. issues should mostly be filed against releases or master, not PRs (which can always potentially break stuff). > The only test system that should be hooked into upstream should just be > upstreams own not some downstreams right. That's what we do today, but these only run the unit tests, which have a very low coverage of all of systemd's functionality. E. g. I found about five regressions in networkd alone last year with these tests, two instances of "sometimes the boot breaks" [1][2], and the regression with handling block devices (#2537). It's so much easier if these get raised right away in the PR that introduces the regression than having to bisect and investigate days or weeks after it landed and the damage is already done. Note that these builds are done with zero downstream patches -- it's just the source as it comes out of the PR. Of course it has to run *on* some OS, and that currently happens to be Ubuntu 16.04 for "ubuntu-ci" and Ubuntu 14.04 for semaphoreci. I'd actually turn it the other way around and claim that if Fedora, Arch, etc. have downstream tests, then please trigger them too. After all, failures of them don't block anything (right now, anyway), and having the extra information in the PRs can only be useful? Martin [1] http://lists.freedesktop.org/archives/systemd-devel/2015-February/028640.html [2] https://github.com/systemd/systemd/issues/1505 -- 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
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
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
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] [RFC] the chopping block
Hello, answering for Debian/Ubuntu. Lennart Poettering [2016-02-11 18:06 +0100]: > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last >time Debian was still using that, maybe this changed now? 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. Not relevant for Ubuntu. > 2) compat support for libsystemd-login.so and friends (these were >merged into a single libsystemd.so a long time ago). We are still >building compat libraries to ease the transition, but that was a >long time ago, hence I'd really love to see this go. Any distro >still using this? D/U dropped the compat libs months ago. > 3) systemd-reply-password – this is really old stuff used by the GNOME >ask-password stuff which was experimental at best, and never found >much use. Unless am very wrong pretty much nobody is using this, >and we can just kill this without replacement. Anybody knows a user >of this that I am not aware of? First time I hear about it TBH. I'm not a GNOME-y/desktop-y person any more, but this suggests that it's nowhere being used except for the rather old systemd-ui: https://codesearch.debian.net/perpackage-results/systemd-reply-password/2/page_0 dracut apparently installs it into the generated initrd, but that's a trivial thing to drop. > 5) Here's the controversial one I think: support for booting up >without /var. Some deprecation time would be appreciated, so that we have time to adjust initramfs-tools, at least for common cases. Traditionally /var has never been required for early boot, thus there are a fair number of people using /var on NFS (judging by bug reports that we get), and squeezing that into an initrd might cause some trouble. 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] CODENAME field in /etc/os-release
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?
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
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] "StandardOutput=console" don't work as expected
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] Trouble building v225 on Ubuntu 15.10
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
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] about the daemon
Hello yankun, yan...@iscas.ac.cn [2015-11-17 14:07 +0800]: > Because Systemd create the socket for the service,so what I want to > know is when I use a daemon , I will get the source of the daemon > and modyfy it,right? You don't _have to_ use socket activation, so it's not a prerequisite to modify daemons to work with systemd. But of course teaching them to become socket activated and adding a .socket unit makes startup more efficient and dependencies simpler, so indeed it's worth doing that. This is documented here: http://0pointer.de/blog/projects/socket-activation.html 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 the daemon
Hello yankun, yan...@iscas.ac.cn [2015-11-17 13:40 +0800]: > If I want to use the systemd,I will rewrite the daemon under the > systemd,right? Sorry, this question is not understandable. Can you please explain your question in a more detailled way? 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] systemd-228 around the corner
David Herrmann [2015-11-13 21:06 +0100]: > Continuing with our strict, biweekly release schedule, we plan to put > forward a new release for Monday. The only thing left for the release > is a logind-fix. If anything else needs attention before the release, > please speak up. There's also still the networkd regression: https://github.com/systemd/systemd/issues/1866 This didn't happen yet in 227, so it would be sad to release 228 with that. That's the only thing that my tests are bitching about, otherwise it looks happy. The other thing that's brand new on my radar are reported SIGBUS unaligned pointer crashes on ARM in siphash24, which liberally casts uint8_t* pointers to uint64t* and then tries to access them. However, this is already in 227, thus I wouldn't consider it a regression that should hold up 228. I'll try to reproduce on Monday, write a test case, and send a GH issue 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 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [packaging] split of systemd package
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
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
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
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] about Authorization
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] [packaging] split of systemd package
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] [packaging] split of systemd package
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] ip forwarding
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
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] about libmount
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] 208 VS 219
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
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] add new entry for HP ProBook 6555b to keyboard.hwdb
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&paste 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
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
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] failed to change interface name (systemd-networkd)
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
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
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] What I think is really wrong with systemd
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] Backport git notes
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
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] Fwd: sd 221 regression: login - nonexistent sessions via lightdm
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] sd 221 regression: login - nonexistent sessions via lightdm
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] sd 221 regression: login - nonexistent sessions via lightdm
Hello David, David Herrmann [2015-07-07 19:10 +0200]: > On Tue, Jul 7, 2015 at 6:55 PM, Martin Pitt 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
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
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] [HEADSUP] systemd-222 around the corner
Hey David, David Herrmann [2015-07-06 19:54 +0200]: > We intend to release v222 tomorrow. If anyone has open issues that > need to be in that release, please speak up. Right now, the release > consists almost exclusively of bug-fixes, and we want to get those > into distributions. Thanks for the notification! All green on the Debian/Ubuntu CI side for the record, today's trunk builds and tests just fine. Just the automatic tests though (but they already cover a lot), I'll do some manual testing tomorrow morning. Compared to 219 and 220, 221 was a real joy (aside from the rumbling about the man page path fixes, but I gave up and applied seddery now). 221-1, i. e. the first-ever upload of 221 went into Debian testing without a hitch and new release-critical bug reports; compared to 7 uploads with lots of patchery that it took for 220. All the semaphore, distro-side CI, and early announcement really paid off from my perspective! 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)
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
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
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
