Re: [systemd-devel] Question about After/Before of services
On 08/09/2012 06:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P Hey, no need to read the source code :). Please see the man page: http://www.freedesktop.org/software/systemd/man/systemd.unit.html Zbyszek The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? If A is started after B is started (still parallel somehow), is there anything I can do to control A to be started right after B is done? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List all available units
Lennart Poettering píše v St 08. 08. 2012 v 18:31 +0200: On Tue, 07.08.12 16:35, Václav Pavlín (vpav...@redhat.com) wrote: I am not sure we should include the units from list-unit-files in the output of list-units, as this would increase the output quite a bit, and would be hardly helpful in many cases, and slow. I didn't really meant to include output of one list-uni* parameter to another. Those lists does not have much in common and, as You point out, merged output could be slow. So, dunno, I am not entirely sure how to expose this best. We probably should get the interface right, and agree how this would be exposed to the user, before we actually think about implementing it. Neither of the three options I currently see (extend systemctl list-units, extend systemctl list-unit-files, add a new systemctl verb) are that pretty in my eyes. I would vote for the new systemctl verb option. If we present the user with a list like this we probably should show a tree view of some kind since the unit file getty@.service might get instantiated a couple of times as getty@tty1.service and so on, and hence is in a tree-like relationship. I like the idea of the tree view, but I cannot imagine how it can help to solve autocompletion problem. If I get it right, getty@.service is template file, which cannot be manually instantiated, so it can be omitted from the output (User cannot do anything with it, right?). On the other hand, getty@tty1.service is an instance, which can be stopped, restarted etc., and it will be listed in list-units output (and then in merged output of new systemctl verb as well). Another option would be to add a notice about systemctl list-unit-files in the footer of systemctl list-units. That should already be a big imprvoement, since most people probably interrpet the current advice of using --all like this. It would be helpful, but, again, does not solve the autocompletion problem. Another option would be to add systemctl complete as hidden option for usage only by bash completion, that does the merging. This makes sense to me. It could be even something like systemctl list-autocomplete-units. Yes, storing this in a hashmap does make sense. But really, before we get hacking we should think about the UI of this. Ok, I will wait for your agreement. Václav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about After/Before of services
On 08/09/2012 01:59 PM, Zbigniew Jędrzejewski-Szmek wrote: On 08/09/2012 06:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P Hey, no need to read the source code :). Please see the man page: http://www.freedesktop.org/software/systemd/man/systemd.unit.html Zbyszek Hi, Trust me, I've read that section hundreds of times. I'm actually not that lazy ;) I come up with this confusion when I configure a service A 'wants' and 'after' B. I thought they should be started one by one in a exact order, but actually they intersected and run in parallel. Anyway, thanks for the rely. The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? If A is started after B is started (still parallel somehow), is there anything I can do to control A to be started right after B is done? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Thanks, WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Re-exec()ing services for 'systemctl restart' ?
On Wed, Aug 08, 2012 at 07:07:38PM +0200, Lennart Poettering wrote: On Mon, 06.08.12 16:52, Daniel P. Berrange (berra...@redhat.com) wrote: For libvirt, we (will soon) have a daemon (virtlockd) which maintains exclusive fcntl() based locks on disk images/devices, on behalf of both libvirtd and any running QEMU or LXC instances. This is a safety critical daemon (hence separate from libvirtd), to the extent that if the daemon stops / crashes, the entire host should be immediately fenced using a kernel watchdog and/or hardware power control device. We still want to be able to restart this daemon during RPM upgrades to newer versions, but we can't use a normal stop+start sequence, because that will loose locks for any active VMs. Thus the daemon has the ability to re-exec() itself triggered by SIGUSR1, preserving its critical state. I've read the manpages for .service, .exec, etc but I've not seen any reference to changing config such that # systemctl restart virtdlockd.service will simply send SIGUSR1 to the process, instead of stopping it and then starting it again. Obviously I could make the RPM %post send SIGUSR1 directly and ignore systemctl, but that doesn't help admins who just expect to use systemctl. So I want to know if there is a recommended way to handle this kind of use case ? This is fundamentally difficult to implement, simply because restarting a service also means that the services binding to it need restarting too. And the ordering of that gets impossible if the stop/start sequence is atomic because it is done internally in the service, and cannot be split into two steps that we can order freely against each other. So, I fear we cannot really add this for you. As Kay suggested systemctl kill is probably your best choice here, or maybe systemctl reload. Ok, thanks for explaining the issues - I think I'll just use systemctl kill for now. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about After/Before of services
On 08/09/2012 10:04 AM, WANG Chao wrote: On 08/09/2012 01:59 PM, Zbigniew Jędrzejewski-Szmek wrote: On 08/09/2012 06:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P Hey, no need to read the source code :). Please see the man page: http://www.freedesktop.org/software/systemd/man/systemd.unit.html Zbyszek Hi, Trust me, I've read that section hundreds of times. I'm actually not that lazy ;) I come up with this confusion when I configure a service A 'wants' and 'after' B. I thought they should be started one by one in a exact order, but actually they intersected and run in parallel. So: A after B, A wants B, means that when A is started, B will be started first, and after B is started, A will be started second. So the startup phase is sequential, but later on run in parallel. Reading your post again, I think you might have something like startup scripts in mind, where the first should finish _running_ and exit before the second one starts. You can achieve this by adding Type = oneshot to the first service (or even to both of them). You also say right after: sorry, can't help you here. There's no way to ensure that the system will not do some work in between. Zbyszek The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? If A is started after B is started (still parallel somehow), is there anything I can do to control A to be started right after B is done? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] why systemd-udevd log to dmesg?
2012/8/8 Lennart Poettering : On Wed, 08.08.12 19:59, Alexey Shabalin wrote: 2012/8/8 Lennart Poettering : On Wed, 08.08.12 12:07, Alexey Shabalin wrote: After run dmesg i can see [434765.990649] systemd-udevd[1186]: invalid rule '/etc/udev/rules.d/90-alsa-tools-firmware.rules:11' [485891.443571] systemd-udevd[1186]: invalid rule '/etc/udev/rules.d/90-alsa-tools-firmware.rules:11' Yes, i know about invalid rule. (need change BUS to SUBSYSTEM) Issue - why in dmesg? I expected to see in syslog only. Which udev/systemd versin is this? As mentioned by Kay we don't write gerneal log output to kmsg anymore. It's all going to the journal now. udev-187, without systemd (with SysV) Ah, in newer systemd versions we default to journal logging, and if that is not available fall back to kmsg. You can set SYSTEMD_LOG_TARGET=syslog as env var if you want to redirect that to syslog. Thank so much. -- Alexey Shabalin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 188
Heya, http://www.freedesktop.org/software/systemd/systemd-188.tar.xz CHANGES WITH 188: * When running in --user mode systemd will now become a subreaper (PR_SET_CHILD_SUBREAPER). This should make the ps tree a lot more organized. * A new PartOf= unit dependency type has been introduced that may be used to group services in a natural way. * systemctl enable may now be used to enable instances of services. * journalctl now prints error log levels in red, and warning/notice log levels in bright white. It also supports filtering by log level now. * cgtop gained a new -n switch (similar to top), to configure the maximum number of iterations to run for. It also gained -b, to run in batch mode (accepting no input). * The suffix .service may now be ommited on most systemctl command lines involving service unit names. * There's a new bus call in logind to lock all sessions, as well as a loginctl verb for it lock-sessions. * libsystemd-logind.so gained a new call sd_journal_perror() that works similar to libc perror() but logs to the journal and encodes structured information about the error number. * /etc/crypttab entries now understand the new keyfile-size= option. * shutdown(8) now can send a (configurable) wall message when a shutdown is cancelled. * The mount propagation mode for the root file system will now default to shared, which is useful to make containers work nicely out-of-the-box so that they receive new mounts from the host. This can be undone locally by running mount --make-rprivate / if needed. * The prefdm.service file has been removed. Distributions should maintain this unit downstream if they intend to keep it around. However, we recommend writing normal unit files for display managers instead. * Since systemd is a crucial part of the OS we will now default to a number of compiler switches that improve security (hardening) such as read-only relocations, stack protection, and suchlike. * The TimeoutSec= setting for services is now split into TimeoutStartSec= and TimeoutStopSec= to allow configuration of individual time outs for the start and the stop phase of the service. Contributions from: Artur Zaprzala, Arvydas Sidorenko, Auke Kok, Bryan Kadzban, Dave Reisner, David Strauss, Harald Hoyer, Jim Meyering, Kay Sievers, Lennart Poettering, Mantas Mikulėnas, Martin Pitt, Michal Schmidt, Michal Sekletar, Peter Alfredsen, Shawn Landden, Simon Peeters, Terence Honles, Tom Gundersen, Zbigniew Jędrzejewski-Szmek 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] service: allow service to inhibit respawn with special return code
On Wed, 08.08.12 21:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 08/08/2012 05:30 PM, Lennart Poettering wrote: On Tue, 07.08.12 16:01, David Strauss (da...@davidstrauss.net) wrote: On Sat, Aug 4, 2012 at 4:46 AM, Lennart Poettering lenn...@poettering.net wrote: (But please, don't implement this bit just yet, let's wait for somebody actually needing this. Note though, that Upstart actually does have functionality like this). There are broken daemons like the cluster support in node.js that return non-zero on clean shutdowns. While this is broken behavior, it seems the systemd standard is to support broken/non-standard behavior with optional settings. (That is, the default in systemd is a well-behaved application.) Hmm, I was kinda waiting for use cases like this. i.e. before we add an option to reconfigure what clean exits are I wanted an explicit request for it, so that we don't end up adding something that is actually unncessary. Added this to the TODO list now. Should not this be fixed in the daemon instead of worked around in systemd? Yes, it should. Generally that's the rule we try to follow, but I think in this case it is OK to make an exception, simply because it's half a valid usecase to return other things than just errors with the exit code, even though I think it's shady... 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 After/Before of services
On 08/09/2012 04:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? Yes If A.service unit has Wants=B.service and After=B.service it will be start after B.service has finished starting *unless* B.service unit is Type=oneshot service then it will be started immediately after B.service is has been started not when B.service has finished starting... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about After/Before of services
2012/8/9 Jóhann B. Guðmundsson johan...@gmail.com: On 08/09/2012 04:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? Yes If A.service unit has Wants=B.service and After=B.service it will be start after B.service has finished starting *unless* B.service unit is Type=oneshot service then it will be started immediately after B.service is has been started not when B.service has finished starting... JBG Or unless B.service is Type=simple (the default). In this case systemd has no way to tell when B.service has finished starting and continues to start A.service right away. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] List all available units
'Twas brillig, and Václav Pavlín at 09/08/12 08:39 did gyre and gimble: Lennart Poettering píše v St 08. 08. 2012 v 18:31 +0200: If we present the user with a list like this we probably should show a tree view of some kind since the unit file getty@.service might get instantiated a couple of times as getty@tty1.service and so on, and hence is in a tree-like relationship. I like the idea of the tree view, but I cannot imagine how it can help to solve autocompletion problem. If I get it right, getty@.service is template file, which cannot be manually instantiated, so it can be omitted from the output (User cannot do anything with it, right?). A user can actually type systemctl enable getty@.service as it has the following: [Install] Alias=getty.target.wants/getty@tty1.service Thus enabling the template unit will actually configure an instantiation of it. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl --user
From Lennart Poettering, the Fri 03 Aug 2012 at 21:49:11 (+0200):
However, this is not the case when running a systemd --user, then systemctl
--user foo.service will not print the corresponding journal logs, even if
there are some. So here is to a feature request :)
This definitely makes snese. Added to the TODO list now.
Great!
so something like journalctl _SYSTEMD_CGROUP='the right regular expression'
could print them, but journalctl does not seem to support regular
expression yet.
regexes are really hard to index by, so I doubt we will support them.
You are right, it is probably more of the resort of a perl script to parse
the output of journalctl -o verbose. I'll try to write one.
The journal bits in systemctl status are currently completely
unprepared for --user, we really need to fix that.
Ok. I have to say that even if systemd --user is not yet completely ironed out,
it is really great and it allowed me to dismiss runsvdir that I was using
previously to launch my user services.
I will describe here my setup if other people are interested (or if you see
a better way to do it!), along with some bugs I found and other feature
requests that could be nice.
So when I log in, there are different types of services that I want to
launch:
1) services that I want always running (and if they exit, I want systemd to
restart them): think offlineimap, mpd, ...
2) services that are linked to my current X session, think things you would
put in ~/.xprofile or ~/.config/autostart like conky, ... Here I want
these services to be restarted by systemd, except when I am closing the
X session. And if I have several X session, I want one such service by
X session.
3) Eventually you could imagine services like (1), but that I want to stop
whenever I have no active sessions anymore. Since I have no use such
services, I have not implemented that.
So (1) is really easy, this is exactly what systemd is for. I regroup all
such services under session.target. The nice thing is that (2) is quite
easy to do using templates, whereas I could not do that previously with
runsvdir. So I have a xsession@.target:
[Unit]
Description=xsession on display %I
Wants=session.target
AllowIsolate=yes
where I put my X session services (not that it automatically pull the
session services). For instance here is my conky@.service:
[Unit]
Description=conky on display %I
BindsTo=xsession@.target
ConditionPathExists=%h/.conkyrc
[Service]
Environment=DISPLAY=%I
ExecStart=/usr/bin/conky
Restart=always
RestartSec=1
StandardOutput=null
[Install]
WantedBy=xsession@.target
Also=xwatch@.service
So when I login, I launch systemctl --user start xsession@$DISPLAY.target
by putting this code in my ~/.xprofile:
if [ -x /bin/systemd ]; then
xhost + SI:localuser:`id -u -n`
if [ systemctl --user --no-pager 2/dev/null ]; then
systemctl --no-block --user start xsession@${DISPLAY}.target
else
exec systemd --user --unit=xsession@${DISPLAY}.target
fi
fi
Some explanations: before running systemctl --user, I want to make sure
that systemd --user is running, or if not launch it. That's what the
if [ systemctl --user --no-pager 2/dev/null ];
is for.
A note about the xhost line: if I log on a X session with a new $DISPLAY,
since systemd is running from my first session, it may happen that the new
X session has not the same XDG_SESSION_COOKIE, and there will be
authorization problems when programs try to connect to the new X display.
The xhost line allow all programs with my uid to connect to the new X
session (it is there by default with gdm, but not when I log using startx
from a console).
Now the only thing left to do is to launch systemctl --user stop
xsession@$DISPLAY.target when I leave the current X session.
Because of the BindsTo=xsession@.target, it will close the conky running
inside it. That is what the xwatch@.service is for:
[Unit]
Description=Watch for X on display %I
BindsTo=xsession@.target
[Service]
Environment=DISPLAY=%I
ExecStart=/home/username/script/services/xwatch %I
[Install]
WantedBy=xsession@.target
where xwatch is
#!/bin/sh
xprop -spy -root XFree86_VT
echo systemctl --user stop xsession@$1.target
systemctl --user stop xsession@$1.target
xprop is just the program I have chosen to communicate with the X socket (I
want a program that is not likely to crash, and this way I even know on
which VT the X session was launched in my logs). When the X session closes,
the xprop program terminates, and xwatch runs systemctl --user stop
xsession@$1.target.
For (3), I have no need for it, but we could imagine a service timer that parse
the results of ck-list-session, and stop the services when I have no seat
left.
Now for the bugs:
1) The specifiers (%something) work only when starting a service, not
loading it. For instance:
ConditionPathExists=%h/.conkyrc
gives an error:
Path in
Re: [systemd-devel] [ANNOUNCE] systemd 188
Hi, 'Twas brillig, and Lennart Poettering at 09/08/12 11:32 did gyre and gimble: http://www.freedesktop.org/software/systemd/systemd-188.tar.xz I seem to get logind/loginctl issues with this release. Just installing this and logging in with gdm means that my session (as listed in loginctl) is not listed as active (which obviously breaks ACLs etc). If I try and manually activate my session (as my user or root) I get: $ loginctl activate 2 Failed to issue method call: No such device or address This could indicate a problem with the dbus tidy ups perhaps? Didn't see anything obvious when I looked at the logind related commits however. v187 is fine. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 188
Just installing this and logging in with gdm means that my session (as listed in loginctl) is not listed as active (which obviously breaks ACLs etc). If I try and manually activate my session (as my user or root) I get: $ loginctl activate 2 Failed to issue method call: No such device or address hmm, wierd, i have yet to test v188 loginctl on v188 logind, but loginctl with my patches does work with v187 logind. (just tested exactly the same 'loginctl activate 2' and it switched sessions without any problems) This could indicate a problem with the dbus tidy ups perhaps? Didn't see anything obvious when I looked at the logind related commits however. v187 is fine. have you tried v187 loginctl with the v188 logind? this might tell us which side is broken. I will look at the patches again. but i suspect the problem to be somewhere else. Simon Peeters ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 188
'Twas brillig, and Peeters Simon at 09/08/12 22:26 did gyre and gimble: Just installing this and logging in with gdm means that my session (as listed in loginctl) is not listed as active (which obviously breaks ACLs etc). If I try and manually activate my session (as my user or root) I get: $ loginctl activate 2 Failed to issue method call: No such device or address hmm, wierd, i have yet to test v188 loginctl on v188 logind, but loginctl with my patches does work with v187 logind. (just tested exactly the same 'loginctl activate 2' and it switched sessions without any problems) Cool, good to know that it's not likely a problem on the client side. This could indicate a problem with the dbus tidy ups perhaps? Didn't see anything obvious when I looked at the logind related commits however. v187 is fine. have you tried v187 loginctl with the v188 logind? this might tell us which side is broken. Nope, not yet. Won't have time to poke just now, but if nothing crops up for others then I'll try this as a test, but it would appear the problem is server side from your tests (assuming it's a replicable problem) so I don't expect much difference. I will look at the patches again. but i suspect the problem to be somewhere else. As I mentioned I couldn't see anything in your patches when I had a quick look either, but I didn't see too many other other logind related changes in the shortlog at first glance. The problem could easily be in one of the other commits. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] util: add symlink_atomic()
---
src/shared/util.c | 19 +--
src/shared/util.h |1 +
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 946b7d5..876eb62 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -4851,7 +4851,7 @@ finish:
return r;
}
-int symlink_or_copy_atomic(const char *from, const char *to) {
+static int symlink_atomic_raw(const char *from, const char *to, bool
allow_copy) {
char *t, *x;
const char *fn;
size_t k;
@@ -4880,7 +4880,14 @@ int symlink_or_copy_atomic(const char *from, const char
*to) {
*x = 0;
-r = symlink_or_copy(from, t);
+if (allow_copy)
+r = symlink_or_copy(from, t);
+else {
+r = symlink(from, t);
+if (r 0)
+r = -errno;
+}
+
if (r 0) {
unlink(t);
free(t);
@@ -4898,6 +4905,14 @@ int symlink_or_copy_atomic(const char *from, const char
*to) {
return r;
}
+int symlink_or_copy_atomic(const char *from, const char *to) {
+return symlink_atomic_raw(from, to, true);
+}
+
+int symlink_atomic(const char *from, const char *to) {
+return symlink_atomic_raw(from, to, false);
+}
+
bool display_is_local(const char *display) {
assert(display);
diff --git a/src/shared/util.h b/src/shared/util.h
index d5a48eb..24fa240 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -436,6 +436,7 @@ int vt_disallocate(const char *name);
int copy_file(const char *from, const char *to);
int symlink_or_copy(const char *from, const char *to);
int symlink_or_copy_atomic(const char *from, const char *to);
+int symlink_atomic(const char *from, const char *to);
int fchmod_umask(int fd, mode_t mode);
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] timedated: gather timezone from /etc/localtime sym target
keep other method for now, consider dropping later.
Supporting relative links here are problematic as timezones in
/usr/share/zoneinfo are often themselves symlinks (and symlinks to
symlinks), so this implamentation only supports absolute symlinks
/usr/share/zoneinfo/ and relative symlinks starting with
../usr/share/zoneinfo
---
src/timedate/timedated.c | 56 ++
1 file changed, 47 insertions(+), 9 deletions(-)
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index 09fd808..b21d930 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -24,6 +24,7 @@
#include errno.h
#include string.h
#include unistd.h
+#include sys/stat.h
#include util.h
#include strv.h
@@ -74,6 +75,9 @@
BUS_GENERIC_INTERFACES_LIST \
org.freedesktop.timedate1\0
+/* Must start and end with '/' */
+#define ZONEINFO_PATH /usr/share/zoneinfo/
+
const char timedate_interface[] _introspect_(timedate1) = INTERFACE;
typedef struct TZ {
@@ -151,13 +155,16 @@ static void verify_timezone(void) {
if (!tz.zone)
return;
-p = strappend(/usr/share/zoneinfo/, tz.zone);
-if (!p) {
-log_oom();
+j = read_full_file(/etc/localtime, a, l);
+
+/* allow /etc/localtime to not exist */
+if (j == -ENOENT)
return;
-}
-j = read_full_file(/etc/localtime, a, l);
+p = strappend(/usr/share/zoneinfo/, tz.zone);
+if (!p)
+return (void)log_oom();
+
k = read_full_file(p, b, q);
free(p);
@@ -174,9 +181,36 @@ static void verify_timezone(void) {
static int read_data(void) {
int r;
+char *t;
+/* we only support the trivial relative link of ..$ABSOLUTE */
+bool relative_link = false;
free_data();
+r = readlink_malloc(/etc/localtime, t);
+if (r 0) {
+if (errno == EINVAL)
+log_warning(/etc/localtime should be a symbolic link
to a timezone data file in %s, ZONEINFO_PATH);
+else
+log_warning(Failed to get target of %s: %m,
/etc/localtime);
+} else if (!startswith(t, ZONEINFO_PATH) !(startswith(t, ..)
startswith(t + strlen(..), ZONEINFO_PATH)))
+log_warning(/etc/localtime should be a symbolic link
to a timezone data file in %s, ZONEINFO_PATH);
+else {
+if (startswith(t, ..))
+relative_link = true;
+
+tz.zone = strdup(t + (relative_link ? strlen(..) : 0) +
strlen(ZONEINFO_PATH));
+if (!tz.zone) {
+free(t);
+return log_oom();
+}
+
+free(t);
+goto have_timezone;
+}
+
+free(t);
+
r = read_one_line_file(/etc/timezone, tz.zone);
if (r 0) {
if (r != -ENOENT)
@@ -192,6 +226,7 @@ static int read_data(void) {
#endif
}
+have_timezone:
if (isempty(tz.zone)) {
free(tz.zone);
tz.zone = NULL;
@@ -207,6 +242,7 @@ static int read_data(void) {
static int write_data_timezone(void) {
int r = 0;
char *p;
+struct stat st;
if (!tz.zone) {
if (unlink(/etc/timezone) 0 errno != ENOENT)
@@ -222,15 +258,17 @@ static int write_data_timezone(void) {
if (!p)
return log_oom();
-r = symlink_or_copy_atomic(p, /etc/localtime);
+r = symlink_atomic(p, /etc/localtime);
free(p);
if (r 0)
return r;
-r = write_one_line_file_atomic(/etc/timezone, tz.zone);
-if (r 0)
-return r;
+if (stat(/etc/timezone, st) == 0 S_ISREG(st.st_mode)) {
+r = write_one_line_file_atomic(/etc/timezone, tz.zone);
+if (r 0)
+return r;
+}
return 0;
}
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: remove timezone(5) and add localtime(5)
--- Makefile.am|2 +- man/localtime.xml | 93 man/timezone.xml | 90 -- units/systemd-timedated.service.in |2 +- 4 files changed, 95 insertions(+), 92 deletions(-) create mode 100644 man/localtime.xml delete mode 100644 man/timezone.xml diff --git a/Makefile.am b/Makefile.am index ad8f71d..88babf2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -468,7 +468,7 @@ MANPAGES = \ man/systemd.conf.5 \ man/tmpfiles.d.5 \ man/hostname.5 \ - man/timezone.5 \ + man/localtime.5 \ man/machine-id.5 \ man/locale.conf.5 \ man/os-release.5 \ diff --git a/man/localtime.xml b/man/localtime.xml new file mode 100644 index 000..09df161 --- /dev/null +++ b/man/localtime.xml @@ -0,0 +1,93 @@ +?xml version='1.0'? !--*-nxml-*-- +?xml-stylesheet type=text/xsl href=http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl;? +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN +http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; + +!-- + This file is part of systemd. + + Copyright 2010 Lennart Poettering + Copyright 2012 Shawn Landden + + systemd is free software; you can redistribute it and/or modify it + under the terms of the GNU Lesser General Public License as published by + the Free Software Foundation; either version 2.1 of the License, or + (at your option) any later version. + + systemd is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with systemd; If not, see http://www.gnu.org/licenses/. +-- + +refentry id=localtime +refentryinfo +title/etc/localtime/title +productnamesystemd/productname + +authorgroup +author +contribDeveloper/contrib +firstnameLennart/firstname +surnamePoettering/surname +emaillenn...@poettering.net/email +/author +author +contribDeveloper/contrib +firstnameShawn/firstname +surnameLandden/surname +emailshawnland...@gmail.com/email +/author +/authorgroup +/refentryinfo + +refmeta +refentrytitlelocaltime/refentrytitle +manvolnum5/manvolnum +/refmeta + +refnamediv +refnamelocaltime/refname +refpurposeLocal time zone configuration file/refpurpose +/refnamediv + +refsynopsisdiv +parafilename/etc/localtime/filename - filename/usr/share/zoneinfo/…/filename/para +/refsynopsisdiv + +refsect1 +titleDescription/title + +paraThe filename/etc/localtime/filename file +configures the system-wide time zone of the local +system that is used by applications for presentation +to the user. It should be an absolute symbolic link +with a destination of filename/usr/share/zoneinfo//filename, +fallowed by a time zone identifier such as +literalEurope/Berlin/literal or literalEtc/UTC/literal. +The resulting link should point to the corresponding binary + citerefentryrefentrytitletzfile/refentrytitlemanvolnum5/manvolnum/citerefentry +time zone data for the configured time zone./para + +paraAs the time zone identifier is extracted from the name of +the target of filename/etc/localtime/filename this file may +not be a normal file or hardlink./para + +paraThe time zone may be overridden for individual +programs by using the TZ environment variable. See + citerefentryrefentrytitleenviron/refentrytitlemanvolnum7/manvolnum/citerefentry./para +/refsect1 + +refsect1 + titleSee Also/title + para + citerefentryrefentrytitletzset/refentrytitlemanvolnum3/manvolnum/citerefentry + citerefentryrefentrytitlelocaltime/refentrytitlemanvolnum3/manvolnum/citerefentry + citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry + /para +/refsect1 + +/refentry diff --git a/man/timezone.xml b/man/timezone.xml deleted file mode 100644 index
Re: [systemd-devel] Question about After/Before of services
On 08/09/2012 05:56 PM, Zbigniew Jędrzejewski-Szmek wrote: On 08/09/2012 10:04 AM, WANG Chao wrote: On 08/09/2012 01:59 PM, Zbigniew Jędrzejewski-Szmek wrote: On 08/09/2012 06:28 AM, WANG Chao wrote: Hi, list As you see in the subject, this question comes from a lazy guy like me, who doesn't read the systemd source code at all :P Hey, no need to read the source code :). Please see the man page: http://www.freedesktop.org/software/systemd/man/systemd.unit.html Zbyszek Hi, Trust me, I've read that section hundreds of times. I'm actually not that lazy ;) I come up with this confusion when I configure a service A 'wants' and 'after' B. I thought they should be started one by one in a exact order, but actually they intersected and run in parallel. So: A after B, A wants B, means that when A is started, B will be started first, and after B is started, A will be started second. So the startup phase is sequential, but later on run in parallel. It matches what I saw. Make sense. Reading your post again, I think you might have something like startup scripts in mind, where the first should finish _running_ and exit before the second one starts. You can achieve this by adding Type = oneshot How could I miss this :( to the first service (or even to both of them). You also say right after: sorry, can't help you here. There's no way to ensure that the system will not do some work in between. Sorry, when I said right after, I didn't mean right after.. Just after is fine. Thanks for your help, I really appreciate it! I learn a lot :) Zbyszek The silly question is if A is configured to 'Wants:B' and 'After:B', will A start exactly after B is finished or after B is started? If A is started after B is started (still parallel somehow), is there anything I can do to control A to be started right after B is done? -- Thanks, WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
