Re: [systemd-devel] [ANNOUNCE] systemd 210
On Mon, 2014-02-24 at 23:08 +0100, Lennart Poettering wrote: * A new unit file option AppArmoreProfile= has been added to set the AppArmor profile for the processes of a unit. I think that should be « AppArmorProfile= », not « AppArmoreProfile= ». At least that's what systemd.exec(5) says. -- Mathieu Bridon boche...@fedoraproject.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Installing gitlab
On Thu, 2014-01-23 at 10:51 +0100, Marwan Rabbâa wrote: that is not very useful for me. /var/www/gitlab/script/sidekiq is just a litle startup script for sidekiq #!/usr/bin/env sh cd /var/www/gitlab /usr/local/bin/bundle exec sidekiq -q post_receive,mailer,system_hook,project_web_hook,gitlab_shell,common,default -e production -P /var/run/gitlab-sidekiq.pid -d -L /var/www/gitlab/log/sidekiq.log /var/www/gitlab/log/sidekiq.log 21 When I run this script in a tty, I have a 0 exit code, I presume it works (the process behind is started). The way sidekiq is started, it forks itself as a daemon, and the parent process exits. Because you didn't specify the Type= option in the gitlab-sidekiq.service file, systemd assumes the default: Type=simple This means that systemd expects the main process to just start, and keep running forever. (systemd handles the forking) So when the parent process exits after forking, systemd assumes that the service failed. To fix this, you should use Type=forking in your gitlab-sidekiq.service file. I recommend you look at the systemd.service(5) manual page for more details. -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Installing gitlab
On Thu, 2014-01-23 at 11:16 +0100, Marwan Rabbâa wrote: there is already Type=forking in the service section Indeed, I got confused between your two services (the second one doesn't have it). And the systemctl status output says the exit code was 1, not 0, so it has indeed nothing to do with what I said. My apologies for not paying more attention. -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to permanently disable a service after first boot
Hi, On Fri, 2013-09-27 at 12:26 +0500, Muhammad Shakeel wrote: If there is a foo.service which is required to run during first system boot then what is the best solution to permanently disable it afterwards? I can think of two solutions but I am not sure which one is correct/more appropriate. 1) ExecStartPost=systemctl disable foo.service (I doubt this will work) You should have tried it, it actually does work. :) Is there any flag in for systemd unit files which can be set to run a service on first boot only? Another way is to have a ConditionFileExists=!/path/to/file pointing to a file created by the service the first time it runs. That's how I run initialization of PostgreSQL instances at first boot: $ cat /lib/systemd/system/postgresql-setup-stage1.service [Unit] ... ConditionPathExists=!/var/lib/pgsql/data/PG_VERSION ... [Service] Type=oneshot ExecStart=/usr/bin/postgresql-setup initdb RemainAfterExit=true The postgresql-setup script will create the file on the first run, and as a result the service is never run any more. -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: Document the actual behaviour of ExecStopPost
The documentation makes it sound like ExecStopPost is only run when stopping the service with `systemctl stop foo.service` However, that is not the case, as it also gets run when the service unexpectedly exists, crashes, or gets SIGKILLed. --- man/systemd.service.xml | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 8977873..b8b19b3 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -464,9 +464,12 @@ termvarnameExecStopPost=/varname/term listitemparaAdditional commands that are executed after the service -was stopped using the commands -configured in -varnameExecStop=/varname. This +was stopped. This includes cases where +the commands configured in +varnameExecStop=/varname were used, +where the service doesn't have any +varnameExecStop=/varname defined, or +where the service exited unexpectedly. This argument takes multiple command lines, following the same scheme as described for varnameExecStart/varname. Use -- 1.8.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: Document the actual behaviour of ExecStopPost
The documentation makes it sound like ExecStopPost is only run when stopping the service with `systemctl stop foo.service` However, that is not the case, as it also gets run when the service unexpectedly exists, crashes, or gets SIGKILLed. --- man/systemd.service.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 8977873..8001d73 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -464,8 +464,8 @@ termvarnameExecStopPost=/varname/term listitemparaAdditional commands that are executed after the service -was stopped using the commands -configured in +was stopped, either unexpectedly or +using the commands configured in varnameExecStop=/varname. This argument takes multiple command lines, following the same scheme as described -- 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] man: Document the actual behaviour of ExecStopPost
On Friday, March 08, 2013 09:40 PM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Mar 08, 2013 at 04:26:36AM -0500, Mathieu Bridon wrote: The documentation makes it sound like ExecStopPost is only run when stopping the service with `systemctl stop foo.service` However, that is not the case, as it also gets run when the service unexpectedly exists, crashes, or gets SIGKILLed. --- man/systemd.service.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 8977873..8001d73 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -464,8 +464,8 @@ termvarnameExecStopPost=/varname/term listitemparaAdditional commands that are executed after the service -was stopped using the commands -configured in +was stopped, either unexpectedly or +using the commands configured in Your patch goes in the right direction, but those are not exhaustive alternatives, e.g. I can stop the service using DBus. But doesn't that end up « using the commands configured in ExecStop » ? -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Wednesday, March 06, 2013 09:40 PM, Lennart Poettering wrote: On Tue, 05.03.13 21:24, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: (Whenever there's more than one local X11 display, gdm itself certainly needs to be able to put a small GNOME session on behalf of the special-purpose 'gdm' user on each of them, in order to have the login screen present, with accessibility and stuff - but maybe it's OK to have a special case for system users.) Yeah, gdm is special, but as mentioned the right way to handle this is probably to have dynamic users for this, which can be allocated, which can't write to disk, Doesn't gdm need to write to disk things like the last session used? (gnome, kde,...) -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need help with getting messages into /var/log/messages
On Wed, 2012-08-01 at 23:57 -0400, Paul Richards wrote:
1. My program just runs once on startup and then exits. Do I need to
put anything in the service file for that?
Use Type=oneshot in the Service section.
Otherwise, by default the type is 'simple', and as such systemd will
consider your service to be in a failure state when it exits.
3. My program can fork on startup if its necessary to. Should I run it
like that so that it returns immediately? Or just leave it run
regularly. Since it uses usb communications it takes about half a
second to quit out of the interrupt loop so maybe I should set the
fork flag in the service file and have it run that way or is it better
to just run regularly from systemd?
If you set it to fork on startup, then you must use Type=forking,
otherwise systemd will consider the service to be stopped when the first
parent exits and will kill all remaining children.
But you said above that your program will exit, so that means it's not
something that runs in the background as a service, like e.g httpd ?
If so, then Type=oneshot is better, systemd will fork to run the
command anyway, and your service will be considered finished (but not
failed) when it exits.
(Note: you might be interested in the RemainAfterExit option, depending
on your use case)
4. I am making rpms for this program as well, should I have the
service files go into '/etc/systemd/system' or in
'/lib/systemd/system'?
They should go in %{_unitdir} ;)
https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations
--
Mathieu
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Not sure if I am doing something wrong or if this is a bug.
On Mon, 2012-07-30 at 21:49 +, Jóhann B. Guðmundsson wrote: On 07/30/2012 09:13 PM, Daniel J Walsh wrote: Is this failing to see the /etc/systemd/system/httpd.service file? Or is the include failing? Include might failing since there is currently no way to replace existing entry with another one. You can easily confirm or deny if that's the case by simply copy the existing unit and set PrivateTmp to false You can also run systemctl show httpd.service It should show you both the full path to the unit file (so you can make sure that the one in /etc is used) as well as the value of PrivateTmp. I'm sure you did, but just to be extra cautious: did you daemon-reload after adding the file in /etc? -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] mysqld about back to use mysqld_safe in Fedora
On Thu, 2012-06-28 at 04:02 +0200, Reindl Harald wrote: Am 28.06.2012 02:21, schrieb Tom Lane: Lennart Poettering lenn...@poettering.net writes: On Wed, 27.06.12 14:50, Honza Horak (hho...@redhat.com) wrote: One of the issue is (in)ability to imitate the original behavior of mysqld_safe, which restarts the main process only if it crashes and the pid file isn't properly cleaned up. I am pretty sure on-abort is actually what you really want here, no? The PID file checking sounds like a hack to achieve the same? every production installation of mysql in the world runs underneath mysqld_safe, and has done for the last ten years or more yes because maintainers like you are not proceeding Maintainers like him are giving the rest of us (including you) something really good [1] for free, while your only involvement seems to be limited to ranting and insulting people on various mailing lists. Maintainers like him are wasting a lot of their valuable and limited time reading emails from poisonous people like you. Honestly, after all the ad-hominems, nonconstructive criticism, and more generally poisonous rants you've spread on the Fedora development mailing list and here, I would have hoped the respective ML admins would have banned you by now. [1] I mean it, I'm using Tom's PostgreSQL packages in production and they work great! Thank you very much for your work Tom, it is much appreciated. -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh socket activation (Was: systemd unit files for Debian based systems)
On Wed, 2012-06-20 at 08:44 +0200, Lennart Poettering wrote: On Wed, 20.06.12 10:17, Mathieu Bridon (boche...@fedoraproject.org) wrote: On Tue, 2012-06-19 at 19:15 +0200, Lennart Poettering wrote: On Tue, 19.06.12 18:50, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Hi, On Tue, Jun 19, 2012 at 10:03:23AM +0200, Lennart Poettering wrote: On Mon, 18.06.12 21:56, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Do you know of a service file for openssh-server? The Fedora packages have some, but I don't like them too much since they don't use socket activation... Is someone actually working on real socket activation for openssh? While the inetd like stuff works, it does not perform well. it doesn't? In which way? It should be totally OK? When we worked on porting the package to systemd units, we found that the per-connection openssh process would exit with a non-zero status code even if the client disconnected properly: https://bugzilla.redhat.com/show_bug.cgi?id=697698#c59 No idea if that has been fixed upstream since, but that's why the inetd-style socket activation units aren't shipped in Fedora. Well, but that's hardly a performance issue, and adding - to the ExecStart= line makes this problem go away nicely. That's what I had proposed at first, but the maintainer didn't want it as that would also ignore actual errors. I'm pretty sure that's the only thing blocking the addition of a openssh-server-ondemand subpackage in Fedora though (the maintainer doesn't want this to be the default if I recall correctly from the bz ticket). -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ssh socket activation (Was: systemd unit files for Debian based systems)
On Tue, 2012-06-19 at 19:15 +0200, Lennart Poettering wrote: On Tue, 19.06.12 18:50, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Hi, On Tue, Jun 19, 2012 at 10:03:23AM +0200, Lennart Poettering wrote: On Mon, 18.06.12 21:56, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Do you know of a service file for openssh-server? The Fedora packages have some, but I don't like them too much since they don't use socket activation... Is someone actually working on real socket activation for openssh? While the inetd like stuff works, it does not perform well. it doesn't? In which way? It should be totally OK? When we worked on porting the package to systemd units, we found that the per-connection openssh process would exit with a non-zero status code even if the client disconnected properly: https://bugzilla.redhat.com/show_bug.cgi?id=697698#c59 No idea if that has been fixed upstream since, but that's why the inetd-style socket activation units aren't shipped in Fedora. -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Adding a service file to run with system-update.target
On Fri, 2012-06-01 at 23:42 +0100, Richard Hughes wrote: I've been playing with the offline updates thing a bit. Is this the kind of service file that PackageKit should install into /usr/lib/systemd/system/ ? [Unit] Description=Updates the operating system whilst offline DefaultDependencies=no After=system-update.target [Service] Type=oneshot ExecStart=/usr/libexec/pk-offline-update I'm guessing I also have to do something like ln -sf /lib/systemd/system/packagekit-offline-update.service /etc/systemd/system/system-update.target.wants/packagekit-offline-update.service as well. You can simplify that last one by adding the following to the unit file: [Install] WantedBy=system-update.target Then you can use systemctl enable packagekit-offline-update.service -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Documentation question
On Tue, 2012-02-28 at 21:19 -0600, David Lambert wrote: I have got a little further in diagnosing this memory leak of systemd-journal. It appears to worsen when I have a process that emits data to stdout. I presume that systemd-journal is attempting to put this somewhere but failing, and consequently is buffering it in its own process. Do you have the folder /var/log/journal on your system? If it exists, systemd-journald will write logs there, otherwise it will write them to /run/journal And since /run is mounted as tmpfs, that could explain the memory usage you are seeing? -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Mount units don't create their mount points at boot-time
Hi, I'm playing with mount units as a replacement of traditional fstab declaration as I'd like to use some systemd facilities, for example requirements between services and their underlying storage. The systemd.mount(5) manual says: If the mount point is not existing at time of mounting, it is created. That seems to work fine when I run manually: [root@localhost ~]# ls -d /foo/bar/ ls: cannot access /foo/bar/: No such file or directory [root@localhost ~]# systemctl start foo-bar.mount [root@localhost ~]# ls -d /foo/bar/ /foo/bar/ However, when the unit is run at boot-time (because it has been enabled), I get the following when the mount point doesn't exist: [root@localhost ~]# systemctl status foo-bar.mount foo-bar.mount - /foo/bar Loaded: loaded (/lib/systemd/system/foo-bar.mount; enabled) Active: failed since Thu, 05 Jan 2012 18:01:05 +0800; 3min 57s ago Where: /foo/bar What: tmpfs Process: 427 ExecMount=/bin/mount tmpfs /foo/bar -t tmpfs (code=exited, status=32) CGroup: name=systemd:/system/foo-bar.mount [root@localhost ~]# dmesg | grep -F [427] [9.450625] mount[427]: mount: mount point /foo/bar does not exist Here is the content of my unit: [root@localhost ~]# cat /lib/systemd/system/foo-bar.mount [Unit] Description=/foo/bar [Mount] What=tmpfs Where=/foo/bar Type=tmpfs [Install] WantedBy=local-fs.target Did I miss something? This is on Fedora 16 with systemd-37-3.fc16.x86_64 -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] help on syslog-ng and systemd-kmsg-syslogd.service
On Mon, 2011-12-12 at 18:12 +0800, microcai wrote: Hi guys. I had this issue since the release of systemd-37. system start up hang on syslog-ng If I comment out ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service then system boots successfull. But, dbus-daemon keep on poluting my screens. dbus became quiet while I manully stop systemd-kmsg-syslogd.service. So, that's why we need ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service in the first place. No, the why is so that systemd-kmsg-syslog leaves the /dev/log socket alone, so that your syslog implementation can use it. The fact that dbus became quiet while [you] manually stop systemd-kmsg-syslogd.service is because once systemd-kmsg-syslog is gone, the messages sent to /dev/log are not redirected to kmsg anymore, and thus they don't appear on your tty anymore. Question is , why system hang when I have ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service in syslog-ng.service ? I **think** it's because something is trying to write synchronously to /dev/log, but there's nothing listening on it yet (since you stop systemd-kmsg-syslogd). My guess is that syslog-ng.service doesn't have StandardOutput=null, so: - systemd sends its stdout to syslog - but nothing is listening on syslog - syslog-ng waits for something to ack its messages sent to /dev/log - but nothing ever acks the messages, since that's syslog-ng's job, and it's waiting for its messages to be acked. Happened to me in the past. ;) -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly allow user to adjust LimitNOFILE?
On Tue, 2011-11-22 at 20:51 +0300, Peter Lemenkov wrote: Hello! I already found that I could add LimitNOFILE=2048 to the Service section to explicitly set max number of opened files but I need something different. I want to allow user to specify it and set it only in case he specifies it. Just to be clear, when you say user, you mean the admin of the machine? It looks like I should use something like ExecStartPre=ulimit -n $ULIMIT_MAX_FILES where ULIMIT_MAX_FILES is read from EnvironmentFile, but maybe there are some other recommended ways? A local admin can always create the /etc/systemd/system/foobar.service file and its content will take precedence over what is in /lib/systemd/system/foobar.service So local admins can already modify your LimitNOFILE setting, no need for an EnvironmentFile scheme. -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] question
On Wed, 2011-09-14 at 10:50 +0200, Reindl Harald wrote: Am 14.09.2011 10:11, schrieb Jóhann B. Guðmundsson: please open a bugreport - maybe they would hear if i am not would be the only person who is unhappy about what was done with F15 but all others out there are silent and hoping for wonders This is rather interesting the person that has been the nosiest the most about systemd breaking his system, disrupting his workflow and what not, is now advocating that we potentially disrupt all deployments by bringing in a newer release of systemd which means bringing in updates to surrounding components as well to accommodating the changes that have been made not only in systemd but the surrounding components so as well. what do you exactyl not understand here? F15 was released with a unfinished systemd with bad usabilty like systemclt is quiet and i want it get finished where it was released: F15 Fedora release cycle is time-based (i.e release roughly every 6 months), not feature-based (i.e release when it's done). Things not being quite complete until next release will happen in such a release cycle. If you can't accept that then simply don't use a distribution with such a cycle. How about you actually for once provide a migrated legacy sysv init script to a native systemd unit in a bug report in bugzilla instead of demanding one from the maintainer or help maintainers updating documentation surrounding their component or bring a patch upstream that fixes the brokenness you seem to be experiencing. mhh if i look to the mysqld-socket discussion this makes no sense and is wasted work as long policies forbid migration in F15, forbid socket activation for most services and so on If you had read the minutes from the latest FESCo meeting, you would know that socket activation is now allowed: http://meetbot.fedoraproject.org/teams/fesco/fesco.2011-09-12-17.00.log.html#l-465 If you are incabable of doing the above I suggest you stop wasting people times with this noise ah if you are not develop this which are unfinsihed pushed to users you have to be quite? nice! You don't have to be quiet, but you have to be civil and understand a few concepts about the product you are using (short time-based cycle, community QA, etc...) At least, when you identify an issue, complain if you want, but accompany that with a patch. Or just use something else, no one is forcing you to use Fedora and systemd. [Note: I'm not a systemd developer, only an enthusiastic user who went to the trouble of having systemd on EL6 because we like it so much at $dayjob. Thank you systemd developers, and thank you Johann for leading the migration effort in Fedora 16] -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Restart and RestartSec in packaged .service files
On Thu, 2011-09-01 at 11:50 +0200, Reindl Harald wrote: Am 01.09.2011 11:45, schrieb Jan Willies: 2011/9/1 Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net also having the restart-options but no way to set them without override the whole .service file is simply a unfinished design That's not true. You can include the original service file and just add/overwrite your specific settings how will you do that? Let's say you want to add Restart=always to foobar.service, waht you'd do is: 1. edit /etc/systemd/system/foobar.service (to overwrite the /lib one) 2. write this in the file: .include /lib/systemd/system/foobar.service Restart=always That's it, you only added your option, and the rest comes from the package manager. This is all explained in the manual: - http://0pointer.de/public/systemd-man/systemd.unit.html - or simply: man systemd.unit -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bug or I misunderstand systemd configuration rules ?
On Thu, 2011-08-25 at 21:33 +0200, Warpme wrote: 4\systemctl restart daemon1 restarts also application1 [... snip ...] Unfortunately for 4\ systemctl hangs during execution systemctl restart daemon1. It is bug or I completely misunderstand systemd configuration rules ? I found the same thing, and reported the bug already: https://bugs.freedesktop.org/show_bug.cgi?id=39824 -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd with older kernels (Was: Re: getting the fedora 13 systemd qemu image)
On Thu, 2011-08-18 at 08:13 -0700, Leisner, Martin wrote: I want to use an out of date image -- I'm looking to port to 2.6.34... (I even had to start patching the kernel to give me /sys/fs/cgroup -- I don't have the hierarchy under that yet). I'm building systemd-5 for starters...(it works somewhat and builds, I tried systemd-15 and had problems). It seems the README doesn't look right (it says Linux kernel = 2.6.30 (with autofs4, devtmpfs, cgroups) I have fedora15 running (as a reference of a working system) -- but I would like something older to see if it works. I have successfully migrated a RHEL 6 based OS from Upstart to systemd, using the RHEL6 «2.6.32» kernel. I basically had to apply three patches to the RHEL6 kernel for systemd to boot properly: - the patch to move the cgroups hierarchy to /sys/fr/cgroup: 676db4af043014e852f67ba0349dae0071bd11f3 - the patch to have printk not mangle the syslog prefixes (this one is optional): 9d90c8d9cde929cbc575098e825d7c29d9f45054 - the patch to add the 'active' sysfs attribute to tty0 and console: fbc92a3455577ab17615cbcb91826399061bd789 You can find those changesets in the linux-2.6 git tree, only the third one took a bit of work to rebase. After building an otherwise «vanilla» RHEL6 kernel with those three patches applied, everything seems to work perfectly fine with systemd 32 (although I have to admit I haven't really tested the more recent parts such as the logind or hostnamed stuff). -- Mathieu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
