[systemd-devel] How to specify dynamic services/requirements
Hello, I'm facing a problem with Xen machines that depends on MD devices. As I'm new to systemd world, I might not be seeing the clean solution. That's why I'm asking for an advice. MD devices are automatically detect by udev. If device state is safe, /dev/md/myraid is started. However, if the state is not safe (like a raid with a missing disk), udev starts mdadm-last-resort@.timer that tries to start the device anyway after 30s. As mdadm-last-resort conflicts with the device presence, it will not run if the required disk appears before 30s. Even with mdadm-last-resort running, MD device might still be usable, although degraded. Xen VM are started by xendomains.service, that simply calls a shell script like in SysV times. It start a bunch of VM in sequence. xendomains.service has only generic dependencies that let it run at a very early stage. Now the problem: If for any reason, a MD device takes some seconds to appear (or even 30s as the last resort), xendomains will fail to start any machine that depends on that MD device. I'm extending manually xendomains.service to depend on a series of MD devices, that fixed the start order problem. However, I created new problems. First I had to frequently regenerate those "Requires" as machines are frequently started/migrated between hosts (I also consider using systemd generators). But worse, whenever a single MD device permanently fails, xendomains is never started and all those VM that does not use the failed MD never start. I though that maybe I could use instances (xendomains@vm1.service) to launch VM individually, each of them depending on those devices it uses. However, these instances would have to be dynamically generated based on its configuration (systemd generators from /etc/xen/vm/xxx.cfg?), either on boot, shutdown or simply periodically. The stop procedure will still be the same, calling the SysV script as systemd will not know about VM (re)started after boot. I even though about simply create an alternative xendomains.service that does not depend on any MD device and launch it using a systemd timer if the xendomains that depends on MD devices isn't started after 30s. It looks ugly but it might work. Regards, -- Luiz Angelo Daros de Luca luizl...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysusers does not create nobody user
On Tue, 2017-09-12 at 13:26 +0200, Lennart Poettering wrote: > On Mo, 11.09.17 23:33, Sébastien Luttringer (se...@seblu.net) wrote: > > > Hello, > > > > It appears that the nobody user/group are not created by systemd-sysusers, > > despite its definition in sysusers.d/basic.conf. > > I guess nss_systemd is always providing answers for nobody user/group which > > mislead systemd-sysusers. > > > > # grep nobody /etc/passwd; echo $? > > 1 > > # getent passwd nobody > > nobody:*:65534:65534:User Nobody:/:/sbin/nologin > > # SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/basic.conf > > Group nobody already exists. > > User nobody already exists. > > > > I guess the issue is the same for root user. > > For reference, this come from this bug report: https://bugs.archlinux.org/t > > ask/ > > 55589 > > > > A side effect, may segfault sshd. See: https://bugs.archlinux.org/task/5557 > > 0 > > > > I tend to think that systemd-users should be able to start working with and > > empty passwd/group. > > What do you think is the correct way to fix these two? > > Ouch! This sounds like a systemd bug indeed. Could you please file a > bug on github about this? > > Lennart > Sure. Done here: https://github.com/systemd/systemd/issues/6808 Cheers, Sébastien "Seblu" Luttringer signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: load drivers only on "add" events
On Tue, Sep 12, 2017 at 01:38:00PM +0200, Lennart Poettering wrote: > On Mo, 11.09.17 11:47, Dmitry Torokhov (dmitry.torok...@gmail.com) wrote: > > > Previously we were loading kernel modules on all device events save > > for "remove". With the introduction of KOBJ_BIND/KOBJ_UNBIND this causes > > issues, as driver modules that have devices bound to their drivers get > > immediately reloaded, and it appears to the user that module unloading > > does not work. > > > > Let's change the rules to only load modules on "add" events instead. > > --- > > > > As a side note, I am confused about handling authorship information in > > systemd repository. The commit 9a39e1ce314d1a6f8a754f6dab040019239666a9 > > adding handling of bind/unbind actions is clearly taken from the email I > > posted on systemd-devel mailing list on the 31st, however it lists > > Lennart's name as the author? > > Oh sorry. As Mantas pointed out, the preferred way to accept patches > is via github PRs these days. To be friendly to submitters used to > old-style kernel submissions we have a bot running that permits us to > create a PR for your from patches submitted to the mailing list. PRs > created by the bot are assigned to the person who clicked on the bot's > email, which in this case was me. In github these PRs hence show up as > owned by me, but the invidual commits in them are still attributed to > you. But then, for single-patch PRs we don't do merges but > rebase+fforward, which github has an explicit button in its UI > for. But that rebase is kinda broken conceptually by them: it rewrites > the commits of the PR as a single commit attributed to the person who > clicked the button, losing all of the original attribution. > > Quite frankly, it's a mess, and a serious brokeness in the github > UI. Anyway, sorry for the confusion, it was definitely not my > intention to steal your commits. No worries, this commit is not something I would worry about too much, I just wanted to raise the issue in general. > > I figure in future we should keep in mind to never use github's > "rebase" merge button for PRs that include commits from people who are > not the PR owners. We should use real merges for all such cases to > avoid such fuck-ups. > > For your new patch the bot's notification is this btw: > > https://lists.freedesktop.org/archives/systemd-devel/2017-September/039513.html > > And I clicked on the link it provides now, so further discussion > should now happen in this github PR: > > https://github.com/systemd/systemd/pull/6802 > > Anyway, patch looks fine. Will merge as soon as the CI passes (and > this time with a real merge so that the attribution isn't lost) > > And please consider submitting patches as github PRs right-away, > that's our preferred workflow these days. OK, if I have more changes I'll do it through github (I do have an account there, it's just my workflow and tools all geared towards mailing list patch submission). Thanks! -- Dmitry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: load drivers only on "add" events
On Tue, Sep 12, 2017 at 2:38 PM, Lennart Poettering wrote: > But then, for single-patch PRs we don't do merges but > rebase+fforward, which github has an explicit button in its UI > for. But that rebase is kinda broken conceptually by them: it rewrites > the commits of the PR as a single commit attributed to the person who > clicked the button, losing all of the original attribution. > I think single commit is a different option (squash+merge); using rebase+merge should still be ok, it keeps the individual commits and only rewrites the "committer" info. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-sysusers does not create nobody user
On Mo, 11.09.17 23:33, Sébastien Luttringer (se...@seblu.net) wrote: > Hello, > > It appears that the nobody user/group are not created by systemd-sysusers, > despite its definition in sysusers.d/basic.conf. > I guess nss_systemd is always providing answers for nobody user/group which > mislead systemd-sysusers. > > # grep nobody /etc/passwd; echo $? > 1 > # getent passwd nobody > nobody:*:65534:65534:User Nobody:/:/sbin/nologin > # SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/basic.conf > Group nobody already exists. > User nobody already exists. > > I guess the issue is the same for root user. > For reference, this come from this bug report: > https://bugs.archlinux.org/task/ > 55589 > > A side effect, may segfault sshd. See: https://bugs.archlinux.org/task/55570 > > I tend to think that systemd-users should be able to start working with and > empty passwd/group. > What do you think is the correct way to fix these two? Ouch! This sounds like a systemd bug indeed. Could you please file a bug on github about this? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: load drivers only on "add" events
On Mo, 11.09.17 11:47, Dmitry Torokhov (dmitry.torok...@gmail.com) wrote: > Previously we were loading kernel modules on all device events save > for "remove". With the introduction of KOBJ_BIND/KOBJ_UNBIND this causes > issues, as driver modules that have devices bound to their drivers get > immediately reloaded, and it appears to the user that module unloading > does not work. > > Let's change the rules to only load modules on "add" events instead. > --- > > As a side note, I am confused about handling authorship information in > systemd repository. The commit 9a39e1ce314d1a6f8a754f6dab040019239666a9 > adding handling of bind/unbind actions is clearly taken from the email I > posted on systemd-devel mailing list on the 31st, however it lists > Lennart's name as the author? Oh sorry. As Mantas pointed out, the preferred way to accept patches is via github PRs these days. To be friendly to submitters used to old-style kernel submissions we have a bot running that permits us to create a PR for your from patches submitted to the mailing list. PRs created by the bot are assigned to the person who clicked on the bot's email, which in this case was me. In github these PRs hence show up as owned by me, but the invidual commits in them are still attributed to you. But then, for single-patch PRs we don't do merges but rebase+fforward, which github has an explicit button in its UI for. But that rebase is kinda broken conceptually by them: it rewrites the commits of the PR as a single commit attributed to the person who clicked the button, losing all of the original attribution. Quite frankly, it's a mess, and a serious brokeness in the github UI. Anyway, sorry for the confusion, it was definitely not my intention to steal your commits. I figure in future we should keep in mind to never use github's "rebase" merge button for PRs that include commits from people who are not the PR owners. We should use real merges for all such cases to avoid such fuck-ups. For your new patch the bot's notification is this btw: https://lists.freedesktop.org/archives/systemd-devel/2017-September/039513.html And I clicked on the link it provides now, so further discussion should now happen in this github PR: https://github.com/systemd/systemd/pull/6802 Anyway, patch looks fine. Will merge as soon as the CI passes (and this time with a real merge so that the attribution isn't lost) And please consider submitting patches as github PRs right-away, that's our preferred workflow these days. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
