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] 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] 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] 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] [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 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 fcro...@suse.com --- 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: 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 fcro...@suse.com 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 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 wer...@suse.de wrote: From: Frederic Crozat fcro...@suse.com 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 fcro...@suse.com
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(defs\n style type=\text/css\\n![CDATA[\n);
svg( rect { stroke-width: 1; }\n);
+svg( rect.bg{ fill: rgb(255,255,255); }\n);
svg( rect.cpu { fill: rgb(64,64,240); stroke-width: 0; fill-opacity: 0.7; }\n);
svg( rect.wait { fill: rgb(240,240,0); stroke-width: 0; fill-opacity: 0.7; }\n);
svg( rect.bi{ fill: rgb(240,128,128); stroke-width: 0; fill-opacity: 0.7; }\n);
@@ -1270,6 +1271,7 @@ void svg_do(const char *build) {
/* after this, we can draw the header with proper sizing */
svg_header();
+svg(rect class=\bg\ width=\100%%\ height=\100%%\ /\n\n);
svg(g transform=\translate(10,400)\\n);
svg_io_bi_bar();
--
1.8.4.5
___
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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com 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] [-tsec] [-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 fcro...@suse.com 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 fcro...@suse.com 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. snip Any unanswered questions? No, just two words: thanks you ! -- Frederic Crozat fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com 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 vmlinuz...@yahoo.com.ar --- 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 fcro...@suse.com 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 vmlinuz...@yahoo.com.ar --- 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 fcro...@suse.com 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 systemd-ma...@redhat.com --- 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 fcro...@suse.com 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 crrodrig...@opensuse.org 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 return to continue, or q return 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 fcro...@suse.com 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 m...@zarb.org 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 fcro...@suse.com
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 fcro...@suse.com 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 krie...@uni-koblenz.de 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 fcro...@suse.com 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 krie...@uni-koblenz.de 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com SUSE ___ 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 fcro...@suse.com
SUSE
From d43a9dc530261506b62c257021c8433d5bf25388 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
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 fcro...@suse.com
SUSE
From a99435109b83e7146a30ccf5387037b51c1fe907 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
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 fcro...@suse.com 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 fcro...@suse.com
SUSE
From 4e7c74b96a2c154cfb3e60fc14c8b50070808758 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
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 fcro...@suse.com SUSE From 94dc949a3056eb989ff2e0c90d951b55eabf72f6 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com 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] 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com 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 à 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com
SUSE
From df77b11852d6b3495848c4123e7cbd9f099910f9 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
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] [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 u...@tezduyar.com 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=1file=fix-umount-order-at-shutdown.patchpackage=systemd.openSUSE_12.2_Updateproject=home%3Afcrozat%3Abranches%3AopenSUSE%3A12.2%3AUpdate ) -- Frederic Crozat fcro...@suse.com 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 fcro...@suse.com SUSE From 2cfd1ed4d853be4a22cc102037347c9041bf5ced Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com 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: literal +Environment=VARIABLE1=word1 word2/literal. +See citerefentryrefentrytitleenviron/refentrytitlemanvolnum7/manvolnum/citerefentry for details./para/listitem /varlistentry -- 1.7.10.4 ___ 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 fcro...@suse.com 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 arvidj...@gmail.com wrote: commit f4ce2b3e5ce93b83f14f8785e205ebb5a9b8c1df Author: Lennart Poettering lenn...@poettering.net 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 fcro...@suse.com 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 arvidj...@gmail.com wrote: commit f4ce2b3e5ce93b83f14f8785e205ebb5a9b8c1df Author: Lennart Poettering lenn...@poettering.net 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com
SUSE
From aeaf77d093f03133a675fee709b6ac8666d472ae Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
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 @@
literalcat/literal is equivalent to passing
option--no-pager/option./para/listitem
/varlistentry
+varlistentry
+termvarname$SYSTEMCTL_OPTIONS/varname/term
+listitemparaOptions specified here will be used
+by systemctl, as if they had been added on command line./para/listitem
+/varlistentry
/variablelist
+
+
/refsect1
refsect1
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 à 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 fcro...@suse.com
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 fcro...@suse.com 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 fcro...@suse.com 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 fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have timers fire after boot is complete
Le jeudi 27 septembre 2012 à 11:07 +, Jóhann B. Guðmundsson a écrit : On 09/27/2012 08:33 AM, Christian Seiler wrote: one of the most-requested features that is not present in systemd currently is a true rc.local-type functionality that runs after all other services. Any particular reason why those user just dont create type oneshot unit then order it as they see fit with after and or before? Mostly because many users have no idea after which units they should schedule their target. And they are used to having a run as last script in their distribution (see https://bugzilla.novell.com/show_bug.cgi?id=778715 which links to openSUSE forum on this topic). -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have timers fire after boot is complete
Le jeudi 27 septembre 2012 à 12:55 +, Jóhann B. Guðmundsson a écrit : On 09/27/2012 11:17 AM, Frederic Crozat wrote: Le jeudi 27 septembre 2012 à 11:07 +, Jóhann B. Guðmundsson a écrit : On 09/27/2012 08:33 AM, Christian Seiler wrote: one of the most-requested features that is not present in systemd currently is a true rc.local-type functionality that runs after all other services. Any particular reason why those user just dont create type oneshot unit then order it as they see fit with after and or before? Mostly because many users have no idea after which units they should schedule their target. And they are used to having a run as last script in their distribution Ordering it after the default target should suffice. I tested that a loong time ago and it wasn't working as expected (but I should re-test that). In Fedora we still support rc.local we just dont ship it by default so if you want/prefer the old behavior. We also have boot.local (which is equivalent to rc.local) and correctly handled by systemd. (see https://bugzilla.novell.com/show_bug.cgi?id=778715 which links to openSUSE forum on this topic). Out of the four forum samples in comment 2 on this bug, 3 of the forum post ( from the look of it ) are workarounds for genuine bugs and one should belong in a rule-*/route-* files under /etc/sysconfig/network which would be picked up by networking scripts ( given that suse networking scripts support that ) . I didn't had time to reply to this bug, yet. I think we (systemd community) need to improve documentation for people who need to write workarounds (or whatever we call them) and were used to after.local (or whatever it is called in various distributions). -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [opensuse-factory] [RFC] sysvinit: plan B
Le dimanche 23 septembre 2012 à 06:23 +0200, Jan Engelhardt a écrit : On Friday 2012-09-07 15:43, Michal Vyskocil wrote [http://lists.opensuse.org/opensuse-factory/2012-09/msg00396.html]: Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init It would seem more advantageous to change the systemd package, and provide an extra binary there that reuses the parser code to give users the possibility to start/stop/restart programs using unit files in a non-systemd environment. . First, I don't see the point of doing a separate package at all for sysvinit compatibility. Second, if people want to use .service, they should use systemd. I don't want us to spend time in doing some strange backport from one new technology to another one when plan to drop. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v9002 1/2] timedated: gather timezone from /etc/localtime sym target
Le mardi 21 août 2012 à 23:11 -0700, Shawn Landden a écrit :
@@ -218,19 +248,21 @@ static int write_data_timezone(void) {
return r;
}
-p = strappend(/usr/share/zoneinfo/, tz.zone);
+p = strappend(ZONEINFO_PATH, tz.zone);
if (!p)
return log_oom();
-r = symlink_or_copy_atomic(p, /etc/localtime);
+r = symlink(p, /etc/localtime);
free(p);
It doesn't work when /etc/localtime already exists, because symlink
returns EEXIST. I guess you should put back your symlink_atomic patch..
--
Frederic Crozat fcro...@suse.com
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v9000 2/3] timedated: gather timezone from /etc/localtime sym target
Le dimanche 12 août 2012 à 22:36 -0700, Shawn Landden a écrit :
/etc/localtime - /usr/share/zoneinfo/...
or
/etc/localtime - ../usr/share/zoneinfo/...
(note, ../usr is not the same if /etc is a symlink, as this isn't
using canonicalize_file_name())
keep other method for now, consider dropping later.
Supporting relative links here are problematic as timezones in
/usr/share/zoneinfo are often themselves symlinks (and symlinks to
symlinks), so this implamentation only supports absolute symlinks
/usr/share/zoneinfo/ and relative symlinks starting with
../usr/share/zoneinfo/
From TODO (kay sievers):
* kill /etc/timezone handling entirely? What does it provide?
- /etc/localtime carries the same information already:
$ ls -l /etc/localtime; cat /etc/timezone
lrwxrwxrwx 1 root root 33 Jul 27 09:55 /etc/localtime -
/usr/share/zoneinfo/Europe/Berlin
Europe/Berlin
- systemd enforces /usr to be available at bootup, so we can
enforce the use of the symlink
---
src/timedate/timedated.c | 50
--
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 09fd808..c3067c8 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -74,6 +74,9 @@
BUS_GENERIC_INTERFACES_LIST \
org.freedesktop.timedate1\0
+/* Must start and end with '/' */
+#define ZONEINFO_PATH /usr/share/zoneinfo/
+
const char timedate_interface[] _introspect_(timedate1) = INTERFACE;
typedef struct TZ {
@@ -152,16 +155,14 @@ static void verify_timezone(void) {
return;
p = strappend(/usr/share/zoneinfo/, tz.zone);
^
it would be better to replace this with the macro you added
(ZONEINFO_PATH)
-if (!p) {
-log_oom();
-return;
-}
+if (!p)
+return (void)log_oom();
I would keep the way the log_oom / return was used initially and not
change it.
--
Frederic Crozat fcro...@suse.com
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v9000 2/3] timedated: gather timezone from /etc/localtime sym target
Le mardi 14 août 2012 à 10:32 +0200, Frederic Crozat a écrit :
Le dimanche 12 août 2012 à 22:36 -0700, Shawn Landden a écrit :
/etc/localtime - /usr/share/zoneinfo/...
or
/etc/localtime - ../usr/share/zoneinfo/...
(note, ../usr is not the same if /etc is a symlink, as this isn't
using canonicalize_file_name())
keep other method for now, consider dropping later.
Supporting relative links here are problematic as timezones in
/usr/share/zoneinfo are often themselves symlinks (and symlinks to
symlinks), so this implamentation only supports absolute symlinks
/usr/share/zoneinfo/ and relative symlinks starting with
../usr/share/zoneinfo/
From TODO (kay sievers):
* kill /etc/timezone handling entirely? What does it provide?
- /etc/localtime carries the same information already:
$ ls -l /etc/localtime; cat /etc/timezone
lrwxrwxrwx 1 root root 33 Jul 27 09:55 /etc/localtime -
/usr/share/zoneinfo/Europe/Berlin
Europe/Berlin
- systemd enforces /usr to be available at bootup, so we can
enforce the use of the symlink
---
src/timedate/timedated.c | 50
--
1 file changed, 40 insertions(+), 10 deletions(-)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 09fd808..c3067c8 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -74,6 +74,9 @@
BUS_GENERIC_INTERFACES_LIST \
org.freedesktop.timedate1\0
+/* Must start and end with '/' */
+#define ZONEINFO_PATH /usr/share/zoneinfo/
+
const char timedate_interface[] _introspect_(timedate1) = INTERFACE;
typedef struct TZ {
@@ -152,16 +155,14 @@ static void verify_timezone(void) {
return;
p = strappend(/usr/share/zoneinfo/, tz.zone);
^
it would be better to replace this with the macro you added
(ZONEINFO_PATH)
And I've found another occurrence of /usr/share/zoneinfo which would
need to be fixed.
--
Frederic Crozat fcro...@suse.com
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: gather timezone from /etc/localtime sym target
Le mercredi 08 août 2012 à 18:51 +0200, Lennart Poettering a écrit : On Tue, 07.08.12 00:31, Shawn Landen (shawnland...@gmail.com) wrote: keep other method for now, consider dropping later. Supporting relative links here could be problematic as timezones in /usr/share/zoneinfo are often themselves symlinks (and symlinks to symlinks), so this implamentation only only support absolute links. Hmm, I am not entirely sure this is really the best thing to do. Always requiring a symlink for /etc/localtime breaks a couple of things: we can't just bind mount things over in an nspawn container, embedded devices have to ship /usr/share/zoneinfo/, which is probably something they might want to avoid. So, dunno, I think this is something to think about first, discuss the pros and cons. I see that just having this as symlink is much simpler, no doubt, but does it have more benefits? And possibly more disadvantages? Well, I just found a major disavantage: openSUSE (and YaST) are not using a symlink for /etc/localtime but a copy of the zoneinfo file (it is probably coming from support of separate /usr, when mounting /usr wasn't handled by initrd). So, this must be fixed to support /etc/localtime being a copy, at least for reading informations (currently, the code crashes, I'll see if I can fix it). -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: gather timezone from /etc/localtime sym target
Le mardi 14 août 2012 à 11:20 +0200, Frederic Crozat a écrit : Le mercredi 08 août 2012 à 18:51 +0200, Lennart Poettering a écrit : On Tue, 07.08.12 00:31, Shawn Landen (shawnland...@gmail.com) wrote: keep other method for now, consider dropping later. Supporting relative links here could be problematic as timezones in /usr/share/zoneinfo are often themselves symlinks (and symlinks to symlinks), so this implamentation only only support absolute links. Hmm, I am not entirely sure this is really the best thing to do. Always requiring a symlink for /etc/localtime breaks a couple of things: we can't just bind mount things over in an nspawn container, embedded devices have to ship /usr/share/zoneinfo/, which is probably something they might want to avoid. So, dunno, I think this is something to think about first, discuss the pros and cons. I see that just having this as symlink is much simpler, no doubt, but does it have more benefits? And possibly more disadvantages? Well, I just found a major disavantage: openSUSE (and YaST) are not using a symlink for /etc/localtime but a copy of the zoneinfo file (it is probably coming from support of separate /usr, when mounting /usr wasn't handled by initrd). So, this must be fixed to support /etc/localtime being a copy, at least for reading informations (currently, the code crashes, I'll see if I can fix it). After discussing with other SUSE fellows (bnc#773491), I'd say we should just ignore when /etc/localtime is a hardlink (or a copy) to a timezone data (since we don't have the name of the timezone in the file itself) and use /etc/sysconfig/clock as fallback (when available). And when updating timezone, /etc/localtime should be created as a symlink. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add keyscript support to cryptsetup
Le mardi 10 juillet 2012 à 16:25 +0200, Lennart Poettering a écrit : 3) systemd specific solution Converting keyscript= scripts to password agents introduce a strong dependency on systemd. I realize that you don't consider it to be a problem but I'm guessing it wouldn't be acceptable to Debian (where systemd is not mandatory). Well, it's currently a Debian-init scripts specific solution... I have similar request from keyscript users (coming from Debian) in SUSE ;) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Generators
Le mercredi 23 mai 2012 à 13:38 +0200, Lennart Poettering a écrit : Heya, in order to make the fstab generator work I have extended the generator logic in systemd quite a bit. It is now possible to override normal unit files with dynamic units generated from generators. Frederic Crozat, iirc you needed precisely this functionality, no? Can you have a look and see if this is what you were looking for? Sounds good to me. Thanks also for documenting the whole thing, it will help a lot. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC : PATCH: initial implementation of system wide rlimit
Le mardi 03 avril 2012 à 15:44 +0200, Frederic Crozat a écrit :
Le lundi 02 avril 2012 à 22:59 +0200, Lennart Poettering a écrit :
On Fri, 30.03.12 17:20, Frederic Crozat (fcro...@suse.com) wrote:
From 5008080dda662208278c159213adbd5211496043 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 29 Mar 2012 17:53:41 +0200
Subject: [PATCH 1/2] macro: add newdup macro, equivalent of new + memdup
but
type-safe
---
src/macro.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/macro.h b/src/macro.h
index 19f259e..a85e72d 100644
--- a/src/macro.h
+++ b/src/macro.h
@@ -137,6 +137,7 @@ static inline size_t ALIGN_TO(size_t l, size_t ali) {
#define memzero(x,l) (memset((x), 0, (l)))
#define zero(x) (memzero((x), sizeof(x)))
+#define newdup(x,l) ( (x= new(typeof(*l),1)) ?
memcpy((x),(l),sizeof(*l)) : NULL)
Hmm, I was more thinking of a definition much closer to new() and
new0(), without typeof, but with allowing allocation of an array
#define newdup(t, p, n) ((t*)memdup(p,sizeof(t)*(n)))
New version attached, based on your comments.
Rebased version, including a fix to newdup macro which went to git some
weeks ago.
--
Frederic Crozat fcro...@suse.com
SUSE
From 5944312f891658446edea08e6907dff05daebdec Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Mon, 21 May 2012 16:53:18 +0200
Subject: [PATCH 1/2] util: fix typo in newdup
---
src/shared/util.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/shared/util.h b/src/shared/util.h
index 3dce047..33a7e7c 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -103,7 +103,7 @@ bool streq_ptr(const char *a, const char *b);
#define newa(t, n) ((t*) alloca(sizeof(t)*(n)))
-#define newdup(t, p, n) ((t*) memdup(p, sizeof(t)*(n))
+#define newdup(t, p, n) ((t*) memdup(p, sizeof(t)*(n)))
#define malloc0(n) (calloc((n), 1))
--
1.7.7
From f175a58a4a183a0d34cb13b77290425eb3f3c9b0 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Wed, 21 Mar 2012 18:03:40 +0100
Subject: [PATCH 2/2] allow system wide limits for services
---
src/core/main.c| 28
src/core/manager.c |7 +++
src/core/manager.h |2 ++
src/core/service.c |8
4 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 8c25819..5e37b47 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -85,6 +85,7 @@ static ExecOutput arg_default_std_output = EXEC_OUTPUT_JOURNAL;
static ExecOutput arg_default_std_error = EXEC_OUTPUT_INHERIT;
static usec_t arg_runtime_watchdog = 0;
static usec_t arg_shutdown_watchdog = 10 * USEC_PER_MINUTE;
+static struct rlimit *default_rlimit[RLIMIT_NLIMITS] = {};
static FILE* serialization = NULL;
@@ -665,6 +666,22 @@ static int parse_config_file(void) {
{ Manager, JoinControllers, config_parse_join_controllers, 0, arg_join_controllers },
{ Manager, RuntimeWatchdogSec,config_parse_usec, 0, arg_runtime_watchdog},
{ Manager, ShutdownWatchdogSec, config_parse_usec, 0, arg_shutdown_watchdog },
+{ Manager, LimitCPU, config_parse_limit,0, default_rlimit[RLIMIT_CPU]},
+{ Manager, LimitFSIZE,config_parse_limit,0, default_rlimit[RLIMIT_FSIZE]},
+{ Manager, LimitDATA, config_parse_limit,0, default_rlimit[RLIMIT_DATA]},
+{ Manager, LimitSTACK,config_parse_limit,0, default_rlimit[RLIMIT_STACK]},
+{ Manager, LimitCORE, config_parse_limit,0, default_rlimit[RLIMIT_CORE]},
+{ Manager, LimitRSS, config_parse_limit,0, default_rlimit[RLIMIT_RSS]},
+{ Manager, LimitNOFILE, config_parse_limit,0, default_rlimit[RLIMIT_NOFILE]},
+{ Manager, LimitAS, config_parse_limit,0, default_rlimit[RLIMIT_AS]},
+{ Manager, LimitNPROC,config_parse_limit,0, default_rlimit[RLIMIT_NPROC]},
+{ Manager, LimitMEMLOCK, config_parse_limit,0, default_rlimit[RLIMIT_MEMLOCK]},
+{ Manager, LimitLOCKS,config_parse_limit,0, default_rlimit[RLIMIT_LOCKS]},
+{ Manager, LimitSIGPENDING, config_parse_limit,0, default_rlimit[RLIMIT_SIGPENDING]},
+{ Manager, LimitMSGQUEUE, config_parse_limit,0, default_rlimit[RLIMIT_MSGQUEUE]},
+{ Manager, LimitNICE, config_parse_limit,0, default_rlimit[RLIMIT_NICE]},
+{ Manager, LimitRTPRIO, config_parse_limit,0, default_rlimit[RLIMIT_RTPRIO]},
+{ Manager, LimitRTTIME
[systemd-devel] Patch: fix typo in newdup
-- Frederic Crozat fcro...@suse.com SUSE From 5944312f891658446edea08e6907dff05daebdec Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Mon, 21 May 2012 16:53:18 +0200 Subject: [PATCH] util: fix typo in newdup --- src/shared/util.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/shared/util.h b/src/shared/util.h index 3dce047..33a7e7c 100644 --- a/src/shared/util.h +++ b/src/shared/util.h @@ -103,7 +103,7 @@ bool streq_ptr(const char *a, const char *b); #define newa(t, n) ((t*) alloca(sizeof(t)*(n))) -#define newdup(t, p, n) ((t*) memdup(p, sizeof(t)*(n)) +#define newdup(t, p, n) ((t*) memdup(p, sizeof(t)*(n))) #define malloc0(n) (calloc((n), 1)) -- 1.7.7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC : PATCH: initial implementation of system wide rlimit
Le lundi 21 mai 2012 à 18:04 +0200, Frederic Crozat a écrit :
Le mardi 03 avril 2012 à 15:44 +0200, Frederic Crozat a écrit :
Le lundi 02 avril 2012 à 22:59 +0200, Lennart Poettering a écrit :
On Fri, 30.03.12 17:20, Frederic Crozat (fcro...@suse.com) wrote:
From 5008080dda662208278c159213adbd5211496043 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 29 Mar 2012 17:53:41 +0200
Subject: [PATCH 1/2] macro: add newdup macro, equivalent of new +
memdup but
type-safe
---
src/macro.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/macro.h b/src/macro.h
index 19f259e..a85e72d 100644
--- a/src/macro.h
+++ b/src/macro.h
@@ -137,6 +137,7 @@ static inline size_t ALIGN_TO(size_t l, size_t ali)
{
#define memzero(x,l) (memset((x), 0, (l)))
#define zero(x) (memzero((x), sizeof(x)))
+#define newdup(x,l) ( (x= new(typeof(*l),1)) ?
memcpy((x),(l),sizeof(*l)) : NULL)
Hmm, I was more thinking of a definition much closer to new() and
new0(), without typeof, but with allowing allocation of an array
#define newdup(t, p, n) ((t*)memdup(p,sizeof(t)*(n)))
New version attached, based on your comments.
Rebased version, including a fix to newdup macro which went to git some
weeks ago.
New version, addressing various comments from irc discussion and with
documentation :)
--
Frederic Crozat fcro...@suse.com
SUSE
From d3b2761ed6a6d0410b9eff66e2e302df76736a25 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Wed, 21 Mar 2012 18:03:40 +0100
Subject: [PATCH] allow system wide limits for services
---
man/systemd.conf.xml | 27 +++
src/core/main.c | 22 ++
src/core/manager.c | 25 +
src/core/manager.h |3 +++
src/core/service.c |8
5 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/man/systemd.conf.xml b/man/systemd.conf.xml
index a110f24..7dfaa18 100644
--- a/man/systemd.conf.xml
+++ b/man/systemd.conf.xml
@@ -182,6 +182,33 @@
effect if a hardware watchdog is not
available./para/listitem
/varlistentry
+
+varlistentry
+termvarnameDefaultLimitCPU=/varname/term
+termvarnameDefaultLimitFSIZE=/varname/term
+termvarnameDefaultLimitDATA=/varname/term
+termvarnameDefaultLimitSTACK=/varname/term
+termvarnameDefaultLimitCORE=/varname/term
+termvarnameDefaultLimitRSS=/varname/term
+termvarnameDefaultLimitNOFILE=/varname/term
+termvarnameDefaultLimitAS=/varname/term
+termvarnameDefaultLimitNPROC=/varname/term
+termvarnameDefaultLimitMEMLOCK=/varname/term
+termvarnameDefaultLimitLOCKS=/varname/term
+termvarnameDefaultLimitSIGPENDING=/varname/term
+termvarnameDefaultLimitMSGQUEUE=/varname/term
+termvarnameDefaultLimitNICE=/varname/term
+termvarnameDefaultLimitRTPRIO=/varname/term
+termvarnameDefaultLimitRTTIME=/varname/term
+listitemparaThese settings control
+various default resource limits for units. See
+citerefentryrefentrytitlesetrlimit/refentrytitlemanvolnum2/manvolnum/citerefentry
+for details. Use the string
+varnameinfinity/varname to
+configure no limit on a specific
+resource. They can be overriden in units files
+using corresponding Limit parameter./para/listitem
+/varlistentry
/variablelist
/refsect1
diff --git a/src/core/main.c b/src/core/main.c
index 8c25819..20c0f3c 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -85,6 +85,7 @@ static ExecOutput arg_default_std_output = EXEC_OUTPUT_JOURNAL;
static ExecOutput arg_default_std_error = EXEC_OUTPUT_INHERIT;
static usec_t arg_runtime_watchdog = 0;
static usec_t arg_shutdown_watchdog = 10 * USEC_PER_MINUTE;
+static struct rlimit *arg_default_rlimit[RLIMIT_NLIMITS] = {};
static FILE* serialization = NULL;
@@ -665,6 +666,22 @@ static int parse_config_file(void) {
{ Manager, JoinControllers, config_parse_join_controllers, 0, arg_join_controllers },
{ Manager, RuntimeWatchdogSec,config_parse_usec, 0, arg_runtime_watchdog
[systemd-devel] Patch: fix memleak in logind
Hi, while researching logind bug with su / sudo, I ran logind under valgrind which spotted at least one memleak. Attached patch fixes the issue. -- Frederic Crozat fcro...@suse.com SUSE From f023b8ccdaeff9696a9ef2523bce256f96586cbf Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Fri, 4 May 2012 16:14:19 +0200 Subject: [PATCH] logind: fix memory leak --- src/login/logind-session.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/login/logind-session.c b/src/login/logind-session.c index 5490366..e297d3f 100644 --- a/src/login/logind-session.c +++ b/src/login/logind-session.c @@ -327,6 +327,7 @@ finish: free(vtnr); free(leader); free(audit_id); +free(class); return r; } -- 1.7.7 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC : PATCH: initial implementation of system wide rlimit
Le lundi 02 avril 2012 à 22:59 +0200, Lennart Poettering a écrit :
On Fri, 30.03.12 17:20, Frederic Crozat (fcro...@suse.com) wrote:
From 5008080dda662208278c159213adbd5211496043 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 29 Mar 2012 17:53:41 +0200
Subject: [PATCH 1/2] macro: add newdup macro, equivalent of new + memdup but
type-safe
---
src/macro.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/macro.h b/src/macro.h
index 19f259e..a85e72d 100644
--- a/src/macro.h
+++ b/src/macro.h
@@ -137,6 +137,7 @@ static inline size_t ALIGN_TO(size_t l, size_t ali) {
#define memzero(x,l) (memset((x), 0, (l)))
#define zero(x) (memzero((x), sizeof(x)))
+#define newdup(x,l) ( (x= new(typeof(*l),1)) ? memcpy((x),(l),sizeof(*l))
: NULL)
Hmm, I was more thinking of a definition much closer to new() and
new0(), without typeof, but with allowing allocation of an array
#define newdup(t, p, n) ((t*)memdup(p,sizeof(t)*(n)))
New version attached, based on your comments.
--
Frederic Crozat fcro...@suse.com
SUSE
From f17a7712ea2be4b540e3af8f474433ff1e989220 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 29 Mar 2012 17:53:41 +0200
Subject: [PATCH 1/2] macro: add newdup macro, equivalent of new + memdup but
type-safe
---
src/macro.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/macro.h b/src/macro.h
index 19f259e..5e1106f 100644
--- a/src/macro.h
+++ b/src/macro.h
@@ -137,6 +137,7 @@ static inline size_t ALIGN_TO(size_t l, size_t ali) {
#define memzero(x,l) (memset((x), 0, (l)))
#define zero(x) (memzero((x), sizeof(x)))
+#define newdup(t, p, n) ((t*)memdup(p,sizeof(t)*(n)))
#define char_array_0(x) x[sizeof(x)-1] = 0;
--
1.7.7
From 81bdc076bba2f4dddb947bf56f4811fd2c031fef Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Wed, 21 Mar 2012 18:03:40 +0100
Subject: [PATCH 2/2] allow system wide limits for services
---
src/main.c| 28
src/manager.c |8
src/manager.h |2 ++
src/service.c |8
4 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/src/main.c b/src/main.c
index 7ae8841..ffb14bc 100644
--- a/src/main.c
+++ b/src/main.c
@@ -80,6 +80,7 @@ static char **arg_default_controllers = NULL;
static char ***arg_join_controllers = NULL;
static ExecOutput arg_default_std_output = EXEC_OUTPUT_JOURNAL;
static ExecOutput arg_default_std_error = EXEC_OUTPUT_INHERIT;
+static struct rlimit *default_rlimit[RLIMIT_NLIMITS] = {};
static FILE* serialization = NULL;
@@ -660,6 +661,22 @@ static int parse_config_file(void) {
{ Manager, DefaultStandardOutput, config_parse_output, 0, arg_default_std_output },
{ Manager, DefaultStandardError, config_parse_output, 0, arg_default_std_error },
{ Manager, JoinControllers, config_parse_join_controllers, 0, arg_join_controllers },
+{ Manager, LimitCPU, config_parse_limit,0, default_rlimit[RLIMIT_CPU]},
+{ Manager, LimitFSIZE,config_parse_limit,0, default_rlimit[RLIMIT_FSIZE]},
+{ Manager, LimitDATA, config_parse_limit,0, default_rlimit[RLIMIT_DATA]},
+{ Manager, LimitSTACK,config_parse_limit,0, default_rlimit[RLIMIT_STACK]},
+{ Manager, LimitCORE, config_parse_limit,0, default_rlimit[RLIMIT_CORE]},
+{ Manager, LimitRSS, config_parse_limit,0, default_rlimit[RLIMIT_RSS]},
+{ Manager, LimitNOFILE, config_parse_limit,0, default_rlimit[RLIMIT_NOFILE]},
+{ Manager, LimitAS, config_parse_limit,0, default_rlimit[RLIMIT_AS]},
+{ Manager, LimitNPROC,config_parse_limit,0, default_rlimit[RLIMIT_NPROC]},
+{ Manager, LimitMEMLOCK, config_parse_limit,0, default_rlimit[RLIMIT_MEMLOCK]},
+{ Manager, LimitLOCKS,config_parse_limit,0, default_rlimit[RLIMIT_LOCKS]},
+{ Manager, LimitSIGPENDING, config_parse_limit,0, default_rlimit[RLIMIT_SIGPENDING]},
+{ Manager, LimitMSGQUEUE, config_parse_limit,0, default_rlimit[RLIMIT_MSGQUEUE]},
+{ Manager, LimitNICE, config_parse_limit,0, default_rlimit[RLIMIT_NICE]},
+{ Manager, LimitRTPRIO, config_parse_limit,0, default_rlimit[RLIMIT_RTPRIO]},
+{ Manager, LimitRTTIME, config_parse_limit,0, default_rlimit[RLIMIT_RTTIME]},
{ NULL, NULL, NULL, 0, NULL }
};
@@ -1404,6 +1421,14 @@ int main(int argc, char *argv[]) {
m-swap_auto = arg_swap_auto
Re: [systemd-devel] RFC : PATCH: initial implementation of system wide rlimit
Le lundi 26 mars 2012 à 18:51 +0200, Lennart Poettering a écrit :
On Mon, 26.03.12 14:25, Frederic Crozat (fcro...@suse.com) wrote:
...
Need to handle OOM. memdup() might be nicer to use here. (In fact, might
be worth introducing newdup() here as a type-safe macro, i.e. a
combination of new() and memdup()).
Here is new version, fixing the various stuff you commented and I've
also added newdup macro (in a separate git commit).
--
Frederic Crozat fcro...@suse.com
SUSE
From 5008080dda662208278c159213adbd5211496043 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 29 Mar 2012 17:53:41 +0200
Subject: [PATCH 1/2] macro: add newdup macro, equivalent of new + memdup but
type-safe
---
src/macro.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/macro.h b/src/macro.h
index 19f259e..a85e72d 100644
--- a/src/macro.h
+++ b/src/macro.h
@@ -137,6 +137,7 @@ static inline size_t ALIGN_TO(size_t l, size_t ali) {
#define memzero(x,l) (memset((x), 0, (l)))
#define zero(x) (memzero((x), sizeof(x)))
+#define newdup(x,l) ( (x= new(typeof(*l),1)) ? memcpy((x),(l),sizeof(*l)) : NULL)
#define char_array_0(x) x[sizeof(x)-1] = 0;
--
1.7.7
From fa5f387335f0df5da5fec26aa3c537e0c0c8dc12 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Wed, 21 Mar 2012 18:03:40 +0100
Subject: [PATCH 2/2] allow system wide limits for services
---
src/main.c| 28
src/manager.c |8
src/manager.h |2 ++
src/service.c |8
4 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/src/main.c b/src/main.c
index 7ae8841..f4295e4 100644
--- a/src/main.c
+++ b/src/main.c
@@ -80,6 +80,7 @@ static char **arg_default_controllers = NULL;
static char ***arg_join_controllers = NULL;
static ExecOutput arg_default_std_output = EXEC_OUTPUT_JOURNAL;
static ExecOutput arg_default_std_error = EXEC_OUTPUT_INHERIT;
+static struct rlimit *default_rlimit[RLIMIT_NLIMITS] = {};
static FILE* serialization = NULL;
@@ -660,6 +661,22 @@ static int parse_config_file(void) {
{ Manager, DefaultStandardOutput, config_parse_output, 0, arg_default_std_output },
{ Manager, DefaultStandardError, config_parse_output, 0, arg_default_std_error },
{ Manager, JoinControllers, config_parse_join_controllers, 0, arg_join_controllers },
+{ Manager, LimitCPU, config_parse_limit,0, default_rlimit[RLIMIT_CPU]},
+{ Manager, LimitFSIZE,config_parse_limit,0, default_rlimit[RLIMIT_FSIZE]},
+{ Manager, LimitDATA, config_parse_limit,0, default_rlimit[RLIMIT_DATA]},
+{ Manager, LimitSTACK,config_parse_limit,0, default_rlimit[RLIMIT_STACK]},
+{ Manager, LimitCORE, config_parse_limit,0, default_rlimit[RLIMIT_CORE]},
+{ Manager, LimitRSS, config_parse_limit,0, default_rlimit[RLIMIT_RSS]},
+{ Manager, LimitNOFILE, config_parse_limit,0, default_rlimit[RLIMIT_NOFILE]},
+{ Manager, LimitAS, config_parse_limit,0, default_rlimit[RLIMIT_AS]},
+{ Manager, LimitNPROC,config_parse_limit,0, default_rlimit[RLIMIT_NPROC]},
+{ Manager, LimitMEMLOCK, config_parse_limit,0, default_rlimit[RLIMIT_MEMLOCK]},
+{ Manager, LimitLOCKS,config_parse_limit,0, default_rlimit[RLIMIT_LOCKS]},
+{ Manager, LimitSIGPENDING, config_parse_limit,0, default_rlimit[RLIMIT_SIGPENDING]},
+{ Manager, LimitMSGQUEUE, config_parse_limit,0, default_rlimit[RLIMIT_MSGQUEUE]},
+{ Manager, LimitNICE, config_parse_limit,0, default_rlimit[RLIMIT_NICE]},
+{ Manager, LimitRTPRIO, config_parse_limit,0, default_rlimit[RLIMIT_RTPRIO]},
+{ Manager, LimitRTTIME, config_parse_limit,0, default_rlimit[RLIMIT_RTTIME]},
{ NULL, NULL, NULL, 0, NULL }
};
@@ -1404,6 +1421,14 @@ int main(int argc, char *argv[]) {
m-swap_auto = arg_swap_auto;
m-default_std_output = arg_default_std_output;
m-default_std_error = arg_default_std_error;
+for (j = 0; j RLIMIT_NLIMITS; j++) {
+if (default_rlimit[j]) {
+newdup(m-rlimit[j],default_rlimit[j]);
+
+if (!m-rlimit[j])
+goto finish;
+}
+}
if (dual_timestamp_is_set(initrd_timestamp))
m-initrd_timestamp = initrd_timestamp;
@@ -1543,6 +1568,9 @@ finish:
if (m)
manager_free(m);
+for (j = 0; j RLIMIT_NLIMITS
[systemd-devel] RFC : PATCH: initial implementation of system wide rlimit
Hi all,
following one of our bug opened on systemd (
https://bugzilla.novell.com/show_bug.cgi?id=744818 ) and after discussing the
issue on irc,
I found some time to do a initial implementation of systemd wide rlimit support.
Idea is simple :
- admin can set system wide limits for all services in
/etc/systemd/system.conf, with a syntax similar to the one from systemd.exec(5)
(LimitCPU ... LimitRTTIME).
- those limits, when set, override the default one (set by kernel) to all
services started, except those which might have their own limits specified in
their .unit file
Current limitations / Not done yet:
- currently, the limits are set on both rlim_cur and rlim_max (due to reuse of
config_parse_limit code). I'd like to extend the implementation to support
separate values for rlim_max and rlim_cur.
But I'm not 100% sure how we should express that in configuration file. Should
we use a additional keyword (LimitCPU / LimitSoftCPU ) or a dual value
(LimitCPU=100;10) ?
- for openSUSE, we will ship a generator which will transform
/etc/sysconfig/ulimit into a /run/systemd/system.conf.
Comments and code review welcome.
--
Frederic Crozat fcro...@suse.com
SUSE
From cc66b23fb2d240f674af9795897de95305c29b9b Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Wed, 21 Mar 2012 18:03:40 +0100
Subject: [PATCH] allow system wide limits for services
---
src/main.c| 35 ++-
src/manager.h |2 ++
src/service.c | 10 ++
3 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/src/main.c b/src/main.c
index ed317b4..c8701aa 100644
--- a/src/main.c
+++ b/src/main.c
@@ -79,6 +79,7 @@ static char **arg_default_controllers = NULL;
static char ***arg_join_controllers = NULL;
static ExecOutput arg_default_std_output = EXEC_OUTPUT_JOURNAL;
static ExecOutput arg_default_std_error = EXEC_OUTPUT_INHERIT;
+static struct rlimit *default_rlimit[RLIMIT_NLIMITS] = {};
static FILE* serialization = NULL;
@@ -659,12 +660,35 @@ static int parse_config_file(void) {
{ Manager, DefaultStandardOutput, config_parse_output, 0, arg_default_std_output },
{ Manager, DefaultStandardError, config_parse_output, 0, arg_default_std_error },
{ Manager, JoinControllers, config_parse_join_controllers, 0, arg_join_controllers },
+{ Manager, LimitCPU, config_parse_limit,0, default_rlimit[RLIMIT_CPU]},
+{ Manager, LimitFSIZE,config_parse_limit,0, default_rlimit[RLIMIT_FSIZE]},
+{ Manager, LimitDATA, config_parse_limit,0, default_rlimit[RLIMIT_DATA]},
+{ Manager, LimitSTACK,config_parse_limit,0, default_rlimit[RLIMIT_STACK]},
+{ Manager, LimitCORE, config_parse_limit,0, default_rlimit[RLIMIT_CORE]},
+{ Manager, LimitRSS, config_parse_limit,0, default_rlimit[RLIMIT_RSS]},
+{ Manager, LimitNOFILE, config_parse_limit,0, default_rlimit[RLIMIT_NOFILE]},
+{ Manager, LimitAS, config_parse_limit,0, default_rlimit[RLIMIT_AS]},
+{ Manager, LimitNPROC,config_parse_limit,0, default_rlimit[RLIMIT_NPROC]},
+{ Manager, LimitMEMLOCK, config_parse_limit,0, default_rlimit[RLIMIT_MEMLOCK]},
+{ Manager, LimitLOCKS,config_parse_limit,0, default_rlimit[RLIMIT_LOCKS]},
+{ Manager, LimitSIGPENDING, config_parse_limit,0, default_rlimit[RLIMIT_SIGPENDING]},
+{ Manager, LimitMSGQUEUE, config_parse_limit,0, default_rlimit[RLIMIT_MSGQUEUE]},
+{ Manager, LimitNICE, config_parse_limit,0, default_rlimit[RLIMIT_NICE]},
+{ Manager, LimitRTPRIO, config_parse_limit,0, default_rlimit[RLIMIT_RTPRIO]},
+{ Manager, LimitRTTIME, config_parse_limit,0, default_rlimit[RLIMIT_RTTIME]},
{ NULL, NULL, NULL, 0, NULL }
};
FILE *f;
const char *fn;
-int r;
+int r, i;
+
+for (i = 0; i RLIMIT_NLIMITS; i++) {
+if (!default_rlimit[i])
+if (!(default_rlimit[i]= new(struct rlimit, 1)))
+break;
+getrlimit(i,default_rlimit[i]);
+}
fn = arg_running_as == MANAGER_SYSTEM ? SYSTEM_CONFIG_FILE : USER_CONFIG_FILE;
f = fopen(fn, re);
@@ -1400,6 +1424,15 @@ int main(int argc, char *argv[]) {
m-swap_auto = arg_swap_auto;
m-default_std_output = arg_default_std_output;
m-default_std_error = arg_default_std_error;
+for (j = 0; j RLIMIT_NLIMITS; j++) {
+if (!m-rlimit[j
Re: [systemd-devel] RFC : PATCH: initial implementation of system wide rlimit
Le lundi 26 mars 2012 à 18:51 +0200, Lennart Poettering a écrit :
On Mon, 26.03.12 14:25, Frederic Crozat (fcro...@suse.com) wrote:
Heya,
- currently, the limits are set on both rlim_cur and rlim_max (due to
reuse of config_parse_limit code). I'd like to extend the
implementation to support separate values for rlim_max and rlim_cur.
But I'm not 100% sure how we should express that in configuration
file. Should we use a additional keyword (LimitCPU / LimitSoftCPU ) or
a dual value (LimitCPU=100;10) ?
I decided not to expose separate values for soft/non-soft on purpose. I
have the suspicion that they only make sense for user sessions, not so
much for system services,
I am mostly waiting for a usecase here. If somebody makes a good case
for hwo they should be useful in system services we can add support for
them, but otherwise I am not convinced.
We generally only expose kernel features we think are useful, but if
they aren't they are better hidden away.
Looking at the defaults shipped with openSUSE, some limits are set to
sane soft value (80% for soft virtual limit, 85% for soft resident
limit, etc..) and some default have different soft / hard value (fdlimit
= 8192 (hard), 1024 (soft) ; locklimit = 256KB (hard), 64KB (soft) ).
With the current implementation, we couldn't ensure such duality.
I'll ask around if people have other use cases.
Another interesting thing I didn't port from SUSE is being able to
express some of those values as percentage of system memory and not as
absolute value.
+for (i = 0; i RLIMIT_NLIMITS; i++) {
+if (!default_rlimit[i])
+if (!(default_rlimit[i]= new(struct rlimit, 1)))
+break;
+getrlimit(i,default_rlimit[i]);
+}
For new code we try to write
x = new(foobar, 1);
if (!x) {
...
}
rather than:
if (!(x = new(foobar, 1))) {
...
}
Sorry, I'm not yet used to it ;)
Also, you need to check for OOM here. And then, if it is clear that
getrlimit() will always return 0 here, then we should make that clear by
enclosing this in assert_se(getrlimit(...) == 0) or so.
I'll fix that.
But in general: why this code anyway? We should just let the pointer
point to NULL if there is not rlimit set. I.e. only those array entries
with non-default values should actually point to something.
I wanted to show the correct system values (default, when not set in
systemd) when using systemctl show. Otherwise, they might look as
infinite value (I was getting that, but I might had a bug there).
fn = arg_running_as == MANAGER_SYSTEM ? SYSTEM_CONFIG_FILE :
USER_CONFIG_FILE;
f = fopen(fn, re);
@@ -1400,6 +1424,15 @@ int main(int argc, char *argv[]) {
m-swap_auto = arg_swap_auto;
m-default_std_output = arg_default_std_output;
m-default_std_error = arg_default_std_error;
+for (j = 0; j RLIMIT_NLIMITS; j++) {
+if (!m-rlimit[j])
+if (!(m-rlimit[j]= new(struct rlimit, 1)))
+break;
+
+(m-rlimit[j])-rlim_cur = default_rlimit[j]-rlim_cur;
+(m-rlimit[j])-rlim_max = default_rlimit[j]-rlim_max;
+}
Need to handle OOM. memdup() might be nicer to use here. (In fact, might
be worth introducing newdup() here as a type-safe macro, i.e. a
combination of new() and memdup()).
I'll see what I can do.
--
Frederic Crozat fcro...@suse.com
SUSE
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le jeudi 22 mars 2012 à 10:32 -0700, Kok, Auke-jan H a écrit : On Wed, Mar 21, 2012 at 5:21 PM, Lennart Poettering lenn...@poettering.net wrote: Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Looks good to me. Applied! Now, one more question, since I actually never used sparse myself: what's the best way to make use of this? If I run autogen and build this with CC=cgcc some things look really borked (like generation of the dbus introspection files goes to stdout). Any suggestions? I'd suggest including this in some 'make test' type target only, but note that most of the stuff sparse throws our are warnings, and so any form of automation isn't really helpful with sparse. agreed. And be sure to run a git sparse, I'm sent some fixes regarding some barrier code which is used by systemd. Sparse checking is great, just like many other tools like valgrind, etc. , but, skilled eyes are required to make sense of the output. Yep. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pam_systemd.so and su
Le jeudi 22 mars 2012 à 02:11 +0100, Lennart Poettering a écrit : On Thu, 22.03.12 00:41, Lennart Poettering (lenn...@poettering.net) wrote: On Sun, 18.03.12 16:08, Canek Peláez Valdés (can...@gmail.com) wrote: Hi; I'm using systemd 43 in Gentoo, and I usally have this line at the end of /etc/pam.d/system-auth: -sessionoptionalpam_systemd.so When I use su to become root, after logout the following message appears: ...killed. Not always, but most of the time. Without the line with pam_systemd.so, the message never appears. So, two questions: 1. Why is my session being killed at logout time? 2. The pam_systemd.so is really necessary? The ...killed. message appears after two or three seconds, and it's slightly annoying. Which version of systemd is this? (If it isnt 44, please upgrade first, then try to reproduce this) Do you have audit enabled in the kernel and are using pam_loginuid? Normally, when the pam session close hooks are called logind responds to this by killing the main process of the session if it still exists. This is probably the source of the problem here. I have now commited a patch to git that might fix your issue. Please test: http://cgit.freedesktop.org/systemd/systemd/commit/?id=75c8e3cffd7da8eede614cf61384957af2c82a29 I assume this fixes your problem, but since our kernels actually have audit enabled I am a bit too lazy trying to reproduce the issue here, so I'd be very thankful if you could test this! I was hoping it would also fix https://bugs.freedesktop.org/show_bug.cgi?id=45670 / https://bugzilla.novell.com/show_bug.cgi?id=746704 but it doesn't :( -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v44
Le samedi 17 mars 2012 à 16:31 +0100, Kay Sievers a écrit : On Sat, Mar 17, 2012 at 15:14, Koen Kooi k...@dominion.thruhere.net wrote: Op 16 mrt. 2012, om 02:40 heeft Lennart Poettering het volgende geschreven: Heya, this is primarily a bugfix release (but does include a couple of new things) and might be very likely the version we'll ship in Fedora 17, unless there's some unforeseen bigger bug left to be fixed. http://cgit.freedesktop.org/systemd/systemd/plain/NEWS http://www.freedesktop.org/software/systemd/systemd-44.tar.xz I get the following error and warnings when crosscompiling for arm: | src/journal/journald.c: In function 'process_event': | src/journal/journald.c:2147:49: error: 'PAGE_SIZE' undeclared (first use in this function) PATH_MAX might be simpler to use here. I'm confirming the issue and the fix when building on PPC. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le vendredi 16 mars 2012 à 14:32 +0100, Frederic Crozat a écrit : Le mercredi 14 mars 2012 à 11:36 -0700, Josh Triplett a écrit : On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote: On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote: I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. This looks really cool! Thanks a lot for this. One comment, before we stick this into systemd: #ifndef SPARSE_ENDIAN_H #define SPARSE_ENDIAN_H #include endian.h #include stdint.h #ifdef __CHECKER__ #define __bitwise __attribute__((bitwise)) #define __force __attribute__((force)) #else #define __bitwise #define __force #endif typedef uint16_t __bitwise le16; typedef uint16_t __bitwise be16; typedef uint32_t __bitwise le32; typedef uint32_t __bitwise be32; typedef uint64_t __bitwise le64; typedef uint64_t __bitwise be64; Can we add a suffix _t here? I much prefer le16_t over le16, since this is a type. Sure, feel free. I used the unsuffixed names to match the kernel's type names and the names used in the conversion functions, but the endianness checking will obviously work with whatever names you prefer. :) The following sed line will give you the names you want: sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h Here is a patch integrating your header (modified as wanted by Lennart) and the changes in various locations of journal to use le64_t. It also fixes some potential endianness errors, please review it carefully. Quick follow-up on this patch : I've tested patched systemd on both x86 and ppc, reading journals generated from one platform on the other and vice-versa and it worked fine. So, with this patch, it seems we fixed the last endianness issue in journal code. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le mercredi 14 mars 2012 à 11:36 -0700, Josh Triplett a écrit :
On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote:
On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote:
I've attached a header file which should provide all the endianness
checking you need. Just include it in place of endian.h everywhere you
currently include endian.h. I stuck an all-permissive MIT license on
it, for maximum possible reuse.
This looks really cool! Thanks a lot for this. One comment, before we
stick this into systemd:
#ifndef SPARSE_ENDIAN_H
#define SPARSE_ENDIAN_H
#include endian.h
#include stdint.h
#ifdef __CHECKER__
#define __bitwise __attribute__((bitwise))
#define __force __attribute__((force))
#else
#define __bitwise
#define __force
#endif
typedef uint16_t __bitwise le16;
typedef uint16_t __bitwise be16;
typedef uint32_t __bitwise le32;
typedef uint32_t __bitwise be32;
typedef uint64_t __bitwise le64;
typedef uint64_t __bitwise be64;
Can we add a suffix _t here? I much prefer le16_t over le16, since this
is a type.
Sure, feel free. I used the unsuffixed names to match the kernel's type
names and the names used in the conversion functions, but the endianness
checking will obviously work with whatever names you prefer. :)
The following sed line will give you the names you want:
sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h
Here is a patch integrating your header (modified as wanted by Lennart)
and the changes in various locations of journal to use le64_t.
It also fixes some potential endianness errors, please review it
carefully.
--
Frederic Crozat fcro...@suse.com
SUSE
From 87859f428ec7927e5a423fa6df46c6b6a54e7817 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Fri, 16 Mar 2012 11:59:04 +0100
Subject: [PATCH] add sparse support to detect endianness bug
le16/32/64_t type should be used when storing little-endian value
header to integrate with sparse from Josh Triplett j...@joshtriplett.org
---
src/journal/journal-def.h | 74 +-
src/journal/journal-file.c | 15 ---
src/journal/journal-file.h |1 +
src/journal/journal-internal.h |2 +-
src/journal/journald.c |5 +-
src/journal/sd-journal.c | 10 +++--
src/journal/sparse-endian.h| 87
7 files changed, 143 insertions(+), 51 deletions(-)
create mode 100644 src/journal/sparse-endian.h
diff --git a/src/journal/journal-def.h b/src/journal/journal-def.h
index 964e0c2..9cb8051 100644
--- a/src/journal/journal-def.h
+++ b/src/journal/journal-def.h
@@ -22,7 +22,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
-#include inttypes.h
+#include sparse-endian.h
#include systemd/sd-id128.h
@@ -60,48 +60,48 @@ _packed_ struct ObjectHeader {
uint8_t type;
uint8_t flags;
uint8_t reserved[6];
-uint64_t size;
+le64_t size;
uint8_t payload[];
};
_packed_ struct DataObject {
ObjectHeader object;
-uint64_t hash;
-uint64_t next_hash_offset;
-uint64_t next_field_offset;
-uint64_t entry_offset; /* the first array entry we store inline */
-uint64_t entry_array_offset;
-uint64_t n_entries;
+le64_t hash;
+le64_t next_hash_offset;
+le64_t next_field_offset;
+le64_t entry_offset; /* the first array entry we store inline */
+le64_t entry_array_offset;
+le64_t n_entries;
uint8_t payload[];
};
_packed_ struct FieldObject {
ObjectHeader object;
-uint64_t hash;
-uint64_t next_hash_offset;
-uint64_t head_data_offset;
-uint64_t tail_data_offset;
+le64_t hash;
+le64_t next_hash_offset;
+le64_t head_data_offset;
+le64_t tail_data_offset;
uint8_t payload[];
};
_packed_ struct EntryItem {
-uint64_t object_offset;
-uint64_t hash;
+le64_t object_offset;
+le64_t hash;
};
_packed_ struct EntryObject {
ObjectHeader object;
-uint64_t seqnum;
-uint64_t realtime;
-uint64_t monotonic;
+le64_t seqnum;
+le64_t realtime;
+le64_t monotonic;
sd_id128_t boot_id;
-uint64_t xor_hash;
+le64_t xor_hash;
EntryItem items[];
};
_packed_ struct HashItem {
-uint64_t head_hash_offset;
-uint64_t tail_hash_offset;
+le64_t head_hash_offset;
+le64_t tail_hash_offset;
};
_packed_ struct HashTableObject {
@@ -111,8 +111,8 @@ _packed_ struct HashTableObject {
_packed_ struct EntryArrayObject {
ObjectHeader object;
-uint64_t next_entry_array_offset;
-uint64_t items[];
+le64_t next_entry_array_offset;
+le64_t items[];
};
union Object {
@@ -145,21
Re: [systemd-devel] PATCH: fix sparse warnings
Le mercredi 07 mars 2012 à 06:34 -0800, Josh Triplett a écrit : On Mon, Mar 05, 2012 at 03:21:12PM +0100, Frederic Crozat wrote: Le lundi 05 mars 2012 ? 15:10 +0100, Lennart Poettering a ?crit : I have little experience with sparse, but iirc it knows decorators for variables for le/be, right? Is this something we might want to use in the journal to avoid LE/BE issues like those you tracked down? Well, I spend almost a day trying to get sparse to spot endian-ness errors but couldn't get it to work properly :( The idea would be to replace any uint64_t type with __le64 (from /usr/include/linux/types.h) in data structures written on disk and make sure only function returning __le64 are used to modify those variables. Unfortunately, I wasn't able to teach sparse about htole64 / le64toh. Help welcome ;) Sparse's endianness support works via the attribute bitwise, which applies to an integral type and creates a new incompatible type every time you use it. Thus, if you write: typedef uint64_t __attribute__((bitwise)) le64; typedef uint64_t __attribute__((bitwise)) be64; then you have types le64 and be64 which Sparse considers incompatible with uint64_t. (The odd name bitwise refers to what you can do with such a type: you can do bitwise operations with two values of the same bitwise type, but you can't do arithmetic or similar.) The corresponding __attribute__((force)) should appear on a type used in a cast, to make that cast suppress warnings (including those about bitwise). The conversion functions should use these casts to convert the type, in addition to actually doing any necessary byteswapping. In order to do that, I'd suggest actually using static inline functions with real types, rather than macros that have no types. (You can use hacks to do typechecking in macros, but you'll end up with something much worse than just defining a function, and more importantly your warning messages won't look as clear.) One of these days, I'd love to see glibc add built-in support for Sparse-style endian-specific types, but for now, you'll have to write your own functions. Assuming that you don't want to change the names of all the byteswapping functions, I'd suggest defining your own set of static inlines with the same names; unfortunately that means #undef-ing all the ones defined by endian.h. Sparse defines the preprocessor symbol __CHECKER__, which you can use to detect Sparse and use Sparse-specific attributes. include/linux/compiler.h in the kernel uses this to define macros like __bitwise and __force which wrap the corresponding Sparse attributes, and which become no-ops when compiling with GCC. I'd recommend following that approach. I've attached a header file which should provide all the endianness checking you need. Just include it in place of endian.h everywhere you currently include endian.h. I stuck an all-permissive MIT license on it, for maximum possible reuse. Thanks Josh, I tried to do something similar to your header and failed (but I'm not sparse expert), so I'll test it and report the results. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le lundi 05 mars 2012 à 15:10 +0100, Lennart Poettering a écrit : On Wed, 29.02.12 18:33, Frederic Crozat (fcro...@suse.com) wrote: Le mercredi 29 février 2012 à 17:04 +, Frederic Crozat a écrit : Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). Better with patch attached ;) From d07e3f17e21ad4b200d0e076e0f49a3f8e91fae9 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Wed, 29 Feb 2012 14:42:49 +0100 Subject: [PATCH] fix sparse warnings Looks all good. Applied. I have little experience with sparse, but iirc it knows decorators for variables for le/be, right? Is this something we might want to use in the journal to avoid LE/BE issues like those you tracked down? Well, I spend almost a day trying to get sparse to spot endian-ness errors but couldn't get it to work properly :( The idea would be to replace any uint64_t type with __le64 (from /usr/include/linux/types.h) in data structures written on disk and make sure only function returning __le64 are used to modify those variables. Unfortunately, I wasn't able to teach sparse about htole64 / le64toh. Help welcome ;) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-journald: fix endianess bug
Le jeudi 01 mars 2012 à 18:01 +0100, Frederic Crozat a écrit :
Le mercredi 29 février 2012 à 13:54 +0100, Frederic Crozat a écrit :
Le mercredi 29 février 2012 à 12:45 +0100, Dirk Eibach a écrit :
---
src/journal/journal-file.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 20ca3f6..275caea 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -238,7 +238,7 @@ static int journal_file_allocate(JournalFile *f,
uint64_t offset, uint64_t size)
if (fstat(f-fd, f-last_stat) 0)
return -errno;
-f-header-arena_size = new_size -
htole64(f-header-arena_offset);
+f-header-arena_size = htole64(new_size -
le64toh(f-header-arena_offset));
return 0;
}
I confirm this patch fixes journald not starting properly on ppc
architecture (got the report yesterday from folks in the office).
But it looks like systemd-journalctl is still broken on this arch.
So far, I think I found two different endianess errors in the code, but
more are pending, since I'm getting assertion when trying to access a
journal file created on x86 architecture, on a powerpc system (and now,
I get similar errors with journal created on ppc, so maybe only the
writing code need fixing ;).
Please review my current patch carefully, I'm not 100% sure my fix are
accurate (this part of journald is a bit tricky to get right ;)
Here is a new version of the patch, we are slowly getting there : I'm
able to read journal created on x86 on a ppc system. Unfortunately,
journal created on ppc is still broken (f-header-entry_array_offset
get a crazy value, probably in BE instead of LE).
--
Frederic Crozat fcro...@suse.com
SUSE
From 3b3267b3a488605317dbc116eafe5462b9d46beb Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 1 Mar 2012 18:00:01 +0100
Subject: [PATCH] journal: fix endianness error
---
src/journal/journal-file.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 275caea..90aa27e 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -771,14 +771,14 @@ static int journal_file_append_data(JournalFile *f, const void *data, uint64_t s
uint64_t journal_file_entry_n_items(Object *o) {
assert(o);
-assert(o-object.type == htole64(OBJECT_ENTRY));
+assert(o-object.type == OBJECT_ENTRY);
return (le64toh(o-object.size) - offsetof(Object, entry.items)) / sizeof(EntryItem);
}
static uint64_t journal_file_entry_array_n_items(Object *o) {
assert(o);
-assert(o-object.type == htole64(OBJECT_ENTRY_ARRAY));
+assert(o-object.type == OBJECT_ENTRY_ARRAY);
return (le64toh(o-object.size) - offsetof(Object, entry_array.items)) / sizeof(uint64_t);
}
@@ -833,7 +833,7 @@ static int link_entry_into_array(JournalFile *f,
o-entry_array.items[i] = htole64(p);
if (ap == 0)
-*first = q;
+*first = htole64(q);
else {
r = journal_file_move_to_object(f, OBJECT_ENTRY_ARRAY, ap, o);
if (r 0)
@@ -866,7 +866,7 @@ static int link_entry_into_array_plus_one(JournalFile *f,
else {
uint64_t i;
-i = le64toh(*idx) - 1;
+i = htole64(le64toh(*idx) - 1);
r = link_entry_into_array(f, first, i, p);
if (r 0)
return r;
--
1.7.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-journald: fix endianess bug
Le mercredi 29 février 2012 à 13:54 +0100, Frederic Crozat a écrit :
Le mercredi 29 février 2012 à 12:45 +0100, Dirk Eibach a écrit :
---
src/journal/journal-file.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 20ca3f6..275caea 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -238,7 +238,7 @@ static int journal_file_allocate(JournalFile *f,
uint64_t offset, uint64_t size)
if (fstat(f-fd, f-last_stat) 0)
return -errno;
-f-header-arena_size = new_size -
htole64(f-header-arena_offset);
+f-header-arena_size = htole64(new_size -
le64toh(f-header-arena_offset));
return 0;
}
I confirm this patch fixes journald not starting properly on ppc
architecture (got the report yesterday from folks in the office).
But it looks like systemd-journalctl is still broken on this arch.
So far, I think I found two different endianess errors in the code, but
more are pending, since I'm getting assertion when trying to access a
journal file created on x86 architecture, on a powerpc system (and now,
I get similar errors with journal created on ppc, so maybe only the
writing code need fixing ;).
Please review my current patch carefully, I'm not 100% sure my fix are
accurate (this part of journald is a bit tricky to get right ;)
--
Frederic Crozat fcro...@suse.com
SUSE
From 440c1612ff63932435b23e9ea99ba23f12d0d851 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 1 Mar 2012 18:00:01 +0100
Subject: [PATCH] journal: fix endianness error
---
src/journal/journal-file.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 275caea..fd8f23d 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -833,7 +833,7 @@ static int link_entry_into_array(JournalFile *f,
o-entry_array.items[i] = htole64(p);
if (ap == 0)
-*first = q;
+*first = htole64(q);
else {
r = journal_file_move_to_object(f, OBJECT_ENTRY_ARRAY, ap, o);
if (r 0)
@@ -866,7 +866,7 @@ static int link_entry_into_array_plus_one(JournalFile *f,
else {
uint64_t i;
-i = le64toh(*idx) - 1;
+i = htole64(le64toh(*idx) - 1);
r = link_entry_into_array(f, first, i, p);
if (r 0)
return r;
--
1.7.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-journald: fix endianess bug
Le mercredi 29 février 2012 à 12:45 +0100, Dirk Eibach a écrit : --- src/journal/journal-file.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c index 20ca3f6..275caea 100644 --- a/src/journal/journal-file.c +++ b/src/journal/journal-file.c @@ -238,7 +238,7 @@ static int journal_file_allocate(JournalFile *f, uint64_t offset, uint64_t size) if (fstat(f-fd, f-last_stat) 0) return -errno; -f-header-arena_size = new_size - htole64(f-header-arena_offset); +f-header-arena_size = htole64(new_size - le64toh(f-header-arena_offset)); return 0; } I confirm this patch fixes journald not starting properly on ppc architecture (got the report yesterday from folks in the office). But it looks like systemd-journalctl is still broken on this arch. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix sparse warnings
Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). -- Frederic Crozat fcro...@novell.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix sparse warnings
Le mercredi 29 février 2012 à 17:04 +, Frederic Crozat a écrit :
Hi,
while trying to use sparse to detect potential endianness errors in
journald code (apparently, we can't use it for that), I found some other
warnings with sparse.
Attached patch fixes those (mostly missing static call, 0 vs NULL and
macros redefinition).
Better with patch attached ;)
--
Frederic Crozat fcro...@suse.com
SUSE
From d07e3f17e21ad4b200d0e076e0f49a3f8e91fae9 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Wed, 29 Feb 2012 14:42:49 +0100
Subject: [PATCH] fix sparse warnings
---
src/getty-generator.c |2 +-
src/hashmap.c |4 ++--
src/log.c |4 ++--
src/macro.h |1 +
src/mount.c |2 +-
src/util.c|4 ++--
6 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/getty-generator.c b/src/getty-generator.c
index 1263785..7fac43a 100644
--- a/src/getty-generator.c
+++ b/src/getty-generator.c
@@ -28,7 +28,7 @@
#include unit-name.h
#include virt.h
-const char *arg_dest = /tmp;
+static const char *arg_dest = /tmp;
static int add_symlink(const char *fservice, const char *tservice) {
char *from = NULL, *to = NULL;
diff --git a/src/hashmap.c b/src/hashmap.c
index 7ef8097..6928118 100644
--- a/src/hashmap.c
+++ b/src/hashmap.c
@@ -55,10 +55,10 @@ struct pool {
unsigned n_used;
};
-struct pool *first_hashmap_pool = NULL;
+static struct pool *first_hashmap_pool = NULL;
static void *first_hashmap_tile = NULL;
-struct pool *first_entry_pool = NULL;
+static struct pool *first_entry_pool = NULL;
static void *first_entry_tile = NULL;
static void* allocate_tile(struct pool **first_pool, void **first_tile, size_t tile_size) {
diff --git a/src/log.c b/src/log.c
index c37ab22..e1f511c 100644
--- a/src/log.c
+++ b/src/log.c
@@ -625,11 +625,11 @@ _noreturn_ static void log_assert(const char *text, const char *file, int line,
}
#pragma GCC diagnostic pop
-void log_assert_failed(const char *text, const char *file, int line, const char *func) {
+_noreturn_ void log_assert_failed(const char *text, const char *file, int line, const char *func) {
log_assert(text, file, line, func, Assertion '%s' failed at %s:%u, function %s(). Aborting.);
}
-void log_assert_failed_unreachable(const char *text, const char *file, int line, const char *func) {
+_noreturn_ void log_assert_failed_unreachable(const char *text, const char *file, int line, const char *func) {
log_assert(text, file, line, func, Code should not be reached '%s' at %s:%u, function %s(). Aborting.);
}
diff --git a/src/macro.h b/src/macro.h
index 58de001..19f259e 100644
--- a/src/macro.h
+++ b/src/macro.h
@@ -23,6 +23,7 @@
***/
#include assert.h
+#include sys/param.h
#include sys/types.h
#include sys/uio.h
#include inttypes.h
diff --git a/src/mount.c b/src/mount.c
index 0ae964b..f80fcf5 100644
--- a/src/mount.c
+++ b/src/mount.c
@@ -271,7 +271,7 @@ static char* mount_test_option(const char *haystack, const char *needle) {
* struct mntent */
if (!haystack)
-return false;
+return NULL;
zero(me);
me.mnt_opts = (char*) haystack;
diff --git a/src/util.c b/src/util.c
index e9869ea..bf22f57 100644
--- a/src/util.c
+++ b/src/util.c
@@ -892,7 +892,7 @@ int load_env_file(
char ***rl) {
FILE *f;
-char **m = 0;
+char **m = NULL;
int r;
assert(fname);
@@ -4177,7 +4177,7 @@ int wait_for_terminate_and_warn(const char *name, pid_t pid) {
}
-void freeze(void) {
+_noreturn_ void freeze(void) {
/* Make sure nobody waits for us on a socket anymore */
close_all_fds(NULL, 0);
--
1.7.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Has anyone written equiv of ck-xinit-session for logind?
Le mardi 28 février 2012 à 00:52 +, Colin Guthrie a écrit : Hi, I'm getting bug reports about startx not registering user sessions under systemd. With console-kit, ck-xinit-session did the job and I was hoping someone (Fred - maybe you've done it on SuSE?) had written the equiv for logind? openSUSE no longer supports starting X when not using a DM, sorry ;) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] BindTo not working as expected with .target ?
Hi all, I'm trying to get a .target working as a trigger one action then go back to not activated state and despite Lennart help on IRC, it keeps failing, so it might indicate a bug : foobar.target : [Unit] Description=my trigger target BindTo=myaction.service myaction.service: [Unit] Description=my action [Service] ExecStart=/bin/true Type=oneshot RemainAfterExit=false when starting foobar.target, myaction.service is correctly started, then service terminates, is no longer active, but foobar.target is still seen as active. BTW, it could be interesting to allow foobar.target.bindto symlink to be created, so we wouldn't have to modify system targets (for instance, sigpwr.target ;) to add BindTo dependencies. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
Le samedi 07 janvier 2012 à 00:21 +0100, Lennart Poettering a écrit : On Fri, 06.01.12 23:17, Jan Engelhardt (jeng...@medozas.de) wrote: Where does /dev/console point to? i.e. what is the contents of /sys/class/tty/console/active if you do that? Sorry, I was unclear. On Xen, you can login on a text terminal. When doing that, /sys/class/tty/console/active outputs : tty-1 tty0 Hmm? So it claims tty0 in that file, bug actually no /dev/tty0 device exists? That souinds like a kernel bug to me. 1. xencons=hvc (the modern variant) creates: /dev/hvc0 implied defaults: console=hvc0 sysfs/active: tty0 hvc0 Judging by this the implied default is actually console=tty0 console=hvc0. /dev/tty0..63 exist. 2. xencons=xvc creates: /dev/xvc0 implied defaults: console=tty0 (!) sysfs/active: xvc-1 tty0 (bug?) /dev/tty0..63 exist. Judging by this the implied default is actually console=xvc-1 console=tty0. I do wonder where the -1 comes from, is there an actual device called /dev/xvc-1? 3. xencons=tty creates: nothing new implied defaults: console=tty1 sysfs/active: tty-1 tty0 (bug) /dev/tty1..63 exist (!), no tty0. Judging by this the implied default is actually console=tty-1 console=tty0. What's this supposed to mean anyway? That Xen emulates a traditional VC of some kind? It's doing a very bad job in that if /dev/tty0 isn't there... And what is tty-1 supposed to be? Is there an actual device called /dev/tty-1? 4. xencons=ttyS creates: /dev/ttyS0 implied defaults: console=tty0 sysfs/active: ttyS-1 tty0 (bug...) /dev/tty0..63 exist. Judging by this the implied default is actually console=ttyS-1 console=tty0. Thinking a bit about this my guess is Xen stores -1 as a number for the device somewhere and the code that formats the active string is a bit confused about that. While it probably means that no such console is configured the kernel just formats it as-is. Kay, you wrote that code, say something! And the 3rd setup apparently shows an additional bug. Both these issues are clearly kernel bugs, and should be fixed in the kernel. Somebody who cares about this should file bugs against the kernel. I'll ask our Xen folks if they can have a look at it. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
Le mardi 03 janvier 2012 à 21:52 +0100, Lennart Poettering a écrit : On Tue, 03.01.12 21:35, Lennart Poettering (lenn...@poettering.net) wrote: currently, logind was enforcing the presence of /dev/tty0 to start properly. This device is not present on Xen (when using xencons=tty) or S/390. Here is a regenerated version against master, since logind was moved to its own directory. Thanks for rebasing the patch! I fear the patch is not complete though. seat_read_active_vt() in login/logind-seat.c needs to guard against the invalid fd in s-manager-console_active_fd. Also, I assume that if /dev/tty0 doesn't exist /dev/tty1, /dev/tty2 and so on don't exist either. That means calls like seat_preallocate_vts() need to be shortcut in this case, too. logind currently implicitly and always creates a seat0, that exists unconditionally, and that all hw that isn't assigned to anything else belongs to. That notion is probably nothing we could or should get rid off that easily, but that means that we need to make sure that a couple of its operations become NOPs on the systems in question. Besides seat_preallocate_vts() that's seat_read_active_vt() and the whole logic that watches VCSA devices (which should be shortcut, as if n_autovts was 0, in manager_connect_udev()). I have now commited a patch which reworks a lot of the logic there and tries to handle the no-VT case as gracefully as possible. We still implicitly create seat0, but we now stop advertising that it was multi-session capable. Hence we still end up with a seat, but only with the minimal properties that we need. This makes most of the other explicit checks unnecessary fortunately. Hmm, I've tested this patch (I'm extracted the patche you did for it and applied to our v37 package, thanks to git ;) and from what I see, console login doesn't get any seat attached (but other login, like over ssh are getting one), unlike my initial patch. So more work is needed somehow. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. Of course, it would be best to have also confirmation from Michal ;) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Le vendredi 06 janvier 2012 à 17:17 +0100, Thomas Meyer a écrit : Zitat von Frederic Crozat fcro...@suse.com: Le vendredi 23 décembre 2011 à 01:47 +0100, Tom Gundersen a écrit : Rather than ordering systemd-random-seed-load.service after local-fs.target, start it by path-activation. We need write access to the seed, so we order the path unit after remount-rootfs.service (in case /var is on the root fs). A better solution might be to introduce PathIsWritable=, but that is not necessary in order to solve the problem, and I don't know of any other usecases for it. I've just tested your patch and it works fine ; I quickly tested with / being read-only and mounted writable by systemd and not initrd (which is the default for openSUSE) and it worked fine too. I wonder what will happen with this patch if /var/lib/random-seed is missing at startup! timeout? Good question. I'd say it will wait forever for it to appear. Maybe we should ensure this file is create in systemd installation ? -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix logind on xen
Le vendredi 06 janvier 2012 à 18:16 +0100, Lennart Poettering a écrit : On Fri, 06.01.12 14:59, Frederic Crozat (fcro...@suse.com) wrote: Le mardi 03 janvier 2012 à 21:52 +0100, Lennart Poettering a écrit : On Tue, 03.01.12 21:35, Lennart Poettering (lenn...@poettering.net) wrote: currently, logind was enforcing the presence of /dev/tty0 to start properly. This device is not present on Xen (when using xencons=tty) or S/390. Here is a regenerated version against master, since logind was moved to its own directory. Thanks for rebasing the patch! I fear the patch is not complete though. seat_read_active_vt() in login/logind-seat.c needs to guard against the invalid fd in s-manager-console_active_fd. Also, I assume that if /dev/tty0 doesn't exist /dev/tty1, /dev/tty2 and so on don't exist either. That means calls like seat_preallocate_vts() need to be shortcut in this case, too. logind currently implicitly and always creates a seat0, that exists unconditionally, and that all hw that isn't assigned to anything else belongs to. That notion is probably nothing we could or should get rid off that easily, but that means that we need to make sure that a couple of its operations become NOPs on the systems in question. Besides seat_preallocate_vts() that's seat_read_active_vt() and the whole logic that watches VCSA devices (which should be shortcut, as if n_autovts was 0, in manager_connect_udev()). I have now commited a patch which reworks a lot of the logic there and tries to handle the no-VT case as gracefully as possible. We still implicitly create seat0, but we now stop advertising that it was multi-session capable. Hence we still end up with a seat, but only with the minimal properties that we need. This makes most of the other explicit checks unnecessary fortunately. Hmm, I've tested this patch (I'm extracted the patche you did for it and applied to our v37 package, thanks to git ;) and from what I see, console login doesn't get any seat attached (but other login, like over ssh are getting one), unlike my initial patch. So more work is needed somehow. console logins? What exactly is that? Logins on /dev/console? Where does /dev/console point to? i.e. what is the contents of /sys/class/tty/console/active if you do that? Sorry, I was unclear. On Xen, you can login on a text terminal. When doing that, /sys/class/tty/console/active outputs : tty-1 tty0 With your patch, no session is assigned to this particular login. Note that we consider serial logins much like ssh logins as virtual, i.e. not physical, and hence with no seat assigned. Wrong choice of word on my side, I was meaning : ssh login are seen as sessions without seats in systemd-loginctl. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: fix logind on xen
Hi,
currently, logind was enforcing the presence of /dev/tty0 to start
properly. This device is not present on Xen (when using xencons=tty) or
S/390.
Attached patch fixes this issue.
--
Frederic Crozat fcro...@suse.com
SUSE
From b40e075944c72a3fc45796c1d059673cef7c7db8 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Mon, 19 Dec 2011 17:17:09 +0100
Subject: [PATCH] logind: do not abort if /dev/tty0 doesn't exist
Xen or S/390 might not have /dev/tty0, logind should cope with it.
---
src/logind.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/logind.c b/src/logind.c
index 4633a5e..f491cee 100644
--- a/src/logind.c
+++ b/src/logind.c
@@ -906,6 +906,8 @@ static int manager_connect_console(Manager *m) {
m-console_active_fd = open(/sys/class/tty/tty0/active, O_RDONLY|O_NOCTTY|O_CLOEXEC);
if (m-console_active_fd 0) {
+if (errno == ENOENT)
+ return 0;
log_error(Failed to open /sys/class/tty/tty0/active: %m);
return -errno;
}
--
1.7.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch: fix generator for cryptoloop
Le jeudi 15 décembre 2011 à 16:57 +0100, Lennart Poettering a écrit :
On Thu, 15.12.11 16:21, Frederic Crozat (fcro...@suse.com) wrote:
Le jeudi 15 décembre 2011 à 16:11 +0100, Lennart Poettering a écrit :
On Thu, 08.12.11 13:55, Frederic Crozat (fcro...@suse.com) wrote:
Hi,
when cryptoloop files are present in /etc/crypttab, systemd is not
correctly creating dependencies for mounting them. Attached patch fixes
this issue.
Hmm, cryptoloop? Isn't this kinda obsolete? Can't dm-crypt handle those
two in compat mode? Can you elaborate on what cryptoloop precisely does
here differently than dm-crypt, and why we want to support this? (Sorry,
I am simply not up-to-date on cryptoloop, and would like to be brought
up to speed, on what this is...)
Sorry, I incorrectly wrote cryptoloop, while talking about file-based
cryptsetup (ie dm-crypt). So, it is not about an obsolete thing :)
Oh, that makes a lot more sense then. May I ask you to repost the patch
with a correct commit text?
Here it is:
--
Frederic Crozat fcro...@suse.com
SUSE
From 652c2db8bb47c7fef243406e2be22aa4efcd3c0e Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 8 Dec 2011 13:51:17 +0100
Subject: [PATCH] cryptsetup-generator: correctly create unit for encrypted
file
Ensure unit created for encrypted file is a path unit and not a device
one.
---
src/cryptsetup-generator.c | 51 +++
1 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/src/cryptsetup-generator.c b/src/cryptsetup-generator.c
index a48b7a4..0cae431 100644
--- a/src/cryptsetup-generator.c
+++ b/src/cryptsetup-generator.c
@@ -64,7 +64,7 @@ static int create_disk(
const char *password,
const char *options) {
-char *p = NULL, *n = NULL, *d = NULL, *u = NULL, *from = NULL, *to = NULL, *e = NULL;
+char *p = NULL, *n = NULL, *d = NULL, *u = NULL, *from = NULL, *to = NULL, *e = NULL, *path_file = NULL;
int r;
FILE *f = NULL;
bool noauto, nofail;
@@ -93,10 +93,50 @@ static int create_disk(
goto fail;
}
-if (!(d = unit_name_from_path(u, .device))) {
-r = -ENOMEM;
-log_error(Failed to allocate device name.);
-goto fail;
+if (!startswith(device,/dev/)) {
+
+if (!(d = unit_name_build_escape(cryptsetup, name, .path))) {
+r = -ENOMEM;
+log_error(Failed to allocate path name.);
+goto fail;
+}
+
+if (asprintf(path_file, %s/%s, arg_dest, d) 0) {
+r = -ENOMEM;
+log_error(Failed to allocate unit file name.);
+goto fail;
+}
+
+if (!(f = fopen(path_file, wxe))) {
+r = -errno;
+log_error(Failed to create unit file: %m);
+goto fail;
+}
+
+fprintf(f,
+[Unit]\n
+Description=Cryptography Setup for %s\n
+DefaultDependencies=no\n
+[Path]\n
+PathExists=%s\n,
+device, device);
+
+fflush(f);
+
+if (ferror(f)) {
+r = -errno;
+log_error(Failed to write file: %m);
+goto fail;
+}
+
+f = NULL;
+} else {
+
+if (!(d = unit_name_from_path(u, .device))) {
+r = -ENOMEM;
+log_error(Failed to allocate device name.);
+goto fail;
+}
}
if (!(f = fopen(p, wxe))) {
@@ -222,6 +262,7 @@ fail:
free(n);
free(d);
free(e);
+free(path_file);
free(from);
free(to);
--
1.7.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Patch: fix generator for cryptoloop
Hi,
when cryptoloop files are present in /etc/crypttab, systemd is not
correctly creating dependencies for mounting them. Attached patch fixes
this issue.
--
Frederic Crozat fcro...@suse.com
SUSE
From 96e7b52ed48e423a62a50677a678d59129a65453 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 8 Dec 2011 13:51:17 +0100
Subject: [PATCH] cryptsetup-generator: correctly create unit for cryptoloop
Ensure unit created for cryptoloop is path unit and not a device one.
---
src/cryptsetup-generator.c | 51 +++
1 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/src/cryptsetup-generator.c b/src/cryptsetup-generator.c
index a48b7a4..0cae431 100644
--- a/src/cryptsetup-generator.c
+++ b/src/cryptsetup-generator.c
@@ -64,7 +64,7 @@ static int create_disk(
const char *password,
const char *options) {
-char *p = NULL, *n = NULL, *d = NULL, *u = NULL, *from = NULL, *to = NULL, *e = NULL;
+char *p = NULL, *n = NULL, *d = NULL, *u = NULL, *from = NULL, *to = NULL, *e = NULL, *path_file = NULL;
int r;
FILE *f = NULL;
bool noauto, nofail;
@@ -93,10 +93,50 @@ static int create_disk(
goto fail;
}
-if (!(d = unit_name_from_path(u, .device))) {
-r = -ENOMEM;
-log_error(Failed to allocate device name.);
-goto fail;
+if (!startswith(device,/dev/)) {
+
+if (!(d = unit_name_build_escape(cryptsetup, name, .path))) {
+r = -ENOMEM;
+log_error(Failed to allocate path name.);
+goto fail;
+}
+
+if (asprintf(path_file, %s/%s, arg_dest, d) 0) {
+r = -ENOMEM;
+log_error(Failed to allocate unit file name.);
+goto fail;
+}
+
+if (!(f = fopen(path_file, wxe))) {
+r = -errno;
+log_error(Failed to create unit file: %m);
+goto fail;
+}
+
+fprintf(f,
+[Unit]\n
+Description=Cryptography Setup for %s\n
+DefaultDependencies=no\n
+[Path]\n
+PathExists=%s\n,
+device, device);
+
+fflush(f);
+
+if (ferror(f)) {
+r = -errno;
+log_error(Failed to write file: %m);
+goto fail;
+}
+
+f = NULL;
+} else {
+
+if (!(d = unit_name_from_path(u, .device))) {
+r = -ENOMEM;
+log_error(Failed to allocate device name.);
+goto fail;
+}
}
if (!(f = fopen(p, wxe))) {
@@ -222,6 +262,7 @@ fail:
free(n);
free(d);
free(e);
+free(path_file);
free(from);
free(to);
--
1.7.7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Understanding systemd-analyze's plots
Le samedi 26 novembre 2011 à 22:52 +0100, Stefan Majewsky a écrit : Hi, my openSUSE 12.1 system boots in about 30 seconds, and I wanted to cut that time down a bit, so I took a look at systemd-analyze's blame and plot output. But I do not really know how to interpret the results which I see in the plot [1]. The startup sequence takes 20.5 seconds in userspace, of which only the last 3 seconds seem to be spent on what I consider the interesting stuff: starting all sorts of services and finally bringing up KDM. The rest of the time seems to be spent activating the hardware, various mounts and udev. (According to the LED on my notebook's case, the disk is busy all the time.) To put my confusion into questions: 1. Why does the system need 6 seconds (from t=6.3s to t=12.3s on the plot) to activate some tmpfs mounts? 2. Why is localnet.service activating for a whole 7 seconds? I looked into it, it's only a SysV init script that sets hostname and domainname from the config in /etc, yet it's number 1 in systemd-analyze blame. 3. Why does it look like about nothing happens between t=13s and t=22s? It might be that openSUSE's unit files (or SysV leftovers) are not yet optimized for the early boot: For example, I seem to have saved some seconds by masking lvm.service (I don't use LVM at all). But that won't explain why systemd is actually slower on this stage of boot vs. the old SysV init some distro versions ago. Can someone enlighten me? Some comments regarding your numbers, since they might be caused by tradeoffs I had to put in openSUSE systemd package : - if you don't use cryptsetup (encrypted partition), you should run systemctl mask storage-after-cryptsetup.service, it should remove the lvm.service reload after cryptsetup.target is reached - if you don't use lvm, systemctl mask lvm.service might help too - localnet.service is still doing too much work, because part of its work is already done by systemd but I didn't had time to move the nisdomain part out of /etc/init.d/boot.localnet to a separate script (or .service). -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] random-seed: break ordering cycle with encrypted tmp partitions
Le mardi 15 novembre 2011 à 19:20 +1100, Tom Gundersen a écrit : The cycle is caused by our ordering is to coarse. We order random-seed-load after all filesystems, but all we really care about is /var/lib being mounted rw. Waiting for all filesystems means that we would also have to wait for /tmp, which might depend on random-seed-load. Maybe the best way to solve this would have been to allow .path units to not only wait for a path, but also wait for it to have a specific permission. However, since we cannot do that at the moment, this should do the trick for now: We would like to wait for var.mount if /var is on a separate partition, and we'd like to wait for remount-rootfs.service otherwise. I couldn't figure out how to do this conditionally, so we unconditionally wait for both. I did a different fix for openSUSE 12.1 (a bit dirty) where cryptsetup creates a systemd-random-seed-load.service unit in /run (or in /etc I'm not 100% sure), depending if tmp is encrypted or not. Patch is included in another patch to fix lvm on top of cryptsetup (see https://build.opensuse.org/package/view_file?file=storage-after-cryptsetup.patchpackage=systemdproject=home%3Afcrozat%3Asystemdrev=f050db3b3513798555eaca39d76e4a16 and yes, it is ugly ;) I think your option of adding var.mount will cause systemd to complain when /var is not a separate partition.. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] PATCH: do not run fsck on tmpfs mountpoint
You really don't want to fsck a tmpfs, even if passno is non-null (it
was causing many issue, forcing system to go to emergency).
--
Frederic Crozat fcro...@suse.com
SUSE
From cca125c2758b48ba8f1afdc4b5751b104f0bd809 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 27 Oct 2011 15:36:57 +0200
Subject: [PATCH] mount: do not try to fsck tmpfs mountpoint with non-null
passno.
---
src/mount.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mount.c b/src/mount.c
index ef953f0..5da4047 100644
--- a/src/mount.c
+++ b/src/mount.c
@@ -434,6 +434,7 @@ static int mount_add_device_links(Mount *m) {
if (p-passno 0
!mount_is_bind(p)
+!streq(p-fstype,tmpfs)
UNIT(m)-meta.manager-running_as == MANAGER_SYSTEM
!path_equal(m-where, /)) {
char *name;
--
1.7.7
___
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 fcro...@suse.com SUSE ___ 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 bonz...@gnu.org 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 fcro...@suse.com 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 fcro...@suse.com
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 21
|| : \
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 21
|| : \
fi
\
/bin/systemctl daemon-reload /dev/null 21 || :
\
/bin/systemctl preset %{?*} /dev/null 21 || :
\
%{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 21 || :
\
/bin/systemctl stop %{?*} /dev/null 21 || :
\
fi
\
%{nil}
# On uninstall, tell systemd to reload
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 fcro...@suse.com 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 fcro...@suse.com SUSE From 1cf32c016f97b2c99d7df06ce5d5b858f86c507a Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com 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 fcro...@suse.com
SUSE
From 3d2d9f22aecb1e1631bd51bc6252bf8813506af5 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
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] 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 fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
