Re: [systemd-devel] Systemd loads units before btrfs subvolumes are mounted
Le jeudi 26 mai 2016 à 11:36 +0200, Lennart Poettering a écrit : > On Thu, 26.05.16 00:52, Rashmi Ranjan Mohanty ( > rashmiranjan.moha...@microfocus.com) wrote: > > > Anyway we are changing the location of unit files to standard > > /usr/lib/systemd/system to fix the issue. Tested it and works fine > > after changing the location. > > /usr is for the OS vendor really. If your package is a 3rd party > package this is probably not a good idea. You could also simply copy > them into /etc/systemd/system, which would also work. I don't know how this software will be shipped, but if it is as a RPM package, it is best to be installed in /usr/lib/systemd/system. /etc/systemd/system should be for admins or 3rd parties not using packages. > > Just out of curiosity... If /usr itself is there on a separate > > partition, can this issue happen > > then or systemd can handle that scenario ? > > If /usr is split off, then we expect it to be mounted by the initrd > already, so that from systemd's PoV it is mounted always, and never > is > missing as long as PID 1 from the host is running. > > (Which means: if suse's default fs setup scheme indeed involves > splitting off /opt and mounting it explicitly, and they want to > support unit files stored in /opt, then I'd recommend them to do the > same for /opt as we require for /usr and mount it from the initrd > already). /opt is a separate btrfs subvolume (to ensure it is not rollbacked along with the system subvolume) but that's it. We don't split /opt to a different partition. -- Frederic Crozat Enterprise Desktop Release Manager SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Options for logging from service started before journald?
Le lundi 19 octobre 2015 à 18:03 +0200, Lennart Poettering a écrit : > On Sun, 18.10.15 18:36, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > > 18.10.2015 18:33, killermoehre пишет: > > >Am 18.10.2015 um 17:05 schrieb Andrei Borzenkov: > > >>What can be done to log from unit that needs to be started before > > >>journald? Journal, syslog or kmsg all require journald connection and as > > >>far as I understand will deadlock on waiting for journald to accept it. > > >>NULL is not an option; is tty the only choice left? > > >> > > >>Background - openSUSE tries to start haveged before journald to add > > >>randomness. > > >> > > >>This sounds like reincarnation of "how to log to syslog and be started > > >>before syslogd". This was solved by moving logging connection to > > >>journald and starting it very early. May be something like minilod or > > >>blogd that buffers output until journald is started would be appropriate > > >>here? > > > > > >How about not putting haveged in the early part if it can't work > > >without? In Arch Linux, haveged is a part of multi-user.target. > > > > > > > Apparently is some configuration not enough entropy was available. I cannot > > decide if journald really needs it or not. > > > > http://bugzilla.opensuse.org/show_bug.cgi?id=950857 > > This bug is nonsense. journald needs no entropy. It used cgrypt for > hashing, it never generates any keys with it. As mentioned it needs > randomness only for the hashtable seeds, and there it doesn't matter. Unfortunately, libgcrypt init does crazy things in FIPS mode (which is where the bug is coming from), which needs a lot of entropy (don't ask me why :( -- Frederic Crozat Enterprise Desktop Release Manager SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Detect if a script runs during bootup
Le jeudi 12 novembre 2015 à 11:31 +0100, Frank Steiner a écrit : > Reindl Harald wrote > > > > This is not possible as it is an opensuse system script that I > > > cannot > > > replace. > > > > says who? > > > > thats why /etc/systemd/system/ exists - override sysvinit scripts > > and > > even systemd-units from packages - just name it identical and it > > will win > > Right, but it's the /etc/init.d/nfsserver script that I'm not going > to replace as it does a lot of stuff for setting up the nfs server > the way the SuSE folks want it... For the record, nfsserver initscript is being replaced by a set of systemd service files in upcoming SLE12 SP1 ;) -- Frederic Crozat Enterprise Desktop Release Manager SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind, su - sessions and initscripts compatibility
Le jeudi 18 décembre 2014 à 12:19 +, Simon McVittie a écrit : > On 18/12/14 08:05, Andrei Borzenkov wrote: > > Any initscript that is using "su -" would [cause badness] > > Don't do that then? Init scripts are fairly clearly not login sessions. > Which init scripts do that? Unfortunately, we don't always have a choice, when initscripts are not shipped as part of packages in the distribution but shipped by an ISV or a random external software :( -- Frederic Crozat Project Manager Enterprise Desktop SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
Le lundi 24 mars 2014 à 18:58 +0100, Lennart Poettering a écrit : > It's simply that the PID file info in the chkconfig header is just > increadibly useful (since it allows us to identify the main process of a > service) and I'd really like to make sure we make use of it wherever > possible. So that chkconfig header bit is what I am interested in, not > the priority number... I must confess I stole the PID file info part and added it in the "LSB" header parsing, because we sometime have initscripts which such informations (which is good) and we also sometime would like to have this information handy, despite the fact we use LSB headers (and not "Fedora" ones).. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
Le lundi 24 mars 2014 à 19:24 +0100, Lennart Poettering a écrit : > On Mon, 24.03.14 19:20, Frederic Crozat (fcro...@suse.com) wrote: > > > Le lundi 24 mars 2014 à 18:58 +0100, Lennart Poettering a écrit : > > > > > It's simply that the PID file info in the chkconfig header is just > > > increadibly useful (since it allows us to identify the main process of a > > > service) and I'd really like to make sure we make use of it wherever > > > possible. So that chkconfig header bit is what I am interested in, not > > > the priority number... > > > > I must confess I stole the PID file info part and added it in the "LSB" > > header parsing, because we sometime have initscripts which such > > informations (which is good) and we also sometime would like to have > > this information handy, despite the fact we use LSB headers (and not > > "Fedora" ones).. > > I can't and won't make you stop doing this, but let me just say that I > really don't like that you do this, and that this is something I would > never merge upstream: > > We really don't want to extend old standards with private systemd > extensions, if we consider those old standards obsolete anyway. If > people want to use systemd features they should use systemd > files. Compatibility we do for the sake of compatibility only, not do > extend standards we consider deeply flawed, and that we'd prfer if they > went away sooner rather than later. Unfortunately, reality not always mixes well with such principles. You are fortunate to have support for this particular header in your flavor of initscripts and we aren't. And there has some particular times where we need this information and we can't just replace initscripts with a service counterpart (specially when you find issues during maintenance update). I'll be happy when we are able to drop those changes (or move them to generator) but we aren't there yet. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/11] Ensure that systemd-sysctl.service is applied after modules are loaded
Le lundi 16 juin 2014 à 10:49 -0400, Cristian Rodríguez a écrit : > El 16/06/14 08:52, Dr. Werner Fink escribió: > > On Fri, Jun 13, 2014 at 05:51:34PM +0200, Tom Gundersen wrote: > >> On Fri, Jun 13, 2014 at 4:41 PM, Werner Fink wrote: > >>> From: Frederic Crozat > >> > >> Hm, this would not help at all for modules loaded on-demand (which are > >> most of them). What is the problem being solved here? > > > > Indeed this does not help for the loaded on-demand modules as this requires > > an other approach. Nevertheless for the modules loaded by the service > > systemd-modules-load.service it helps to load the the kernel parameters > > afterwards as with many modules there will be *new* entiers below /proc/sys/ > > What exactly is the problem you are trying to solve with this ? It still > looks wrong .. The only way that could work is using an udev rule or an > /etc/modprobe.d/ snippet. AFAIK any other approach is doomed in one way > or another. See https://bugzilla.novell.com/show_bug.cgi?id=725412 -- Frederic Crozat Project Manager Enterprise Desktop SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix systemd-bootchart svg background
Hi all,
attached is a fix for SVG generated by systemd-bootchart, similar to a
fix already done in systemd-analyze.
--
Frederic Crozat
Project Manager Enterprise Desktop
SUSE
>From d018c76c3cfee47fe92f2115bee3be662ff9225d Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Mon, 16 Jun 2014 18:49:12 +0200
Subject: [PATCH] bootchart: set white background
In programs like eog and gimp the transparant background did not
look very good.
Similar fix from the one done in systemd-analyze (418e3750)
---
src/bootchart/svg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index a53f98a..8121199 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -123,6 +123,7 @@ static void svg_header(void) {
svg("\n
Re: [systemd-devel] PATCH: fix systemd-bootchart svg background
Le lundi 16 juin 2014 à 10:13 -0700, Kok, Auke-jan H a écrit : > On Mon, Jun 16, 2014 at 9:52 AM, Frederic Crozat wrote: > > Hi all, > > > > attached is a fix for SVG generated by systemd-bootchart, similar to a > > fix already done in systemd-analyze. > > yeah, that's a nice change. Looks good to me. Great. Could somebody push it on git, I don't have write privilege there ? Thanks ! -- Frederic Crozat Project Manager Enterprise Desktop SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 03/11] Ensure that ask-password-wall starts after getty.target
Le vendredi 20 juin 2014 à 04:48 +0200, Zbigniew Jędrzejewski-Szmek a écrit : > On Fri, Jun 13, 2014 at 04:41:02PM +0200, Werner Fink wrote: > > From: Frederic Crozat > > > > --- > > units/systemd-ask-password-wall.service.in |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git units/systemd-ask-password-wall.service.in > > units/systemd-ask-password-wall.service.in > > index 0eaa274..179b010 100644 > > --- units/systemd-ask-password-wall.service.in > > +++ units/systemd-ask-password-wall.service.in > > @@ -8,7 +8,8 @@ > > [Unit] > > Description=Forward Password Requests to Wall > > Documentation=man:systemd-ask-password-console.service(8) > > -After=systemd-user-sessions.service > > +Wants=getty.target > > +After=systemd-user-sessions.service getty.target > > Why? It feels wrong to pull in getty.target from a password > service. Password entry mechanisms and user login machanisms should be > loosely coupled. One might e.g. use one manually configured getty to > login into the system and e.g. enter passwords... Hmm, the initial patch was ensuring this service was only started after getty@tty1. From our changelog, it was later changed to the current version with : "- Make sure that systemd-ask-password-wall.service has a tty as it is not sure that a tty1 exists" Werner, could you elaborate ? -- Frederic Crozat Project Manager Enterprise Desktop SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files
Le vendredi 20 juin 2014 à 20:02 +0200, Lennart Poettering a écrit : > 2) I change the paths to store this in. I drop the coredumps in >/var/lib/systemd/coredump/ now. While the journal logs appear to be >something worth sharing across the network as "logs"; I am not >convinced that the coredumps would fit that category. How about storing those in /var/cache/systemd/coredump ? This would make obvious they can be safely removed at any time.. -- Frederic Crozat Project Manager Enterprise Desktop SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a écrit : > Signed-off-by: Gerardo Exequiel Pozzi > --- > units/systemd-udev-settle.service.in | 1 - > units/systemd-udev-trigger.service.in | 1 - > units/systemd-udevd-control.socket| 1 - > units/systemd-udevd-kernel.socket | 1 - > 4 files changed, 4 deletions(-) What do you expect to fix with this patch ? This will just break distro containers (nspawn / lxc) since it will cause udev to be started there. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
Le jeudi 25 juillet 2013 à 10:45 +0200, Thomas Bächler a écrit : > Am 25.07.2013 10:18, schrieb Frederic Crozat: > > Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a > > écrit : > >> Signed-off-by: Gerardo Exequiel Pozzi > >> --- > >> units/systemd-udev-settle.service.in | 1 - > >> units/systemd-udev-trigger.service.in | 1 - > >> units/systemd-udevd-control.socket| 1 - > >> units/systemd-udevd-kernel.socket | 1 - > >> 4 files changed, 4 deletions(-) > > > > What do you expect to fix with this patch ? > > > > This will just break distro containers (nspawn / lxc) since it will > > cause udev to be started there. > > If these units should not be started in containers, this should be > reflected with ConditionVirtualization. ConditionCapability is not > related to containers at all. Kay changed from ConditionVirtualizaton to ConditionCapability with commit 9371e6f3e04b03692c23e392fdf005a08ccf1edb (Date: Wed Oct 12 02:02:16 2011 +0200) -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is ExecStop executed when service terminates by itself?
Le jeudi 12 septembre 2013 à 01:22 +0200, Lennart Poettering a écrit : > On Fri, 26.07.13 17:44, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > > The https://bugzilla.novell.com/show_bug.cgi?id=830675 describes a > > problem where vbox initscript apparently stopped working under systemd. > > Script is supposed to start VMs on system boot. As long as I can tell, > > script actually does work - but when it finishes, systemd interprets it > > as service has finished and starts ExecStop script which in this case > > stops VMs again: > > > > jul 26 18:30:08 linux-mh9j systemd[1]: Child 11556 died (code=exited, > > status=0/SUCCESS) > > jul 26 18:30:08 linux-mh9j systemd[1]: Child 11556 belongs to vboxes.service > > jul 26 18:30:08 linux-mh9j systemd[1]: vboxes.service: control process > > exited, code=exited status=0 > > jul 26 18:30:08 linux-mh9j systemd[1]: vboxes.service got final SIGCHLD for > > state start > > jul 26 18:30:08 linux-mh9j systemd[1]: About to execute: /etc/init.d/vboxes > > stop > > ... > > jul 26 18:30:08 linux-mh9j vboxes[11580]: Shutting down Virtualbox > > machines: suse_12.3 (user: root) > > ... > > > > I do not see this behavior actually documented anywhere so my question > > is - is it intentional? > > > > This is openSUSE 12.3 with systemd 195. > > > > P.S. note proper unit will lose very useful functionality - actual > > status output of running VMs. Any news about ExecStatus support? > > ___ > > systemd-devel mailing list > > systemd-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > The "X-Systemd-RemainAfterExit" stuff suggests that there are Suse > patches to systemd's core involved here which play games with > RemainAfterExit=. Please direct any questions to the Suse folks > regarding this. It doesn't play "game", it just allows to set/unset RemainAfterExit flag to a initscript, which is not possible otherwise. > (Meh, such sysvinit script extensions are just evil shit, I wish suse > wouldn't do such nonsense...) Well, sometime, we don't have a choice, specially once a release is out and we can't start adding .service on the fly. The patches are pretty simple: https://build.opensuse.org/package/view_file/Base:System/systemd/remain_after_exit-initscript-heuristic-and-add-new-LSB-hea.patch?expand=1 https://build.opensuse.org/package/view_file/Base:System/systemd/service-flags-sysv-service-with-detected-pid-as-RemainAfte.patch?expand=1 It is the only way I found to have some coherent state for initscripts (systemclt status) between those which are "forking" type and those which are "oneshot" type (and we can't rely on PIDFile: header, since it is not a LSB header but a RH only one). If you have a better solution which doesn't involve creating .service file as a workaround, I'd be happy to drop those patches.. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is ExecStop executed when service terminates by itself?
Le jeudi 12 septembre 2013 à 12:50 +0200, Kay Sievers a écrit : > On Thu, Sep 12, 2013 at 8:57 AM, Frederic Crozat wrote: > > Le jeudi 12 septembre 2013 à 01:22 +0200, Lennart Poettering a écrit : > > >> (Meh, such sysvinit script extensions are just evil shit, I wish suse > >> wouldn't do such nonsense...) > > > > Well, sometime, we don't have a choice, specially once a release is out > > and we can't start adding .service on the fly. > > > > The patches are pretty simple: > > https://build.opensuse.org/package/view_file/Base:System/systemd/remain_after_exit-initscript-heuristic-and-add-new-LSB-hea.patch?expand=1 > > https://build.opensuse.org/package/view_file/Base:System/systemd/service-flags-sysv-service-with-detected-pid-as-RemainAfte.patch?expand=1 > > > > It is the only way I found to have some coherent state for initscripts > > (systemclt status) between those which are "forking" type and those > > which are "oneshot" type (and we can't rely on PIDFile: header, since it > > is not a LSB header but a RH only one). > > Hmm, you cannot rely on a header variable Fedora has used, but you can > invent your own ones? I don't understand that. The Fedora one doesn't follow LSB rules for naming (X-...). And it isn't even parsed when a LSB header is read: look at my patch, I had to alter systemd code so it accepted to read PidFile when a LSB header is detected (I initially didn't added this part but since there are some upstream which are using it, let's keep it). Moreover, the PIDFile header doesn't fix all possible cases (ie when a service might not create a PIDFile). For instance, network initscript might have process still running (dhcpcd, etc..) or none (if configured to use static IP). > > If you have a better solution which doesn't involve creating .service > > file as a workaround, I'd be happy to drop those patches.. > > This should and will some day be replaced by a generator which creates > unit files at startup. All the built-in initscripts logic will go > away. It will just move the issue from core systemd code to a generator but won't fix it, unfortunately. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] What to backport?
Le vendredi 13 septembre 2013 à 02:40 +0200, Lennart Poettering a écrit : > Heya! > > I'd like to announce a new service for systemd downstream packagers. In > the upstream git repository we have started indicating with "git notes" > which commits are particularly good candidates for backporting into the > systemd packages f various distributions. > > Any unanswered questions? No, just two words: thanks you ! -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journalctl performance
Le mercredi 25 septembre 2013 à 12:10 +0100, Colin Guthrie a écrit : > Hi, > > On a relatively average journal it can take a long time to page > through all the data collected. > > With data stored from 5th August to 25th September and running > "journalctl" and pressing G to jump to the end in less, and it takes > several minutes before the end of the messages are reached with > journalctl taking 100% CPU for most of that time. > > This is on a slightly older systemd (approximately similar to the 195 > version used in Suse - i.e. a shitton of backported patches!) but even > on my regular-use laptop (with SSD) and logs dating back to Jun 18th it > takes ~1m 30s to do the same. This is ultimately with something > approximating 2.5m lines of output to be paged through (systemd > debugging is on!) > > With this kind of performance, it's kinda a hard sell, although I'm not > really sure if I should *expect* any better performance and I appreciate > that listing specific date ranges or particular services can reduce the > amont of data returned and thus speed things up dramitcally. So I guess > my question is is it basically unrealistic to expect better performance > from a simple "just output everything" operation like this? Sadly this > is exactly the type of operation a typical user who is used to syslog > would do with journalctl and thus don't see the beneifts. > > Any thoughts on this? > > HDD (systemd 195+patches): > [root@marley ~]# du -sh /var/log/journal/ > 1.5G /var/log/journal/ > [root@marley ~]# date; journalctl | wc -l; date > Wed 25 Sep 11:39:00 BST 2013 > 1957295 > Wed 25 Sep 11:42:16 BST 2013 > > > SSD (systemd 207): > [root@jimmy ~]# du -sh /var/log/journal/ > 2.0G /var/log/journal/ > [root@jimmy ~]# date; journalctl | wc -l; date > Wed 25 Sep 11:40:18 BST 2013 > 2391076 > Wed 25 Sep 11:42:10 BST 2013 > > > And just for some plain text comparisions on the older, HDD machine: > > [root@marley ~]# date; journalctl >/home/journal; date > Wed 25 Sep 11:50:41 BST 2013 > Wed 25 Sep 11:53:59 BST 2013 > [root@marley ~]# wc -l /home/journal > 1957527 /home/journal > [root@marley ~]# date; cat /home/journal >/dev/null; date > Wed 25 Sep 11:54:49 BST 2013 > Wed 25 Sep 11:54:50 BST 2013 > [root@marley ~]# date; cat /home/journal | gzip >/home/journal.gz; date > Wed 25 Sep 11:55:23 BST 2013 > Wed 25 Sep 11:55:28 BST 2013 > [root@marley ~]# date; zcat /home/journal.gz >/dev/null; date > Wed 25 Sep 11:55:50 BST 2013 > Wed 25 Sep 11:55:51 BST 2013 > [root@marley ~]# date; cat /home/journal | xz >/home/journal.xz; date > Wed 25 Sep 11:56:15 BST 2013 > Wed 25 Sep 11:58:12 BST 2013 > [root@marley ~]# date; xzcat /home/journal.xz >/dev/null; date > Wed 25 Sep 12:01:25 BST 2013 > Wed 25 Sep 12:01:27 BST 2013 > [root@marley ~]# ls -lh /home/journal* > -rw-r--r-- 1 root root 244M Sep 25 11:53 /home/journal > -rw-r--r-- 1 root root 17M Sep 25 11:55 /home/journal.gz > -rw-r--r-- 1 root root 9.8M Sep 25 11:58 /home/journal.xz > > So, 2 seconds to page through 9.8M of compressed data directly with log > files, or ~2 minutes, 30 seconds to page through 1.5GB of journal based > logs to produce the same result (and I know the files here will be > "hot" in terms of cache etc which gives them a slightly unfair > advantage, but this would factor into real world usage too) > > Now, of course I do know that in the journalctl case, there is both more > to look at, perhaps some old journals that are ultimately analysed at > but never used because they are corrupt or something, and a whole bunch > of other data that is not synthesizable to the journalctl syslog-style > output, but forgetting features and looking at raw numbers and, as I > said above, it's a hard sell on the surface! > > Is there something wrong here? Are my numbers unrealistic? Is this > pointing at a larger problem with my setup/usage? I'm seeing similar bad numbers on openSUSE, but I recently noticed an owner difference between some journal files (since journal files moved from adm to systemd-journal group) and I'm wondering if it wasn't breaking cleanup / rotation of old journal entries (I haven't investigated much :( -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does not start in graphical mode
Le lundi 16 décembre 2013 à 12:32 +0100, Cecil Westerhof a écrit : > I made a openSUSE 13.1 VM in virtualbox. I start it in graphical mode. > But I do not get a X environment. > > With journalctl I see that it is reached: > Dec 16 12:18:33 linux-r4lo.site systemd[1]: Starting Graphical Interface. > Dec 16 12:18:33 linux-r4lo.site systemd[1]: Reached target Graphical > Interface. > > But only after giving: > init 5 > I get a X environment. > > With ‘journalctl -b -p err’ I see: > Dec 16 12:18:17 linux-r4lo kernel: piix4_smbus :00:07.0: SMBus base > address uninitialized - upgrade BIOS or use force_addr=0xaddr > Dec 16 12:18:34 linux-r4lo.site killproc[1170]: killproc: Usage: > killproc [-v] [-q] > [-L] [-g|-G] [-N] [-p pid_file] [-i ingnore_file] \ > [-c root] > [-t] [-SIG] /full/path/to/executable > killproc -l > > > Anybody an idea what could be happening here, or how to get information > to find out what is happening? Something is using killproc incorrectly.. You should look at the journalctl output more closely to find which service is sending this error. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd shutdown problem on openSuSE 13.1 with NFS mounted user home
Le mardi 04 février 2014 à 11:31 +0100, Rainer Krienke a écrit : > Hello, > > I am experiencing problems on openSuSE 13.1 systems using systemd, iff > this system uses NFS mounts for the users home directory mounted by > automount. > > Regular 13.1 installations with local user home directories just work fine. > > The problem is, that when trying to shut the system down this shutdown > process hangs for a very long time (> 5min). After 5 Min I went away , > when I came back an hour later the shutdown had succeded. > > To investigate the problem I created a systemd debug log of such a > shutdown you can download here: > > http://userpages.uni-koblenz.de/~krienke/tmp/systemd/shutdown-debug.log > > My problem is to extract really useful information about the real reason > for the hanging shutdown. My thoughts are, that perhaps systemd already > tries to umount NFS filesystems when there are still user processes > active on them and thus the umount hangs. > > In the default openSuSE 13.1 autofs.service file there is no dependency > on user sessions (only this: After=network.target remote-fs.target > ypbind.service) and perhaps this is the reason for my problem. But I do > not know how I could tell systemd to stop automount only after the users > session has been terminated and thus his NFS home directory can be > umounted by stopping automount. > > Any help is welcome This is a know bug, which is being worked on : https://bugzilla.novell.com/show_bug.cgi?id=849387 https://bugzilla.novell.com/show_bug.cgi?id=857031 -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Too little information is shown when system enters emergency mode
Le dimanche 21 octobre 2012 à 15:59 +0400, Andrey Borzenkov a écrit : > This issue comes up relatively often on openSUSE forums. Users > complaint that when system drops in emergency, there is nothing that > would explain user why it happened or what to do. Typical situation is > https://bugzilla.novell.com/show_bug.cgi?id=782904. > > openSUSE by default is using "splash quiet" kernel parameter. So the > first issue is, interpretation of "quite" changed in systemd. Now it > means suppress all output of systemd services. As result we have the > following (even without boot splash involved) when some device in > fstab is missing: > > doing fast boot > Creating device nodes with udev > Waiting for device /dev/root to appear: ok > fsck from util-linux 2.21.2 > [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/sda6 > /dev/sda6: clean, 31805/705744 files, 344231/2819584 blocks > fsck succeeded. Mounting root device read-write. > Mounting root /dev/root > mount -o rw,acl,user_xattr -t ext4 /dev/root /root > [ 10.706463] piix4_smbus :00:07.3: SMBus base address > uninitialized - upgrade BIOS or use force_addr=0xaddr > Welcome to emergency mode. Use "systemctl default" or ^D to enter default > mode. > Give root password for login: > > This is literally everything that user sees on console. My first > reaction was to add "systemctl --failed" as pre-exec to emergency. > Unfortunately: > > linux-q652:~ # systemctl --no-pager --failed > UNIT LOAD ACTIVE SUB JOB DESCRIPTION > > LOAD = Reflects whether the unit definition was properly loaded. > ACTIVE = The high-level unit activation state, i.e. generalization of SUB. > SUB= The low-level unit activation state, values depend on unit type. > JOB= Pending job for the unit. > > 0 units listed. Pass --all to see inactive units, too. > > Everything is fine. This is understandable - we are now in different > transaction and as far as I understand, systemctl --failed shows only > results of currently active transaction (am I right?). > > Only when "quiet" is turned off, do I really see something (again - > assuming we do not have bootsplash ...) > > Started /boot/efi [ OK > ] > Dependency failed. Aborted start of /mnt [ > ABORT] > Dependency failed. Aborted start of Login Service [ > ABORT] > Dependency failed. Aborted start of D-Bus System Message Bus [ > ABORT] > Welcome to emergency mode. Use "systemctl default" or ^D to enter default > mode. > > So right now if anything goes extremely wrong we have baffled user > sitting before "emergency mode" prompt and not knowing what to do > next. Is it considered a problem by someone else? Would it be feasible > to turn off "quiet" and bootsplash immediately after any unit failed > during system boot? Please note the version of systemd (v44) in openSUSE doesn't have all the needed bits to always display on the screen why dependency failed (and you end up in emergency mode). This is fixed with systemd 195 which should land in Factory pretty soon. However, on a more general basis (not openSUSE specific), I think we should add some special handly in systemd for a kernel command line option (for instance debug or debug=1), which would "expand" into "systemd.log_level=debug systemd.log_target=kmsg). This would be much easier to tell users when debug is needed and we could also add an additional menu entry in bootloader (under the "advanced settings") so this setting would be always available, if needed. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] openvpn + auth-user-pass + password agents
Le mardi 27 novembre 2012 à 09:50 +, Colin Guthrie a écrit : > Hi, > > Has anyone got patches to add password agent support to openvpn? I don't > see any patches in Fedora at least. I did them and they are upstream nowadays :) -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
Hi,
on openSUSE, we found the need to sometime force "--ignore-dependencies"
when systemctl is called (usually from other services / initscripts /
tools started by initscripts and which can cause deadlock).
To handle this in a transparent manner, I'd like to introduce
SYSTEMCTL_OPTIONS environment variable, which, if set, would cause
systemctl to append its contents as if it was specified on command line.
--
Frederic Crozat
SUSE
>From aeaf77d093f03133a675fee709b6ac8666d472ae Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Wed, 16 Jan 2013 17:21:13 +0100
Subject: [PATCH] systemctl: handle SYSTEMCTL_OPTIONS environment variable
SYSTEMCTL_OPTIONS environement variable allows to specify some options
for use by systemctl.
---
man/systemctl.xml |7 +++
src/systemctl/systemctl.c | 25 +
2 files changed, 32 insertions(+)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 2f33e0c..c623534 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -1293,7 +1293,14 @@
cat is equivalent to passing
--no-pager.
+
+$SYSTEMCTL_OPTIONS
+Options specified here will be used
+by systemctl, as if they had been added on command line.
+
+
+
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 7cf51dc..257fb39 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -43,6 +43,7 @@
#include "log.h"
#include "util.h"
#include "macro.h"
+#include "missing.h"
#include "set.h"
#include "utmp-wtmp.h"
#include "special.h"
@@ -5398,6 +5399,7 @@ static int runlevel_main(void) {
int main(int argc, char*argv[]) {
int r, retval = EXIT_FAILURE;
+char **to_free = NULL;
DBusConnection *bus = NULL;
DBusError error;
@@ -5407,6 +5409,27 @@ int main(int argc, char*argv[]) {
log_parse_environment();
log_open();
+if (secure_getenv("SYSTEMCTL_OPTIONS")) {
+char **parsed_systemctl_options = strv_split_quoted(getenv("SYSTEMCTL_OPTIONS"));
+
+if (*parsed_systemctl_options && **parsed_systemctl_options) {
+char **k,**a;
+char **new_argv = new(char*, strv_length(argv) + strv_length(parsed_systemctl_options) + 1);
+new_argv[0] = strdup(argv[0]);
+for (k = new_argv+1, a = parsed_systemctl_options; *a; k++, a++) {
+*k = strdup(*a);
+}
+for (a = argv+1; *a; k++, a++) {
+*k = strdup(*a);
+}
+*k = NULL;
+argv = new_argv;
+argc = strv_length(new_argv);
+strv_free (parsed_systemctl_options);
+to_free = new_argv;
+}
+}
+
r = parse_argv(argc, argv);
if (r < 0)
goto finish;
@@ -5508,6 +5531,8 @@ finish:
strv_free(arg_property);
+strv_free(to_free);
+
pager_close();
ask_password_agent_close();
polkit_agent_close();
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
Le mercredi 16 janvier 2013 à 17:47 +0100, Lennart Poettering a écrit : > On Wed, 16.01.13 17:34, Frederic Crozat (fcro...@suse.com) wrote: > > > Hi, > > > > on openSUSE, we found the need to sometime force "--ignore-dependencies" > > when systemctl is called (usually from other services / initscripts / > > tools started by initscripts and which can cause deadlock). > > I am pretty sure that this is really something to work-around (or even > better: just fix) in the specific init scripts, rather than work-around > in systemctl. Unfortunately, it is not that simple: - we are already forced to use --ignore-dependencies when network service tried to start/restart some network dependent services (like smb when ip address or dhcp hostname changes). - 2nd stage of our installer is running as part of the boot process and tries to start some services itself, but trying to start them will block, before they are already in the queue for being started and blocked by other services will be started once the installer has finished its duties. There, I've also discovered the merge of actions in the queue is not working at 100% : if you specify --ignore-dependencies on a action which is already in the queue, it will be bumped on top, to be processed but the options seems to be dropped (causing a deadlock). But that's another story. I was planning to handle this environment variable in our tools but tools team would prefer to have it in systemctl. I guess I'll have to maintain this patch downstream in openSUSE :( -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
Le mercredi 16 janvier 2013 à 16:58 +, Colin Guthrie a écrit :
> 'Twas brillig, and Frederic Crozat at 16/01/13 16:34 did gyre and gimble:
> > Hi,
> >
> > on openSUSE, we found the need to sometime force "--ignore-dependencies"
> > when systemctl is called (usually from other services / initscripts /
> > tools started by initscripts and which can cause deadlock).
> >
> > To handle this in a transparent manner, I'd like to introduce
> > SYSTEMCTL_OPTIONS environment variable, which, if set, would cause
> > systemctl to append its contents as if it was specified on command line.
>
> Most common use case for this is using the --no-block and
> --ignore-dependancies options. I found a need for this to prevent
> deadlocks when certainly early packages (e.g. mandriva_everytime (if you
> can remember back that far to your mdv days) which would do various h/w
> fu (much of it outdated these days tho') and even start some services.
> As this was done early in boot the starting of those services could
> block in systemd - hence the need to use --no-block)
>
> IIRC this is handled in the redhat "initscripts" (used also on Mageia -
> dunno about suse...)
>
>
> e.g. see this from /etc/init.d/functions (possibly a bit out of date and
> IIRC slightly patched by me for Mageia too (the NO_BLOCK option)):
>
> systemctl_redirect () {
> local s
> local prog=${1##*/}
> local command=$2
> local options=""
>
> case "$command" in
> start)
> s=`gprintf "Starting %s (via systemctl): " $prog`
> ;;
> stop)
> s=`gprintf "Stopping %s (via systemctl): " $prog`
> ;;
> reload|try-reload)
> s=`gprintf "Reloading %s configuration (via systemctl):
> " $prog`
> ;;
> restart|try-restart|condrestart)
> s=`gprintf "Restarting %s (via systemctl): " $prog`
> ;;
> esac
>
> if [ -n "$SYSTEMCTL_IGNORE_DEPENDENCIES" ] ; then
> options="$options --ignore-dependencies"
> fi
> if [ -n "$SYSTEMCTL_NO_BLOCK" ] ; then
> options="$options --no-block"
Yes, we have a similar patch in /etc/rc.status on openSUSE, which is
using SYSTEMCTL_OPTIONS as variable name. So far, I haven't found a case
where --no-block was needed, only "--ignore-dependencies" was needed
(which is why I used a catch-all variable name, just in case
"--no-block" would be needed later, so we wouldn't need to release
another version of the package shipping /etc/rc.status).
But it is no longer enough because we started to migrate some
initscripts to systemd unit and our YaST tools have also learned to call
systemctl to start / stop services. And because of that, the
"workaround" in /etc/rc.status is no longer effective. And YaST team
doesn't handle to handle the "SYSTEMCTL_OPTIONS" workaround in their
generic service handling code (I can understand that).
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
Le mercredi 16 janvier 2013 à 17:15 +, Colin Guthrie a écrit : > 'Twas brillig, and Frederic Crozat at 16/01/13 17:07 did gyre and gimble: > > I was planning to handle this environment variable in our tools but > > tools team would prefer to have it in systemctl. I guess I'll have to > > maintain this patch downstream in openSUSE :( > > It would seem to me that the tools is where it should be handled (as is > done in the initscripts wrapper), but hey ho' - everyone prefers it done > elsewhere. :) > At least it's a relatively neat patch and hopefully it's need within > Suse will disappear as the tools are refactored anyway? No, YaST tool has already been updated to handle systemd (and they prefer to not handle workaround like this). We'll have to live with a patched systemctl. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl
Le jeudi 17 janvier 2013 à 13:59 +, Colin Guthrie a écrit : > 'Twas brillig, and Frederic Crozat at 16/01/13 17:15 did gyre and gimble: > > Yes, we have a similar patch in /etc/rc.status on openSUSE, which is > > using SYSTEMCTL_OPTIONS as variable name. So far, I haven't found a case > > where --no-block was needed, only "--ignore-dependencies" was needed > > (which is why I used a catch-all variable name, just in case > > "--no-block" would be needed later, so we wouldn't need to release > > another version of the package shipping /etc/rc.status). > > > > But it is no longer enough because we started to migrate some > > initscripts to systemd unit and our YaST tools have also learned to call > > systemctl to start / stop services. And because of that, the > > "workaround" in /etc/rc.status is no longer effective. And YaST team > > doesn't handle to handle the "SYSTEMCTL_OPTIONS" workaround in their > > generic service handling code (I can understand that). > > It feels kinda weird that --ignore-dependancies is the right solution > here. I would have thought that --no-block makes more sense generally. > Ignoring deps when starting a job could easily lead to failures, but if > you just want to start something and not necessarily wait for it to be > available, --no-block seems the better solution to me. > > I guess it very much depends on where you are using it and for what > purposes, but as mentioned in the man page --ignore-dependencies "is > mostly a debugging and rescue tool for the administrator and should not > be used by applications" which makes me wonder if --no-block might be > the better solution to at least some of your problems. IIRC, it was tested and it didn't help (probably because those blocking services were waiting for a dependency, like network being up, which wasn't visible at the systemd level). Moreover, using --no-block, you can't be sure the service you just started has been really started (which can be problematic). But it might be worth investigating again if --no-block could be used for calls from inside network hooks (although it would delay those services execution after the network service is complete, unlike the solution we have ATM). Initially, we were "unwrapping" initscripts (ie not starting them under systemd) instead of --ignore-dependencies, because it was only done during "2nd stage" of our installer (ie not often and before those services would be "normally" started by systemd). Now, services are handled through systemd but we are still stucked due to the "pending" queue of services to be started by systemd. And if, for instance, the "2nd stage" installer is starting sshd to allow remote installation, you can't really use --no-block because sshd won't be started. Again, it is not a definitive answer, but so far, it is the one which has proved to be working for us. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - .gitignore Makefile.am src/bootchart src/core src/efi-boot-generator src/shared
Le lundi 21 janvier 2013 à 12:03 +0100, Kay Sievers a écrit : > On Mon, Jan 21, 2013 at 7:29 AM, Andrey Borzenkov wrote: > > >> commit f4ce2b3e5ce93b83f14f8785e205ebb5a9b8c1df > >> Author: Lennart Poettering > >> Date: Mon Jan 21 01:02:53 2013 +0100 > >> > >> efi: add efi boot generator that automatically mounts the ESP to /boot > > > > Has something changed? ESP has always been mounted on /boot/efi, and > > mounting it on /boot is plain wrong; ESP is shared resource for all OS > > installed, not private space to place files of this specific > > installation. > > The Linux kernel acts as an EFI boot loader, if copied to the ESP it > can be directly executed by the EFI firmware. > > The initramfs and the kernel live in a vendor sub-directory in the ESP > and are read directly by EFI code, and there is no need for grub2, any > other additional filesystem driver, raid, network setup, or whatever > additional code people think they would need to bring up all sorts of > systems. > > The kernel itself with the initramfs can boot everything, has all the > filesystem access which is ever needed, there is no need for anything > else on EFI machines. Even the craziest setups can boot directly out > of the firmware that way. > > It's the simplest and most efficient setup a system can have. But this setup is not shim loader/"Secure Boot" compatible. And it will force most (if not all) distributions to probably "patch" (or disable) this generator so it behave as it is expected by them (ie /boot/efi). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - .gitignore Makefile.am src/bootchart src/core src/efi-boot-generator src/shared
Le lundi 21 janvier 2013 à 11:49 +, Colin Guthrie a écrit : > 'Twas brillig, and Kay Sievers at 21/01/13 11:03 did gyre and gimble: > > On Mon, Jan 21, 2013 at 7:29 AM, Andrey Borzenkov > > wrote: > > > >>> commit f4ce2b3e5ce93b83f14f8785e205ebb5a9b8c1df > >>> Author: Lennart Poettering > >>> Date: Mon Jan 21 01:02:53 2013 +0100 > >>> > >>> efi: add efi boot generator that automatically mounts the ESP to /boot > >> > >> Has something changed? ESP has always been mounted on /boot/efi, and > >> mounting it on /boot is plain wrong; ESP is shared resource for all OS > >> installed, not private space to place files of this specific > >> installation. > > > > The Linux kernel acts as an EFI boot loader, if copied to the ESP it > > can be directly executed by the EFI firmware. > > > > The initramfs and the kernel live in a vendor sub-directory in the ESP > > and are read directly by EFI code, and there is no need for grub2, any > > other additional filesystem driver, raid, network setup, or whatever > > additional code people think they would need to bring up all sorts of > > systems. > > > > The kernel itself with the initramfs can boot everything, has all the > > filesystem access which is ever needed, there is no need for anything > > else on EFI machines. Even the craziest setups can boot directly out > > of the firmware that way. > > > > It's the simplest and most efficient setup a system can have. > > > > And "plain wrong" is the sick game which is called grub2, not mounting > > the EFI partition at /boot. :) > > Forgive the noob question (as I have no EFI h/w to be bothered to learn > this stuff!), but if What Andrey says is correct would this mean we > cannot have two separate installs without sharing the same /boot? (or > even a Windows install assuming it uses that space too?). Can you > comment on those kind of set ups? You can have several kernel / boot managers on a UEFI partition, usually from different vendors, because each vendor must use a different prefix (/EFI/openSUSE vs /EFI/Fedora for instance), so it shouldn't conflict, unless you try to use different release of the same distributions. In that case, you'll probably need to edit the EFI Boot Manager entries (using efibootmgr) and hope each kernel / initrd are stored with a versioned name. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - .gitignore Makefile.am src/bootchart src/core src/efi-boot-generator src/shared
Le lundi 21 janvier 2013 à 13:09 +0100, Kay Sievers a écrit : > On Mon, Jan 21, 2013 at 1:05 PM, Frederic Crozat wrote: > > Le lundi 21 janvier 2013 à 12:03 +0100, Kay Sievers a écrit : > > >> It's the simplest and most efficient setup a system can have. > > > > But this setup is not shim loader/"Secure Boot" compatible. > > Sure it is. Why not? It has nothing to do which filesystem /boot uses. the generator isn't a problem, I was commenting on the "simplest" part. You still need a shim loader there, since an EFI-stubed kernel can't be signed by UEFI Signing Service (I'm not discussing signing a kernel yourself or injecting its key into EFI firmware). > > And it will > > force most (if not all) distributions to probably "patch" (or disable) > > this generator so it behave as it is expected by them (ie /boot/efi). > > If you would have read the code or the commit or the wiki page, you > would have noticed that the generator never gets active in any other > setup. I read the code before commenting, and I noticed it won't quick in as long as /boot is not empty nor mounted in fstab. But you are still "deviating" from the common practice among distributions and to be useful and work "as expected" on such distributions, this generator should use /boot/efi instead. Obviously, you already made you mind, so I guess it is useless to argue anymore but I doubt it will be of great usage on most distributions. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd down/upstream meeting at FOSDEM?
Le mardi 22 janvier 2013 à 23:11 +0100, Lennart Poettering a écrit : > Heya, > > I just learned that a number of systemd downstream and upstream folks > are attending FOSDEM. We'll at least have Michael Biebl, Tollef Fog > Heen, Colin Guthrie, Kay Sievers, Harald Hoyer and myself around. > > We were wondering whether it might be a good idea to meet up for some > kind of systemd BOF at FOSDEM? My current thinking goes towards maybe > lunch on saturday, but details about time and location are to be > determined. > > Anybody else is coming who'd like to join us? Anybody from ArchLinux > attending FOSDEM? SUSE? Or the other distributions? I'll be there too (doing also a talk about Secure Boot on Sunday). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: improve Environment= section in manpage
Hi all,
while working on another bug, I discovered the "strange" way systemd is
parsing Environment= in .service and thought it was worth documenting
(because I don't expect people to find this syntax by themselves unless
they read the parsing code ;)
--
Frederic Crozat
SUSE
>From 2cfd1ed4d853be4a22cc102037347c9041bf5ced Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Thu, 24 Jan 2013 17:55:42 +0100
Subject: [PATCH] man: systemd.exec - explicit Environment assignment
Be more verbose about using space in Environment field and not
using value of other variables
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=840260
---
man/systemd.exec.xml |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 8a22ac0..70859fd 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -286,7 +286,14 @@
empty string is assigned to this
option the list of environment
variables is reset, all prior
-assignments have no effect. See
+assignments have no effect.
+Value of other environment variable will
+not be expanded when used as value.
+If you need to assign value containing space
+to a variable, use double quotes (")
+for the assignment. Example:
+Environment="VARIABLE1=word1 word2".
+See
environ7
for details.
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] List configuration dirs in order of a preference
Le vendredi 25 janvier 2013 à 19:37 +0100, Lennart Poettering a écrit : > On Fri, 25.01.13 11:14, Michal Vyskocil (mvysko...@suse.cz) wrote: > > > It makes an order of a preference more clear without a need to read the > > CONFIGURATION FORMAT section. > > To make this really clear: in systemd /etc overrides both /run and and > /usr/. And /run overrides /usr. > > Administrator >> Runtime >> Vendor. > > The current man pages should document already correctly everywhere, > though for unit files we are currently not mentioning this at all, and > we should add that. I think Michal might also be confused because the behavior changed between systemd v44 (which is currently shipped as stable on openSUSE 12.2) and latest systemd releases. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] core: keep mountinfo .mounts until late shutdown
Le lundi 04 février 2013 à 16:23 +0100, Zbigniew Jędrzejewski-Szmek a écrit : > Hi, > > On Mon, Feb 04, 2013 at 03:03:59PM +0100, Umut Tezduyar wrote: > > Downside of this patch is, mountinfo mounts stick around as inactive-dead > > even when the file system they represent is unmounted. > > > > > > On Mon, Feb 4, 2013 at 3:00 PM, Umut Tezduyar wrote: > > > > > .mount units coming from /proc/self/mountinfo file are > > > unmounted after local-fs.target is reached during shutdown. > > > > > > Problem: .mount units popping up in mountinfo file are > > > added to systemd without any dependency. For that reason, > Hm, what do you mean exactly by that? Mount units I see have dependencies > on mount points higher in the hierarchy. E.g. > Requires=systemd-journald.socket -.mount home.mount > After=systemd-journald.socket -.mount home.mount > Description=/home/zbyszek/debian-x32/home > SourcePath=/proc/self/mountinfo > > > > they are the first one to be unmounted during shutdown. > This seems correct. Usually they were mounted last, by an admin, > and should be unmounted first. There was a bug in v44 where some mount points mounted by initscripts (for instance /var/lib/nfs/rpc_pipefs in nfs initscript) which was unmounted before initscripts were stopped but it was fixed during the rewrite done for fstab-generator (I've extracted it as https://build.opensuse.org/package/view_file?expand=1&file=fix-umount-order-at-shutdown.patch&package=systemd.openSUSE_12.2_Update&project=home%3Afcrozat%3Abranches%3AopenSUSE%3A12.2%3AUpdate ) -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network/openvswitch dependency loop/deadlock
Le jeudi 07 février 2013 à 09:55 -0600, Ian Pilcher a écrit : > On 02/07/2013 06:13 AM, Colin Guthrie wrote: > > 'Twas brillig, and Ian Pilcher at 06/02/13 22:27 did gyre and gimble: > >> * systemd sees "Before=... network.target" in openvswitch.service and > >> waits for the network service to complete -- which will never happen, > >> because the network service is waiting for the openvswitch servicr to > >> start. > >> > >> * DEADLOCK! > > > > This last step shouldn't (in theory) be a problem as far as I understand > > it. Before=network.target doesn't imply it that has to wait for > > network.service to complete - it should only imply that both > > network.service and openvswitch.service are both have to start before > > network.target is considered reached. If it said After=network.target > > then I would see an obvious deadlock, but with both saying Before= they > > should be able to work fine. > > Well it would help if my brain worked a bit better. openvswitch.service > does, in fact, contain: > > After=syslog.target network.target > > So there's the "obvious deadlock". > > >> Assuming that the answer is yes, what is the best way to work around > >> this? > >> > >> * Removing network.target from the Before=... line in > >> openvswitch.service is not an option. See comment #1 of that bug. > >> > >> * Changing the network startup script (ifup-ovs) to use "systemctl > >> --ignore-dependencies start openvswitch.service" appears to work, but > >> the man page discourages its use for anything but debugging. > > > > Depending on how the daemon is used, it might make more sense to use > > --no-block. This will return control to the command line straight away, > > but obviously the daemon may not be "ready" for communications yet and > > the script may fail. > > --no-block is not going to be an option. The script is trying to bring > up an Open vSwitch bridge, and it can't do so without a running daemon. > > > I'm not familiar with the daemon or what it does and how any IPC may > > work (i.e. how you talk to the daemon). > > The script uses ovs-vsctl to talk to ovs-vswitchd. > > > I get the feeling I'm perhaps misinterpreting something. I think the > > real reason for the deadlock would be good to track down. It could be > > that it is being artificially held back from completing or some other > > dep is causing the problem. > > You made the mistake of believing what I wrote. > > > Also re the initscripts tweaks and the if statement proposed in the bug, > > there is a SYSTEMCTL_IGNORE_DEPENDENCIES=1 env var you can export that > > will make "service openvswitch start" pass the --ignore-dependencies > > argument if it redirects to systemctl. That's likely cleaner than the if > > [ -x /usr/bin/systemctl ] check. Obviously as this is arguably not the > > right fix anyway, it's perhaps a moot point. > > Cool. > > So given that it is in fact "After=... network.target" (in > openvswitch.service) that is causing the problem, do you see a better > solution than using SYSTEMCTL_IGNORE_DEPENDENCIES? We have exactly the same issue on openSUSE with some network services, and we are using --ignore-dependencies in those case (because --no-block is not always the "right" solution). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: handle rbind mount as bind mounts
Hi all,
attached patch fixes bug reported recently about systemd not handling
rbind mount as bind mount.
Fix is straightforward.
--
Frederic Crozat
SUSE
>From df77b11852d6b3495848c4123e7cbd9f099910f9 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Thu, 21 Feb 2013 15:40:52 +0100
Subject: [PATCH] detect rbind as bind mount
Correctly detect rbind mount option as bind mount.
Fixes https://bugzilla.novell.com/show_bug.cgi?id=804575.
---
src/core/mount.c | 6 ++
src/fstab-generator/fstab-generator.c | 4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index e3d298e..419cf27 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -329,6 +329,12 @@ static bool mount_is_bind(MountParameters *p) {
if (p->fstype && streq(p->fstype, "bind"))
return true;
+if (mount_test_option(p->options, "rbind"))
+return true;
+
+if (p->fstype && streq(p->fstype, "rbind"))
+return true;
+
return false;
}
diff --git a/src/fstab-generator/fstab-generator.c b/src/fstab-generator/fstab-generator.c
index bfedded..9db4123 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -178,7 +178,9 @@ static bool mount_is_bind(struct mntent *me) {
return
hasmntopt(me, "bind") ||
-streq(me->mnt_type, "bind");
+streq(me->mnt_type, "bind") ||
+hasmntopt(me, "rbind") ||
+streq(me->mnt_type, "rbind");
}
static bool mount_is_network(struct mntent *me) {
--
1.8.1.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On(Resume|suspend|hibernate) in unit files?
Le jeudi 28 février 2013 à 15:55 +, Colin Guthrie a écrit : > 'Twas brillig, and Lennart Poettering at 28/02/13 12:37 did gyre and gimble: > > On Wed, 27.02.13 22:22, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: > > > >> Hi: > >> > >> There is buggy, legacy software around which simply does not behave > >> properly when faced with resume/suspend/hibernate which is not > >> always practical to modify or fix. > >> > >> Is there any way to have something like > >> > >> ReloadOnResume=[true|false] > >> StopOnSuspend=[true|false] > >> > >> Or some other mechanism provided by systemd/logind that does not > >> require to use the ugly /usr/lib/systemd/system-sleep/ hooks ? > > > > My recommendation would be to fix the software in question. I mean, we > > will provide compatibility with older software, but we are very > > conservative on adding hacky work-arounds for broken software, > > especially if no such hack existed in the solutions that were used > > before systemd. > > FWIW, while I'm in total agreement with what you say and the resolution, > the pm-utils hooks are what was used before systemd so there technical > was such a hack that existed in the solutions that were used before systemd. > > I remember seeing various hooks here to e.g. shut down mysql and restart > it again and such like things. That particular example hasn't been > needed for me for ages, but I'm sure there are other examples that might > be more legitimate. > > That said, I think Fred had patches that are applied in Suse to read > these pm-utils hooks anyway, so that might be what Cristian needs? Well, the patch in question is even more ugly than that, since it defers to pm-utils (when available) suspend / hibernate ;( -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On(Resume|suspend|hibernate) in unit files?
Le jeudi 28 février 2013 à 17:58 +0100, Tom Gundersen a écrit : > On Thu, Feb 28, 2013 at 5:51 PM, Frederic Crozat wrote: > > Le jeudi 28 février 2013 à 15:55 +, Colin Guthrie a écrit : > >> 'Twas brillig, and Lennart Poettering at 28/02/13 12:37 did gyre and > >> gimble: > >> > On Wed, 27.02.13 22:22, Cristian Rodríguez (crrodrig...@opensuse.org) > >> > wrote: > >> > > >> >> Hi: > >> >> > >> >> There is buggy, legacy software around which simply does not behave > >> >> properly when faced with resume/suspend/hibernate which is not > >> >> always practical to modify or fix. > >> >> > >> >> Is there any way to have something like > >> >> > >> >> ReloadOnResume=[true|false] > >> >> StopOnSuspend=[true|false] > >> >> > >> >> Or some other mechanism provided by systemd/logind that does not > >> >> require to use the ugly /usr/lib/systemd/system-sleep/ hooks ? > >> > > >> > My recommendation would be to fix the software in question. I mean, we > >> > will provide compatibility with older software, but we are very > >> > conservative on adding hacky work-arounds for broken software, > >> > especially if no such hack existed in the solutions that were used > >> > before systemd. > >> > >> FWIW, while I'm in total agreement with what you say and the resolution, > >> the pm-utils hooks are what was used before systemd so there technical > >> was such a hack that existed in the solutions that were used before > >> systemd. > >> > >> I remember seeing various hooks here to e.g. shut down mysql and restart > >> it again and such like things. That particular example hasn't been > >> needed for me for ages, but I'm sure there are other examples that might > >> be more legitimate. > > If they are needed, couldn't equivalent /usr/lib/systemd/system-sleep > hooks be created in their place? For most of them, I guess, yes. But there is no ordering guaranty in systemd-sleep directory, unlike pm-utils (were you can order modules by their name). > >> That said, I think Fred had patches that are applied in Suse to read > >> these pm-utils hooks anyway, so that might be what Cristian needs? > > > > Well, the patch in question is even more ugly than that, since it defers > > to pm-utils (when available) suspend / hibernate ;( > > At some point we had a 'legacy' hook for Arch, but eventually decided > against shipping it. It was a script > /usr/lib/systemd/system-sleep/pm-utils which would simply convert the > systemd arguments to pm-utils ones and call all the scripts in > /usr/lib/pm-utils/sleep.d with this argument. Is that what you had as > well? Something like that (I wasn't aware of it, otherwise I would probably have stolen it :) but since it had to be done very late in 12.3 release cycle, I modified systemd-sleep to call pm-utils (if available), after running systemd hooks, instead of doing the write to /sys/power/disk. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl link and systemctl enable/disable incompatibility
Le vendredi 15 mars 2013 à 09:43 +0200, Oleksii Shevchuk a écrit : > Hi list. Currently we have next problem. systemctl have link option, and > manual says: > The effect of this command is that a unit file is available for > start and *other* commands although it isn't installed directly in the > unit search path. > > So, I assume at that point, that systemctl enable/disable should work > for linked units. Unfortunately it couldn't, because install/remove > contexts called with allow_symlinks=false, so unit_file_load returns > ELOOP. Looks like this behavior couldn't be changed with simple > allow_symlinks=false->true, because of problems with disable and Alias. > > So, either enable/disable logic should be refactored, or additional info > should go to the manual page, or link functionality should be dropped i > think. > > What is the right way to solve that problem? Bug was opened on similar issue this week : https://bugs.freedesktop.org/show_bug.cgi?id=62300 -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootchart issues on slow hardware
Le dimanche 17 mars 2013 à 14:54 +0100, Kay Sievers a écrit : > Here is a chart: > http://people.freedesktop.org/~kay/bootchart-20130317-1434.svg > > Rotating media and really cheap hardware looks very sad, and we take > like 5 times longer to boot than Windows 8. > > Why does bootchart stop before all the *really* slow desktop stuff starts? > > Why does bootchart claim an idle time of ~5 sec, not that I wouldn't > like that, but :) Another thing we lost with current readahead (compared to what we had with meego's readahead) is prefetching user session files (say gnome-shell, files in /usr/share/applications, etc..), which, on workstation used by a single user is really having an impact on perceived system "speed" (ie when user can start working). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootchart issues on slow hardware
Le lundi 18 mars 2013 à 14:34 +0100, Lennart Poettering a écrit : > On Mon, 18.03.13 09:39, Frederic Crozat (fcro...@suse.com) wrote: > > > Le dimanche 17 mars 2013 à 14:54 +0100, Kay Sievers a écrit : > > > Here is a chart: > > > http://people.freedesktop.org/~kay/bootchart-20130317-1434.svg > > > > > > Rotating media and really cheap hardware looks very sad, and we take > > > like 5 times longer to boot than Windows 8. > > > > > > Why does bootchart stop before all the *really* slow desktop stuff starts? > > > > > > Why does bootchart claim an idle time of ~5 sec, not that I wouldn't > > > like that, but :) > > > > Another thing we lost with current readahead (compared to what we had > > with meego's readahead) is prefetching user session files (say > > gnome-shell, files in /usr/share/applications, etc..), which, on > > workstation used by a single user is really having an impact on > > perceived system "speed" (ie when user can start working). > > Hmm, how would we have lost that? the readahead stuff stays running for > a while after the system job queue is empty, in order to cover the user > session and suchlike. I've checked readahead data on my test "netbook" and unfortunately, the system is taking soo much time to start GNOME 3 after the job queue empty that it doesn't catch enough readahead data on the user session (and it can only work if you enable autologin). I've checked what we were doing on Meego and the timer was 15s instead of 10s (not sure it would gain much more). What is frustrating is to see IO going near 0 once the readhead replay is done and then, going up just for the user session, and in between, a nice gap which would love to be filled with IO prefetching ;) And when you start digging in the readahead data, you can see ugly prefetch, like stuff in /var/log/* :( -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix LSB Provides handling
Hi all,
in https://bugzilla.novell.com/show_bug.cgi?id=809646 we noticed LSB
Provides can sometime be incorrectly handled (resulting in "Failed to
add LSB Provides name .service, ignoring: File exists" errors),
depending on initscript parsing order (if a provides is required by
another initscript and this initscript is parsed before the one with the
provides).
Attached patch fixes this issue.
--
Frederic Crozat
SUSE
>From 4e7c74b96a2c154cfb3e60fc14c8b50070808758 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Thu, 21 Mar 2013 15:40:45 +0100
Subject: [PATCH] core: ensure LSB Provides are handled correctly
Depending on initscript reading order, one initscript might
reference as a Required-Start/Should-Start dependency another
initscript provides, before initscript containing provides has been
parsed and the corresponding in-memory unit has been created. This
change ensure the unit created for the dependency is merged with the
one containing the provides.
---
src/core/service.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/core/service.c b/src/core/service.c
index 080d583..efbc94c 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -764,8 +764,15 @@ static int service_load_sysv_path(Service *s, const char *path) {
if (r == 0)
continue;
-if (unit_name_to_type(m) == UNIT_SERVICE)
-r = unit_add_name(u, m);
+if (unit_name_to_type(m) == UNIT_SERVICE) {
+Unit *existing_unit;
+
+existing_unit=manager_get_unit(UNIT(s)->manager, m);
+if (existing_unit)
+r = unit_merge (u, existing_unit);
+else
+r = unit_add_name(u, m);
+}
else
/* NB: SysV targets
* which are provided
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: ensure systemd-udev is started before local-fs-pre.target
Hi all, on https://bugzilla.novell.com/show_bug.cgi?id=809820 we noted loopback mountpoint could failed if systemd was trying to mount them before systemd-udevd was started, since some static devices node wouldn't be created in time. This patches ensures local-fs-pre.target is started after systemd-udevd is started. -- Frederic Crozat SUSE >From 94dc949a3056eb989ff2e0c90d951b55eabf72f6 Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Thu, 21 Mar 2013 17:28:13 +0100 Subject: [PATCH] udevd: ensure static nodes are created before local-fs mount static nodes (like /dev/loop-control) are created when systemd-udevd is started and needed to mount loopback devices. Therefore, local-fs-pre.target should be only started after systemd-udevd is started. --- units/systemd-udevd.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/systemd-udevd.service.in b/units/systemd-udevd.service.in index 86c650c..97fb2f3 100644 --- a/units/systemd-udevd.service.in +++ b/units/systemd-udevd.service.in @@ -10,7 +10,7 @@ Description=udev Kernel Device Manager Documentation=man:systemd-udevd.service(8) man:udev(7) Wants=systemd-udevd-control.socket systemd-udevd-kernel.socket After=systemd-udevd-control.socket systemd-udevd-kernel.socket -Before=sysinit.target +Before=sysinit.target local-fs-pre.target DefaultDependencies=no ConditionCapability=CAP_MKNOD -- 1.8.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix LSB Provides handling
Le vendredi 22 mars 2013 à 23:53 +0100, Lennart Poettering a écrit :
> On Thu, 21.03.13 17:04, Frederic Crozat (fcro...@suse.com) wrote:
>
> > Hi all,
> >
> > in https://bugzilla.novell.com/show_bug.cgi?id=809646 we noticed LSB
> > Provides can sometime be incorrectly handled (resulting in "Failed to
> > add LSB Provides name .service, ignoring: File exists" errors),
> > depending on initscript parsing order (if a provides is required by
> > another initscript and this initscript is parsed before the one with the
> > provides).
>
> Can you explain the problem in more detail? Not following here.
Yes, sorry, I didn't give our test example :
Let's say you have two initscripts, A and B:
A contains in its LSB header:
Required-Start: C
and B contains in its LSB header:
Provides: C
When systemd is parsing /etc/rc.d/, depending on the file order, you can
end up with:
- B is parsed first. An unit "C.service" will be "created" and will be
added as additional name to B.service, with unit_add_name. No bug.
- A is parsed first. An unit "C.service" is created for the
"Required-Start" dependency (it will have no file attached, since
nothing provides this dependency yet). Then B is parsed and when trying
to handle "Provides: C", unit_add_name is called but will fail, because
"C.service" already exists in manager->units. Therefore, a merge should
occur for that case.
>
> Also, whitespace/coding style issues.
Will fix.
> Hmm, and also, unit_merge_by_name() looks like the easier way here, as
> it does pretty much what you do here anyway
Indeed. I overlooked it..
New patch attached.
--
Frederic Crozat
SUSE
>From d43a9dc530261506b62c257021c8433d5bf25388 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Thu, 21 Mar 2013 15:40:45 +0100
Subject: [PATCH] core: ensure LSB Provides are handled correctly
Depending on initscript reading order, one initscript might
reference as a Required-Start/Should-Start dependency another
initscript provides, before initscript containing provides has been
parsed and the corresponding in-memory unit has been created. This
change ensure the unit created for the dependency is merged with the
one containing the provides.
---
src/core/service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/service.c b/src/core/service.c
index 080d583..5c7d919 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -765,7 +765,7 @@ static int service_load_sysv_path(Service *s, const char *path) {
continue;
if (unit_name_to_type(m) == UNIT_SERVICE)
-r = unit_add_name(u, m);
+r = unit_merge_by_name (u, m);
else
/* NB: SysV targets
* which are provided
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix LSB Provides handling
Le lundi 25 mars 2013 à 12:04 +, Colin Guthrie a écrit :
> 'Twas brillig, and Frederic Crozat at 25/03/13 10:14 did gyre and gimble:
> > Le vendredi 22 mars 2013 à 23:53 +0100, Lennart Poettering a écrit :
> >> On Thu, 21.03.13 17:04, Frederic Crozat (fcro...@suse.com) wrote:
> >>
> >>> Hi all,
> >>>
> >>> in https://bugzilla.novell.com/show_bug.cgi?id=809646 we noticed LSB
> >>> Provides can sometime be incorrectly handled (resulting in "Failed to
> >>> add LSB Provides name .service, ignoring: File exists" errors),
> >>> depending on initscript parsing order (if a provides is required by
> >>> another initscript and this initscript is parsed before the one with the
> >>> provides).
> >>
> >> Can you explain the problem in more detail? Not following here.
> >
> > Yes, sorry, I didn't give our test example :
> >
> > Let's say you have two initscripts, A and B:
> >
> > A contains in its LSB header:
> > Required-Start: C
> >
> > and B contains in its LSB header:
> > Provides: C
> >
> > When systemd is parsing /etc/rc.d/, depending on the file order, you can
> > end up with:
> > - B is parsed first. An unit "C.service" will be "created" and will be
> > added as additional name to B.service, with unit_add_name. No bug.
> > - A is parsed first. An unit "C.service" is created for the
> > "Required-Start" dependency (it will have no file attached, since
> > nothing provides this dependency yet). Then B is parsed and when trying
> > to handle "Provides: C", unit_add_name is called but will fail, because
> > "C.service" already exists in manager->units. Therefore, a merge should
> > occur for that case.
>
> Is this explanation perhaps worthy of going in the commit message? It
> was all very clear when I read this extended explanation but I didn't
> 100% grok it before :)
>
> >>
> >> Also, whitespace/coding style issues.
> >
> > Will fix.
>
> Sorry to be a pain, but technically the new, much leaner patch still
> contains a whitespace/coding style issue :p
>
> unit_merge_by_name should not have a space after it before it's parenthesis.
>
>
>
> Of course it's trivial for someone to do both those things above when
> merging, but. :)
New patch version, this time with the improved commit message and space
error fixed.
--
Frederic Crozat
SUSE
>From a99435109b83e7146a30ccf5387037b51c1fe907 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Thu, 21 Mar 2013 15:40:45 +0100
Subject: [PATCH] core: ensure LSB Provides are handled correctly
Let's say you have two initscripts, A and B:
A contains in its LSB header:
Required-Start: C
and B contains in its LSB header:
Provides: C
When systemd is parsing /etc/rc.d/, depending on the file order, you
can end up with either:
- B is parsed first. An unit "C.service" will be "created" and will be
added as additional name to B.service, with unit_add_name. No bug.
- A is parsed first. An unit "C.service" is created for the
"Required-Start" dependency (it will have no file attached, since
nothing provides this dependency yet). Then B is parsed and when trying
to handle "Provides: C", unit_add_name is called but will fail, because
"C.service" already exists in manager->units. Therefore, a merge should
occur for that case.
---
src/core/service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/service.c b/src/core/service.c
index 4451d38..fa8a1cb 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -762,7 +762,7 @@ static int service_load_sysv_path(Service *s, const char *path) {
continue;
if (unit_name_to_type(m) == UNIT_SERVICE)
-r = unit_add_name(u, m);
+r = unit_merge_by_name(u, m);
else
/* NB: SysV targets
* which are provided
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
Le vendredi 22 mars 2013 à 15:22 -0700, Auke Kok a écrit : > Readahead has all sorts of bad side effects depending on your > storage media. On rotating disks, it may be degrading startup > performance if enough requests are queued spanning linearly > over all blocks early at boot, and mount, blkid and friends > want to insert reads to the start of these block devices after. > > The end result is that on spinning disks with ext3/4 that udev > and mounts take a very long time, and nothing really happens until > readahead is completely finished. > > This has the net effect that the CPU is almost entirely idle > for the entire period that readahead is working. We could have > finished starting up quite a lot of services in this time if > we were smarter at how we do readahead. > > This patch sorts all requests into 2 second "chunks" and sub-sorts > each chunk by block. This adds a single cross-drive seek per "chunk" > but has the benefit that we will have a lot of the blocks we need > early on in the boot sequence loaded into memory faster. > > For a comparison of how before/after bootcharts look (ext4 on a > mobile 5400rpm 250GB drive) please look at: > > http://foo-projects.org/~sofar/blocked-tests/ > > There are bootcharts in the "before" and "after" folders where you > should be able to see that many low-level services finish 5-7 > seconds earlier with the patch applied (after). I've checked on my "test" netbook system and I can confirm your findings (with ext4 as fs), gain is around 3s, compared to the "old" readahead in systemd which was sometime slowing boot by 3s, compared to "no" readahead. I'd say commit it :) -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
Le jeudi 28 mars 2013 à 12:22 +, Belal, Awais a écrit : > Hi Guys, > > Just a newbie question as I am not much familiar with systemd yet. > While setting up a system I have systemd-195 running but some of the > services are not launched properly. I get the following: > > systemd[1]: Found ordering cycle on basic.target/start > systemd[1]: Walked on cycle path to sockets.target/start > systemd[1]: Walked on cycle path to dbus.socket/start > systemd[1]: Walked on cycle path to sysinit.target/start > systemd[1]: Walked on cycle path to run-postinsts.service/start > systemd[1]: Walked on cycle path to basic.target/start > systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start > systemd[1]: Deleting job ofono.service/start as dependency of job > dbus.socket/start > systemd[1]: Deleting job dbus.service/start as dependency of job > dbus.socket/start > systemd[1]: Deleting job connman.service/start as dependency of job > dbus.socket/start Based on experience, the problem usually lays in the .service listed in the cycle, in your case "run-postinsts.service". It has probably incorrect (or no) LSB dependencies. systemd could be improved to not drop dbus.socket in its ordering cycle break algorithm (there were some discussions some time ago on IRC) but it hasn't happened yet. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] cryptsetup: RequiresMountsFor if source is a file
Le vendredi 29 mars 2013 à 16:07 +0100, Lennart Poettering a écrit : > On Wed, 27.03.13 17:52, Thomas Weißschuh (tho...@t-8ch.de) wrote: > > > +if (startswith(u, "/dev/")) > > Looks like we want is_device_path for this? > > > +fprintf(f, > > +"BindsTo=%s\n" > > +"After=%s\n" > > +"Before=umount.target\n", > > +d, d); > > +else > > +fprintf(f, > > +"RequiresMountsFor=%s\n", > > +u); > > + > > fprintf(f, > > "\n[Service]\n" > > "Type=oneshot\n" > > Oh, and could you add a full http URL path to the bug in the commit msg? > otherwise it's not clear if that's fdobz or rhbz or any other. You can use https://bugzilla.novell.com/show_bug.cgi?id=730496 for instance (I have similar patch I had on my list to upstream again, since I sent a early version before RequiresMountsFor was written but forgot). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] RFC: should try-restart be a no-op or restart when "stop" is pending
Hi all, in one of opened bug reports against systemd ( https://bugzilla.novell.com/show_bug.cgi?id=812541 ), I found a questionable behavior regarding try-restart: when a "stop" call is pending (for instance reboot / shutdown / etc..), a "try-restart" call will act as noop or as restart, depending if "stop" call was processed or not when "try-restart" is called. Michal has already fixed the "shutdown doesn't terminate properly" bug by creating irreversible jobs (but unfortunately, I can't backport the patch, due to its size). However, on a more general level, I'm still wondering if "try-restart" behavior should be more deterministic (ie check if a "stop" call is pending) or should we keep the current behavior ? Is there people expecting issue if the behavior is changed ? Thanks. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging systemd shutdown problem on openSuSE 12.3
Le lundi 13 mai 2013 à 16:05 +0200, Zbigniew Jędrzejewski-Szmek a écrit : > On Mon, May 13, 2013 at 03:50:41PM +0200, Rainer Krienke wrote: > > Am 13.05.2013 15:45, schrieb Andrey Borzenkov: > > > On Mon, May 13, 2013 at 5:28 PM, Rainer Krienke > > > wrote: > > >> Hello, > > >> > > >> I i trouble on a openSuSE 12.3 system that is using autofs to mount > > >> users home directories and other shares. The system basically works fine. > > >> > > >> When I try to shut down or reboot the system sometimes this works, but > > >> most of the time the system terminates kdm and other processes (eg ssh > > >> access no longer works then) but it won't reboot or turn power off in > > >> case of shutdown. > > >> > > > > > > Using openSUSE 12.3 as well. > > > > > > How long did you wait? I have the same symptom on my home notebook, it > > > appears to hang on reboot but after some time (appr 1 - 2 minutes) it > > > reboots. > > > > > > > I waited at least 5 minutes one time even an hour. It seems most > > processes are beeing killed however something hangs. My guess was that > > perhaps autofs is not terminated correctly which might cause hanging NFS > > mounts, but this is only a guess because I cannot see what happens > > inside systemd. Thats why I look for ways to find out more. > There've been a number of fixes in this area since systemd-195. > Most notably http://cgit.freedesktop.org/systemd/systemd/commit/?id=aaf7eb8. > Would be great if you could try with a recent version. This patch is already in the maintenance update for 12.3 which was released some weeks ago. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging systemd shutdown problem on openSuSE 12.3
Le lundi 13 mai 2013 à 15:50 +0200, Rainer Krienke a écrit : > Am 13.05.2013 15:45, schrieb Andrey Borzenkov: > > On Mon, May 13, 2013 at 5:28 PM, Rainer Krienke > > wrote: > >> Hello, > >> > >> I i trouble on a openSuSE 12.3 system that is using autofs to mount > >> users home directories and other shares. The system basically works fine. > >> > >> When I try to shut down or reboot the system sometimes this works, but > >> most of the time the system terminates kdm and other processes (eg ssh > >> access no longer works then) but it won't reboot or turn power off in > >> case of shutdown. > >> > > > > Using openSUSE 12.3 as well. > > > > How long did you wait? I have the same symptom on my home notebook, it > > appears to hang on reboot but after some time (appr 1 - 2 minutes) it > > reboots. > > > > I waited at least 5 minutes one time even an hour. It seems most > processes are beeing killed however something hangs. My guess was that > perhaps autofs is not terminated correctly which might cause hanging NFS > mounts, but this is only a guess because I cannot see what happens > inside systemd. Thats why I look for ways to find out more. Did you try to enable a debug-shell, following http://freedesktop.org/wiki/Software/systemd/Debugging#Early_Debug_Shell ? -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd debugging option, documentation clarification
Le jeudi 16 mai 2013 à 15:10 +0200, Zbigniew Jędrzejewski-Szmek a écrit : > On Wed, May 15, 2013 at 10:28:54PM +0200, John Connor wrote: > > 1: It would be useful for debugging if systemctl had an option to show > > output on the screen (especially output from scripts run under > > systemd), rather than dumping it in a journal which you then have to > > search through. This should be a command-line option, because you > > would normally use it only for debugging, not for a normal boot. I > > don't know how practicable this would be, but it would be useful. > This wouldn't be particularly useful because of parallelism. Output > from various services would be completely mixed. This wasn't a > problem when things were started sequentially or with just a bit > in parallel. You can try systemd.log_target=console. John was suggesting this for systemctl is called from CLI, not at startup. In that case, parallelism is less of an issue (and I still getting many complains from people wondering :"did the service started ? I had to run systemctl status after starting to check if it was ok"). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Debugging systemd shutdown problem on openSuSE 12.3
Le jeudi 16 mai 2013 à 21:51 +0400, Andrey Borzenkov a écrit : > В Mon, 13 May 2013 11:16:34 -0700 > "Kok, Auke-jan H" пишет: > > > On Mon, May 13, 2013 at 6:28 AM, Rainer Krienke > > wrote: > > > I i trouble on a openSuSE 12.3 system that is using autofs to mount > > > users home directories and other shares. The system basically works fine. > > > > > > When I try to shut down or reboot the system sometimes this works, but > > > most of the time the system terminates kdm and other processes (eg ssh > > > access no longer works then) but it won't reboot or turn power off in > > > case of shutdown. > > > > > > I added > > > systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M > > > systemd.sysv_console=1 > > > to the kernel command line and created a debug.sh file > > > > > > #!/bin/sh > > > mount -o remount,rw / > > > dmesg > /shutdown-log.txt > > > mount -o remount,ro / > > > > > > in /usr/lib/systemd/system-shutdown. Once I found a /shutdown-log.txt > > > log file but it did not contain any real hint for me why rebooting seems > > > to hang. > > > > > > The problem is that I do not see what is hanging. How can I get better > > > debugging results from systemd to find out more? Is it possible to > > > redirect all steps systemd makes when rebooting to a virtual tty? What > > > else could I do to get more information of what happens during > > > reboot/shutdown? > > > > I guess what we need is a similar mechanism that is used to display > > messages when we're starting up and waiting for tasks, and have this > > appear at shutdown for tasks taking a long time to shut down. > > > > Should not 03b717a3c4f9348807fc56e7a7d711d72d4ec0cb also work for > shutdown case? I do not really see any condition limiting it to > booting, although I of course may misunderstand it. I think it does already.. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System units packaging and rpmlint
Le lundi 20 mai 2013 à 19:58 -0700, T.C. Hollingsworth a écrit :
> On Sat, May 18, 2013 at 2:44 PM, Michael Scherer wrote:
> > So I planned to warn if the unit are directly in /lib, but I know there
> > is some distribution that didn't choose this path yet. So when /usr is
> > not merged, what is the canonical location ( ie, for Opensuse, Mandriva,
> > since they are both rpm based ) ?
>
> Shouldn't rpmlint just make sure the spec uses "%{_unitdir}"? Nothing
> except the systemd package should hardcode this directory.
>
> (Or if the check has to be on the binary RPM side, just `rpm --eval
> '%_unitdir'` for the right location?)
Yes, I agree with this suggestion. This way, even if a new rpmlint
release was used on a "old" openSUSE (where /lib/systemd/system was
used), it would still work.
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl v202, loop endlessly
Le mercredi 08 mai 2013 à 03:53 +0200, Sébastien Luttringer a écrit : > On Tue, May 7, 2013 at 4:01 AM, Cristian Rodríguez > wrote: > > El 05/05/13 13:17, Sébastien Luttringer escribió: > > > >> Hello, > >> > >> "journcalctl --no-pager" or" journalctl | cat" produce enless content > >> by looping accross journal entries. The date in lines restart from the > >> beginning when the end is reached. > > > > > > We have reports about this behaviour in openSUSE as well, the problem is > > that I cannot reproduce it, even with your sample journal files.. > Bizarre. > > I'm able to reproduce the bug with the attached C code (from man 2 > sd_journal_next) and the provided tarball. > > I also built systemd from git tree (~ v203) and bug still occur. > > With some profiling + tracing, I guess it comes from sd_journal_next > in src/journal/journalctl.c which never return 0. > So the following break condition is never true and the loop is infinite. > > Some breakpoints in gdb shows a kind of switch between system.journal > and user-18136.journal files before printing each log lines before the > bug occur. > When we have looped, only one journal file is looked between entries. > I don't know if it's usefull. > > (gdb) info breakpoints > 16 breakpoint keep y 0x0042b4d7 in output_short at > src/shared/logs-show.c:292 > stop only if strcmp(message, "New session 6 of user seblu.") == 0 > breakpoint already hit 5 times > 17 breakpoint keep y 0x004136fa in > real_journal_next at src/journal/sd-journal.c:913 > stop only if found > breakpoint already hit 24295 times > silent > print f->path > c > > > mai 05 17:08:49 achille.seblu.net named[274]: dumpstats complete > $32223 = 0x6556b0 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal" > $32224 = 0x655ba0 "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system.journal" > mai 05 17:11:26 achille.seblu.net sshd[7372]: Accepted publickey for > seblu from 82.234.72.62 port 6239 ssh2 > $32225 = 0x6556b0 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal" > $32226 = 0x655ba0 "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system.journal" > mai 05 17:11:26 achille.seblu.net sshd[7372]: pam_unix(sshd:session): > session opened for user seblu by (uid=0) > $32227 = 0x6556b0 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal" > $32228 = 0x655ba0 "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system.journal" > mai 05 17:11:26 achille.seblu.net systemd-logind[251]: New session 6 > of user seblu. > ---Type to continue, or q to quit--- > > Breakpoint 16, output_short (f=0x773172a0 <_IO_2_1_stdout_>, > j=0x63df40, mode=OUTPUT_SHORT, n_columns=118, > flags=OUTPUT_COLOR) at src/shared/logs-show.c:292 > 292if (flags & OUTPUT_CATALOG) > (gdb) > Continuing. > $32229 = 0x6556b0 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/user-18136.journal" > mai 05 17:11:26 achille.seblu.net sshd[7374]: subsystem request for > sftp by user seblu > $32230 = 0x655950 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~" > -- Reboot -- > avril 22 03:00:42 zeus.seblu.net systemd-logind[248]: Removed session 7. > $32231 = 0x655950 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~" > avril 22 03:01:00 zeus.seblu.net fcron[10414]: Job /usr/sbin/run-cron > /etc/cron.hourly started for user systab...0415) > $32232 = 0x655950 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~" > avril 22 03:01:02 zeus.seblu.net fcron[10414]: Job /usr/sbin/run-cron > /etc/cron.hourly completed > $32233 = 0x655950 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~" > avril 22 03:07:09 zeus.seblu.net named[8102]: received control channel > command 'reload' > $32234 = 0x655950 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~" > avril 22 03:07:09 zeus.seblu.net named[8102]: loading configuration > from '/etc/named.conf' > $32235 = 0x655950 > "/tmp/toto/3d69b1d747744a53ac1c25b78eee2764/system@0004db40759a1f99-767afdbe88695384.journal~" > avril 22 03:07:09 zeus.seblu.net named[8102]: reading built-in trusted > keys from file '/etc/bind.keys' So, I've tested your journal, as well as journals from other reporters ( https://bugzilla.novell.com/show_bug.cgi?id=817778 ) and this infinite loop is a regression caused by commit a3e6f050de81a9830e52af09d5d38dad9a356e3b (journal: when iterating through a file we might lose messages when changing https://bugs.freedesktop.org/show_bug.cgi?id=63672 ) -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] makefile:put macros file to the correct place
Le vendredi 28 juin 2013 à 10:50 +0200, Václav Pavlín a écrit : > Zbigniew Jędrzejewski-Szmek píše v Čt 27. 06. 2013 v 17:00 +0200: > > On Thu, Jun 27, 2013 at 04:30:12PM +0200, Vaclav Pavlin wrote: > > > From: Fedora systemd team > > > > > > --- > > > Makefile.am | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/Makefile.am b/Makefile.am > > > index 3a196a6..c3988e8 100644 > > > --- a/Makefile.am > > > +++ b/Makefile.am > > > @@ -65,7 +65,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig > > > pkgconfiglibdir=$(libdir)/pkgconfig > > > polkitpolicydir=$(datadir)/polkit-1/actions > > > bashcompletiondir=@bashcompletiondir@ > > > -rpmmacrosdir=$(sysconfdir)/rpm > > > +rpmmacrosdir=$(prefix)/lib/rpm/macros.d > > Is this a recent change in rpmbuild? I don't see any macros > > in the new dir on FC19, and even don't have the dir on FC18... > > > > Zbyszek > RPM guys removed systemd from default build-requires in buildroot by > mistake. So we discussed how to do it so that systemd does not have to > be default require for all packages that ship unit files. The result of > this discussion was that we create a subpackage that will contain only > rpm macro files. This is funny, we just did the same on openSUSE Factory. Our package name is systemd-rpm-macros -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] FYI : [PATCH] insserv.conf[.d] support for systemd, as a generator
Hi all,
some time ago, I wrote support for insserv.conf inside systemd main
daemon and we have been using this code in openSUSE for several
releases.
The main goal was to move this patch (which was adding parsing
insserv.conf to systemd core) to a separate generator. This work is now
complete and available in the attached patch. I don't expect it to be
merged in systemd but since it might be useful for other distributions,
I'm sending it here for broadcast.
If you have comments on the code itself, go ahead (I used
fstab-generator.c as a basis ;)
--
Frederic Crozat
SUSE
>From a8cbe79c77836cc2466e3534157864abc98ef3ef Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Fri, 28 Jun 2013 17:54:41 +0200
Subject: [PATCH] insserv.conf generator
parse /etc/insserv.conf.dd content and /etc/insserv.conf and generate
systemd unit drop-in files to add dependencies
---
Makefile.am | 9 +
src/insserv-generator/Makefile| 28 +++
src/insserv-generator/insserv-generator.c | 309 ++
3 files changed, 346 insertions(+)
create mode 100644 src/insserv-generator/Makefile
create mode 100644 src/insserv-generator/insserv-generator.c
diff --git a/Makefile.am b/Makefile.am
index 016d7da..9f8319d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -315,6 +315,7 @@ rootlibexec_PROGRAMS = \
systemd-sleep
systemgenerator_PROGRAMS = \
+ systemd-insserv-generator \
systemd-getty-generator \
systemd-fstab-generator \
systemd-system-update-generator
@@ -1549,6 +1550,14 @@ systemd_delta_LDADD = \
libsystemd-shared.la
# --
+systemd_insserv_generator_SOURCES = \
+ src/insserv-generator/insserv-generator.c
+
+systemd_insserv_generator_LDADD = \
+ libsystemd-label.la \
+ libsystemd-shared.la
+
+# --
systemd_getty_generator_SOURCES = \
src/getty-generator/getty-generator.c
diff --git a/src/insserv-generator/Makefile b/src/insserv-generator/Makefile
new file mode 100644
index 000..9d07505
--- /dev/null
+++ b/src/insserv-generator/Makefile
@@ -0,0 +1,28 @@
+# This file is part of systemd.
+#
+# Copyright 2010 Lennart Poettering
+#
+# systemd is free software; you can redistribute it and/or modify it
+# under the terms of the GNU Lesser General Public License as published by
+# the Free Software Foundation; either version 2.1 of the License, or
+# (at your option) any later version.
+#
+# systemd is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public License
+# along with systemd; If not, see <http://www.gnu.org/licenses/>.
+
+# This file is a dirty trick to simplify compilation from within
+# emacs. This file is not intended to be distributed. So, don't touch
+# it, even better ignore it!
+
+all:
+ $(MAKE) -C ..
+
+clean:
+ $(MAKE) -C .. clean
+
+.PHONY: all clean
diff --git a/src/insserv-generator/insserv-generator.c b/src/insserv-generator/insserv-generator.c
new file mode 100644
index 000..067ee2f
--- /dev/null
+++ b/src/insserv-generator/insserv-generator.c
@@ -0,0 +1,309 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright 2012 Lennart Poettering
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see <http://www.gnu.org/licenses/>.
+ ***/
+
+#include
+#include
+#include
+#include
+
+#include "mkdir.h"
+#include "log.h"
+#include "fileio.h"
+#include "unit-name.h"
+#include "special.h"
+#include "path-util.h"
+#include "util.h"
+#include "strv.h"
+
+static const char *arg_dest = "/tmp";
+
+static char *sysv_translate_name(const char *name) {
+char *r;
+
+r = new(char, strlen(name) + sizeof(".service"));
+if (!r)
+return NULL;
+
+if (endswith(name, ".sh"))
+/* Drop .sh suffix */
+strcpy(stpcpy(r, name) - 3, ".service");
+else
+/* Normal init script na
[systemd-devel] PATCH: handle ncp just like ncpfs in fstab-generator
Hi all, the attached patch fixes an issue with ncp mount points not being recognized as network mount points (ncp is alias for ncpfs). -- Frederic Crozat SUSE >From 6bf298c8626cbfc3c3b0bd92fd2437260ce7610c Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Mon, 15 Jul 2013 10:27:31 +0200 Subject: [PATCH] util: recognize 'ncp' as an alias to 'ncpfs' ncp is also used for Netware mount point, recognize it as such. Fixes https://bugzilla.novell.com/show_bug.cgi?id=828905. --- src/shared/util.c | 1 + 1 file changed, 1 insertion(+) Index: systemd-195/src/shared/util.c === --- systemd-195.orig/src/shared/util.c +++ systemd-195/src/shared/util.c @@ -2114,6 +2114,7 @@ bool fstype_is_network(const char *fstyp "cifs\0" "smbfs\0" "ncpfs\0" +"ncp\0" "nfs\0" "nfs4\0" "gfs\0" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: enable chkconfig support in systemctl for openSUSE
Attached patch enables chkconfig support in systemctl for openSUSE.
--
Frederic Crozat
SUSE
>From ea4192a54fdbfebdec80f445d702625bc3412d7e Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Wed, 8 Jun 2011 15:30:55 +0200
Subject: [PATCH] systemctl: enable sysv chkconfig handling for openSUSE.
---
src/systemctl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/systemctl.c b/src/systemctl.c
index a82cce4..faca797 100644
--- a/src/systemctl.c
+++ b/src/systemctl.c
@@ -4089,7 +4089,7 @@ static int install_info_apply(const char *verb, LookupPaths *paths, InstallInfo
}
if (!f) {
-#if (defined(TARGET_FEDORA) || defined(TARGET_MANDRIVA)) || defined(TARGET_MEEGO) && defined (HAVE_SYSV_COMPAT)
+#if (defined(TARGET_FEDORA) || defined(TARGET_MANDRIVA) || defined(TARGET_SUSE)) || defined(TARGET_MEEGO) && defined (HAVE_SYSV_COMPAT)
if (endswith(i->name, ".service")) {
char *sysv;
--
1.7.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] enable chkconfig support in systemctl for ALTLinux
Le mardi 14 juin 2011 à 14:34 +0400, Alexey Shabalin a écrit : > enable chkconfig support in systemctl for ALTLinux Hmm, this patch looks wrong, you should insert Alt_linux just after TARGET_SUSE, unless you want, like meego, a condition on HAVE_SYSV_COMPAT. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Hi all, as we are working in integrating systemd in openSUSE for next release, we will have to handle .unit files in various packages, enabling / disabling services on package install / upgrades, etc.. Fedora already hit the bullet with https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd and https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd but maybe we could improve the scriplet part by creating a cross-distribution set of macros to handle systemctl calls and get it merged in rpm 4.x (or have them shipped in systemd). Opinions welcome.. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: add support for --root for systemctl enable/disable/is-enabled
Add --root= for enable/disable/is-enabled systemctl commands. To
be used for easily enable / disable systemd services for a chroot,
without running systemctl inside chroot.
--
Frederic Crozat
SUSE
>From 318ca654ff4f6f0a45108fff33a62a93799aec2f Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Fri, 24 Jun 2011 15:02:02 +0200
Subject: [PATCH] Add --root= for enable/disable/is-enabled systemctl commands.
To be used for easily enable / disable systemd services for a chroot,
without running systemctl inside chroot.
---
man/systemctl.xml | 11 +
src/systemctl.c | 63 ++--
2 files changed, 62 insertions(+), 12 deletions(-)
diff --git a/man/systemctl.xml b/man/systemctl.xml
index 2fd2b7b..a3e0a30 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -382,6 +382,17 @@
+--root=
+
+When used with
+enable/
+disable/
+is-enabled,
+use alternative root path for systemd
+install.
+
+
+
-H
--host
diff --git a/src/systemctl.c b/src/systemctl.c
index ab41566..f6dca5b 100644
--- a/src/systemctl.c
+++ b/src/systemctl.c
@@ -80,6 +80,7 @@ static bool arg_failed = false;
static char **arg_wall = NULL;
static const char *arg_kill_who = NULL;
static const char *arg_kill_mode = NULL;
+static const char *arg_root = NULL;
static int arg_signal = SIGTERM;
static usec_t arg_when = 0;
static enum action {
@@ -3848,8 +3849,14 @@ static int remove_marked_symlinks(const char *config_path) {
return r;
}
-static int create_symlink(const char *verb, const char *old_path, const char *new_path) {
+static int create_symlink(const char *verb, const char *orig_old_path, const char *new_path) {
int r;
+ const char *old_path;
+
+ if (arg_root)
+ old_path = orig_old_path+strlen(arg_root);
+ else
+ old_path = orig_old_path;
assert(old_path);
assert(new_path);
@@ -4062,12 +4069,23 @@ static int install_info_apply(const char *verb, LookupPaths *paths, InstallInfo
STRV_FOREACH(p, paths->unit_path) {
int fd;
+ char *path, *should_free;
+
+ if (arg_root)
+ should_free = path = strappend(arg_root, *p);
+ else {
+ should_free = NULL;
+ path = *p;
+ }
-if (!(filename = path_make_absolute(i->name, *p))) {
+if (!(filename = path_make_absolute(i->name, path))) {
log_error("Out of memory");
return -ENOMEM;
}
+ if (should_free)
+ free(should_free);
+
/* Ensure that we don't follow symlinks */
if ((fd = open(filename, O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NOCTTY)) >= 0)
if ((f = fdopen(fd, "re")))
@@ -4102,7 +4120,14 @@ static int install_info_apply(const char *verb, LookupPaths *paths, InstallInfo
}
sysv[strlen(sysv) - sizeof(".service") + 1] = 0;
-exists = access(sysv, F_OK) >= 0;
+if (arg_root) {
+char *tmp_path;
+
+tmp_path = strappend (arg_root, sysv);
+exists = access (tmp_path, F_OK) >= 0;
+free (tmp_path);
+ } else
+exists = access(sysv, F_OK) >= 0;
if (exists) {
pid_t pid;
@@ -4112,6 +4137,7 @@ static int install_info_apply(const char *verb, LookupPaths *paths, InstallInfo
"/sbin/chkconfig",
NULL,
NULL,
+NULL,
NULL
};
@@ -4121,8 +4147,10 @@ static int install_info_apply(const char *verb, LookupPaths *paths, InstallInfo
argv[2] =
streq(verb, "enable") ? "on" :
streq(verb, "disable") ? "off" : "--level=5";
+if (arg_root)
+argv[3] = strappend("--root=", arg_root);
-log_info("Executing %s %s %s", argv[0], argv[1], strempty(argv[2]));
+ log_info("Executing %s %s %s %s", argv[0], argv[1], strempty(argv[2]), strempty(argv[3]));
if ((pid = fork()) < 0) {
log_error("Failed t
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le jeudi 16 juin 2011 à 18:49 +0200, Frederic Crozat a écrit :
> Hi all,
>
> as we are working in integrating systemd in openSUSE for next release,
> we will have to handle .unit files in various packages, enabling /
> disabling services on package install / upgrades, etc..
>
> Fedora already hit the bullet with
> https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd and
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
>
> but maybe we could improve the scriplet part by creating a
> cross-distribution set of macros to handle systemctl calls and get it
> merged in rpm 4.x (or have them shipped in systemd).
>
> Opinions welcome..
Ok, here is a proposal that has been commented (and amended) on
opensuse-packaging mailing list :
(the various macros could be modified by distro if they also want to
support sysvinit service with the same macro, but it is outside the
scope of this initial proposal)
%service_add()
if [ "$1" -eq 1 ] ; then
# Initial installation
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi
%service_add_enabled()
if [ "$1" -eq 1 ] ; then
# Initial installation
/bin/systemctl enable %{1}.service >/dev/null 2>&1 || :
fi
%service_del_preun()
if [ "$1" -eq 0 ] ; then
# Package removal, not upgrade
/bin/systemctl --no-reload disable %{1}.service > /dev/null 2>&1 || :
/bin/systemctl stop %{1}.service > /dev/null 2>&1 || :
fi
%service_del_postun()
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ "$1" -ge 1 ] ; then
# Package upgrade, not uninstall
/bin/systemctl try-restart %{1}.service >/dev/null 2>&1 || :
fi
(this macro could refer to different package, if people don't agree on
systemd-units as packagename)
%define systemd_requires()
# This is for /bin/systemctl
Requires(post): systemd-units \
Requires(preun): systemd-units \
Requires(postun): systemd-units \
%service_migrate_to_systemd(l)
{-l:LEVEL="-l $1 ; shift }
if /sbin/chkconfig $LEVEL %{1} ; then
/bin/systemctl --no-reload enable %{1}.service >/dev/null 2>&1 || :
fi
usage :
%post
%service_add demo.service
# Alternative: %service_add_enabled demo.service
%preun
%service_del_preun demo.service
%postun
%service_del_postun demo.service
when migrating a package from sysvinit to systemd :
%triggerun -- package_name < version_where_switch_occured
%service_migration_to_systemd [ -l run_level ] service_name
-l is optional
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le lundi 27 juin 2011 à 14:24 +0200, Lennart Poettering a écrit :
> On Fri, 24.06.11 15:08, Frederic Crozat (fcro...@suse.com) wrote:
>
> Heya,
>
> Sounds good! A few comments:
>
> > %service_add()
> > if [ "$1" -eq 1 ] ; then
> > # Initial installation
> > /bin/systemctl daemon-reload >/dev/null 2>&1 || :
> > fi
> >
> > %service_add_enabled()
> > if [ "$1" -eq 1 ] ; then
> > # Initial installation
> > /bin/systemctl enable %{1}.service >/dev/null 2>&1 || :
> > fi
>
> I'd strongly advise against this. Units might install more than one
> service, and other units instead of services (example: sshd might just
> enable a socket by default, but not a service). Hence we should not
> appaned .service but leave it to the package to specifiy the full name
> and we also need to make sure packagers can specify multiple unit files
> at once.
This question was also spotted on opensuse-packaging and we thought it
should be discussed here :)
So, usage would become :
%post
%service_add ssh.socket
%post
%service_add_enabled foobar.service
?
> Bill, what's your take on this? For some reason we solve very little
> with macros like this on Fedora. Not sure why. Should I push for
> including macros like this in rpm, or in the systemd packages?
If we could get some skeleton directly in "upstream" rpm, that would be
awesome ;)
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le lundi 27 juin 2011 à 14:38 +0200, Lennart Poettering a écrit :
> On Mon, 27.06.11 14:34, Frederic Crozat (fcro...@suse.com) wrote:
>
> > > > %service_add_enabled()
> > > > if [ "$1" -eq 1 ] ; then
> > > > # Initial installation
> > > > /bin/systemctl enable %{1}.service >/dev/null 2>&1 || :
> > > > fi
> > >
> > > I'd strongly advise against this. Units might install more than one
> > > service, and other units instead of services (example: sshd might just
> > > enable a socket by default, but not a service). Hence we should not
> > > appaned .service but leave it to the package to specifiy the full name
> > > and we also need to make sure packagers can specify multiple unit files
> > > at once.
> >
> > This question was also spotted on opensuse-packaging and we thought it
> > should be discussed here :)
> >
> > So, usage would become :
> >
> > %post
> > %service_add ssh.socket
> >
> > %post
> > %service_add_enabled foobar.service
> >
> > ?
>
> Well, and maybe even this:
>
> %service_add waldi.socket wuffwuff.service piepapo.service
>
> i.e. allow multiple unit names to be specified at once.
It shouldn't be a problem, I just need to refresh my rpm macro
kung-fu ;)
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: support for parsing /etc/insserv.conf for LSB system facilities
Hi,
as discussed on irc, I've implemented parsing /etc/insserv.conf, which,
on SUSE (and maybe on Debian), provides LSB System Facilities (instead
of using Provides: in LSB initscripts, for things like $network,
$portmap, etc..).
I didn't implement the part of insserv.conf, since
X-Interactive is currently broken in systemd and we'd like to keep
sysvinit for openSUSE 12.1 (so, we could just remove X-Interactive flags
from legacy initscripts on openSUSE, but when booting with old sysvinit,
list would be used to tell boot scripts which one are
interactive).
--
Frederic Crozat
SUSE
>From 2e7bf2ef302428ea69babb498f937dca80daf361 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Wed, 29 Jun 2011 13:59:34 +0200
Subject: [PATCH] parse insserv.conf and plugs its system facilities into systemd.
---
src/service.c | 71 +
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/src/service.c b/src/service.c
index d59c4cb..1420619 100644
--- a/src/service.c
+++ b/src/service.c
@@ -2950,6 +2950,73 @@ static void service_notify_message(Unit *u, pid_t pid, char **tags) {
}
#ifdef HAVE_SYSV_COMPAT
+
+#ifdef TARGET_SUSE
+static void sysv_facility_in_insserv_conf(Manager *mgr) {
+FILE *f=NULL;
+int r;
+
+if (!(f = fopen("/etc/insserv.conf", "re"))) {
+r = errno == ENOENT ? 0 : -errno;
+goto finish;
+}
+
+while (!feof(f)) {
+char l[LINE_MAX], *t;
+char **parsed = NULL;
+
+if (!fgets(l, sizeof(l), f)) {
+if (feof(f))
+break;
+
+r = -errno;
+log_error("Failed to read configuration file '/etc/insserv.conf': %s", strerror(-r));
+goto finish;
+}
+
+t = strstrip(l);
+if ((*t != '$') && (*t != '<'))
+continue;
+
+parsed = strv_split (t,WHITESPACE);
+/* we ignore , not used, equivalent to X-Interactive */
+if (parsed && !startswith_no_case (parsed[0], "")) {
+char *facility;
+Unit *u;
+if (sysv_translate_facility(parsed[0], NULL, &facility) < 0)
+continue;
+if ((u = manager_get_unit (mgr, facility)) && (u->meta.type == UNIT_TARGET)) {
+UnitDependency e;
+char *dep = NULL, *name;
+int j;
+
+for (j=1;parsed[j]; j++) {
+if (parsed[j][0]=='+') {
+e = UNIT_WANTS;
+name = parsed[j]+1;
+}
+else {
+e = UNIT_REQUIRES;
+name = parsed[j];
+}
+if (sysv_translate_facility(name, NULL, &dep) < 0)
+continue;
+
+r = unit_add_two_dependencies_by_name(u, UNIT_BEFORE, e, dep, NULL, true);
+free(dep);
+}
+}
+free(facility);
+}
+strv_free (parsed);
+}
+finish:
+if (f)
+fclose(f);
+
+}
+#endif
+
static int service_enumerate(Manager *m) {
char **p;
unsigned i;
@@ -3095,6 +3162,10 @@ static int service_enumerate(Manager *m) {
r = 0;
+#ifdef TARGET_SUSE
+ sysv_facility_in_insserv_conf (m);
+#endif
+
finish:
free(path);
free(fpath);
--
1.7.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: support for parsing /etc/insserv.conf for LSB system facilities
Le vendredi 01 juillet 2011 à 23:30 +0200, Lennart Poettering a écrit :
> On Fri, 01.07.11 11:20, Frederic Crozat (fcro...@suse.com) wrote:
>
> > Hi,
>
> Heya,
> >
> > as discussed on irc, I've implemented parsing /etc/insserv.conf, which,
> > on SUSE (and maybe on Debian), provides LSB System Facilities (instead
> > of using Provides: in LSB initscripts, for things like $network,
> > $portmap, etc..).
>
> Michael, Tollef, can you comment on this too, plz? Would be good to have
> some input from you if this is useful for Debian, too.
Please note that I didn't put parsing of /etc/insserv.d in the current
patch, as it is not used on openSUSE (but I can add it, if requested ;)
> > I didn't implement the part of insserv.conf, since
> > X-Interactive is currently broken in systemd and we'd like to keep
> > sysvinit for openSUSE 12.1 (so, we could just remove X-Interactive flags
> > from legacy initscripts on openSUSE, but when booting with old sysvinit,
> > list would be used to tell boot scripts which one are
> > interactive).
>
> I think the idea of X-Interactive is unfixably broken, i.e. if you end
> up starting a service after boot-up at which time tty1 is blocked by a
> getty, then this will necessarily deadlock. I am not sure how this could
> ever be fixed.
This is why I excluded parsing the list ;)
> > +t = strstrip(l);
> > +if ((*t != '$') && (*t != '<'))
>
> Please don't place redundant brackets here.
Fixed.
>
> > +continue;
> > +
> > +parsed = strv_split (t,WHITESPACE);
>
> Please no spaces between a function and the opening bracket. This is
> good: sin(x), this is bad: sin (x).
Oops, missed this.. Fixed.
> > +/* we ignore , not used, equivalent to
> > X-Interactive */
> > +if (parsed && !startswith_no_case (parsed[0],
> > "")) {
> > +char *facility;
> > +Unit *u;
> > +if (sysv_translate_facility(parsed[0], NULL,
> > &facility) < 0)
> > +continue;
> > +if ((u = manager_get_unit (mgr, facility)) &&
> > (u->meta.type == UNIT_TARGET)) {
> > +UnitDependency e;
> > +char *dep = NULL, *name;
> > + int j;
> > +
> > +for (j=1;parsed[j]; j++) {
>
> Please use STRV_FOREACH for iterating through string arrays.
Forgot about it.. Fixed.
Here is new version attached
--
Frederic Crozat
SUSE
>From c4f60bddda53704ed4601b8af28a1e628b405674 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Wed, 29 Jun 2011 13:59:34 +0200
Subject: [PATCH] parse insserv.conf and plugs its system facilities into systemd.
---
src/service.c | 70 +
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/src/service.c b/src/service.c
index d59c4cb..96baa82 100644
--- a/src/service.c
+++ b/src/service.c
@@ -2950,6 +2950,72 @@ static void service_notify_message(Unit *u, pid_t pid, char **tags) {
}
#ifdef HAVE_SYSV_COMPAT
+
+#ifdef TARGET_SUSE
+static void sysv_facility_in_insserv_conf(Manager *mgr) {
+FILE *f=NULL;
+int r;
+
+if (!(f = fopen("/etc/insserv.conf", "re"))) {
+r = errno == ENOENT ? 0 : -errno;
+goto finish;
+}
+
+while (!feof(f)) {
+char l[LINE_MAX], *t;
+char **parsed = NULL;
+
+if (!fgets(l, sizeof(l), f)) {
+if (feof(f))
+break;
+
+r = -errno;
+log_error("Failed to read configuration file '/etc/insserv.conf': %s", strerror(-r));
+goto finish;
+}
+
+t = strstrip(l);
+if (*t != '$' && *t != '<')
+continue;
+
+parsed = strv_split(t,WHITESPACE);
+/* we ignore , not used, equivalent to X-Interactive */
+if (parsed && !startswith_no_case (parsed[0], "")) {
+char *facility;
+Unit *u;
+if (sysv_translate_facility(parsed[0], NULL, &facility) < 0)
+continue;
+if ((u = manager_get_unit(mgr, facility)) && (u->meta.type == UNIT_TAR
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le samedi 02 juillet 2011 à 01:33 +0200, Lennart Poettering a écrit :
> On Tue, 28.06.11 13:11, Kay Sievers (kay.siev...@vrfy.org) wrote:
>
> > Right, it doesn't cover: [ "$1" -eq 1 ], which it should. Packaging
> > enable-links in /etc/systemd should just be %ghosted not installed.
> > Services which can not be enabled/disabled like udev, D-Bus,
> > systemd-internal services might install the links directly to
> > /lib/systemd/system/, but that should never be done for /etc.
> >
> > Anyway, when we think about general service integration into package
> > management, I like to see something like some 'product package
> > defaults' included from the first step on, or at least have thought
> > about them and prepared the hooks in the same way we would use them,
> > when such defaults would exist.
> >
> > It does not make much sense to encode the enabled-at-install,
> > enabled-on-update, started-at-install, restarted-on-update flags into
> > the spec file, it should all be derived from some database that comes
> > along with the system to be installed. Encoding such distro/product
> > policy in the spec file is a bad start. General distros have several
> > products based on the same package, and products might differ
> > completely in the policy they apply to packages. The server product
> > might have very different services enabled/disabled by default than
> > the Live-CD, but they have exactly the same packages.
> >
> > I think %service_add() vs. %service_add_enabled() and so on, is
> > nothing that should be done in the spec file, or which should differ
> > from one service to the other. These calls should all be one and the
> > same generic macro, and the policy should be executed behind the
> > macro, depending on the product, not depending on the spec file.
>
> I agree with this. I'd really like to see someone working on getting
> "service enabling profiles" or something like that solved at the same
> time as we consider these macros. These two changes to service handling
> should probably go hand in hand.
>
> I wonder if we should actually help implementation of this with
> systemd. i.e. add a switch "--if-listed" or so to "systemctl enable"
> which enables a unit only if it is listed in some profile file in
> /lib/systemd/enable or so. Might be something to think about. By default
> we would not ship such a file, and hence would leave all services
> disabled when this switch is applied, but distributions could just drop
> a file in there and ship different versions on livecds, installs, on
> desktops, servers and the various spins.
Ok, so based on everybody feedback, here is an amended proposal, which
includes the following changes :
-%service_* macros are expecting full unit name (sshd.service,
foobar.socket)
-%service_add_enabled is no longer part of the proposal, policy for
enable / disable service is out of the scope of this proposal.
-%service_* macros accepts several units files as parameters
(the various macros could be modified by distro if they also want to
support sysvinit service with the same macro, but it is outside the
scope of this initial proposal)
%service_add()
if [ "$1" -eq 1 ] ; then
# Initial installation
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
fi
%service_del_preun()
if [ "$1" -eq 0 ] ; then
# Package removal, not upgrade
/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || :
/bin/systemctl stop %{?*} > /dev/null 2>&1 || :
fi
%service_del_postun()
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
if [ "$1" -ge 1 ] ; then
# Package upgrade, not uninstall
/bin/systemctl try-restart %{1} >/dev/null 2>&1 || :
fi
(this macro could refer to different package, if people don't agree on
systemd-units as packagename)
%define systemd_requires()
# This is for /bin/systemctl
Requires(post): systemd-units \
Requires(preun): systemd-units \
Requires(postun): systemd-units \
%service_migrate_to_systemd(l)
{-l:LEVEL="-l $1 ; shift }
for service in %{?*} ; do \
if /sbin/chkconfig $LEVEL $service ; then
/bin/systemctl --no-reload enable `echo $service | sed -e
's/\.service//g'` >/dev/null 2>&1 || :
fi
usage :
%post
%service_add demo.service foobar.socket
%preun
%service_del_preun demo.service
%postun
%service_del_postun demo.service
when migrating a package from sysvinit to systemd :
%triggerun -- package_name < version_where_switch_occured
%service_migration_to_systemd [ -l run_level ] service_name.service
foobar.socket
-l is optional
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le lundi 04 juillet 2011 à 14:53 +0200, Kay Sievers a écrit : > On Mon, Jul 4, 2011 at 14:10, Frederic Crozat wrote: > > > (this macro could refer to different package, if people don't agree on > > systemd-units as packagename) > > I don't agree on the split-off in general. :) > > I don't really see how a subpackage gives us any advantage, and we > should not recommend its use, I think. In that case, I suggest we keep the macro name in the proposal (because we want other packages to requires "some" systemd package in their specfile, but the content of the macro can change in distributions. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le lundi 04 juillet 2011 à 19:28 +0200, Kay Sievers a écrit : > On Mon, Jul 4, 2011 at 14:57, Frederic Crozat wrote: > > Le lundi 04 juillet 2011 à 14:53 +0200, Kay Sievers a écrit : > >> On Mon, Jul 4, 2011 at 14:10, Frederic Crozat wrote: > >> > >> > (this macro could refer to different package, if people don't agree on > >> > systemd-units as packagename) > >> > >> I don't agree on the split-off in general. :) > >> > >> I don't really see how a subpackage gives us any advantage, and we > >> should not recommend its use, I think. > > > > In that case, I suggest we keep the macro name in the proposal (because > > we want other packages to requires "some" systemd package in their > > specfile, but the content of the macro can change in distributions. > > What's the point of having "some" sub-package at all? I guess, stuff > should just depend on systemd.rpm instead of making it all needlessly > complicated. Or should I package udev-rules.rpm next? :) Please re-read what I wrote : the point is to have a common macro which would allow packagers to ensure they don't forget anything. The name of the package pulled by this macro is not relevant. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le mardi 05 juillet 2011 à 18:25 +0200, Kay Sievers a écrit : > On Tue, Jul 5, 2011 at 10:09, Frederic Crozat wrote: > > Le lundi 04 juillet 2011 à 19:28 +0200, Kay Sievers a écrit : > >> On Mon, Jul 4, 2011 at 14:57, Frederic Crozat wrote: > >> > Le lundi 04 juillet 2011 à 14:53 +0200, Kay Sievers a écrit : > >> >> On Mon, Jul 4, 2011 at 14:10, Frederic Crozat wrote: > >> >> > >> >> > (this macro could refer to different package, if people don't agree on > >> >> > systemd-units as packagename) > >> >> > >> >> I don't agree on the split-off in general. :) > >> >> > >> >> I don't really see how a subpackage gives us any advantage, and we > >> >> should not recommend its use, I think. > >> > > >> > In that case, I suggest we keep the macro name in the proposal (because > >> > we want other packages to requires "some" systemd package in their > >> > specfile, but the content of the macro can change in distributions. > >> > >> What's the point of having "some" sub-package at all? I guess, stuff > >> should just depend on systemd.rpm instead of making it all needlessly > >> complicated. Or should I package udev-rules.rpm next? :) > > > > Please re-read what I wrote : > > Nice hint. :) > > > the point is to have a common macro which would allow packagers to > > ensure they don't forget anything. The name of the package pulled by > > this macro is not relevant. > > Yeah, and again, it's just 'Requires: systemd', and I think no need to > play distro-package indirection/abstraction games here. No, it is : Requires(post) Requires(preun) Requires(postun) and from experience, people tends to forgot one or another. Using a macro helps for readability and consistency. But if you really don't want this macro, I guess it will be SUSE only.. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Preset Files
Le mardi 05 juillet 2011 à 21:21 +0200, Lennart Poettering a écrit : > Heya, > > many of you probably saw Frederic's rpm macros suggested here. This got > Kay and me thinking about implementing something like "presets" in > systemd, and before we go and implement that we'd like to hear your > opinions on it. This would go hand in hand with Frederic's macros, and > both would be included in the upstream systemd package. < snip proposal > I like it (except the enable-by-default policy, but this is something we can fix as a distributor). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le mardi 05 juillet 2011 à 15:06 -0400, Bill Nottingham a écrit :
> Frederic Crozat (fcro...@suse.com) said:
> > %service_migrate_to_systemd(l)
> > {-l:LEVEL="-l $1 ; shift }
> > for service in %{?*} ; do \
> > if /sbin/chkconfig $LEVEL $service ; then
> > /bin/systemctl --no-reload enable `echo $service | sed -e
> > 's/\.service//g'` >/dev/null 2>&1 || :
> > fi
>
> If you've got a version of chkconfig that forwards to systemd,
> the level argument isn't optional here ; it's required so that it
> actually checks the sysv service.
we have such version but it is a perl wrapper over insserv. And after
checking, the syntax isn't exactly the same :(
Moreover, I used an old version of
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd as a
basis and it seems it has evolved a little, with a python script to
handle the work :
http://pkgs.fedoraproject.org/gitweb/?p=systemd.git;a=blob;f=systemd-sysv-convert;h=1c3f1a98ebe7b829b2311346a660dcd07454275c;hb=HEAD
Do you think we should merge this script in systemd upstream ? Or maybe
use the name in the macro ?
--
Frederic Crozat
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le mardi 05 juillet 2011 à 23:39 +0200, Lennart Poettering a écrit : > On Tue, 05.07.11 18:37, Frederic Crozat (fcro...@suse.com) wrote: > > > > > the point is to have a common macro which would allow packagers to > > > > ensure they don't forget anything. The name of the package pulled by > > > > this macro is not relevant. > > > > > > Yeah, and again, it's just 'Requires: systemd', and I think no need to > > > play distro-package indirection/abstraction games here. > > > > No, it is : > > Requires(post) > > Requires(preun) > > Requires(postun) > > > > and from experience, people tends to forgot one or another. Using a > > macro helps for readability and consistency. > > > > But if you really don't want this macro, I guess it will be SUSE only.. > > Oh, we all want standardized systemd macros for RPM, there's not doubt > on that. The question is just how exactly they should look like. And > that means two things: first we have to agree how the macro should be > called (and that implies figuring out policy of enabling and stuff, > since we probably shouldn't suggest in the name of a macro that it does > specific policy decisions if later on we decide to do policy completely > differently -- for example with the preset stuff I just posted the RFC > about), and secondly we have to agree how the default macro definitions > should look like. Agreed :) > Kay just wanted to point out that the Requires(post) might not be the > right choice to place in the default macross. > > The simple thing is that if we add this to systemd (or RPM, but I prefer > systemd) then this will be something gazillions of packages will rely > on, or will even copy, so we really should get it right. And that > includes that we need to question every single line of it, which in this > case raised some eyebrows on the usefulness of Requires(post) and > friends if Requires is already in the header anyway. > > The simple fact is that we need a dependency on systemd anyway in the > RPMS to get the ownership for the units directory right. Now, if we have > "Requires: systemd" in the header, why do we also need "Requires(post): > systemd"? What does this buy us? Requires(post/preun/postun) on the package containing systemctl is needed as soon as systemctl is called in %post/preun/postun. A simple Requires is not enough, because you might end up installing systemd and the package requiring it in the same rpm transaction, but in the incorrect order. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: creating a set of systemd RPM macros across distributions ?
Le mercredi 06 juillet 2011 à 13:51 +0200, Kay Sievers a écrit : > On Wed, Jul 6, 2011 at 11:15, Frederic Crozat wrote: > > Le mardi 05 juillet 2011 à 23:39 +0200, Lennart Poettering a écrit : > > >> The simple fact is that we need a dependency on systemd anyway in the > >> RPMS to get the ownership for the units directory right. Now, if we have > >> "Requires: systemd" in the header, why do we also need "Requires(post): > >> systemd"? What does this buy us? > > > > Requires(post/preun/postun) on the package containing systemctl is > > needed as soon as systemctl is called in %post/preun/postun. A simple > > Requires is not enough, because you might end up installing systemd and > > the package requiring it in the same rpm transaction, but in the > > incorrect order. > > That's just not true. The 'Requires: systemd', which we always need > anyway, will ensure the proper install ordering just fine during a > transaction. Otherwise tons of similar things in that context would > just not work like they work today. > > Scriptlet dependencies are needed if cyclic loops need to be broken, > means systemd.rpm requires itself some other package which itself has > 'Requires: systemd'. Then the explicit scriptlet dependency binds > stronger than the normal Requires:, and ensures loop breaking at that > point in the circle. > > Or scriptlet dependencies are useful if the required package should be > able to get un-installed later, which isn't the case for systemd. This could be uninstalled, at least for now on non-F16 distribution ;) > I'm not saying we it might not be useful for corner cases, and if we > decide so, we might end up doing something like this, but it's surely > not *needed* at all for the common case, and if we need the reverse > for some special packages it might even get in our way. Having to handle this kind of corner cases (and I'm not as convinced as you it is a rare corner case) is a bad idea, specially since we can make sure the problem won't appear at all by using Requires(post...). I'm still strongly in favor of Require(post..), based on my experience in various RPM distributions.. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: add units for boot.local/halt.local on openSUSE
Hi, attached patch adds a modified version of fedora rc-local/halt-local services for openSUSE. -- Frederic Crozat SUSE >From 06238c421548f9af6ebebd54eba99bba2a2049d4 Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Thu, 7 Jul 2011 14:56:30 +0200 Subject: [PATCH] units: add units for boot.local/halt.local on SUSE distributions. --- Makefile.am | 19 +++ units/suse/halt-local.service | 20 units/suse/rc-local.service | 18 ++ 3 files changed, 57 insertions(+), 0 deletions(-) create mode 100644 units/suse/halt-local.service create mode 100644 units/suse/rc-local.service diff --git a/Makefile.am b/Makefile.am index 78e5caf..d3265b0 100644 --- a/Makefile.am +++ b/Makefile.am @@ -436,6 +436,12 @@ dist_systemunit_DATA += \ units/frugalware/display-manager.service endif +if TARGET_SUSE +dist_systemunit_DATA += \ + units/suse/rc-local.service \ + units/suse/halt-local.service +endif + if HAVE_PLYMOUTH dist_systemunit_DATA += \ units/plymouth-start.service \ @@ -1689,6 +1695,19 @@ if TARGET_DEBIAN_OR_UBUNTU $(LN_S) multi-user.target runlevel5.target ) endif +if TARGET_SUSE + $(MKDIR_P) -m 0755 $(DESTDIR)$(systemunitdir)/final.target.wants + ( cd $(DESTDIR)$(systemunitdir)/multi-user.target.wants && \ + rm -f rc-local.service && \ + $(LN_S) $(systemunitdir)/rc-local.service rc-local.service ) + ( cd $(DESTDIR)$(systemunitdir) && \ + rm -f local.service && \ + $(LN_S) rc-local.service local.service ) + ( cd $(DESTDIR)$(systemunitdir)/final.target.wants && \ + rm -f halt-local.service && \ + $(LN_S) $(systemunitdir)/halt-local.service halt-local.service ) +endif + if HAVE_SYSV_COMPAT ( cd $(DESTDIR)$(systemunitdir)/local-fs.target.wants && \ rm -f var-lock.mount && \ diff --git a/units/suse/halt-local.service b/units/suse/halt-local.service new file mode 100644 index 000..68cacc6 --- /dev/null +++ b/units/suse/halt-local.service @@ -0,0 +1,20 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. + +[Unit] +Description=/etc/init.d/halt.local Compatibility +ConditionPathExists=/etc/init.d/halt.local +DefaultDependencies=no +After=shutdown.target +Before=final.target + +[Service] +Type=oneshot +ExecStart=/etc/init.d/halt.local +TimeoutSec=0 +StandardOutput=tty +RemainAfterExit=yes diff --git a/units/suse/rc-local.service b/units/suse/rc-local.service new file mode 100644 index 000..38884c5 --- /dev/null +++ b/units/suse/rc-local.service @@ -0,0 +1,18 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. + +[Unit] +Description=/etc/init.d/boot.local Compatibility +ConditionPathExists=/etc/init.d/boot.local + +[Service] +Type=oneshot +ExecStart=/etc/init.d/boot.local +TimeoutSec=0 +StandardOutput=tty +RemainAfterExit=yes +SysVStartPriority=99 -- 1.7.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] common RPM spec file?
Le samedi 30 juillet 2011 à 16:36 +0200, Lennart Poettering a écrit : > On Thu, 28.07.11 09:49, Andreas Jaeger (a...@suse.com) wrote: > > > How are other distros packaging systemd? The systemd 31 release now adds > > devel > > files, so I consider creating a systemd-devel package. > > > > Can we all agree - at least the RPM world - to use the same basic split of > > systemd in subpackages? In that case we could keep a version in git and use > > as > > reference. > > We have a slightly different split on Fedora, but we'd acttually like to > clean this up and merge two of those packages again. > > > > > Right now on openSUSE we have: > > * systemd > > * systemd-gtk > > * systemd-sysvinit > > What is this one for? (We used to have one like this, but we dropped > that when systemd become the only supported init system in Fedora) systemd-sysvinit is only used to create the various compatibility symlinks for /sbin/init, halt, shutdown, etc.. For openSUSE 12.1, we still plan to have both sysvinit and systemd coexist. > > * systemd-plymouth > > Note that we will soon move the Plymouth unit files into Plymouth proper > and they will then be removed from systemd. And we don't enable plymouth support by default yet, so it is not really an issue. > On Fedora we have two further packages: > > systemd-units: exists mostly for legacy reasons and we hope to fold this > back into systemd soon, if we manage to get the upgrade path right. > > systemd-sysv: contains some compat code which i'd like to get rid of in > F17 or so. > > putting this together we have: > > systemd > systemd-units (will go away) > systemd-sysv (will go away) > systemd-gtk > systemd-devel > > > And I would now introduce > > * systemd-devel for include files, pkg files and .so link > > > > This common usage would make life easier for people developing packages for > > several distributions that require systemd at build time, > > So I am wondering about systemd-sysvinit. Otherwise it looks like we'll > eventually have the same packaging on Suse and Fedora. From what I see in your sysvinit package, it doesn't do exactly the same thing, it is mostly to package the convert script which save the initscripts states before migrating them to systemd units equivalent. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix bash completion for systemctl restart
Current bash completion doesn't use the correct service list for restart command, preventing to restart a already running service. -- Frederic Crozat SUSE Business cards request.ods Description: application/vnd.oasis.opendocument.spreadsheet ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix bash completion for systemctl restart
Le lundi 01 août 2011 à 18:45 +0200, Frederic Crozat a écrit :
> Current bash completion doesn't use the correct service list for restart
> command, preventing to restart a already running service.
Grrr, wrong file attached :)
--
Frederic Crozat
SUSE
>From e8f9239aac3253884406c35309d673070c2b Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Mon, 1 Aug 2011 18:43:01 +0200
Subject: [PATCH] bash: Allow to restart already started service.
Allow to restart all services, not only inactive one.
https://bugzilla.novell.com/show_bug.cgi?id=704782
---
src/systemctl-bash-completion.sh |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/systemctl-bash-completion.sh b/src/systemctl-bash-completion.sh
index acdc086..6369a6c 100644
--- a/src/systemctl-bash-completion.sh
+++ b/src/systemctl-bash-completion.sh
@@ -79,10 +79,11 @@ _systemctl () {
local -A VERBS=(
[ALL_UNITS]='enable disable is-active is-enabled status show'
[FAILED_UNITS]='reset-failed'
- [STARTABLE_UNITS]='start restart reload-or-restart'
+ [STARTABLE_UNITS]='start'
[STOPPABLE_UNITS]='stop kill try-restart condrestart'
[ISOLATABLE_UNITS]='isolate'
[RELOADABLE_UNITS]='reload reload-or-try-restart force-reload'
+ [RESTARTABLE_UNITS]='restart reload-or-restart'
[JOBS]='cancel'
[SNAPSHOTS]='delete'
[ENVS]='set-environment unset-environment'
@@ -110,6 +111,10 @@ _systemctl () {
comps=$( __filter_units_by_property CanStart yes \
$( __get_inactive_units | grep -Ev '\.(device|snapshot)$' ))
+elif __contains_word "$verb" ${VERBS[RESTARTABLE_UNITS]}; then
+comps=$( __filter_units_by_property CanStart yes \
+ $( __get_all_units | grep -Ev '\.(device|snapshot|socket|timer)$' ))
+
elif __contains_word "$verb" ${VERBS[STOPPABLE_UNITS]}; then
comps=$( __filter_units_by_property CanStop yes \
$( __get_active_units ) )
--
1.7.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: detect SUSE initrd for fsck-root
Hi, currently fsck-root.service detects only dracut initrd to prevent running fsck on / when it was mounted rw by initrd. Attached patch adds detection for SUSE initrd. -- Frederic Crozat SUSE >From 687d70cc43b34eb2359598d0ca0b69e996aa1b38 Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Wed, 3 Aug 2011 16:46:52 +0200 Subject: [PATCH] units: detect SUSE initrd and do not run fsck on /. --- units/fsck-root.service.in |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/units/fsck-root.service.in b/units/fsck-root.service.in index 7b3529d..2f8c8f5 100644 --- a/units/fsck-root.service.in +++ b/units/fsck-root.service.in @@ -13,6 +13,8 @@ Before=local-fs.target shutdown.target # Dracut informs us with this flag file if the root fsck was already run ConditionPathExists=!/run/initramfs/root-fsck +# Detect SUSE initrd too +ConditionPathExists=!/dev/shm/initrd_exports.sh [Service] Type=oneshot -- 1.7.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: detect SUSE initrd for fsck-root
Le mercredi 03 août 2011 à 18:45 +0200, Lennart Poettering a écrit : > On Wed, 03.08.11 18:35, Frederic Crozat (fcro...@suse.com) wrote: > > Heya, > > > currently fsck-root.service detects only dracut initrd to prevent > > running fsck on / when it was mounted rw by initrd. Attached patch adds > > detection for SUSE initrd. > > Humm. /dev/shm is the place where POSIX shared memory should be > placed. It is not the place to put flag files. > > I'd prefer if the suse initrd would just use the same flag files as > Dracut. On purpose we kept the names of these files generic > (i.e. "initramfs" instead of "dracut"). I am not particularly keen on > maintaining per distro checks like this where it would be very easy to > unify things. I'll discuss with our mkinitrd guy to touch this file. > Even better would be if Suse could adopt Dracut too... Heh, we are trying to break one thing at a time ;) -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: detect SUSE initrd for fsck-root
Le mercredi 03 août 2011 à 18:49 +0200, Frederic Crozat a écrit : > Le mercredi 03 août 2011 à 18:45 +0200, Lennart Poettering a écrit : > > On Wed, 03.08.11 18:35, Frederic Crozat (fcro...@suse.com) wrote: > > > > Heya, > > > > > currently fsck-root.service detects only dracut initrd to prevent > > > running fsck on / when it was mounted rw by initrd. Attached patch adds > > > detection for SUSE initrd. > > > > Humm. /dev/shm is the place where POSIX shared memory should be > > placed. It is not the place to put flag files. > > > > I'd prefer if the suse initrd would just use the same flag files as > > Dracut. On purpose we kept the names of these files generic > > (i.e. "initramfs" instead of "dracut"). I am not particularly keen on > > maintaining per distro checks like this where it would be very easy to > > unify things. > > I'll discuss with our mkinitrd guy to touch this file. Fixed in next openSUSE mkinitrd. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: accept "none" as a crypttab option
SUSE is adding "none" as a option to /etc/crypttab when nothing is
relevant to be put there.
Attached patch ensures systemd doesn't complain about it (since it works
fine).
--
Frederic Crozat
SUSE
>From aa5f34f2109a02db7887c220c5a35b6a8ee3e6c8 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Thu, 4 Aug 2011 16:04:43 +0200
Subject: [PATCH] cryptsetup: accept "none" option
---
src/cryptsetup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/cryptsetup.c b/src/cryptsetup.c
index cf288de..ac7b6d6 100644
--- a/src/cryptsetup.c
+++ b/src/cryptsetup.c
@@ -110,7 +110,7 @@ static int parse_one_option(const char *option) {
return 0;
}
-} else
+} else if (!streq(option, "none"))
log_error("Encountered unknown /etc/crypttab option '%s', ignoring.", option);
return 0;
--
1.7.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: ensure cryptsetup targets are dependency of local-fs.target
Since openSUSE doesn't use plymouth, there is no way to ensure xdm/gdm/kdm or getty isn't started while passphrase query is being asked on tty1. Attached patch ensures local-fs.target is only reached when passphrase was typed (we were using the same dependency on openSUSE sysvinit). -- Frederic Crozat SUSE >From d58446e4b3217f97baca7961154813a563ccdd19 Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Thu, 4 Aug 2011 16:46:33 +0200 Subject: [PATCH] cryptsetup-generator: block boot when querying passphrase. Ensure we wait for passphrase before starting tty1 or graphical display. Needed when not using plymouth. --- src/cryptsetup-generator.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/cryptsetup-generator.c b/src/cryptsetup-generator.c index a340218..6f3aa78 100644 --- a/src/cryptsetup-generator.c +++ b/src/cryptsetup-generator.c @@ -112,7 +112,8 @@ static int create_disk( "DefaultDependencies=no\n" "BindTo=%s dev-mapper-%%i.device\n" "After=systemd-readahead-collect.service systemd-readahead-replay.service %s\n" -"Before=umount.target\n", +"Before=umount.target\n" +"Before=local-fs.target\n", d, d); if (!nofail) -- 1.7.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] v33 - crashes on 'systemctl enable'?
Le lundi 15 août 2011 à 19:12 +0300, Mantas M. a écrit : > So I just had systemd (v33 Arch Linux) crash while running "systemctl enable > nscd.service" -- twice (after reboot). > > Syslog: > | sudo: grawity : TTY=pts/2 ; PWD=/home/grawity ; USER=root ; > COMMAND=/bin/systemctl start nscd.service > | sudo: grawity : TTY=pts/2 ; PWD=/home/grawity ; USER=root ; > COMMAND=/bin/systemctl enable nscd.service > | systemd[1]: Caught , dumped core as pid 3238. > | systemd[1]: Executing crash shell in 10s... > | systemd[1]: Successfully spawned crash shell as pid 3242. > | systemd[1]: Freezing execution. > > "gdb -p 1": > | (gdb) bt > | #0 0x7fc9e97260e0 in __pause_nocancel () from /lib/libpthread.so.0 > | #1 0x0046a69d in ?? () > | #2 0x0040a638 in ?? () > | #3 > | #4 0x7fc9e8bc4725 in raise () from /lib/libc.so.6 > | #5 0x7fc9e8bc5b9b in abort () from /lib/libc.so.6 > | #6 0x7fc9e9963955 in ?? () from /usr/lib/libdbus-1.so.3 > | #7 0x7fc9e995abe7 in ?? () from /usr/lib/libdbus-1.so.3 > | #8 0x7fc9e994da2b in dbus_message_iter_append_basic () from > /usr/lib/libdbus-1.so.3 > | #9 0x0043aaa5 in ?? () > | #10 0x0043d81e in ?? () > | #11 0x7fc9e99518a1 in ?? () from /usr/lib/libdbus-1.so.3 > | #12 0x7fc9e99437c0 in dbus_connection_dispatch () from > /usr/lib/libdbus-1.so.3 > | #13 0x0043968a in ?? () > | #14 0x00410b9c in ?? () > | #15 0x0040885d in ?? () > | #16 0x7fc9e8bb113d in __libc_start_main () from /lib/libc.so.6 > | #17 0x004098bd in ?? () > | #18 0x7fff2f102c98 in ?? () > | #19 0x in ?? () > | #20 0x0001 in ?? () > | #21 0x7fff2f103fd3 in ?? () > | #22 0x in ?? () > > I have no clue what else to include in a crash report... The system is still > up and running, though. I'm also seeing similar crashes on openSUSE Factory : #0 0xe430 in __kernel_vsyscall () #1 0xb754ae5f in raise () from /lib/libc.so.6 #2 0x08051be3 in crash (sig=6) at src/main.c:121 #3 #4 0xe430 in __kernel_vsyscall () #5 0xb754ae5f in raise () from /lib/libc.so.6 #6 0xb754c7f5 in abort () from /lib/libc.so.6 #7 0xb7722305 in _dbus_abort () at dbus-sysdeps.c:94 #8 0xb771830b in _dbus_warn_check_failed ( format=0xb77281e8 "arguments to %s() were incorrect, assertion \"%s \" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:289 #9 0xb7708ffc in dbus_message_iter_append_basic (iter=0xbf891d3c, type=98, value=0xbf891de4) at dbus-message.c:2514 #10 0x08088b84 in message_from_file_changes (m=, changes=0x8189a48, n_changes=1, carries_install_info=2) at src/dbus-manager.c:448 #11 0x0808bec1 in bus_manager_message_handler (connection=0x818a1d8, message=0x8199e28, data=0x811e5c8) at src/dbus-manager.c:1365 #12 0xb770d9db in _dbus_object_tree_dispatch_and_unlock (tree=0x818ab38, message=0x8199e28, found_object=0xbf892368) at dbus-object-tree.c:862 #13 0xb76fd599 in dbus_connection_dispatch (connection=0x818a1d8) at dbus-connection.c:4644 #14 0x0808748c in bus_dispatch (m=0x811e5c8) at src/dbus.c:521 #15 0x08059353 in manager_loop (m=0x811e5c8) at src/manager.c:2426 #16 0x0804f6d2 in main (argc=1, argv=0xbf892834) at src/main.c:1317 -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: add missing header include
Hi, MS_REC is not always defined in sys/mount.h. linux/fs.h should be included, since it is always defined there. -- Frederic Crozat SUSE >From 9f8a50decf45aaa4436b9fb3a0ab360f238b7d96 Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Thu, 18 Aug 2011 15:42:29 +0200 Subject: [PATCH] nspawn: add missing include header for MS_REC. --- src/nspawn.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/nspawn.c b/src/nspawn.c index 2c1144a..19d95b2 100644 --- a/src/nspawn.c +++ b/src/nspawn.c @@ -37,6 +37,7 @@ #include #include #include +#include #include "log.h" #include "util.h" -- 1.7.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: add missing header include
Le jeudi 18 août 2011 à 16:00 +0200, Lennart Poettering a écrit : > On Thu, 18.08.11 15:50, Frederic Crozat (fcro...@suse.com) wrote: > > > Hi, > > > > MS_REC is not always defined in sys/mount.h. linux/fs.h should be > > included, since it is always defined there. > > Not always? Can you be more specific please? Which version of glibc is that? Well, I haven't found it on glibc 2.11.3, shipped in latest openSUSE (it was added by Ulrich in 02/2010, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=11235 ie for glib 2.12). Another solution could be to add it to missing.h. I wasn't sure which one was best, since namespace.c is including linux/fs.h, because of MS_REC and MS_MS_UNBINDABLE. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: add support for compose_table, kbd_rate and disabling caplocks
Hi,
even if I know it is kind of SUSE specific, I was wondering if you were
interested in merging attached patch (I tried to wrapped most of it
inside TARGET_SUSE) which support more options from SUSE kbd
initscripts.
I haven't done yet another option which sets leds for numlock and so on,
because I'm not sure I want it in vconsole-setup (reading bios data
which should probably be restored by kernel itself, etc..) but probably
in a separate helper (either C or shell).
--
Frederic Crozat
SUSE
>From e183dbe195058ef921c4bd9760dc3631b425dd92 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Thu, 18 Aug 2011 18:28:01 +0200
Subject: [PATCH] handle disable_caplock and compose_table and kbd_rate
---
src/vconsole-setup.c | 93 --
1 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/src/vconsole-setup.c b/src/vconsole-setup.c
index 4347a20..28dc1d9 100644
--- a/src/vconsole-setup.c
+++ b/src/vconsole-setup.c
@@ -39,6 +39,7 @@
#include "util.h"
#include "log.h"
#include "macro.h"
+#include "strv.h"
static bool is_vconsole(int fd) {
unsigned char data[1];
@@ -78,8 +79,8 @@ static int disable_utf8(int fd) {
return r;
}
-static int load_keymap(const char *vc, const char *map, const char *map_toggle, bool utf8, pid_t *_pid) {
-const char *args[8];
+static int load_keymap(const char *vc, const char *map, const char *map_toggle, bool utf8, bool disable_capslock, const char *compose_table, pid_t *_pid) {
+const char *args[1024];
int i = 0;
pid_t pid;
@@ -98,6 +99,35 @@ static int load_keymap(const char *vc, const char *map, const char *map_toggle,
args[i++] = map;
if (map_toggle)
args[i++] = map_toggle;
+if (disable_capslock)
+args[i++] = "disable.capslock";
+if (compose_table) {
+char **strv_compose_table = NULL;
+
+strv_compose_table = strv_split(compose_table, WHITESPACE);
+if (strv_compose_table) {
+bool compose_loaded = false;
+bool compose_clear = false;
+char **name;
+char *arg;
+
+STRV_FOREACH (name, strv_compose_table) {
+if (streq(*name,"-c") || streq(*name,"clear")) {
+compose_clear = true;
+continue;
+}
+if (!compose_loaded) {
+if (compose_clear)
+args[i++] = "-c";
+}
+asprintf(&arg, "compose.%s",*name);
+compose_loaded = true;
+args[i++] = arg;
+
+}
+}
+strv_free(strv_compose_table);
+}
args[i++] = NULL;
if ((pid = fork()) < 0) {
@@ -149,6 +179,42 @@ static int load_font(const char *vc, const char *font, const char *map, const ch
return 0;
}
+#ifdef TARGET_SUSE
+static int set_kbd_rate(const char *vc, const char *kbd_rate, const char *kbd_delay, pid_t *_pid) {
+const char *args[7];
+int i = 0;
+pid_t pid;
+
+if (isempty(kbd_rate) && isempty(kbd_delay)) {
+*_pid = 0;
+return 0;
+}
+
+args[i++] = "/bin/kbdrate";
+if (!isempty(kbd_rate)) {
+args[i++] = "-r";
+args[i++] = kbd_rate;
+}
+if (!isempty(kbd_delay)) {
+args[i++] = "-d";
+args[i++] = kbd_delay;
+}
+args[i++] = "-s";
+args[i++] = NULL;
+
+if ((pid = fork()) < 0) {
+log_error("Failed to fork: %m");
+return -errno;
+} else if (pid == 0) {
+execv(args[0], (char **) args);
+_exit(EXIT_FAILURE);
+}
+
+*_pid = pid;
+return 0;
+}
+#endif
+
int main(int argc, char **argv) {
const char *vc;
char *vc_keymap = NULL;
@@ -156,14 +222,22 @@ int main(int argc, char **argv) {
char *vc_font = NULL;
char *vc_font_map = NULL;
char *vc_font_unimap = NULL;
+char *vc_compose_table = NULL;
#ifdef TARGET_GENTOO
char *vc_unicode = NULL;
#endif
#ifdef TARGET_MANDRIVA
char *vc_keytable = NULL;
#endif
+#ifdef TARGET_SUSE
+char *vc_kbd_delay = NULL;
+char *vc_kbd_rate = NULL;
+char *vc_kbd_disable_caps_lock = NULL;
+pid_t kbd_rate_pid = 0;
+#endif
int fd = -1;
Re: [systemd-devel] PATCH: add support for compose_table, kbd_rate and disabling caplocks
Le vendredi 19 août 2011 à 18:15 +0200, Kay Sievers a écrit : > What's the plan long term with that code we add here? TARGET_SUSE (and > all the others) will need to move to the distro's package after a > while, instead of having it available in the upstream tree. We need to > find a balance between making things easier now, and not to need to > throw out a lot of things when we are going to remove all the > TARGET_DISTRO stuff, which will happen after a while. Any ideas? So, we need to "extract" the various features present in the various distro and either make sure they are implemented in vconsole-setup (ie it can be specified in vconsole.conf ) or can be moved to a separate package. In our particular SUSE case, I see three features : - "compose" key : should goes in, since it is better to have just one call for loadkeys than calling it two or three times (like it is done in our initscript or if we add another helper). - kbd rate : could be moved to a separate helper - setleds : same (although some of it should be handled by the kernel itself..) In the mean time, I'll keep a patch in SUSE systemd for compose and kbd_rate and a separate service for setleds. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix kexec support when using /dev/initctl
Hi,
when the various sysvinit compat symlink are not installed, calling
kexec /boot/vmlinuz doesn't kexec the system because
systemd-initctl doesn't check /sys/kernel/kexec_loaded value (unlike
when using systemctl reboot or when systemctl is symlinked
to /sbin/shutdown).
Attached patch fixes the issue (and move kexec_loaded function to
util.[ch] since it is used in two places now).
--
Frederic Crozat
SUSE
>From b1e304bb59e1a80abacfd6f0377ae14c3c1a10cc Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Mon, 22 Aug 2011 14:58:50 +0200
Subject: [PATCH] initctl: check for kexec_loaded when reboot is requested through initctl
---
src/initctl.c |2 ++
src/systemctl.c | 12
src/util.c | 12
src/util.h |2 ++
4 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/src/initctl.c b/src/initctl.c
index f36f1cc..eaa717a 100644
--- a/src/initctl.c
+++ b/src/initctl.c
@@ -93,6 +93,8 @@ static const char *translate_runlevel(int runlevel, bool *isolate) {
for (i = 0; i < ELEMENTSOF(table); i++)
if (table[i].runlevel == runlevel) {
*isolate = table[i].isolate;
+if (runlevel == '6' && kexec_loaded())
+return SPECIAL_KEXEC_TARGET;
return table[i].special;
}
diff --git a/src/systemctl.c b/src/systemctl.c
index bb998d3..0ff9221 100644
--- a/src/systemctl.c
+++ b/src/systemctl.c
@@ -4403,18 +4403,6 @@ static int parse_time_spec(const char *t, usec_t *_u) {
return 0;
}
-static bool kexec_loaded(void) {
- bool loaded = false;
- char *s;
-
- if (read_one_line_file("/sys/kernel/kexec_loaded", &s) >= 0) {
- if (s[0] == '1')
- loaded = true;
- free(s);
- }
- return loaded;
-}
-
static int shutdown_parse_argv(int argc, char *argv[]) {
enum {
diff --git a/src/util.c b/src/util.c
index 8d54049..247156d 100644
--- a/src/util.c
+++ b/src/util.c
@@ -5680,3 +5680,15 @@ static const char *const signal_table[] = {
};
DEFINE_STRING_TABLE_LOOKUP(signal, int);
+
+bool kexec_loaded(void) {
+ bool loaded = false;
+ char *s;
+
+ if (read_one_line_file("/sys/kernel/kexec_loaded", &s) >= 0) {
+ if (s[0] == '1')
+ loaded = true;
+ free(s);
+ }
+ return loaded;
+}
diff --git a/src/util.h b/src/util.h
index 407160d..8b31e5b 100644
--- a/src/util.h
+++ b/src/util.h
@@ -497,4 +497,6 @@ int signal_from_string_try_harder(const char *s);
extern int saved_argc;
extern char **saved_argv;
+bool kexec_loaded(void);
+
#endif
--
1.7.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] generators and service symlink
Hi, I'm testing a systemd-generator to create default.target symlink, depending on /etc/inittab content. Generator is working fine, creating symlink in /run/systemd/generator but systemd isn't noticing the file (it is still using default.target from /lib/systemd/system/ ) until systemctl daemon-reload is started. Sounds like a bug but I'm not sure where it is.. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generators and service symlink
Le mardi 23 août 2011 à 17:56 +0200, Lennart Poettering a écrit : > On Mon, 22.08.11 17:52, Frederic Crozat (fcro...@suse.com) wrote: > > > Hi, > > > > I'm testing a systemd-generator to create default.target symlink, > > depending on /etc/inittab content. > > > > Generator is working fine, creating symlink in /run/systemd/generator > > but systemd isn't noticing the file (it is still using default.target > > from /lib/systemd/system/ ) until systemctl daemon-reload is started. > > > > Sounds like a bug but I'm not sure where it is.. > > Hmm, I am a bit confused. A reload of systemd will cause the generators > to be run, so yupp, they should be applied in that case. > > Maybe your generator does not work properly during the early boot phase > since it requires file systems or services which aren't around yet? > > Generators are executed very very early, and can only access data from > the root fs, not even /usr. Hence writing them in anything but C is not > really an option. After digging further, I found the issue : - generators was not at fault - unlike what I was thinking, /run/systemd/generator doesn't take precedence over /lib, so it couldn't work - but /run/systemd/system is supposed to take precedence over everything (/lib and /etc). I've adapted my generator to only create the file in /run/systemd/system if there was none in /etc/systemd/system. It didn't work as expected due to a bug in path-lookup.c:lookup_paths_init which remove from the lookup path lists empty directories : therefore /run/systemd/system was evicted from the directory list to monitor and wasn't used at all. This was added by commit a9dd208208e672a4fe5a3c2405946c1506e034db and it should be reverted. I'm also attaching a patch for an error I found while reading lookup_paths_init code. -- Frederic Crozat SUSE >From 1cf32c016f97b2c99d7df06ce5d5b858f86c507a Mon Sep 17 00:00:00 2001 From: Frederic Crozat Date: Wed, 24 Aug 2011 13:39:06 +0200 Subject: [PATCH] path-lookup: monitor /etc/systemd/user for user manager --- src/path-lookup.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/path-lookup.c b/src/path-lookup.c index bed9175..5f5ad8c 100644 --- a/src/path-lookup.c +++ b/src/path-lookup.c @@ -209,7 +209,7 @@ int lookup_paths_init(LookupPaths *p, ManagerRunningAs running_as, bool personal * the arrays in user_dirs() above! */ "/run/systemd/user", USER_CONFIG_UNIT_PATH, -"/etc/systemd/system", +"/etc/systemd/user", "/usr/local/lib/systemd/user", "/usr/local/share/systemd/user", USER_DATA_UNIT_PATH, -- 1.7.3.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generators and service symlink
Le mercredi 24 août 2011 à 13:42 +0200, Frederic Crozat a écrit :
> Le mardi 23 août 2011 à 17:56 +0200, Lennart Poettering a écrit :
> > On Mon, 22.08.11 17:52, Frederic Crozat (fcro...@suse.com) wrote:
> >
> > > Hi,
> > >
> > > I'm testing a systemd-generator to create default.target symlink,
> > > depending on /etc/inittab content.
> > >
> > > Generator is working fine, creating symlink in /run/systemd/generator
> > > but systemd isn't noticing the file (it is still using default.target
> > > from /lib/systemd/system/ ) until systemctl daemon-reload is started.
> > >
> > > Sounds like a bug but I'm not sure where it is..
> >
> > Hmm, I am a bit confused. A reload of systemd will cause the generators
> > to be run, so yupp, they should be applied in that case.
> >
> > Maybe your generator does not work properly during the early boot phase
> > since it requires file systems or services which aren't around yet?
> >
> > Generators are executed very very early, and can only access data from
> > the root fs, not even /usr. Hence writing them in anything but C is not
> > really an option.
>
> After digging further, I found the issue :
> - generators was not at fault
> - unlike what I was thinking, /run/systemd/generator doesn't take
> precedence over /lib, so it couldn't work
> - but /run/systemd/system is supposed to take precedence over everything
> (/lib and /etc).
>
> I've adapted my generator to only create the file in /run/systemd/system
> if there was none in /etc/systemd/system.
>
> It didn't work as expected due to a bug in
> path-lookup.c:lookup_paths_init which remove from the lookup path lists
> empty directories : therefore /run/systemd/system was evicted from the
> directory list to monitor and wasn't used at all.
>
> This was added by commit a9dd208208e672a4fe5a3c2405946c1506e034db and it
> should be reverted.
To be more precise, attached part should be committed (only revert one
part of the commit).
--
Frederic Crozat
SUSE
>From 3d2d9f22aecb1e1631bd51bc6252bf8813506af5 Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Wed, 24 Aug 2011 13:52:47 +0200
Subject: [PATCH] path-lookup: don't remove empty directories.
They might be populated by generator.
---
src/path-lookup.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/path-lookup.c b/src/path-lookup.c
index 5f5ad8c..7f8b0cb 100644
--- a/src/path-lookup.c
+++ b/src/path-lookup.c
@@ -240,7 +240,6 @@ int lookup_paths_init(LookupPaths *p, ManagerRunningAs running_as, bool personal
return -ENOMEM;
strv_uniq(p->unit_path);
-strv_path_remove_empty(p->unit_path);
if (!strv_isempty(p->unit_path)) {
--
1.7.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] generators and service symlink
Le mercredi 24 août 2011 à 14:12 +0200, Lennart Poettering a écrit : > On Wed, 24.08.11 13:42, Frederic Crozat (fcro...@suse.com) wrote: > > It didn't work as expected due to a bug in > > path-lookup.c:lookup_paths_init which remove from the lookup path lists > > empty directories : therefore /run/systemd/system was evicted from the > > directory list to monitor and wasn't used at all. > > Hmm, are you suggesting lookup_paths_init() is called before the > generators? That would be wrong. We should definitely strip empty > directories, but of course taking into account everything the generators > might have generated. Yes, it is : lookup_paths_init is called in manager_new and generators are called later, in manager_startup. If we make sure lookup_paths_init is called last, we could remove from manager_run_generators the need to add "/run/systemd/generator" to lookup_paths : instead, we always "put it" in the list and it will evicted if empty by lookup_paths_init -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: support for parsing /etc/insserv.conf for LSB system facilities
Le mardi 02 août 2011 à 01:43 +0200, Lennart Poettering a écrit : > On Mon, 04.07.11 11:39, Frederic Crozat (fcro...@suse.com) wrote: > > > Le vendredi 01 juillet 2011 à 23:30 +0200, Lennart Poettering a écrit : > > > On Fri, 01.07.11 11:20, Frederic Crozat (fcro...@suse.com) wrote: > > > > > > > Hi, > > > > > > Heya, > > Thanks, > > applied! After our discussion at systemd BoF during Desktop Summit and since I had to change this code to fix some cycles introduced by it, I've decided to completely remove the code and use a bash4 based generator instead. Please revert de3910a324aefcb15c26be27033d6917494e5946 For reference, I've attached the generator we use now in openSUSE. -- Frederic Crozat SUSE systemd-insserv_conf Description: application/shellscript ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/14] systemadm updates
Le lundi 19 septembre 2011 à 17:49 +0200, Kay Sievers a écrit : > 2011/9/19 Zbigniew Jędrzejewski-Szmek : > > On 09/19/2011 02:02 PM, microcai wrote: > >> > >> Can you send git pull request and just mail diff state ? > > > > Will do so in the future. > > > > The commits are here: git://in.waw.pl/git/systemd systemadm_changes > > I think it's time to move that tool out to its on tarball and we get > rid of the gtk and vala dependencies in the basic systemd package. The > broken vala autotools integration really stand in our way to do the > long overdue cleanup of Makefile.am. Indeed.. -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to activate service 'org.freedesktop.ConsoleKit': timed out
Le lundi 19 septembre 2011 à 23:02 +0200, Lennart Poettering a écrit : > On Sun, 18.09.11 18:20, Reindl Harald (h.rei...@thelounge.net) wrote: > > > Sep 18 18:18:04 rh dbus-daemon: [system] Failed to activate service > > 'org.freedesktop.ConsoleKit': timed out > > > > this happens on all my machines upgraded to F15 > > > > i think this is the reason why if i login to fast after boot in KDE > > the whole desktop sucks - but how to fix this problem? > > Seems for some reason CK fails to show up on the bus. what does > "systemctl status console-kit-daemon.service" say after boot? Strangely, I got similar bug report from KDE users on openSUSE Factory (didn't had time to investigate myself) : https://bugzilla.novell.com/show_bug.cgi?id=715467 -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] RPM macros for systemd : latest version
Hi all,
we've been doing another round of changes to the RPM macros for systemd.
It is mostly to handle :
- migration from sysvinit (using Fedora scripts, but not relying on
triggers, because they don't play very will with OBS)
- presets (systemctl preset is called automatically)
--
Frederic Crozat
SUSE
# RPM macros for packages installing systemd unit files
#
###
#
# When a package install systemd unit files, it should use the following macros:
#
# add %systemd_requires in the specfile
#
# %post
# %service_add_pre demo.service demo1.service
#
# %post
# %service_add_post demo.service demo1.service
#
# %preun
# %service_del_preun demo.service
#
# %postun
# %service_del_postun demo.service
#
###
# This is for /bin/systemctl
%systemd_requires
\
Requires(pre): systemd
\
Requires(post): systemd
\
Requires(preun): systemd
\
Requires(postun): systemd
\
%_unitdir /lib/systemd/system
%service_add_pre()
\
test -n "$FIRST_ARG" || FIRST_ARG=$1
\
# disable migration if initial install under systemd
\
if [ $FIRST_ARG -eq 1 ]; then
\
for service in %{?*} ; do
\
sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'`
\
touch "/var/lib/systemd/migrated/$sysv_service"
\
done
\
else
\
for service in %{?*} ; do
\
sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'`
\
if [ ! -e "/var/lib/systemd/migrated/$sysv_service" ]; then
\
services_to_migrate="$services_to_migrate $sysv_service"
\
fi
\
done
\
if [ -n "$services_to_migrate" ]; then
\
/usr/sbin/systemd-sysv-convert --save $services_to_migrate >/dev/null 2>&1
|| : \
fi
\
fi
\
%{nil}
# On install, tell systemd to reload its unit files
%service_add_post()
\
test -n "$FIRST_ARG" || FIRST_ARG=$1
\
for service in %{?*} ; do
\
sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'`
\
if [ ! -e "/var/lib/systemd/migrated/$sysv_service" ]; then
\
services_to_migrate="$services_to_migrate $sysv_service"
\
touch "/var/lib/systemd/migrated/$sysv_service"
\
fi
\
done
\
if [ -n "$services_to_migrate" ]; then
\
/usr/sbin/systemd-sysv-convert --apply $services_to_migrate >/dev/null 2>&1
|| : \
fi
\
/bin/systemctl daemon-reload >/dev/null 2>&1 || :
\
/bin/systemctl preset %{?*} >/dev/null 2>&1 || :
\
%{nil}
# On uninstall, disable and stop services
%service_del_preun()
\
test -n "$FIRST_ARG" || FIRST_ARG=$1
\
if [ $FIRST_ARG -eq 0 ]; then
\
# Package removal, not upgrade
\
/bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || :
\
/bi
[systemd-devel] PATCH: improve LSB initscript handling regarding RemainAfterExit
Hi,
currently, all LSB initscripts have RemainAfterExit=true, since pidfile
is not available in the header (unlike "fedora" like headers). This is
problematic when a daemon started from an initscript gets killed (or
something similar), because the service still looks active (see
https://bugzilla.novell.com/show_bug.cgi?id=721426 ).
Attached patch tries to mitigate that, by checking if a daemon was
detected in this case and change RemainAfterExit to false.
--
Frederic Crozat
SUSE
>From 700b1261115a67392014ff2c887a9cffc28108ab Mon Sep 17 00:00:00 2001
From: Frederic Crozat
Date: Fri, 30 Sep 2011 12:58:17 +0200
Subject: [PATCH] service: flags sysv service with detected pid as RemainAfterExit=false
LSB header doesn't give pidfile, so all LSB initscripts have
RemainAfterExit=false, causing daemon termination to not be reported as
such by systemd. Checking at startup if daemon is still running for
sysv initscript to disable RemainAfterExit helps a lot.
Fixes https://bugzilla.novell.com/show_bug.cgi?id=721426
---
src/service.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/src/service.c b/src/service.c
index 6b7064a..eb2699c 100644
--- a/src/service.c
+++ b/src/service.c
@@ -2012,9 +2012,15 @@ static void service_enter_running(Service *s, bool success) {
main_pid_ok = main_pid_good(s);
cgroup_ok = cgroup_good(s);
+
if ((main_pid_ok > 0 || (main_pid_ok < 0 && cgroup_ok != 0)) &&
-(s->bus_name_good || s->type != SERVICE_DBUS))
+(s->bus_name_good || s->type != SERVICE_DBUS)) {
+#ifdef HAVE_SYSV_COMPAT
+if (s->sysv_enabled && !s->pid_file)
+s->remain_after_exit = false;
+#endif
service_set_state(s, SERVICE_RUNNING);
+}
else if (s->remain_after_exit)
service_set_state(s, SERVICE_EXITED);
else
--
1.7.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead: read /usr files last for rotational media, skip /var
Le vendredi 30 septembre 2011 à 13:32 +0200, Kay Sievers a écrit : > On Fri, Sep 30, 2011 at 13:18, Paolo Bonzini wrote: > > On 09/30/2011 01:05 PM, Tom Gundersen wrote: > >> > >> Also, I'm not sure if I understand your suggestion that /var should be > >> ignored. In particular I think /var/tmp would be useful to readahead > >> (albeit probably as one of the last things to do). > > > > You could add that as a third group, after / and /usr. The patch makes that > > kind of extensibility very easy. > > Rules which files to prioritize *might* make sense, sorting by > top-level dir doesn't really. We should probably set a milestone for basic.target, splitting the readahead for files needed to reach basic.target and all other files after it. This is something we were doing in speedboot on Mdv (and similar stuff was done in Fedora readahead IIRC). -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: avoid ordering cycle on swap
Le lundi 17 octobre 2011 à 13:01 +0200, Tom Gundersen a écrit : > Devices with random keys (swap), should not be ordered before local-fs.target, > as this creates a cycle with systemd-load-random-seed.service (and also it > does not make sense, a swap device is not a local-fs). FYI, this patch was confirmed to fix issue reported on our bugzilla : https://bugzilla.novell.com/show_bug.cgi?id=721666 -- Frederic Crozat SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
