Re: [systemd-devel] Running packagekitd on shutdown
On 08/24/2011 01:55 AM, Lennart Poettering wrote: So, we want to make clear that any kind of solution that does not use a proper recovery partition is merely a stop gap in our eyes. Agreed the way forward is recovery partition which get's created at install time and should be an opt out option in the installer ( or opt in ) however recovery partition is not enough. For upgrades/updates we should be looking at solaris and it's boot environment and live upgrades[1],[2].( I would not be surprised if Apple did just that ) For desktop applications we need something like [3] along with Time machine + btrfs support as and I personally would say drop the hack Lennart suggested to meet your needs and go straight for the recovery/upgrades/updates partition/snapshot implementation in systemd, tools and desktop applications. ( Go get it right from the start instead of implementing something that kinda works but actually does not ) Just my 2 cents. JBG 1.http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide#Solaris_Live_Upgrade_Migration_Scenarios 2.http://www.filibeto.org/sun/lib/solaris10-docs/E19253-01/821-1910/6nms46fkb/index.html 3.http://support.apple.com/kb/DL1433 ( Looks like just some livecd/usb creation app Gnome needs a well integrated livecd/usb creation app other DE probably too ) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running packagekitd on shutdown
On 24.08.2011 10:08, Jóhann B. Guðmundsson wrote: On 08/24/2011 01:55 AM, Lennart Poettering wrote: So, we want to make clear that any kind of solution that does not use a proper recovery partition is merely a stop gap in our eyes. Agreed the way forward is recovery partition which get's created at install time and should be an opt out option in the installer ( or opt in ) however recovery partition is not enough. For upgrades/updates we should be looking at solaris and it's boot environment and live upgrades[1],[2].( I would not be surprised if Apple did just that ) For desktop applications we need something like [3] along with Time machine + btrfs support as and I personally would say drop the hack Lennart suggested to meet your needs and go straight for the recovery/upgrades/updates partition/snapshot implementation in systemd, tools and desktop applications. ( Go get it right from the start instead of implementing something that kinda works but actually does not ) Just my 2 cents. JBG 1.http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide#Solaris_Live_Upgrade_Migration_Scenarios 2.http://www.filibeto.org/sun/lib/solaris10-docs/E19253-01/821-1910/6nms46fkb/index.html 3.http://support.apple.com/kb/DL1433 ( Looks like just some livecd/usb creation app Gnome needs a well integrated livecd/usb creation app other DE probably too ) Hmm, with the initramfs moving in the direction of being able to mount /usr, we could extend it to mount the rest as well. We can see the initramfs as _the_ rescue environment, which could do the upgrade as well, without the need of doing a reboot afterwards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SYSTEMD_WANTS and oneshot services
Hello On Tue, Aug 23, 2011 at 6:09 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 21.08.11 14:01, Albert Strasheim (full...@gmail.com) wrote: Is there a way to always get this behavior? I'd like my network interfaces to be brought up regardless of how and when their modules are loaded. Hmm, can you run systemctl status on the service before you reload the kmod and paste the output here? Just to verify that the foo-net-em1.service Loaded: loaded (/etc/systemd/system/foo-net-em1.service) Active: active (exited) since Wed, 24 Aug 2011 12:30:08 +; 1min 49s ago Process: 1044 ExecStart=/sbin/ifup em1 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/foo-net-em1.service service is properly stopped. Then, please set systemd.log_level=debug systemd.log_target=kmsg when reloading it. This will cause the transaction to be written to kmsg, please paste that as well. This should tell us what is included in the triggered transaction. When reloading the module, there is no transaction in the debug log. When I strace systemd, I can see that epoll returns and that systemd calls recvmsg twice for the netlink messages about the two network ports. systemd doesn't do anything else after that. At this point, a systemctl daemon-reload followed by a systemctl status still yields an active (exited) service. Reloading the module after the systemctl daemon-reload still does not rerun the service. I must then do systemctl stop foo-net-em1.service. Then systemctl status says: foo-net-em1.service Loaded: loaded (/etc/systemd/system/foo-net-em1.service) Active: inactive (dead) CGroup: name=systemd:/system/foo-net-em1.service If I then load the module again, I get the transaction as expected and the service is started again. Maybe the service should have a Requisite= on the sys-subsystem...device so that it is stopped when the device disappears? I tried this, but the subsystem alias still doesn't seem to work, even with the fixed udev rules. Thoughts? Regards Albert ___ 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] Running packagekitd on shutdown
On 08/24/2011 08:32 AM, Harald Hoyer wrote: Hmm, with the initramfs moving in the direction of being able to mount /usr, we could extend it to mount the rest as well. We can see the initramfs as_the_ rescue environment, which could do the upgrade as well, without the need of doing a reboot afterwards. I should mention catch 22 when using snapshot(s) for live update/upgrading to bear in mind when architect/engineering a future solution for this, that is any changes that needs to be kept persistent across live upgrade/update cannot be on the same volume that is being snapshot for the live update/upgrade process. Let's say for example that you perform an live upgrade/update on /var and you are running database server such as postgresql or mysql which in Fedora defaults to be stored on /var and for some reason the upgrade/update fails and you need to boot into the pre upgrade/update snapshot you will have lost all the database transaction that happen in between or any changes you made to a configuration file(s) in /etc etc.. There is always a catch 22 :) JBG ___ 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] Question about nspawn.c
On Wed, 24.08.11 11:41, Stef Bon (stef...@gmail.com) wrote: I see, but why the MS_MOVE? In the namespace we are not interested anymore in the original mount. We want to move it to our root dir. As I already tried to explain, a move is a little bit strange, you do not want to move the root. Actually I do. Remember this is in the private namespace! Does the combination MS_BIND | MS_MOVE first do a bind, and moves that bind to the desired location?? If this is the case, it makes more sense. Thinking about it I figure MS_MOVE might actually suffice. Not sure. 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] SYSTEMD_WANTS and oneshot services
On Wed, 24.08.11 13:26, Albert Strasheim (full...@gmail.com) wrote: When reloading the module, there is no transaction in the debug log. When I strace systemd, I can see that epoll returns and that systemd calls recvmsg twice for the netlink messages about the two network ports. systemd doesn't do anything else after that. At this point, a systemctl daemon-reload followed by a systemctl status still yields an active (exited) service. Reloading the module after the systemctl daemon-reload still does not rerun the service. active (exited) suggests that you set RemainAfterExit=yes? I must then do systemctl stop foo-net-em1.service. So it apparently did run. So everything is in order? Then systemctl status says: foo-net-em1.service Loaded: loaded (/etc/systemd/system/foo-net-em1.service) Active: inactive (dead) CGroup: name=systemd:/system/foo-net-em1.service If I then load the module again, I get the transaction as expected and the service is started again. Maybe the service should have a Requisite= on the sys-subsystem...device so that it is stopped when the device disappears? I tried this, but the subsystem alias still doesn't seem to work, even with the fixed udev rules. You need BindTo=, not Requires= for that. 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] SYSTEMD_WANTS and oneshot services
Hello On Wed, Aug 24, 2011 at 2:04 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 24.08.11 13:26, Albert Strasheim (full...@gmail.com) wrote: When reloading the module, there is no transaction in the debug log. When I strace systemd, I can see that epoll returns and that systemd calls recvmsg twice for the netlink messages about the two network ports. systemd doesn't do anything else after that. At this point, a systemctl daemon-reload followed by a systemctl status still yields an active (exited) service. Reloading the module after the systemctl daemon-reload still does not rerun the service. active (exited) suggests that you set RemainAfterExit=yes? I have tried with RemainAfterExit=yes and no. Neither one makes systemd restart the service after reloading the module. Maybe the service should have a Requisite= on the sys-subsystem...device so that it is stopped when the device disappears? I tried this, but the subsystem alias still doesn't seem to work, even with the fixed udev rules. You need BindTo=, not Requires= for that. Thanks. I tried adding BindTo= to the service, hoping that it would really be stopped when the device disappeared, but systemd still doesn't rerun the service. Also, a BindTo= that refers to the sys-subsystem-... alias eventually times out saying the device failed to start, so that isn't working either (even with the fixed udev rule). I'll do the extra bit of debugging you suggested. This issue should be quite easy to reproduce using any machine with its network card code as a module. Regards Albert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about nspawn.c
Please let me explain why I think this is strange to me: in line 713 there is a call to clone, so here the cloned child process has it's own namespace. in line 759 all the submount like proc, dev and sys are done on the directory to change to. in line 775 the mount is done were talking about, using arg_directory A bind mount I can understand, but a move?? Moving the root to arg_directory will overwrite the just created mounts done in line 759? These mounts are created in this namespace... Stef 2011/8/24 Lennart Poettering lenn...@poettering.net: On Wed, 24.08.11 11:41, Stef Bon (stef...@gmail.com) wrote: I see, but why the MS_MOVE? In the namespace we are not interested anymore in the original mount. We want to move it to our root dir. As I already tried to explain, a move is a little bit strange, you do not want to move the root. Actually I do. Remember this is in the private namespace! Does the combination MS_BIND | MS_MOVE first do a bind, and moves that bind to the desired location?? If this is the case, it makes more sense. Thinking about it I figure MS_MOVE might actually suffice. Not sure. 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] Question about nspawn.c
On Wed, 24.08.11 14:38, Stef Bon (stef...@gmail.com) wrote: Please let me explain why I think this is strange to me: in line 713 there is a call to clone, so here the cloned child process has it's own namespace. in line 759 all the submount like proc, dev and sys are done on the directory to change to. in line 775 the mount is done were talking about, using arg_directory A bind mount I can understand, but a move?? Moving the root to arg_directory will overwrite the just created mounts done in line 759? No, it's the other way round. We move arg_directory to /, so that it becomes our new root directory of the namespace. 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] Question about nspawn.c
2011/8/24 Lennart Poettering lenn...@poettering.net: On Wed, 24.08.11 14:38, Stef Bon (stef...@gmail.com) wrote: Please let me explain why I think this is strange to me: in line 713 there is a call to clone, so here the cloned child process has it's own namespace. in line 759 all the submount like proc, dev and sys are done on the directory to change to. in line 775 the mount is done were talking about, using arg_directory A bind mount I can understand, but a move?? Moving the root to arg_directory will overwrite the just created mounts done in line 759? No, it's the other way round. We move arg_directory to /, so that it becomes our new root directory of the namespace. Ah! That explains it. I did not see that. Thanks a lot! Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start service only on specific exit status of some prog
On Tue, 02.08.11 17:06, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: hi.. since conditions specifying wheter a service should start are somehow limited to the existence of some files/directories/etc. i was searching for something more complex to handle conditional service starts. is there a way to execute a program and take its exit status to evaluate the condition? like ConditionExec or whatever. currently we need a service that only starts if the current hostname matches some value, i.e. only start service on hostA. or we need to start a service only if some special IP is configured on a network interface. is this already possible without getting a failed service? Hmm, so I think we should make sure that systemd unit files don't become a programming language. i.e. there needs to be a limit on what we want to allow to be expressed in unit files. I am tempted to say that checks like this are probably beyond that limit, and fall into the domain where shell scripts should be used. I.e. write a tiny shell script that is executed in ExecStartPre invokes your tool, checks the return code and then fails if needed. 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] [PATCH] build-sys: Add --disable-timedated configure switch
On Wed, 03.08.11 00:05, Miklos Vajna (vmik...@frugalware.org) wrote: Subject: [PATCH] build-sys: Add --disable-timedated configure switch Thanks a lot! Applied. 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] Tomcat.service / PID aquiring
On Wed, 03.08.11 07:46, Josh Geisser (j...@gebaschtel.ch) wrote: Hi there We developt an own rc script a while ago for maintaining our tomcats. (mainly improved shutdown behaviour with eventual kill). The script takes start/Stopp/status as arguments, and identifies the right PID by a filtered 'ps'. It also keeps track of the tomcats pid in an own pid-file. So far the ExecStart and ExecStop is clear, but is there something like ExecStatus? No there isn't. For that the best thing is just to supply an indepdent tool, as there is little real need to integrate that in systemd itself. Or, is it possible that systemd reads the service-pid from a file generated by not himself? As mentioned, use PIDFile= to let system know which PID file it should read. Note that systemd never writes PID files, it only reads them. 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] net stats per app
On Wed, Aug 24, 2011 at 10:42 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 02.08.11 15:51, Daniel Wagner (w...@monom.org) wrote: So my thinking is, instead of using the uid driver trick, I could use cgroups for collecting the network traffic. At least from the sub module description it seems to be the right spot to add a new statistic interface. Yupp, that makes a lot of sense I'd say. For CPU accounting there's already cpuacct. Adding a netacct cgroup controller would make a lot of sense to me. (a hackish way to achieve this with existing tools might be to use net_cls for this or so. dunno, might already be enough if ip rules allows accounting.) A open question is how I get the whole thing persistent. So not each time when an application starts the counters begin at 0. My guts feeling systemd should take of this but I don't know if that is the right direction. Hmm, you could simply precreate the cgroups and mark the tasks file with +t (sticky bit). systemd won't remove the cgroup then after use. Or, we could add a new switch ControlGroupPersistant=yes or so which would set +t automatically but systemd would still create the groups for you (so that youdon't have to pre-create anything), but not delete them anymore. Would that make sense? (I have added this option now to the todo list, since it will make sense for stuff like cpuacct where we are in the same boat) Likely he will need to keep accounting between reboots as well, in this case the solution can't be in systemd or kernel, will need a tool to walk these groups accumulate them into a persistent media. Be it periodically, upon reboot or some other method. -- 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] net stats per app
On Wed, 2011-08-24 at 11:19 -0300, Gustavo Sverzut Barbieri wrote: On Wed, Aug 24, 2011 at 10:42 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 02.08.11 15:51, Daniel Wagner (w...@monom.org) wrote: So my thinking is, instead of using the uid driver trick, I could use cgroups for collecting the network traffic. At least from the sub module description it seems to be the right spot to add a new statistic interface. Yupp, that makes a lot of sense I'd say. For CPU accounting there's already cpuacct. Adding a netacct cgroup controller would make a lot of sense to me. (a hackish way to achieve this with existing tools might be to use net_cls for this or so. dunno, might already be enough if ip rules allows accounting.) A open question is how I get the whole thing persistent. So not each time when an application starts the counters begin at 0. My guts feeling systemd should take of this but I don't know if that is the right direction. Hmm, you could simply precreate the cgroups and mark the tasks file with +t (sticky bit). systemd won't remove the cgroup then after use. Or, we could add a new switch ControlGroupPersistant=yes or so which would set +t automatically but systemd would still create the groups for you (so that youdon't have to pre-create anything), but not delete them anymore. Would that make sense? (I have added this option now to the todo list, since it will make sense for stuff like cpuacct where we are in the same boat) Likely he will need to keep accounting between reboots as well, in this case the solution can't be in systemd or kernel, will need a tool to walk these groups accumulate them into a persistent media. Be it periodically, upon reboot or some other method. ControlGroupPersistant=yes for persistent runtime only statistics ControlGroupPersistent=/filename for persistent disk-backed statistics? Would this be at all feasible? if the string is not yes/no string variations, checking it for being a valid pathname and using it as an on-disk store of statistics? Feasible? 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
Re: [systemd-devel] Tomcat.service / PID aquiring
Hi Lennart Yep, I didn't read the last sentence in the documentation about this parameter. (embarrassing) Seems to work fine now, start script writes this file and systemd successfully reports the tomcat as running. Thanks a lot Cheers josh -Ursprüngliche Nachricht- Von: Lennart Poettering [mailto:lenn...@poettering.net] Gesendet: Mittwoch, 24. August 2011 16:06 An: Josh Geisser Cc: systemd-devel@lists.freedesktop.org Betreff: Re: [systemd-devel] Tomcat.service / PID aquiring On Wed, 03.08.11 07:46, Josh Geisser (j...@gebaschtel.ch) wrote: Hi there We developt an own rc script a while ago for maintaining our tomcats. (mainly improved shutdown behaviour with eventual kill). The script takes start/Stopp/status as arguments, and identifies the right PID by a filtered 'ps'. It also keeps track of the tomcats pid in an own pid-file. So far the ExecStart and ExecStop is clear, but is there something like ExecStatus? No there isn't. For that the best thing is just to supply an indepdent tool, as there is little real need to integrate that in systemd itself. Or, is it possible that systemd reads the service-pid from a file generated by not himself? As mentioned, use PIDFile= to let system know which PID file it should read. Note that systemd never writes PID files, it only reads them. 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] net stats per app
On 08/24/2011 04:19 PM, Gustavo Sverzut Barbieri wrote: A open question is how I get the whole thing persistent. So not each time when an application starts the counters begin at 0. My guts feeling systemd should take of this but I don't know if that is the right direction. Hmm, you could simply precreate the cgroups and mark the tasks file with +t (sticky bit). systemd won't remove the cgroup then after use. Or, we could add a new switch ControlGroupPersistant=yes or so which would set +t automatically but systemd would still create the groups for you (so that youdon't have to pre-create anything), but not delete them anymore. Would that make sense? (I have added this option now to the todo list, since it will make sense for stuff like cpuacct where we are in the same boat) Likely he will need to keep accounting between reboots as well, in this case the solution can't be in systemd or kernel, will need a tool to walk these groups accumulate them into a persistent media. Be it periodically, upon reboot or some other method. Yes, the aim is to maintain statistics even over system reboots. I had not yet time to figure out how this could be done. The use case is as following: We have a browser instance which is only used to connect to a our company portal. The user is able to start another instance of the browser which is used for ordinary web browsing. These two instance should be treated differently, so we have to maintain two statistics, one for the portal browser and one for the normal browser. If a certain traffic limit has been reached on the ordinary web browser, ConnMan should stop this session. The portal web browser is still allowed to access the internet through the current path. We have some more of those use cases but most of them can be mapped to that one. If a limit for an application is reached either shutdown the session or reroute the traffic to an different device. If ConnMan would know which application is put into which cgroup then ConnMan could maintain the statistics (also persistent). ConnMan knows which network device/route is currently in use for the application. So everything is there. I think systemd would be the wrong place to solve this. cheers, daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit failed to load: Cannot allocate memory.
On Tue, 23 Aug 2011 18:11:40 +0200 Lennart Poettering lenn...@poettering.net wrote: On Sat, 20.08.11 15:21, Mike Kazantsev (mk.frag...@gmail.com) wrote: On Thu, 18 Aug 2011 16:20:20 +0200 Lennart Poettering lenn...@poettering.net wrote: On Tue, 09.08.11 07:02, Mike Kazantsev (mk.frag...@gmail.com) wrote: Good day, Updating to systemd-33 (with include missing.h patch) seem to give me the following errors on boot: [ 27.024525] systemd[1]: Cannot add dependency job for unit fossil_echo.service, ignoring: Unit fossil_echo.service failed to load: Cannot allocate memory. See system logs and 'systemctl status fossil_echo.service' for details. ... Any chance you can bisect this? Reexec reacts on these units right before Deserializing state... msg, with the same messages. I'll check whether they go away on reexec to 32 and reappear in 33, and if that's the case, will have results shortly. Can you reproduce this issue when you run systemd --test --system as normal user after boot? Yes, seem 100% reproducable that way. Same units, same errors. Looks like it can be (relatively) easily debugged with stuff like gdb now, I'll see if I can come up with conditional breakpoint for failed mallocs. Haven't really used gdb for anything but crash backtraces though, so any suggestions are welcome. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start service only on specific exit status of some prog
On 24.08.2011 16:01, Lennart Poettering wrote: On Tue, 02.08.11 17:06, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: is there a way to execute a program and take its exit status to evaluate the condition? like ConditionExec or whatever. is this already possible without getting a failed service? Hmm, so I think we should make sure that systemd unit files don't become a programming language. i.e. there needs to be a limit on what we want to allow to be expressed in unit files. I am tempted to say that checks like this are probably beyond that limit, and fall into the domain where shell scripts should be used. I.e. write a tiny shell script that is executed in ExecStartPre invokes your tool, checks the return code and then fails if needed. Hi... thanks for the reply.. i really don't want to implement complex checks within unit files.. but currently systemd lacks a clean possibility to implement complex checks outside of unit files. I first tried the StartExecPre= approach.. but it turns out to be somehow destructive in combination with Restart=always.. and you end with a failed service. Currently we have a unit that starts a script which starts other units via systemctl.. it works.. but this too is not really nice, because you can still directly start those unit files by mistake and they won't complain about any external conditions.. since i can't figure out a nice way to evaluate complex conditions i asked for some help here and proposed something like ConditionExec=/some/prog to be able to implement some small c-program to do complex condition checking outside of systemd... We just need a way to integrate the result without loosing some cool systemd features.. 8) may be this could be implemented in future releases or is this a real no-go? regards, marius.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit failed to load: Cannot allocate memory.
On Wed, 24.08.11 21:40, Mike Kazantsev (mk.frag...@gmail.com) wrote: Reexec reacts on these units right before Deserializing state... msg, with the same messages. I'll check whether they go away on reexec to 32 and reappear in 33, and if that's the case, will have results shortly. Can you reproduce this issue when you run systemd --test --system as normal user after boot? Yes, seem 100% reproducable that way. Same units, same errors. Looks like it can be (relatively) easily debugged with stuff like gdb now, I'll see if I can come up with conditional breakpoint for failed mallocs. Haven't really used gdb for anything but crash backtraces though, so any suggestions are welcome. My recommendation would be to start gdb, then do b strerror which will set a breakpoint on strerror() which we'll only call if there's soemthing wrong. Then do r to run the app. You might have to skip over a couple of strerror invocations with c until you find the one that results in memory error. Use n to step over function calls, and s to step into function calls. Use l to figure out where you are and bt to get a backtrace. And that's gdb in a nutshell... 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] net stats per app
On Thu, 25.08.11 02:43, Jeremy (belxjan...@gmail.com) wrote: ControlGroupPersistant=yes for persistent runtime only statistics ControlGroupPersistent=/filename for persistent disk-backed statistics? I don't think systemd should be involved in syncing to disk the data the kernel generates for cgroups, this can easily live in indepdendent code that simply monitors whenever a cgroup goes empty and writes to disk what is store in them or something like that. Would this be at all feasible? if the string is not yes/no string variations, checking it for being a valid pathname and using it as an on-disk store of statistics? Feasible? I don't think saving stats really belongs in systemd. I think systemd should provide you with the right hooks to make it easy to implement this outside of systemd though, and ControlGroupPersistant=yes is quite useful for that. 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] Running packagekitd on shutdown
Lennart Poettering (lenn...@poettering.net) said:
very very early at boot /var might not be around yet. So maybe the
upgrade packs should be placed somewhere in the rootfs (or in /boot?
that might be a good idea actually if it fits...). Split-off /var is
nothing we can get rid of, and makes a lot of sense to support.
So, Kay and I discussed this a bit, and so here's what we'd like to suggest:
Place the actual upgrade packs in /var/lib/something/, and use a touch
file in the root dir to for the next reboot
(i.e. in style of /forcefsck and so so). That way we know from the
earliest moment of boot where we have to boot into, but we don't have to
place the large upgrade packs in the root fs.
That means if PK wants to prepare for an upgrade it would just place the
upgrade pack in /var/lib/something/ and touch /upgrade and that's it.
The generator would then be even simpler:
if (access(/upgrade, F_OK) = 0) {
asprintf(dest, %s/default.target, argv[1]);
symlink(/lib/systemd/system/upgrade.target, dest);
free(dest);
}
(plus some error checking...)
Generators get the path where they should place their generated unit
configuration in as argv[1], hence the asprintf().
And we'd then like to ask you to place a tmpfiles fragment in
/usr/lib/tmpfiles.d/ which includes the following line:
r /upgrade
That way we can be sure that the flag file is removed as soon as the
root fs is writable.
The rest of the earlier suggestion would stay the same.
So, thinking about the UI of this, I'm assuming the flow would be.
1. PK notices updates that require this mechanism
2. PK asks 'Upgrade Now?'
2a. Yes - step 4
2a. No - continue session. (Perhaps a persistent notification here.)
3. On user-initiated shutdown/restart, ask again.
3a. Yes - step 4
3b. No, reboot as normal. Notification returns on next login.
4. PK drops the flag in
5. PK reboots into upgrade
6. Upgrade reboots into system once done
The main points I'm addressing here:
1) You don't want to have to try and get all the infrastructure up to
ask what the user wants to do on boot; do this in the normal session.
2) You don't want to offer to upgrade on the next reboot, have the user
keep working, have a system crash/battery die/whatever, and then start
upgrading when the user reboots to finish their document.
You may already be heading this way in the design, but the gnome.org page
wasn't clear yet.
So, we want to make clear that any kind of solution that does not use a
proper recovery partition is merely a stop gap in our eyes. And due to
that it probably makes little sense to standardize upgrade.target in
systemd. It should hence be shipped along with PK.
Not to get too into the technical wonkery, but the problem with the
recovery partition and any advanced packaging system is that you may very
well need to update the recovery partition just to be able to install your
updates, depending on any underlying packaging changes.
Bill
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running packagekitd on shutdown
On Wed, 24.08.11 13:39, Bill Nottingham (nott...@redhat.com) wrote: r /upgrade That way we can be sure that the flag file is removed as soon as the root fs is writable. The rest of the earlier suggestion would stay the same. So, thinking about the UI of this, I'm assuming the flow would be. 1. PK notices updates that require this mechanism 2. PK asks 'Upgrade Now?' 2a. Yes - step 4 2a. No - continue session. (Perhaps a persistent notification here.) 3. On user-initiated shutdown/restart, ask again. 3a. Yes - step 4 3b. No, reboot as normal. Notification returns on next login. 4. PK drops the flag in 5. PK reboots into upgrade 6. Upgrade reboots into system once done The main points I'm addressing here: 1) You don't want to have to try and get all the infrastructure up to ask what the user wants to do on boot; do this in the normal session. 2) You don't want to offer to upgrade on the next reboot, have the user keep working, have a system crash/battery die/whatever, and then start upgrading when the user reboots to finish their document. You may already be heading this way in the design, but the gnome.org page wasn't clear yet. I generally agree with your ideas, except maybe that I'd drop 3, and just keep the request in the message tray as long as the user didn't agree to it. 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] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc
On Sat, 06.08.11 15:48, Josh Triplett (j...@joshtriplett.org) wrote: Many people prefer to avoid clearing /tmp and /var/tmp, and distributions often have explicit settings for how often to clear them if at all. Overriding those with systemd currently requires overriding all of /usr/lib/tmpfiles.d/systemd.conf via /etc/tmpfiles.d/systemd.conf, copying across all the other entries, and updating that override when systemd.conf changes. Move the /tmp and /var/tmp entries from systemd.conf to a separate tmp.conf, making them easier to override without affecting the rest of systemd.conf. Applied. Thanks! 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] PATCH: add support for compose_table, kbd_rate and disabling caplocks
On Fri, 19.08.11 17:22, Frederic Crozat (fcro...@suse.com) wrote: Hi, even if I know it is kind of SUSE specific, I was wondering if you were interested in merging attached patch (I tried to wrapped most of it inside TARGET_SUSE) which support more options from SUSE kbd initscripts. I haven't done yet another option which sets leds for numlock and so on, because I'm not sure I want it in vconsole-setup (reading bios data which should probably be restored by kernel itself, etc..) but probably in a separate helper (either C or shell). So, humm. I agree with Kay's sentiment on this. I do believe that the compose stuff is a bit too exotic to cover in the simple systemd tools. This should live outside of systemd. I'd be open to do some minimal configuration of the kbd rate and even the led, but not by calling external tools, and no #ifdef SUSE please. If you provide me with a minimal patch that adds two or three options for this and translates them directly to KDSKBLED and KDKBDREP. We call setfont because it actually parses stuff and so on, but I don't think it would make sense to invoke external tools just to call two trivial ioctls. 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] start service only on specific exit status of some prog
On 24.08.2011 18:52, Lennart Poettering wrote: Hmm, yeah, if ExecStartPre= we put the unit in failure mode. So, let me see if I got this right: you are looking for something like ExecStartPre= but twhere the program when it returns non-zero should just cause the service to be skipped but not be put in failure state? Yes. that's my request. something like ConditionExec=/bin/true and ConditionExec=/bin/false so i can implement any thinkable logic outside of systemd and still maintain access to all features like Restart= etc. I thought this may be an easy way to expand the already existent conditions (ConditionPathExists= etc.) without implementing too many special conditional tests in systemd itself. (e.g. check if the current hostname matches some pattern - which was my original issue i tried to solve) 8) bye, marius.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionKernelCommandLine not working?
On Tue, 16.08.11 19:53, Albert Strasheim (full...@gmail.com) wrote: Hello again My previous example confused the issue by mentioning fedora-autorelabal.service. With the following in /etc/systemd/system/foobar.service: So, I tried to reproduce your issue with ConditionKernelCommandLine= to no luck. Everything appears to work just fine for me? Can you isolate a minimal test case for me against current git? 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] start service only on specific exit status of some prog
On Wed, 24.08.11 21:12, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: On 24.08.2011 18:52, Lennart Poettering wrote: Hmm, yeah, if ExecStartPre= we put the unit in failure mode. So, let me see if I got this right: you are looking for something like ExecStartPre= but twhere the program when it returns non-zero should just cause the service to be skipped but not be put in failure state? Yes. that's my request. something like ConditionExec=/bin/true and ConditionExec=/bin/false so i can implement any thinkable logic outside of systemd and still maintain access to all features like Restart= etc. I thought this may be an easy way to expand the already existent conditions (ConditionPathExists= etc.) without implementing too many special conditional tests in systemd itself. (e.g. check if the current hostname matches some pattern - which was my original issue i tried to solve) 8) I have now added this to the TODO list. It won't be easy to add this though, as execution extrernal processes synchronously is not an option. More likely I'll add an additional prefix char to ExecStart= (like -) which would indicate skip-on-fail or so. 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] ConditionKernelCommandLine not working?
Hello On Wed, Aug 24, 2011 at 9:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 16.08.11 19:53, Albert Strasheim (full...@gmail.com) wrote: Hello again My previous example confused the issue by mentioning fedora-autorelabal.service. With the following in /etc/systemd/system/foobar.service: So, I tried to reproduce your issue with ConditionKernelCommandLine= to no luck. Everything appears to work just fine for me? Have you tried the .service I provided here? http://lists.freedesktop.org/archives/systemd-devel/2011-August/003143.html I just tested again with systemd v33 and had the same issue. I can't see anything in the git log that would have fixed this issue between v33 and HEAD. Also, Jóhann Guðmundsso said here that foo=bar isn't parsed correctly: http://lists.freedesktop.org/archives/systemd-devel/2011-August/003155.html Was he right about that? Maybe it matters where foo=bar appears in cmdline? In my tests I have it as the last parameter. By the way, it might be useful if systemctl status could provide more information about which condition failed instead of just start condition failed? Can you isolate a minimal test case for me against current git? Testing against current git is a bit tricky for me, since I don't have a F16 development machine up yet. I'm building and running test systems using F16 packages on F15 with qemu-kvm. I'll see if I can get one up tomorrow. Regards Albert ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc
On Wed, Aug 24, 2011 at 08:39:38PM +0200, Lennart Poettering wrote: On Sat, 06.08.11 15:48, Josh Triplett (j...@joshtriplett.org) wrote: Many people prefer to avoid clearing /tmp and /var/tmp, and distributions often have explicit settings for how often to clear them if at all. Overriding those with systemd currently requires overriding all of /usr/lib/tmpfiles.d/systemd.conf via /etc/tmpfiles.d/systemd.conf, copying across all the other entries, and updating that override when systemd.conf changes. Move the /tmp and /var/tmp entries from systemd.conf to a separate tmp.conf, making them easier to override without affecting the rest of systemd.conf. Applied. Thanks! Excellent, thank you! - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionKernelCommandLine not working?
On 08/24/2011 08:04 PM, Albert Strasheim wrote: Also, Jóhann Guðmundsso said here that foo=bar isn't parsed correctly: http://lists.freedesktop.org/archives/systemd-devel/2011-August/003155.html Was he right about that? Nope I was wrong about that statement but it might be a bug as Lennart mentioned... No, what Albert is using there is actually syntax that we should read correctly. If we misparse that then this is a bug in systemd, and we should fix it. I did not create any test cases to see if that was truly the case... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start service only on specific exit status of some prog
On 24.08.2011 21:21, Lennart Poettering wrote: On Wed, 24.08.11 21:12, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: On 24.08.2011 18:52, Lennart Poettering wrote: Hmm, yeah, if ExecStartPre= we put the unit in failure mode. So, let me see if I got this right: you are looking for something like ExecStartPre= but twhere the program when it returns non-zero should just cause the service to be skipped but not be put in failure state? Yes. that's my request. I have now added this to the TODO list. It won't be easy to add this though, as execution extrernal processes synchronously is not an option. More likely I'll add an additional prefix char to ExecStart= (like -) which would indicate skip-on-fail or so. I think you mean ExecStartPre= here!? And thanks for considering implementing this feature sometime.. 8) regards, marius.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start service only on specific exit status of some prog
On Wed, 24.08.11 23:54, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: On 24.08.2011 21:21, Lennart Poettering wrote: On Wed, 24.08.11 21:12, Marius Tolzmann (tolzm...@molgen.mpg.de) wrote: On 24.08.2011 18:52, Lennart Poettering wrote: Hmm, yeah, if ExecStartPre= we put the unit in failure mode. So, let me see if I got this right: you are looking for something like ExecStartPre= but twhere the program when it returns non-zero should just cause the service to be skipped but not be put in failure state? Yes. that's my request. I have now added this to the TODO list. It won't be easy to add this though, as execution extrernal processes synchronously is not an option. More likely I'll add an additional prefix char to ExecStart= (like -) which would indicate skip-on-fail or so. I think you mean ExecStartPre= here!? Indeed. Sorry for the confusion. And thanks for considering implementing this feature sometime.. 8) 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] [PATCH] build-sys: Add --disable-localed configure switch
Hi, Just like timedated, I think localed can go on embedded systems. Thanks. From ab1358c122783eb2bb592c514ea0853c5395d0e0 Mon Sep 17 00:00:00 2001 From: Miklos Vajna vmik...@frugalware.org Date: Thu, 25 Aug 2011 00:45:26 +0200 Subject: [PATCH] build-sys: Add --disable-localed configure switch --- Makefile.am | 52 ++-- configure.ac |8 2 files changed, 50 insertions(+), 10 deletions(-) diff --git a/Makefile.am b/Makefile.am index c1a4a5f..862bb01 100644 --- a/Makefile.am +++ b/Makefile.am @@ -171,7 +171,6 @@ rootlibexec_PROGRAMS = \ systemd-ac-power \ systemd-detect-virt \ systemd-sysctl \ -systemd-localed \ systemd-logind \ systemd-uaccess @@ -190,6 +189,11 @@ rootlibexec_PROGRAMS += \ systemd-timedated endif +if ENABLE_LOCALED +rootlibexec_PROGRAMS += \ + systemd-localed +endif + systemgenerator_PROGRAMS = \ systemd-getty-generator @@ -234,7 +238,6 @@ dist_pkgsysconf_DATA = \ dist_dbuspolicy_DATA = \ src/org.freedesktop.systemd1.conf \ -src/org.freedesktop.locale1.conf \ src/org.freedesktop.login1.conf if ENABLE_HOSTNAMED @@ -247,9 +250,13 @@ dist_dbuspolicy_DATA += \ src/org.freedesktop.timedate1.conf endif +if ENABLE_LOCALED +dist_dbuspolicy_DATA += \ + src/org.freedesktop.locale1.conf +endif + dist_dbussystemservice_DATA = \ src/org.freedesktop.systemd1.service \ -src/org.freedesktop.locale1.service \ src/org.freedesktop.login1.service if ENABLE_HOSTNAMED @@ -262,6 +269,11 @@ dist_dbussystemservice_DATA += \ src/org.freedesktop.timedate1.service endif +if ENABLE_LOCALED +dist_dbussystemservice_DATA += \ +src/org.freedesktop.locale1.service +endif + dist_udevrules_DATA = \ src/70-uaccess.rules \ src/71-seat.rules @@ -283,8 +295,7 @@ dbusinterface_DATA = \ org.freedesktop.systemd1.Automount.xml \ org.freedesktop.systemd1.Snapshot.xml \ org.freedesktop.systemd1.Swap.xml \ - org.freedesktop.systemd1.Path.xml \ -org.freedesktop.locale1.xml + org.freedesktop.systemd1.Path.xml if ENABLE_HOSTNAMED dbusinterface_DATA += \ @@ -296,6 +307,11 @@ dbusinterface_DATA += \ org.freedesktop.timedate1.xml endif +if ENABLE_LOCALED +dbusinterface_DATA += \ + org.freedesktop.locale1.xml +endif + dist_bashcompletion_DATA = \ src/systemctl-bash-completion.sh @@ -381,7 +397,6 @@ nodist_systemunit_DATA = \ units/systemd-initctl.service \ units/systemd-logger.service \ units/systemd-shutdownd.service \ - units/systemd-localed.service \ units/systemd-logind.service \ units/systemd-kmsg-syslogd.service \ units/systemd-modules-load.service \ @@ -425,6 +440,11 @@ nodist_systemunit_DATA += \ units/systemd-timedated.service endif +if ENABLE_LOCALED +nodist_systemunit_DATA += \ + units/systemd-localed.service +endif + dist_userunit_DATA = \ units/user/default.target \ units/user/exit.target @@ -440,7 +460,6 @@ EXTRA_DIST = \ units/systemd-initctl.service.in \ units/systemd-logger.service.in \ units/systemd-shutdownd.service.in \ - units/systemd-localed.service.in \ units/systemd-logind.service.in \ units/systemd-kmsg-syslogd.service.in \ units/systemd-modules-load.service.in \ @@ -492,6 +511,11 @@ EXTRA_DIST += \ units/systemd-timedated.service.in endif +if ENABLE_LOCALED +EXTRA_DIST += \ + units/systemd-localed.service.in +endif + if TARGET_FEDORA dist_systemunit_DATA += \ units/fedora/prefdm.service \ @@ -554,7 +578,6 @@ pkgconfiglib_DATA = \ # Passed through intltool only polkitpolicy_in_files = \ -src/org.freedesktop.locale1.policy.in \ src/org.freedesktop.login1.policy.in if ENABLE_HOSTNAMED @@ -567,6 +590,11 @@ polkitpolicy_in_files += \ src/org.freedesktop.timedate1.policy.in endif +if ENABLE_LOCALED +polkitpolicy_in_files += \ +src/org.freedesktop.locale1.policy.in +endif + # First passed through sed, followed by intltool polkitpolicy_in_in_files = \ src/org.freedesktop.systemd1.policy.in.in @@ -1791,10 +1819,9 @@ endif $(LN_S) graphical.target runlevel5.target \ $(LN_S) reboot.target runlevel6.target ) ( cd $(DESTDIR)$(systemunitdir) \ - rm -f default.target ctrl-alt-del.target dbus-org.freedesktop.locale1.service dbus-org.freedesktop.login1.service autovt@.service \ + rm -f default.target ctrl-alt-del.target dbus-org.freedesktop.login1.service autovt@.service \ $(LN_S) graphical.target default.target \ $(LN_S) reboot.target ctrl-alt-del.target \ -$(LN_S) systemd-localed.service dbus-org.freedesktop.locale1.service \ $(LN_S)
