Re: [systemd-devel] How to set complex environment for apache?
On Wed, 23.05.12 16:45, Joachim Banzhaf (joachim.banz...@googlemail.com) wrote: > Am 22.05.2012 22:51, schrieb Zbigniew Jędrzejewski-Szmek: > > On 05/22/2012 10:46 PM, Joachim Banzhaf wrote: > >> It sets and modifies environment variables. I'll have a look and try, > > See also Environment= and EnvironmentFile= in systemd.exec(5). > > > > Zbyszek > > I tried now. Not sure if the result is optimal, but it might still help > others with a similar problem. > > The DB2 provided profile script (for now) only sets and changes > environment variables (PATH, LD_LIBRARY_PATH, CLASSPATH, DB2INSTANCE), > with some if/else logic based on what product options are installed or not. > > I cannot use the script as is in ExecStartPre because this only allows > binaries. > I even tried /bin/bash script, but as expected the changed environment > is not inherited by ExecStart > > So the only systemd options (I know of now) left are Environment and > EnvironmentFile. > I went with EnvironmentFile, because that is what I used before. I just > added the variables by hand instead of by sourcing the db2profile > script. This worked (I had to export the variables to make it backward > compatible with SysV init though). > > If I'd use this approach with systemd and DB2 I'd have to manually > analyze changes in the db2profile and try to mimic that with every > fixpack or special build delivered by IBM. Too error prone, not acceptable. > > Finally I tried this, and it worked. But I am not sure about side effects: > > I changed >ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start' > to >ExecStart=/bin/bash -c '. /home/db2inst1/sqllib/db2profile; > /usr/sbin/start_apache2 -D SYSTEMD -k start' > > > Thanks for you support! This solution is pretty much what I'd recommend too. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Wed, 23.05.12 12:10, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: > >> One suggestion at IRC was to just keep systemd mount units. But if we > >> should go this route, then we should call to deprecate /etc/fstab. > >> Last time we discussed about it, people said it was not going to > >> happen since some tools were parsing and relying on it. Whats is the > >> way to go? > > > > We don't really deprecate it. But if people want to they don't have to > > use it now, and can do this easily by dropping the file and removing the > > generator. > > > > You know, fewer PIDs are definitely a good thing, but for some things > > doing them out-of-process is actually a good thing. Unix knows processes > > and process isolation for a reason. > > In this case I'm still more for having the fstab parser bultin, > however I understand your point. > > In my usage I'll just drop fstab and see what happens. For sure simple > "mount /mountpoint" will not work anymore, then I wonder if there is > any plan to provide systemd-mount to be linked as /bin/mount in order > to get the mount description (device, point, options) from systemd > mount units instead of fstab. We have that already. It has a slightly different syntax though: systemctl start mountpoint.mount Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OT: Races with GDM3 and accountsservice
Am Dienstag, den 22.05.2012, 23:48 +0200 schrieb Paul Menzel: > Am Dienstag, den 22.05.2012, 18:41 +0200 schrieb Michael Biebl: > > 2012/5/22 Paul Menzel : > > > 2. GDM 3 did not list the available users though, which had to be > > > entered manually. After logging out again users are displayed fine. > > > > The user list is populated via accountsservice. > > A D-Bus activated system service. accounts-daemon.service shows up in > > your list above. So I'm wondering if there is genuine bug / race in > > the way gdm interacts with accountsdaemon. > > It looks like a race. The next two system starts the user list was > correctly populated and now it is not populated again. After the third boot it worked too, but after the fourth it failed again. I do not know where to look for causes for this problem. I just found the following. # less /var/log/gdm3/\:0-greeter.log gnome-session[951]: WARNING: Failed to start app: Unable to start application: Kindprozess »gnome-power-manager« konnte nicht ausgeführt werden (Datei oder Verzeichnis nicht gefunden) Gtk-Message: Failed to load module "atk-bridge" gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook gdm-simple-greeter[1138]: Gtk-WARNING: Overriding tab label for notebook gdm-simple-greeter[1138]: Gtk-WARNING: /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtkwidget.c:7117: widget not within a GtkWindow gdm-simple-greeter[1138]: Gtk-CRITICAL: gtk_widget_get_preferred_height_for_width: assertion `width >= 0' failed gdm-simple-greeter[1138]: Gtk-CRITICAL: gtk_widget_get_preferred_height_for_width: assertion `width >= 0' failed gdm-simple-greeter[1138]: Gtk-WARNING: gtk_widget_size_allocate(): attempt to allocate widget with width -47 and height -47 Warnung der Fensterverwaltung:Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x107 (Anmeldefen) Warnung der Fensterverwaltung:meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemctl: check the argument to -t for invalid values
Systemctl accepted anything as the argument for -t, and simply said '0
units found'. It is better to catch this user error early.
---
A small thing thing I noticed today.
src/systemctl/systemctl.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 66f4113..d353071 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4325,6 +4325,19 @@ static int runlevel_help(void) {
return 0;
}
+static int arg_type_ok(const char *type) {
+
+static const char *types[] = {"service", "socket", "device", "mount",
+ "swap", "automount", "target", "path",
+ "timer", "snapshot"};
+unsigned i;
+
+for (i=0; ihttp://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a general inittab entry replacement available?
Am 22.05.2012 21:42, schrieb Tomasz Torcz: > On Tue, May 22, 2012 at 09:27:34PM +0200, Joachim Banzhaf wrote: >> As it happens I also like IBM DB2 a lot (for other reasons). >> DB2 is closed source (I hope you dont stop reading now) and it installs >> an inittab entry. >> >> fmc:2345:respawn:/opt/ibm/db2/V10.1/bin/db2fmcd #DB2 Fault Monitor >> Coordinator >> >> You know that this does no longer work. >> >> Inittab is a very old, very widely spread concept so I have hope you >> even have thought about porting something like this in a generic way >> already and I just failed to find it? > inittab is not used on general Linux for few years already. Most distros > switched to upstart some time ago, upstart isn't parsing inittab (except > for default runlevel). > > The line you provided translates to following systemd unit: > /etc/systemd/system/fmc.service > --- > [Unit] > Description=DB2 Fault Monitor Coordinator > > [Service] > ExecStart=/opt/ibm/db2/V10.1/bin/db2fmcd > Restart=always > > [Install] > WantedBy=multi-user.target > --- > > It simple, but let me describe it: > > "fmc" becomes service name - fmc.service > > "2345" is not directly mappable. There are no runlevels with systemd. > > multi-user.target is roughly equivalent of all system services started. > If your inittab had "1" here (single user), you would want > WantedBy=rescue.target > in [Install] session. Please see "man systemd.special" for description of > other targets. > > "respawn" becomes Restart=always > > The command itself lands in ExecStart=; because this command do not daemonize > (requisite for being in inittab), you can skip Type= declaration. It will > default to simple. > > You can put comment in Description field. > > You are now only "systemctl enable fmc.service" away of emulating inittab. > > Above unit definition is really simple but fully replaces inittab entry. > However, please look at man pages of systemd.exec and systemd.service. You > will > find many way to augment this unit (various limits, chroot, running as > specific > user, group etc). It works now. Only difference: I had to add this to [Unit] section: After=remote-fs.target Before=apache2.service Without it, the fmc was started but never became operational. Don't know why. I assume inittab entries are started sequentially, which in my case would mean: fmc last. That's why I chose one of the last targets in my dependency list (I love systemd-analyze plot) and why it worked with SysV init. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Wed, May 23, 2012 at 8:51 AM, Lennart Poettering wrote: > On Tue, 22.05.12 18:13, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) > wrote: > >> >> On Tue, May 22, 2012 at 3:03 PM, Lennart Poettering >> wrote: >> > Heya, >> > >> > just a quick heads-up. I just commited to git some work that rips out >> > the fstab parsing from PID 1 and places this in a generator instead. The >> > idea is that sooner or later we only parse native unit files from PID 1, >> > and everything else is transformed as needed with generators. This makes >> > the core a bit smaller and simplifies a lot of things. >> > >> > This is quite a substantial change, and hence I am not sure I got it all >> > right. I am writing this mail for two reasons: to warn you that current >> > git might break your boot more likely then usually, and secondly: please >> > test this, especially if you have a more complex setup with nofail, >> > noauto and x-systemd.automount in the mix! >> >> Lennart, Kay: I hate you damn it! :-D >> >> Man, how can a fstab file be so complex to justify it? It's simpler >> than the service files we already load. Now to simply parse /etc/fstab >> we need to call a generator, that parses (was being done already), >> generates a new file, that triggers inotify, that calls systemd, that >> parses it again. Ouch, that's cumbersome at least, slow at last! > > Well, as Kay is pointed out this paragraph makes little sense. > > That said I can give you a number of reasons why it actually might be > faster this way: > > - The generators are all executed in parallel, and hence allow a level > of parallelization we didn't have before > - fstab mount units are now subject to the same kind of lazy loading we > have for all other units hence otpimizing resource usages > - People who don't need fstab (embedded and containers) can leave the > generator out entirely and thus save time and resources > - if you feel like it you can even run the generator offline and use the > generator unit files for all next boots, to speed up things for > certain embedded use cases. > > The summary of this is probably: without proper profiling claiming that > things slow down stuff is non-sense. Sure, I previously assumed that the systemd would be notified somehow about the unit, but he explained that the generators run before systemd actually check for units. Will try to remember this for the next time ;-) >> One suggestion at IRC was to just keep systemd mount units. But if we >> should go this route, then we should call to deprecate /etc/fstab. >> Last time we discussed about it, people said it was not going to >> happen since some tools were parsing and relying on it. Whats is the >> way to go? > > We don't really deprecate it. But if people want to they don't have to > use it now, and can do this easily by dropping the file and removing the > generator. > > You know, fewer PIDs are definitely a good thing, but for some things > doing them out-of-process is actually a good thing. Unix knows processes > and process isolation for a reason. In this case I'm still more for having the fstab parser bultin, however I understand your point. In my usage I'll just drop fstab and see what happens. For sure simple "mount /mountpoint" will not work anymore, then I wonder if there is any plan to provide systemd-mount to be linked as /bin/mount in order to get the mount description (device, point, options) from systemd mount units instead of fstab. > They come at a price but that > doesn't mean you should avoid them at all cost. Agreed. The best part is that in this case we can avoid the extra pid easily, systemd rocks :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to set complex environment for apache?
Am 22.05.2012 22:51, schrieb Zbigniew Jędrzejewski-Szmek: > On 05/22/2012 10:46 PM, Joachim Banzhaf wrote: >> It sets and modifies environment variables. I'll have a look and try, > See also Environment= and EnvironmentFile= in systemd.exec(5). > > Zbyszek I tried now. Not sure if the result is optimal, but it might still help others with a similar problem. The DB2 provided profile script (for now) only sets and changes environment variables (PATH, LD_LIBRARY_PATH, CLASSPATH, DB2INSTANCE), with some if/else logic based on what product options are installed or not. I cannot use the script as is in ExecStartPre because this only allows binaries. I even tried /bin/bash script, but as expected the changed environment is not inherited by ExecStart So the only systemd options (I know of now) left are Environment and EnvironmentFile. I went with EnvironmentFile, because that is what I used before. I just added the variables by hand instead of by sourcing the db2profile script. This worked (I had to export the variables to make it backward compatible with SysV init though). If I'd use this approach with systemd and DB2 I'd have to manually analyze changes in the db2profile and try to mimic that with every fixpack or special build delivered by IBM. Too error prone, not acceptable. Finally I tried this, and it worked. But I am not sure about side effects: I changed ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start' to ExecStart=/bin/bash -c '. /home/db2inst1/sqllib/db2profile; /usr/sbin/start_apache2 -D SYSTEMD -k start' Thanks for you support! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] confusing output with a swap device missing
Hi, I booted a system after (inadvertently) changing the UUID of a swap device. This causes the .swap unit to time-out, and since swap.target wants the .swap unit, this makes the whole boot very slow. Unfortunately, understanding what is the cause of the timeout is not trivial, unless one knows what to look for. $ journalctl -a |grep Startup May 23 15:44:31 fedora-15 systemd[1]: Startup finished in 740ms 270us (kernel) + 1s 934ms 75us (initrd) + 1min 33s 387ms 780us (userspace) = 1min 36s 62ms 125us. $ systemd-analyze blame 2746ms network.service 355ms udev-settle.service ... (nothing here) $ systemctl status swap.target swap.target - Swap Loaded: loaded (/usr/lib/systemd/system/swap.target; static) Active: active since Wed, 23 May 2012 15:44:28 +0200; 34min ago (Completely misleading -- no swap devices were activated...) $ systemctl --failed ... (nothing interesting here) $ systemctl --failed --all ... (nothing interesting here) $ systemd-analyze plot Here one can see that swap.target is the first thing which is active a long delay. $ systemctl show swap.target ... Wants=dev-disk-by\x2duuid-xx.swap $ systemctl status dev-disk-by\x2duuid-xx.swap ... Active: inactive (dead) (OK, now it becomes obvious... but such information should be more visible.) $ journalctl ... May 23 15:42:59 fedora-15 systemd-tmpfile[519]: Successfully loaded SELinux database in 21ms 628us, size on heap is 536K. May 23 15:44:28 fedora-15 systemd[1]: Job dev-disk-by\x2duuid-xx.device/start timed out. May 23 15:44:28 fedora-15 systemd[1]: Job dev-disk-by\x2duuid-xx.swap/start failed with result 'dependency'. May 23 15:44:28 fedora-15 systemd[1]: Job dev-disk-by\x2duuid-xx.device/start failed with result 'timeout'. It would be really nice if this information which is buried in the logs could be displayed more prominently when one uses other diagnostic tools. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind: session management
Hi Lennart On Mon, May 21, 2012 at 10:18 PM, Lennart Poettering wrote: > On Wed, 16.05.12 16:01, David Herrmann (dh.herrm...@googlemail.com) wrote: [..snip..] >> 3) The idea behind kmscon is to set CONFIG_VT=n (for several different >> reasons but mainly to avoid having UI code in the kernel). Does >> systemd provide a simple way to replace the VT-switching logic? My >> idea was using sd_login_monitor to watch for session changes. If it >> changes, I check with sd_session_is_active() whether my session is >> still active. If not, I stop using the drm, input, etc. devices and >> for instance an xserver can show up. If the user switches to kmscon >> again, I am notified via the sd_login_monitor and >> sd_session_is_active() will be true again and I can start showing up >> again. The interface for switching "VTs"/sessions would then be some >> kind of "sd_activate_session" dbus/library call. >> However, looking at logind sources it seems the "active" logic is >> tightly bound to VTs. I would start working on implementing this, >> however, I'd like to get some review on the idea before I spend too >> much time in it. > > It shouldn't be too hard to beef this up in logind. So far indeed only > kernel VTs are supported. > > I expect that doing the VT switching fully async won't be too much fun. > > If you implement VTs in userspace I'd avoid all the complexity of kernel > VTs with the preallocated VTs and fixed device mappings. > > Honstely I am not entirely sure how virtualized VTs should exactly > work. I have one suspicion though: if we do this we probably should do > this based on a Wayland system compositor. The wayland folks are > planning to have one anyway, and it should probable be the code that > does VT switching. Also, there's a good chance that a minimal wayland > compositor for systems without opengl is doable. There is a software OpenGL/EGL backend based on fbdev. It is pretty easy to make wayland use it. There is even ongoing work to make wayland work without the mesa GL stack and use pixmap etc. for the compositing. Anyway, I'd like to see vt-switching independent of wayland. Otherwise, you couldn't run x11+kmscon without wayland (or any other combination). > So I am not entirely sure what to suggest here: a) implement hooks > in logind specifically for kmscon to emulate VTs; b) do the same, but > for a plymouth compositor; c) allow this to be abstract and allow two > implementations. Plymouth? I think you mean wayland? Plymouth is independent of seats I think. Anyway, I'd prefer c). > I am generally not too much of a fan of keeping things too abstract, but > maybe in this case the iface could just be kept abstract by side-effect. > > We could implement VT switching via D-Bus iface. i.e. if a certain bus > name exists we use its functionality to do VT switching instead of the > kernel interfaces. This bus interface would have to provide: > > - Notification about VT switches > - Call to trigger a VT switch > - Call to allocate a VT > - Call to disallocate a VT Yes. My idea was something like "org.freedesktop.vtmaster" with an interface that does: - Return a list of names for registered VTs - Return the currently active VT - Function to request to activate a specific VT - Function to register/unregister a VT - Signals about VT switches Each VT then has to implement: - listening for signals so the VT sees when it becomes active - an interface with a function that is called if the VT should become inactive. If the function fails, then the VT switch will fail, too. So a VT can reject being put in background. The daemon which implements that can be integrated into other daemons like wayland, logind or kmscon or rather be independent. If it is independent it could also provide a generic way to switch VTs. That is, listening on input devices in the background and waiting for ctrl+fX to change VTs. I will try it out and send my results to this list again. And I will talk to Kristian and the wayland guys about it so we can all agree on a system that works best for all. >> 4) Does systemd implement some internal timeouts for device >> reassignments? Imagine drm-card0 is assigned to seat5 and the user >> reassigns it to seat6. If the xserver starts directly up on seat6, it >> might not be able to get drmMaster for the card (xserver crashes in >> this case) because the process on seat5 did not release the drmMaster >> fast enough. The VT-switching logic uses roundtrips to acknowledge >> release/acquire, however, I cannot see something like this for logind >> session/device switching. > > The correct fix to this problem appears to be a revoke() system cal as > it has been discussed many times. Without that the best way is probably > to patch the clients in question to use inotify to watch when the device > is closed. THis is what PA does. Some devices OTOH may be opened > multiple times (input...), so for them the problem might not exist. Yes, without revoke this gets pretty hard. But it
Re: [systemd-devel] Is there a general inittab entry replacement available?
On Tue, 22.05.12 22:25, Joachim Banzhaf (joachim.banz...@googlemail.com) wrote: > Am 22.05.2012 22:13, schrieb Tomasz Torcz: > > On Tue, May 22, 2012 at 10:06:04PM +0200, Joachim Banzhaf wrote: > >> Thanks for your answers, all three of them! > >> > >> Am 22.05.2012 21:42, schrieb Tomasz Torcz: > >>> Restart=always > >> AFAIK SysV init restarts the service on failures immediatelly for some > >> times, then uses a delay of some minutes before it retries, which seems > >> sensible. If I understand systemd.service man correctly this is not > >> possible? > > > > You are looking for StartLimitInterval=, StartLimitBurst= in that manpage. > > > > Not in my version. Maybe openSUSE is a bit behind (v37) - you guys move > fast! In older versions of systemd we also applied a start rate limit, but the parameters where not configurable. In fact this worked pretty much exactly like in sysvinit, where the start rate limit was hardcoded too, and could not be turned off. In newer versions of systemd you can now turn the rate off or change the parameters, but that's all, the basic logic always was in place. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, 22.05.12 18:13, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote: > > On Tue, May 22, 2012 at 3:03 PM, Lennart Poettering > wrote: > > Heya, > > > > just a quick heads-up. I just commited to git some work that rips out > > the fstab parsing from PID 1 and places this in a generator instead. The > > idea is that sooner or later we only parse native unit files from PID 1, > > and everything else is transformed as needed with generators. This makes > > the core a bit smaller and simplifies a lot of things. > > > > This is quite a substantial change, and hence I am not sure I got it all > > right. I am writing this mail for two reasons: to warn you that current > > git might break your boot more likely then usually, and secondly: please > > test this, especially if you have a more complex setup with nofail, > > noauto and x-systemd.automount in the mix! > > Lennart, Kay: I hate you damn it! :-D > > Man, how can a fstab file be so complex to justify it? It's simpler > than the service files we already load. Now to simply parse /etc/fstab > we need to call a generator, that parses (was being done already), > generates a new file, that triggers inotify, that calls systemd, that > parses it again. Ouch, that's cumbersome at least, slow at last! Well, as Kay is pointed out this paragraph makes little sense. That said I can give you a number of reasons why it actually might be faster this way: - The generators are all executed in parallel, and hence allow a level of parallelization we didn't have before - fstab mount units are now subject to the same kind of lazy loading we have for all other units hence otpimizing resource usages - People who don't need fstab (embedded and containers) can leave the generator out entirely and thus save time and resources - if you feel like it you can even run the generator offline and use the generator unit files for all next boots, to speed up things for certain embedded use cases. The summary of this is probably: without proper profiling claiming that things slow down stuff is non-sense. > One suggestion at IRC was to just keep systemd mount units. But if we > should go this route, then we should call to deprecate /etc/fstab. > Last time we discussed about it, people said it was not going to > happen since some tools were parsing and relying on it. Whats is the > way to go? We don't really deprecate it. But if people want to they don't have to use it now, and can do this easily by dropping the file and removing the generator. You know, fewer PIDs are definitely a good thing, but for some things doing them out-of-process is actually a good thing. Unix knows processes and process isolation for a reason. They come at a price but that doesn't mean you should avoid them at all cost. Lennart -- Lennart Poettering - Red Hat, Inc. ___ 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 SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
On Tue, 22.05.12 21:26, Bardur Arantsson (s...@scientician.net) wrote: > > On 05/22/2012 08:03 PM, Lennart Poettering wrote: > > Heya, > > > > just a quick heads-up. I just commited to git some work that rips out > > the fstab parsing from PID 1 and places this in a generator instead. The > > idea is that sooner or later we only parse native unit files from PID 1, > > and everything else is transformed as needed with generators. This makes > > the core a bit smaller and simplifies a lot of things. > > > > This is quite a substantial change, and hence I am not sure I got it all > > right. I am writing this mail for two reasons: to warn you that current > > git might break your boot more likely then usually, and secondly: please > > test this, especially if you have a more complex setup with nofail, > > noauto and x-systemd.automount in the mix! > > > > Speaking of which... does the code actually check for > >x-systemd.automount > or x-systemd-automount The former. The common prefix for all systemd mount option extensions is "x-systemd." Thanks for pointing this out. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] Generators
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? I have taken the opportunity to document generators and their semantics in detail: http://www.freedesktop.org/wiki/Software/systemd/Generators Please have a look! Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
