Re: [systemd-devel] Unable to override systemd-udevd.service
While playing with this I've also noticed that systemd treats symlinks in a bit weird way: looks like if it sees a symlink it dereferences it, but not all the symlinks in the path. Here is an example: # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib64/systemd/system/systemd-udevd.service # ln -s /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system # systemctl daemon-reload # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service # readlink -f /etc/systemd/system/systemd-udevd.service /usr/lib64/systemd/system/systemd-udevd.service I feel that I'm interested in the _reason_ why this unit is loaded, that is, I guess, I'd like to see `/etc/systemd/system/system-udevd.service` in this case, as it _explains why_ systemd loaded this unit. But what I see is `/usr/lib/systemd/system/systemd-udevd.service` which is totally unhelpful as it is neither the path that systemd used to discover the unit, nor the actual path to the unit file (which is `/usr/lib64/…`). (Here, on Gentoo, `/usr/lib` is a symlink to `/usr/lib64`.) Probably, somehow using this and the fact that if `cp`'s target is a symlink, then the symlink's target will be overwritten with the symlink left where it was, it is possible to reproduce the issue. -- Кирилл Елагин On Wed, Apr 23, 2014 at 8:43 AM, Lennart Poettering lenn...@poettering.netwrote: On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote: linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl daemon-reload linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # exit From non-exhaustive testing it appears to be the only unit showing this property. Enabling systemd debug does not add any useful information (no output about unit discovery). Any way to debug it? The version is systemd-208-19.1.x86_64 from openSUSE. Hmm, that's weird. Is /etc on some weird mount point or so? It might be interesting to run strace -o log -e open -p 1 and then trigger a reload, and then look at the generate log file log. It should show you where systemd is looking for the udev service file, and might contain a hint, why it skips the file in /etc? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Revisiting the ExecRestart issue
On Fri, 28.03.14 12:12, Brandon Black (blbl...@gmail.com) wrote: 4) Socket Activation! I know this is what some will scream when they skim the above, but it's not a realistic solution in this case for a few reasons: a) The startup delay, in some cases, can be many whole wallclock seconds. This is necessary and acceptable in the general sense (this is network service that people use with large server-side installations, not a desktop thing). UDP is lossy anyway, and a startup delay of a few seconds shouldn't be an issue at all. If we are speaking of 15min or so here, that might be a problem, but otherwise this really sounds fine. And if your daemon really takes 15min this sounds like something to look into... c) Another side-point that might be better addressed in another thread: even if both of the above weren't true, this daemon uses several sockets for multiple roles internally, some of which share all low-level details (e.g. two distinct use-cases for multiple TCP sockets that serve different high-level protocols, where the user might choose arbitrary ports for both). I'm not seeing any trivial way to distinguish these via socket activation - perhaps some kind of socket label that could be accessed by the daemon via sd_* APIs to distinguish would be useful here? You can query the listening ports and properties using getsockname() and friends. Also, sd-daemon provides sd_is_socket() which allows you to do similar checks. On our TODO list is to add an fd store concept to units where service code can push fds to systemd, and pull them out again (to make reloads nice). At the same time we'd add concept of labelling them. 5) ExecReexec - this was one of Lennart's musings in the previous thread in Dec2012. However, this doesn't map well to gdnsd's model if implemented in the obvious manner of having ExecRexec send a signal to the running daemon to re-exec itself. It would map well if gdnsd could respond to SIGFOO via fork()-execve() on itself with the restart verb and let the new instance replace itself when it's ready. The problem is that the new restarting copy needs elevated privileges to bind its sockets, which it then loses permanently by the time it becomes a real daemon (and thus can't provide to the newly execve'd copy). In some cases we could pass on the sockets on by clearing FD_CLOEXEC, but there's no guarantee as to what socket bindings the new daemon will have: typically the same as before, but perhaps the address or port number has changed in the config file for one of five different sockets. At this point in time I am quite sure that ExecReload= should simply be used for this. I am quite sure that systemctl restart should do the same thing for all services, and that means stopping the service, followed by starting, and have both of these jobs follow the usual ordering dependency logic (so that other jobs might be order between the stop/start!). OTOH systemctl reload should be that verb where some service-specific reload operation is executed, where no restriction is made how this ultimately is implemented, and where no ordering logic really applies. Whether a process reexec is done for this or not is an implementation detail of the specific service, where systemd shouldn't really have to be involved. In general the only suggestion we'd make is that the effect of ExecReload should be synchronous, as comprehensive as possible, yet also as graceful as possible. Reexecing as part of reload sounds like a good idea, if enough care is taken not to stop any ongoing connections or transactions. There have been some changes in systemd a while back that makes sure that ExecReload= can replace the process, so this should pretty much work now if the daemon is up to it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] backlight: do nothing if max_brightness is 0
Am 23.04.2014 07:00, schrieb Lennart Poettering: On Thu, 27.03.14 23:41, Thomas Bächler (tho...@archlinux.org) wrote: On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded. It exposes a backlight device despite the lack of any physical backlight devices. This fake backlight device has max_brightness set to 0. Since the introduction of the clamp_brightness function, systemd-backlight tries to write '1' to brightness and fails. This patch changes systemd-backlight to exit gracefully when max_brightness is 0 before performing any action. This affects both the load and save actions. Humm. To me this appears like the driver is broken. The kernel should not expose a backlight device if there isn't any backend to it? Yes. Have you filed a kernel bug? No, I'll take care of it though. I have changed git now to still print a warning in this case, as we shouldn't silently tape over broken drivers. Very good. While we should not try to work with nonsense brightness values, a warning is perfectly fine. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-notify --ready is not reliable
Hi all, I've noticed that the command systemd-notify --ready does not work reliably to signal that a service is ready. It works sometimes, but most of the time you get a message like: systemd[1]: Cannot find unit for notify message of PID 3137. in the journal, and the service stays in the activating state. The reason is that systemd-notify sends its message asynchronously and exits immediately. So by the time systemd processes the message, systemd-notify has probably already exited, and so systemd cannot gets cgroup. (Note that this affects other systemd-notify messages as well, but for --ready it's particularly bad because it causes services to hang in the activating state.) Any suggestions what to do about this? I can see a few solutions: * Have sd_notify() include its own unit name in the notification message. This would be insecure (though probably fine if the sender is root). However, it could be made secure by having systemd pass some random cookie to services via an environment variable, which sd_notify() could then include in its notification messages to authenticate itself. * Make systemd-notify synchronous, i.e., have it wait for a message back from systemd after it has determined the client's unit. Not entirely trivial given that sd_notify() uses SOCK_DGRAM. * Give each service its own notification socket, rather than using the global /run/systemd/notify. That is, in the service, set $NOTIFY_SOCKET to something like /run/systemd/notify-foo.service, and have systemd listen on that socket. By making the socket private to the service's mount namespace, you would know for sure that any message arriving on the socket comes from the service. * Document that you shouldn't use systemd-notify. Not an ideal solution :-) What do you think? -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journalctl --since today --follow weirdness
Hiya, A colleague pointed out an oddity in journalctl --since today --follow output. It seems the two arguments somewhat contradict each other: one asks for all the output for today and the other asks for all future messages, but using them together should obviously behave in a somewhat sensible way! What I was expecting was basically the same as what journalctl --follow would produce, but excluding any output not from today. e.g. if the first 5 lines of a standard journalctl -f happened to be from yesterday, then I'd expect only the 5 lines from today to be printed and then any further output as it happens. What appears to happen instead is that you get the first 10 lines from the day (i.e. after midnight) and then *all* lines from today following that after a small delay (likely not a deliberate delay - just whatever overhead it takes to lookup and output the data), thus taking quite some time to page through which is definitely not what you expect from --follow, but arguably what you would expect from --since today. It's only the delay before full output that makes this very much feel like a bug rather than intentional (i.e. --since having a higher precedence than --follow's 10 line limit!) This is with a recent version of the 208-stable branch. Can someone confirm is this is still a problem in more recent versions? 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] journalctl --since today --follow weirdness
On Wed, Apr 23, 2014 at 6:12 PM, Colin Guthrie gm...@colin.guthr.ie wrote: What appears to happen instead is that you get the first 10 lines from the day (i.e. after midnight) and then *all* lines from today following that after a small delay (likely not a deliberate delay - just whatever overhead it takes to lookup and output the data) strace shows that it isn't looking up any data; it's actually waiting for inotify events for the --follow mode. Seems odd. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] stable Branch 'v208-stable' - 10 commits - hwdb/20-bluetooth-vendor-product.hwdb hwdb/20-OUI.hwdb hwdb/20-pci-vendor-model.hwdb hwdb/ids-update.pl man/sysctl.d.xm
On Wed, 23.04.14 06:21, Zbigniew Jędrzejewski-Szmek
(zbys...@kemper.freedesktop.org) wrote:
New commits:
commit f4b442a95d85a73cbe3a75fb20812942900c4307
Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl
Date: Wed Apr 16 23:33:41 2014 -0400
delta: do not use unicode chars in C locale
https://bugzilla.redhat.com/show_bug.cgi?id=1088418
(cherry picked from commit 00a5cc3a63c125633e822f39efd9c32223169f62)
(cherry picked from commit 1ba98e163ed872d8744ff644e3d255b4be171bc6)
diff --git a/src/delta/delta.c b/src/delta/delta.c
index a8dd57e..f1aea80 100644
--- a/src/delta/delta.c
+++ b/src/delta/delta.c
@@ -85,6 +85,10 @@ static void pager_open_if_enabled(void) {
pager_open(false);
}
+static inline const char* arrow(void) {
+return is_locale_utf8() ? ??? : -;
+}
+
Didn't notice this commit any ealer, but this looks like something to
fold into draw_special_char()?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
В Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net пишет: Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Hmm, this sounds nasty. I wodner what we can do about it... Provide boot completed indication? systemd already provides starting and running states. Which logically implies that bootup is finished when starting is replaced by running. Add new timer condition which fires at this point? This will stop misusing Idle for poor man's replacement of proper boot completed event. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
On Wed, 23.04.14 21:01, Andrey Borzenkov (arvidj...@gmail.com) wrote: В Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net пишет: Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Hmm, this sounds nasty. I wodner what we can do about it... Provide boot completed indication? systemd already provides starting and running states. Which logically implies that bootup is finished when starting is replaced by running. Well, it works the other way round. running is entered as soon as there are no jobs anymore... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to override systemd-udevd.service
В Wed, 23 Apr 2014 06:43:04 +0200 Lennart Poettering lenn...@poettering.net пишет: On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote: linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl daemon-reload linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # exit From non-exhaustive testing it appears to be the only unit showing this property. Enabling systemd debug does not add any useful information (no output about unit discovery). Any way to debug it? The version is systemd-208-19.1.x86_64 from openSUSE. Hmm, that's weird. Is /etc on some weird mount point or so? Not really. Just plain disk in QEMU VM. 17 21 0:5 / /dev rw,relatime shared:2 - devtmpfs devtmpfs rw,size=380164k,nr_inodes=95041,mode=755 18 17 0:15 / /dev/shm rw,relatime shared:3 - tmpfs tmpfs rw 19 21 0:16 / /run rw,nosuid,nodev,relatime shared:6 - tmpfs tmpfs rw,mode=755 20 17 0:11 / /dev/pts rw,relatime shared:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 21 1 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,data=ordered ... etc It might be interesting to run strace -o log -e open -p 1 and then trigger a reload, and then look at the generate log file log. It should show you where systemd is looking for the udev service file, and might contain a hint, why it skips the file in /etc? Actually, it does not :) 1 open(/usr/lib/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/usr/lib/systemd/system/systemd-udevd-kernel.socket, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/usr/lib/systemd/system/systemd-udevd-control.socket, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/etc/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 18 1 openat(AT_FDCWD, /etc/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /run/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /run/systemd/generator/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /usr/local/lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /usr/lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) But this is really the only system exhibiting this behavior ... another VM with the same openSUSE version does not. This particular system ignores /etc/systemd/system/systemd-udev.service even after reboot. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl --since today --follow weirdness
Yeah, I see this with systemd 212. And let me clarify a little bit: this delay after showing first 10 lines is not a result of looking up for something; Following lines appear as soon as there is something new in the log (that is, actually what `-f` does). So, here is what I see: I type `journalctl --since today -f`. First 10 lines from today appear. As soon as something is written to log (e.g. I simulate this by deliberately failing a `sudo` authentication) all the remaining lines from today (including the new ones, of course) appear. That's clearly a bug. -- Кирилл Елагин On Wed, Apr 23, 2014 at 8:05 PM, Mantas Mikulėnas graw...@gmail.com wrote: On Wed, Apr 23, 2014 at 6:12 PM, Colin Guthrie gm...@colin.guthr.ie wrote: What appears to happen instead is that you get the first 10 lines from the day (i.e. after midnight) and then *all* lines from today following that after a small delay (likely not a deliberate delay - just whatever overhead it takes to lookup and output the data) strace shows that it isn't looking up any data; it's actually waiting for inotify events for the --follow mode. Seems odd. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
Hi, On Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net wrote: [...] Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Yes. Of course, the meaning of long really depends... but it can be ~10 sec. Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'll have to test this, but I'll speculate that list-jobs will show nothing by the time I login, because it takes about 30 sec for me to enter login credentials... Use systemctl enable debug-shell... OK will do. I didn't know about the debug shell. Thanks, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D 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] journalctl --since today --follow weirdness
On Wed, 23.04.14 16:12, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hiya, A colleague pointed out an oddity in journalctl --since today --follow output. It seems the two arguments somewhat contradict each other: one asks for all the output for today and the other asks for all future messages, but using them together should obviously behave in a somewhat sensible way! What I was expecting was basically the same as what journalctl --follow would produce, but excluding any output not from today. e.g. if the first 5 lines of a standard journalctl -f happened to be from yesterday, then I'd expect only the 5 lines from today to be printed and then any further output as it happens. What actually happens is that the output will show you everything from today, and when it is done with that continue with a live output. To me this appears as the right thing to do, no? To me --follow is kinda the little add-on just says and then continue live... Of course, this definition means that --until and --follow are contradictory when combined, so we should probably just check for that and exit with an error What appears to happen instead is that you get the first 10 lines from the day (i.e. after midnight) and then *all* lines from today following that after a small delay (likely not a deliberate delay - just whatever overhead it takes to lookup and output the data), thus taking quite some time to page through which is definitely not what you expect from --follow, but arguably what you would expect from --since today. It's only the delay before full output that makes this very much feel like a bug rather than intentional (i.e. --since having a higher precedence than --follow's 10 line limit!) Hmm, I am actually seeing that I get the full output of today, plus anything that happens afterwards, this looks quite ok to me... This is with a recent version of the 208-stable branch. can you check with git? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
On Wed, 23.04.14 13:15, Leonid Isaev (lis...@umail.iu.edu) wrote: Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... Hmm, thinking about this: the problem is actually not restricted to persistent timers, any timer that has OnBootSec=10ms or so is also affected by this, should the boot take longer than 10ms... Another option might be to change what Type=idle means: instead of making it wait until the job queue is empty it might be better to simply make it wait until the default job is finished (with other words, until graphical.target is reached). That way it doesn't matter what services are added in by timers... Somehow this appears like the better solution to me. This probably also means changing the manager state machine, and splitting its starting state into two: one state for the time until the default target is not yet reached, and a second state for the time until the job queue is actually empty. I added this to the TODO list now. I'd be happy to take a patch for this though! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-notify --ready is not reliable
On Wed, 23.04.14 15:15, Eelco Dolstra (eelco.dols...@logicblox.com) wrote: Hi all, I've noticed that the command systemd-notify --ready does not work reliably to signal that a service is ready. It works sometimes, but most of the time you get a message like: systemd[1]: Cannot find unit for notify message of PID 3137. in the journal, and the service stays in the activating state. The reason is that systemd-notify sends its message asynchronously and exits immediately. So by the time systemd processes the message, systemd-notify has probably already exited, and so systemd cannot gets cgroup. (Note that this affects other systemd-notify messages as well, but for --ready it's particularly bad because it causes services to hang in the activating state.) Any suggestions what to do about this? I can see a few solutions: There is ongoing work to fix the kernel to add SCM_CGROUPS for us to messages. With that in place we have a race-free way to get this data for incoming messages. I have some hopes that this will soonishly enter the kernel, but then again, this story has been cookie for the past 5 years to no successs... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] core: Move user generator directories to XDG_RUNTIME_DIR
On Fri, 28.03.14 19:38, Hristo Venev (hri...@venev.name) wrote:
Predictable names and more consistent.
This definitely feels like the right thing to do.
---
src/core/manager.c | 48 +++-
1 file changed, 11 insertions(+), 37 deletions(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index ce8759e..b409738 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -2550,50 +2550,24 @@ static int create_generator_dir(Manager *m, char
**generator, const char *name)
if (*generator)
return 0;
-if (m-running_as == SYSTEMD_SYSTEM getpid() == 1) {
-/* systemd --system, not running --test */
-
-p = strappend(/run/systemd/, name);
-if (!p)
-return log_oom();
-
-r = mkdir_p_label(p, 0755);
-if (r 0) {
-log_error(Failed to create generator directory %s:
%s,
- p, strerror(-r));
-free(p);
-return r;
-}
-} else if (m-running_as == SYSTEMD_USER) {
-const char *s = NULL;
+if (m-running_as == SYSTEMD_SYSTEM getpid() != 1) {
+/* systemd --system --test */
-s = getenv(XDG_RUNTIME_DIR);
-if (!s)
-return -EINVAL;
-p = strjoin(s, /systemd/, name, NULL);
+p = strjoin(/tmp/systemd-, name, .XX, NULL);
if (!p)
return log_oom();
-
-r = mkdir_p_label(p, 0755);
-if (r 0) {
-log_error(Failed to create generator directory %s:
%s,
- p, strerror(-r));
-free(p);
-return r;
-}
} else {
-/* systemd --system --test */
-
-p = strjoin(/tmp/systemd-, name, .XX, NULL);
+p = strjoin(manager_get_runtime_prefix(m), /systemd/,
name, NULL);
if (!p)
return log_oom();
+}
-if (!mkdtemp(p)) {
-log_error(Failed to create generator directory %s:
%m,
- p);
-free(p);
-return -errno;
-}
Hmm, we still need the mkdtemp() here for the --system --test case, no?
Or am I missing something?
+r = mkdir_p_label(p, 0755);
+if (r 0) {
+log_error(Failed to create generator directory %s: %s,
+ p, strerror(-r));
+free(p);
+return r;
}
*generator = p;
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl --since today --follow weirdness
I've checked the code, and the issue is, basically, that `--since` and skipping to the end with `--follow` are in a way “mutually exclusive”, that is, they are handled in a single `if … else if …` statement, so, because `--since` is processed first, we don't skip to head. But since `--follow` sets arg_lines to 10, we still get just 10 lines of output. And then the rest. -- Кирилл Елагин On Wed, Apr 23, 2014 at 9:53 PM, Kirill Elagin kirela...@gmail.com wrote: Yeah, I see this with systemd 212. And let me clarify a little bit: this delay after showing first 10 lines is not a result of looking up for something; Following lines appear as soon as there is something new in the log (that is, actually what `-f` does). So, here is what I see: I type `journalctl --since today -f`. First 10 lines from today appear. As soon as something is written to log (e.g. I simulate this by deliberately failing a `sudo` authentication) all the remaining lines from today (including the new ones, of course) appear. That's clearly a bug. -- Кирилл Елагин On Wed, Apr 23, 2014 at 8:05 PM, Mantas Mikulėnas graw...@gmail.comwrote: On Wed, Apr 23, 2014 at 6:12 PM, Colin Guthrie gm...@colin.guthr.ie wrote: What appears to happen instead is that you get the first 10 lines from the day (i.e. after midnight) and then *all* lines from today following that after a small delay (likely not a deliberate delay - just whatever overhead it takes to lookup and output the data) strace shows that it isn't looking up any data; it's actually waiting for inotify events for the --follow mode. Seems odd. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] core: Put transient user units in XDG_RUNTIME_DIR instead of XDG_CONFIG_HOME.
On Fri, 28.03.14 21:42, Hristo Venev (hri...@venev.name) wrote: On Fri, 2014-03-28 at 19:52 +0100, Kay Sievers wrote: It should still go into its own variable if you want to skip the check. We should not rely on the behaviour of external functions like that. Even when it is not likely to ever fail, or never even to be called as PID1, it's still the coding pattern that matters, and PID1 code has stricter rules than usual user code. Kay Can manager_get_runtime_prefix return NULL? Yes, it can. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl --since today --follow weirdness
On Wed, Apr 23, 2014 at 10:16 PM, Lennart Poettering lenn...@poettering.net wrote: What actually happens is that the output will show you everything from today, and when it is done with that continue with a live output. Not exactly. You don't get _everything_ form to day, you get just arg_lines lines. And you get the rest from today when something new is added to log. This happens because `--follow` sets args_lines to 10 and once n_shown is 10 we pause waiting for more lines to come, and once they come we output everything in bulk. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] core: Put transient user units in XDG_RUNTIME_DIR instead of XDG_CONFIG_HOME.
On Fri, 28.03.14 19:38, Hristo Venev (hri...@venev.name) wrote:
Also looks like the absolute right thing to do.
They are temporary and should not clutter the configuration directory.
---
src/core/unit.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index 153b79b..69971ba 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -2955,11 +2955,18 @@ static int drop_in_file(Unit *u,
UnitSetPropertiesMode mode, const char *name, c
if (u-manager-running_as == SYSTEMD_USER) {
_cleanup_free_ char *c = NULL;
-r = user_config_home(c);
-if (r 0)
-return r;
-if (r == 0)
-return -ENOENT;
+if (mode UNIT_PERSISTENT !u-transient)
Can you enclose the binary check with (), to clarify, what's going on here?
+r = user_config_home(c);
+if (r 0)
+return r;
+if (r == 0)
+return -ENOENT;
+
+else {
+c = strappend(getenv(XDG_RUNTIME_DIR),
-/systemd/user);
This needs error checkiing, getenv() might return NULL
+
+if (!c) return -ENOMEM;
Please break this into two lines...
+}
p = strjoin(c, /, u-id, .d, NULL);
} else if (mode == UNIT_PERSISTENT !u-transient)
@@ -3086,8 +3093,6 @@ int unit_remove_drop_in(Unit *u, UnitSetPropertiesMode
mode, const char *name) {
}
int unit_make_transient(Unit *u) {
-int r;
-
assert(u);
u-load_state = UNIT_STUB;
@@ -3098,19 +3103,12 @@ int unit_make_transient(Unit *u) {
u-fragment_path = NULL;
if (u-manager-running_as == SYSTEMD_USER) {
-_cleanup_free_ char *c = NULL;
-
-r = user_config_home(c);
-if (r 0)
-return r;
-if (r == 0)
-return -ENOENT;
-
-u-fragment_path = strjoin(c, /, u-id, NULL);
+_cleanup_free_ char *dir =
strappend(getenv(XDG_RUNTIME_DIR), /systemd/user/);
+u-fragment_path = strappend(dir, u-id);
if (!u-fragment_path)
return -ENOMEM;
We try to avoid declaring variables and invoking functions in the same
line. Could you split this up into two?
It might be nicer to use strjoin() here, and just concatenate the full
thing in one step, and then use mkdir_parents() instead of mkdir_p() to
create the parent directory...
-mkdir_p(c, 0755);
+mkdir_p(dir, 0755);
} else {
u-fragment_path = strappend(/run/systemd/system/, u-id);
if (!u-fragment_path)
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] core: add EnvironmentFiles to settable transient unit properties
On Fri, 28.03.14 19:38, Hristo Venev (hri...@venev.name) wrote:
Sounds useful.
---
src/core/dbus-execute.c | 16
src/libsystemd/sd-bus/bus-util.c | 18 +-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index 13b3d0d..1f1f602 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -851,6 +851,22 @@ int bus_exec_context_set_transient_property(
return 1;
+} else if (streq(name, EnvironmentFiles)) {
+
+_cleanup_strv_free_ char **l = NULL;
+
+r = sd_bus_message_read_strv(message, l);
+if (r 0)
+return r;
+
+if (mode != UNIT_CHECK) {
+r = strv_extend_strv(c-environment_files, l);
+if (r 0)
+return r;
+}
+
+return 1;
+
This should probably check whether the list only contains absolute file
names (possily prefixed with -), and refuse otherwise. It should
follow the rough behaviour of config_parse_unit_env_file().
This also needs to use unit_write_drop_in_private_format() or so, so
that the stuff is written to /run, so that it isn't lost on reload.
+else if (streq(field, EnvironmentFiles)) {
+_cleanup_strv_free_ char **l = strv_split_quoted(eq);
+if(!l) return -ENOMEM;
Please avoid calling functions and declaring variables in the same line,
and also please write the if check in two lines...
+
+r = sd_bus_message_open_container(m, 'v', as);
+if (r 0) {
+return bus_log_create_error(r);
+}
No {} please if the if block only contains a single line.
Also 8ch indenting, please.
+
+r = sd_bus_message_append_strv(m, l);
+if (r 0) {
+return bus_log_create_error(r);
+}
Same here.
+
+r = sd_bus_message_close_container(m);
+
+} else if (streq(field, DeviceAllow)) {
if (isempty(eq))
r = sd_bus_message_append(m, v, a(ss), 0);
Looks good otherwise!
Thanks!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Revisiting the ExecRestart issue
On Tue, 01.04.14 01:55, Brandon Black (blbl...@gmail.com) wrote: On Fri, Mar 28, 2014 at 12:12 PM, Brandon Black blbl...@gmail.com wrote: Given where things are at today, as best I can tell my best bet is to go down that sort of road, though, and try to clone over the cgroups memberships manually somehow during an ExecReload= command for this restart (even though it really is a restart), and leaving true reloads (SIGHUP to a running daemon) to be done from outside systemd. I've done some experimenting this evening (on a Fedora 20 system w/ systemd-208), playing with methods of MAINPID notification and how to coerce ExecReloadinto letting me do an overlapped restart. The result is that I can make it work, but it's hacky. The main thing that bothers me about it is that the mechanisms probably aren't officially supported interfaces and my methods will randomly fail on a future version of systemd (or a differently-configured distro). You should be able to either inform systemd of new new PID by sending MAINPID, or simply write a new PID file out, systemd should read it again, if you configure it with PIDFile. To recap my results: there were primarily two things in the way of naively using ExecReload to trigger gdnsd's overlapped restart: 1) gdnsd wants to use sd_notifyf() to indicate the MAINPID switch in the new daemon, which is a descendant of the ExecReload process. The ExecReloadprocess doesn't get a copy of $NOTIFY_SOCKET even with NotifyAccess=all. So I hacked around that by having the daemon set $NOTIFY_SOCKET for itself, to the value @/org/freedesktop/systemd1/notify, which seems semi-standard for the moment. 2) ExecReload control processes can't become the MAINPID even after notification because they're not in the correct cgroup (or subgroup, or whatever it is that's special about most control procs), unlike Start'scontrol process, which is in the right cgroup for its descendants to become MAINPID successfully. This was hacked around by grabbing the basic unit name from sd_pid_get_unit() (let's call the result $U) and then writing our pid to /sys/fs/cgroup/systemd /system.slice/$U/cgroup.procs from the new daemon before it drops root privs and later notifies about the MAINPID switch. Hmm, yeah, the new process really needs to be forked off the original main process. Control processes really can't become the main process I fear... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 2/2] bootchart: add cgroup option
On Fri, 28.03.14 17:07, WaLyong Cho (walyong@samsung.com) wrote:
Sounds useful.
---
src/bootchart/bootchart.c|9 -
src/bootchart/bootchart.conf |1 +
src/bootchart/bootchart.h|2 ++
src/bootchart/store.c| 25 +
src/bootchart/svg.c |5 +++--
5 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 9f72d98..1c87085 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -78,6 +78,7 @@ bool initcall = true;
bool arg_relative = false;
bool arg_filter = true;
bool arg_show_cmdline = false;
+bool arg_show_cgroup = false;
bool arg_pss = false;
int samples;
int arg_samples_len = 500; /* we record len+1 (1 start sample) */
@@ -113,6 +114,7 @@ static void parse_conf(void) {
{ Bootchart, PlotEntropyGraph, config_parse_bool, 0,
arg_entropy },
{ Bootchart, ScaleX, config_parse_double, 0,
arg_scale_x },
{ Bootchart, ScaleY, config_parse_double, 0,
arg_scale_y },
+{ Bootchart, Cgroup, config_parse_bool,
0, arg_show_cgroup },
Please do not abbreviate this option, please use ControlGroup here.
+static void get_cgroup_name(int pid, struct ps_struct *ps) {
+_cleanup_fclose_ FILE *cg = NULL;
+char filename[PATH_MAX], *line = NULL;
+int r, fd;
+
+sprintf(filename, %d/cgroup, pid);
+fd = openat(procfd, filename, O_RDONLY);
+if (fd == -1)
+return;
+
+cg = fdopen(fd, r);
+if (!cg)
+return;
+
+r = read_one_line_from_file_if_has(cg, line, name=systemd:/);
+if (r 0)
+return;
+
+strncpy(ps-cgroup, line, sizeof(ps-cgroup));
+free(line);
+}
+
Please use cg_pid_get_path() for this instead.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Tue, 25.03.14 19:07, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-25 0:14 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 23:59, Michael Biebl (mbi...@gmail.com) wrote: I think the priority information is irrelevant in this particular issue. It's the discrepancy regarding runlevel information. So I doubt your patch makes a difference, but I'll double check. I am tempted to also drop the runlevel parsing from the LSB and chkconfig headers. After all they are mostly irrelevant since what is linked in /etc/rc?.d/ is what matters, and not the stuff in the init script themselves. Let me now if this would make things work then for you. If so, I'll drop this too then. I think this might work, without having actually tested it. That said, if you drop runlevel and priority parsing from the chkconfig header, is there anything useful left in # chkconfig: ? Nope, there wouldn't be. Regarding # pidfile:, it's basically the same problem, ie. the mere existence (on Debian) doesn't necessarily mean it is correct. The result could be, that we mark a service as Type=forking pointing it at the wrong pid file, leading to the service not being tracked properly. I'd have to check all packages affected by this [0], to see if the information in there is actually correct. [0] http://codesearch.debian.net/search?q=%23+pidfile%3A I am pretty sure that this is something to fix in the init scripts rather than to drop entirely. the pidfile option is simply increadibly useful. I have now added a todo list item to drop chkconfig parsing entirely. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] System locale not set in tty
On Tue, 25.03.14 17:35, Armin K. (kre...@email.com) wrote: Hello there, I'm using stock systemd-211 release and I have noticed today that locale isn't set anymore in tty. My X session, which runs on tty1 has the locale correctly set up, but when I swich to tty2 and log in, the locale is set to POSIX, LANG isn't set at all. Is this expected behaviour or what? Do I still need shell scripts for parsing /etc/locale.conf and setting it like that in /etc/profile* scripts? Yeah, we explicitly don't pass the locale to gettys on the VC: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1640944a847249d3f5f0fb0d5a5f820a82efaed0 You basically have to pull in the file from a .profile or suchlike. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 2/2] bootchart: add cgroup option
On Wed, Apr 23, 2014 at 1:13 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 28.03.14 17:07, WaLyong Cho (walyong@samsung.com) wrote: Sounds useful. Agreed - this looks highly useful. Would be nice maybe to see an example output file somehere, but otherwise thumbs up (though, please refactor as per Lennart's comments). Thanks WaLyong, Kyungmin! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] service: add FailureAction= option
On Tue, 15.04.14 08:26, Michael Olbrich (m.olbr...@pengutronix.de) wrote: It has the same possible values as StartLimitAction= and is executed immediately if a service fails. Looks good! But doesn't apply anymore, could you rebase both patches please, will merge then! Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] hostnamed: expose OperatingSystemName and OperatingSystemRelease on the bus
On Thu, 27.03.14 19:48, Djalal Harouni (tix...@opendz.org) wrote:
Hmm, thinking about this again, given that this is actually the kernel
identity we return here we should really name those props KernelName and
KernelRelease...
Sorry for the constant forth and back!
Otherwise looks great, can you ren ame the props? will then merge!
---
src/hostname/hostnamed.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 3b19d43..abafa62 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -23,6 +23,7 @@
#include string.h
#include unistd.h
#include dlfcn.h
+#include sys/utsname.h
#include util.h
#include strv.h
@@ -40,6 +41,8 @@ enum {
PROP_PRETTY_HOSTNAME,
PROP_ICON_NAME,
PROP_CHASSIS,
+PROP_OS_NAME,
+PROP_OS_RELEASE,
PROP_OS_PRETTY_NAME,
PROP_OS_CPE_NAME,
_PROP_MAX
@@ -70,11 +73,18 @@ static void context_free(Context *c, sd_bus *bus) {
static int context_read_data(Context *c) {
int r;
+struct utsname u;
assert(c);
context_reset(c);
+assert_se(uname(u) = 0);
+c-data[PROP_OS_NAME] = strdup(u.sysname);
+c-data[PROP_OS_RELEASE] = strdup(u.release);
+if (!c-data[PROP_OS_NAME] || !c-data[PROP_OS_RELEASE])
+return -ENOMEM;
+
c-data[PROP_HOSTNAME] = gethostname_malloc();
if (!c-data[PROP_HOSTNAME])
return -ENOMEM;
@@ -555,6 +565,8 @@ static const sd_bus_vtable hostname_vtable[] = {
SD_BUS_PROPERTY(PrettyHostname, s, NULL, offsetof(Context, data)
+ sizeof(char*) * PROP_PRETTY_HOSTNAME, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(IconName, s, property_get_icon_name, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(Chassis, s, property_get_chassis, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+SD_BUS_PROPERTY(OperatingSystemName, s, NULL, offsetof(Context,
data) + sizeof(char*) * PROP_OS_NAME, SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(OperatingSystemRelease, s, NULL,
offsetof(Context, data) + sizeof(char*) * PROP_OS_RELEASE,
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(OperatingSystemPrettyName, s, NULL,
offsetof(Context, data) + sizeof(char*) * PROP_OS_PRETTY_NAME,
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(OperatingSystemCPEName, s, NULL,
offsetof(Context, data) + sizeof(char*) * PROP_OS_CPE_NAME,
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_METHOD(SetHostname, sb, NULL, method_set_hostname,
SD_BUS_VTABLE_UNPRIVILEGED),
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemd-analyze: read host and system information from remote
On Mon, 07.04.14 22:38, Djalal Harouni (tix...@opendz.org) wrote:
This makes systemd-analyze plot read host information from remote.
While we are it show if this is a virtualized system.
https://bugs.freedesktop.org/show_bug.cgi?id=76498
Looks great! Can you rebase this after renaming the props? will merge then!
Reported-by: Zach zachcook1...@gmail.com
---
src/analyze/analyze.c | 105
++
1 file changed, 81 insertions(+), 24 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index 3d2d08f..49b28d4 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -100,6 +100,15 @@ struct unit_times {
usec_t time;
};
+struct host_info {
+char *hostname;
+char *os_release;
+char *os_version;
+char *os_pretty_name;
+char *virtualization;
+char *architecture;
+};
+
static void pager_open_if_enabled(void) {
if (arg_no_pager)
@@ -170,21 +179,6 @@ static int compare_unit_start(const void *a, const void
*b) {
((struct unit_times *)b)-activating);
}
-static int get_os_name(char **_n) {
-char *n = NULL;
-int r;
-
-r = parse_env_file(/etc/os-release, NEWLINE, PRETTY_NAME, n,
NULL);
-if (r 0)
-return r;
-
-if (!n)
-return -ENOENT;
-
-*_n = n;
-return 0;
-}
-
static void free_unit_times(struct unit_times *t, unsigned n) {
struct unit_times *p;
@@ -372,6 +366,61 @@ finish:
return 0;
}
+static void free_host_info(struct host_info *hi) {
+free(hi-hostname);
+free(hi-os_release);
+free(hi-os_version);
+free(hi-os_pretty_name);
+free(hi-virtualization);
+free(hi-architecture);
+free(hi);
+}
+
+static int acquire_host_info(sd_bus *bus, struct host_info **hi) {
+int r;
+struct host_info *host;
+
+static const struct bus_properties_map hostname_map[] = {
+{ Hostname, s, NULL, offsetof(struct host_info,
hostname) },
+{ OperatingSystemRelease, s, NULL, offsetof(struct
host_info, os_release) },
+{ OperatingSystemVersion, s, NULL, offsetof(struct
host_info, os_version) },
+{ OperatingSystemPrettyName, s, NULL, offsetof(struct
host_info, os_pretty_name) },
+{}
+};
+
+static const struct bus_properties_map manager_map[] = {
+{ Virtualization, s, NULL, offsetof(struct host_info,
virtualization) },
+{ Architecture, s, NULL, offsetof(struct host_info,
architecture) },
+{}
+};
+
+host = new0(struct host_info, 1);
+if (!host)
+return log_oom();
+
+r = bus_map_all_properties(bus,
+ org.freedesktop.hostname1,
+ /org/freedesktop/hostname1,
+ hostname_map,
+ host);
+if (r 0)
+goto fail;
+
+r = bus_map_all_properties(bus,
+ org.freedesktop.systemd1,
+ /org/freedesktop/systemd1,
+ manager_map,
+ host);
+if (r 0)
+goto fail;
+
+*hi = host;
+return 0;
+fail:
+free_host_info(host);
+return r;
+}
+
static int pretty_boot_time(sd_bus *bus, char **_buf) {
char ts[FORMAT_TIMESPAN_MAX];
struct boot_times *t;
@@ -437,10 +486,10 @@ static void svg_graph_box(double height, double begin,
double end) {
static int analyze_plot(sd_bus *bus) {
struct unit_times *times;
struct boot_times *boot;
-struct utsname name;
+struct host_info *host = NULL;
int n, m = 1, y=0;
double width;
-_cleanup_free_ char *pretty_times = NULL, *osname = NULL;
+_cleanup_free_ char *pretty_times = NULL;
struct unit_times *u;
n = acquire_boot_times(bus, boot);
@@ -451,12 +500,13 @@ static int analyze_plot(sd_bus *bus) {
if (n 0)
return n;
-get_os_name(osname);
-assert_se(uname(name) = 0);
+n = acquire_host_info(bus, host);
+if (n 0)
+return n;
n = acquire_time_data(bus, times);
if (n = 0)
-return n;
+goto out;
qsort(times, n, sizeof(struct unit_times), compare_unit_start);
@@ -551,9 +601,13 @@ static int analyze_plot(sd_bus *bus) {
svg(rect class=\background\ width=\100%%\ height=\100%%\
/\n);
svg(text x=\20\ y=\50\%s/text, pretty_times);
-
Re: [systemd-devel] Removing BindsTo with drop-in config
On Thu, 27.03.14 09:36, John Lane (syst...@jelmail.com) wrote: Heya, I need to undo the effect of BindsTo in a unit and have tried to use a drop-in config with it set to empty (BindsTo=) but it doesn't appear to have any effect. Yupp, dependencies cannot be undone with this. And this is unlikely to change I fear... If not, is there another way to achieve this (without editing the unit, which I have no control over). Could you elaborate on the usecase for this? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: add startup resource control option
On Wed, 26.03.14 00:12, WaLyong Cho (walyong@samsung.com) wrote: On 03/25/2014 05:01 AM, Lennart Poettering wrote: On Tue, 25.03.14 01:03, WaLyong Cho (walyong@samsung.com) wrote: /* Figure out which controllers we need */ -if (c-cpu_accounting || c-cpu_shares != 1024) +if (c-cpu_accounting || +c-startup_cpu_shares != 1024 || +(manager_state(m) != MANAGER_STARTING c-cpu_shares != 1024)) This looks incorrect. Shouldn't it be like this: ... if (c-cpu_accounting || (manager-state(m) == MANAGER_STARTING ? c-startup_cpu_shares : c-cpu_shares) != 1024) At previous patch, I also wrote similar with your thought. Assume, some of units just only specified StartupCPUShares=(or StartupBlockIOWeight=). In this case, that unit will not be changed to default weight because global state is already changed to running. So I put startup_cpu_shares condition alone. No sure I understand. The service processes should be removed from the CPU cgroup as soon as the global state reaches RUNNING if only CPUShares= is set, but StartupCPUShares= isn't? Hence the startup cpu shares value should not have an effect anymore. Am I missing something? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
On Wed, 26.03.14 14:55, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
On 03/26/2014 01:50 PM, Kai Hendry wrote:
Thanks Michael for answering, :)
On 26 March 2014 18:59, Michael Biebl mbi...@gmail.com wrote:
2014-03-26 3:56 GMT+01:00 Kai Hendry hen...@webconverger.com:
If your daemon is not functional if the hardware is not present, I'd
probably start it via a udev rule and SYSTEMD_WANTS.
Do you have an example for this please?
I don't quite understand why I can't I just name the device in the
service file. Why does it have to be so confusing. Still don't
understand the need for escaping... is there a need?
The reason is when your hardware becomes available you activate the
service.
My udev foo is a bit rusty but you can try something along the lines of...
/etc/udev/rules.d/98-shk-local.rules
SUBSYSTEM==input, ENV{ID_INPUT_KEYBOARD}==?*,
ENV{.INPUT_CLASS}=kbd, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=shkd@%p.service
/etc/systemd/system/shkd@.service
[Unit]
Description=Simple HotKey Daemon
You really want a BindTo back to the .device unit here, so that the
service is removed as soon as the device vanishes.
[Service]
ExecStart=/usr/local/bin/shkd %I
Restart=always
[Install]
WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
On Wed, 26.03.14 21:50, Kai Hendry (hen...@webconverger.com) wrote: Thanks Michael for answering, :) On 26 March 2014 18:59, Michael Biebl mbi...@gmail.com wrote: 2014-03-26 3:56 GMT+01:00 Kai Hendry hen...@webconverger.com: If your daemon is not functional if the hardware is not present, I'd probably start it via a udev rule and SYSTEMD_WANTS. Do you have an example for this please? I don't quite understand why I can't I just name the device in the service file. Why does it have to be so confusing. Still don't understand the need for escaping... is there a need? Well, on the command line we will actually escape automatically for you, i.e. systemctl status /dev/sda5 will magically turn into systemctl status dev-sda5.device. However, we make stricter requirements when writing unit files to avoid redundant syntaxes, and we should expect the admin to take a little more care... I think this is the right behaviour as it is OK to be a bit more sloppy (and hence user-friendly) for day-to-day command lines, and require more correctness when writing new files. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logind: export *IgnoreInhibited settings to DBus
On Sat, 05.04.14 15:38, Mantas Mikulėnas (graw...@gmail.com) wrote:
Do you have a usecase for this? (Not opposed to the patch, just
wondering. The reason I left this out was mostly that I figured this
wouldn't be useful to anybody to query, and I wanted to keep the iface
small).
---
src/login/logind-dbus.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 0af6714..0e58955 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -1922,6 +1922,10 @@ const sd_bus_vtable manager_vtable[] = {
SD_BUS_PROPERTY(HandleSuspendKey, s, property_get_handle_action,
offsetof(Manager, handle_suspend_key), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(HandleHibernateKey, s,
property_get_handle_action, offsetof(Manager, handle_hibernate_key),
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(HandleLidSwitch, s, property_get_handle_action,
offsetof(Manager, handle_lid_switch), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(PowerKeyIgnoreInhibited, b, NULL,
offsetof(Manager, power_key_ignore_inhibited), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(SuspendKeyIgnoreInhibited, b, NULL,
offsetof(Manager, suspend_key_ignore_inhibited),
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(HibernateKeyIgnoreInhibited, b, NULL,
offsetof(Manager, hibernate_key_ignore_inhibited),
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(LidSwitchIgnoreInhibited, b, NULL,
offsetof(Manager, lid_switch_ignore_inhibited), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(IdleAction, s, property_get_handle_action,
offsetof(Manager, idle_action), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(IdleActionUSec, t, NULL, offsetof(Manager,
idle_action_usec), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(PreparingForShutdown, b, property_get_preparing,
0, 0),
You need to use bus_property_get_bool() for the props, due to the
discrepancy between the size of C99 bool and the C89 int we expose
for booleans in sd-bus. The sizes differ, so it matters how we access
the variables.
Background: internally we use C99 bools. Externally we expose C89 ints
as bools, for example in sd-bus. This means we need some extra glue
whenever we export C99 bools.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] hostnamed: expose OperatingSystemName and OperatingSystemRelease on the bus
On Wed, Apr 23, 2014 at 11:05:53PM +0200, Lennart Poettering wrote: On Thu, 27.03.14 19:48, Djalal Harouni (tix...@opendz.org) wrote: Hmm, thinking about this again, given that this is actually the kernel identity we return here we should really name those props KernelName and KernelRelease... Ok. Sorry for the constant forth and back! Otherwise looks great, can you ren ame the props? will then merge! Ok, I'm updating and testing, patches will follow this thread. BTW there is also this series to close a bugzilla entry: http://lists.freedesktop.org/archives/systemd-devel/2014-April/018496.html It depends on the following patches, I'll update it in its thread. Thanks -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: add waiting jobs to run queue in unit_coldplug
On Tue, 01.04.14 18:45, Michal Sekletar (msekl...@redhat.com) wrote:
When we have job installed and added to run queue for service which is still
in
dead state and systemd initiates reload then after reload we never add
deserialized job to the run queue again. This is caused by check in
service_coldplug() where we check if deserialized state is something else
than dead state, which is not the case thus we never call service_set_state()
and finally unit_notify() where we would have added job to the run queue.
---
This looks correct, but could you move this into job_coldplug()?
Otherwise looks great!
src/core/unit.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/core/unit.c b/src/core/unit.c
index 153b79b..bb7893b 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -2558,6 +2558,9 @@ int unit_coldplug(Unit *u) {
r = job_coldplug(u-job);
if (r 0)
return r;
+
+if (u-job-state == JOB_WAITING)
+job_add_to_run_queue(u-job);
} else if (u-deserialized_job = 0) {
/* legacy */
r = manager_add_job(u-manager, u-deserialized_job, u,
JOB_IGNORE_REQUIREMENTS, false, NULL, NULL);
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/2] hostnamed: expose KernelName and KernelRelease on the bus
---
src/hostname/hostnamed.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 3b19d43..2be6dcd 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -23,6 +23,7 @@
#include string.h
#include unistd.h
#include dlfcn.h
+#include sys/utsname.h
#include util.h
#include strv.h
@@ -40,6 +41,8 @@ enum {
PROP_PRETTY_HOSTNAME,
PROP_ICON_NAME,
PROP_CHASSIS,
+PROP_KERNEL_NAME,
+PROP_KERNEL_RELEASE,
PROP_OS_PRETTY_NAME,
PROP_OS_CPE_NAME,
_PROP_MAX
@@ -70,11 +73,18 @@ static void context_free(Context *c, sd_bus *bus) {
static int context_read_data(Context *c) {
int r;
+struct utsname u;
assert(c);
context_reset(c);
+assert_se(uname(u) = 0);
+c-data[PROP_KERNEL_NAME] = strdup(u.sysname);
+c-data[PROP_KERNEL_RELEASE] = strdup(u.release);
+if (!c-data[PROP_KERNEL_NAME] || !c-data[PROP_KERNEL_RELEASE])
+return -ENOMEM;
+
c-data[PROP_HOSTNAME] = gethostname_malloc();
if (!c-data[PROP_HOSTNAME])
return -ENOMEM;
@@ -555,6 +565,8 @@ static const sd_bus_vtable hostname_vtable[] = {
SD_BUS_PROPERTY(PrettyHostname, s, NULL, offsetof(Context, data) +
sizeof(char*) * PROP_PRETTY_HOSTNAME, SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(IconName, s, property_get_icon_name, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(Chassis, s, property_get_chassis, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+SD_BUS_PROPERTY(KernelName, s, NULL, offsetof(Context, data) +
sizeof(char*) * PROP_KERNEL_NAME, SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(KernelRelease, s, NULL, offsetof(Context, data) +
sizeof(char*) * PROP_KERNEL_RELEASE, SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(OperatingSystemPrettyName, s, NULL,
offsetof(Context, data) + sizeof(char*) * PROP_OS_PRETTY_NAME,
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(OperatingSystemCPEName, s, NULL, offsetof(Context,
data) + sizeof(char*) * PROP_OS_CPE_NAME, SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_METHOD(SetHostname, sb, NULL, method_set_hostname,
SD_BUS_VTABLE_UNPRIVILEGED),
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/2] hostnamectl: read kernel name and release from remote
---
src/hostname/hostnamectl.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 326f371..70049d3 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,8 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *kernel_name;
+char *kernel_release;
char *os_pretty_name;
char *os_cpe_name;
char *virtualization;
@@ -76,7 +78,6 @@ typedef struct StatusInfo {
static void print_status_info(StatusInfo *i) {
sd_id128_t mid = {}, bid = {};
int r;
-struct utsname u;
assert(i);
@@ -112,8 +113,8 @@ static void print_status_info(StatusInfo *i) {
if (!isempty(i-os_cpe_name))
printf( CPE OS Name: %s\n, i-os_cpe_name);
-assert_se(uname(u) = 0);
-printf(Kernel: %s %s\n, u.sysname, u.release);
+if (!isempty(i-kernel_name) !isempty(i-kernel_release))
+printf(Kernel: %s %s\n, i-kernel_name,
i-kernel_release);
if (!isempty(i-architecture))
printf( Architecture: %s\n, i-architecture);
@@ -156,6 +157,8 @@ static int show_all_names(sd_bus *bus) {
{ PrettyHostname, s, NULL, offsetof(StatusInfo,
pretty_hostname) },
{ IconName, s, NULL, offsetof(StatusInfo, icon_name)
},
{ Chassis,s, NULL, offsetof(StatusInfo, chassis) },
+{ KernelName, s, NULL, offsetof(StatusInfo,
kernel_name) },
+{ KernelRelease, s, NULL, offsetof(StatusInfo,
kernel_release) },
{ OperatingSystemPrettyName, s, NULL,
offsetof(StatusInfo, os_pretty_name) },
{ OperatingSystemCPEName,s, NULL,
offsetof(StatusInfo, os_cpe_name) },
{}
@@ -191,6 +194,8 @@ fail:
free(info.pretty_hostname);
free(info.icon_name);
free(info.chassis);
+free(info.kernel_name);
+free(info.kernel_release);
free(info.os_pretty_name);
free(info.os_cpe_name);
free(info.virtualization);
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/2] hostnamectl: read kernel name and release from remote
On Wed, 23.04.14 22:41, Djalal Harouni (tix...@opendz.org) wrote:
Applied both! Thanks!
---
src/hostname/hostnamectl.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 326f371..70049d3 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -67,6 +67,8 @@ typedef struct StatusInfo {
char *pretty_hostname;
char *icon_name;
char *chassis;
+char *kernel_name;
+char *kernel_release;
char *os_pretty_name;
char *os_cpe_name;
char *virtualization;
@@ -76,7 +78,6 @@ typedef struct StatusInfo {
static void print_status_info(StatusInfo *i) {
sd_id128_t mid = {}, bid = {};
int r;
-struct utsname u;
assert(i);
@@ -112,8 +113,8 @@ static void print_status_info(StatusInfo *i) {
if (!isempty(i-os_cpe_name))
printf( CPE OS Name: %s\n, i-os_cpe_name);
-assert_se(uname(u) = 0);
-printf(Kernel: %s %s\n, u.sysname, u.release);
+if (!isempty(i-kernel_name) !isempty(i-kernel_release))
+printf(Kernel: %s %s\n, i-kernel_name,
i-kernel_release);
if (!isempty(i-architecture))
printf( Architecture: %s\n, i-architecture);
@@ -156,6 +157,8 @@ static int show_all_names(sd_bus *bus) {
{ PrettyHostname, s, NULL, offsetof(StatusInfo,
pretty_hostname) },
{ IconName, s, NULL, offsetof(StatusInfo,
icon_name) },
{ Chassis,s, NULL, offsetof(StatusInfo, chassis)
},
+{ KernelName, s, NULL, offsetof(StatusInfo,
kernel_name) },
+{ KernelRelease, s, NULL, offsetof(StatusInfo,
kernel_release) },
{ OperatingSystemPrettyName, s, NULL,
offsetof(StatusInfo, os_pretty_name) },
{ OperatingSystemCPEName,s, NULL,
offsetof(StatusInfo, os_cpe_name) },
{}
@@ -191,6 +194,8 @@ fail:
free(info.pretty_hostname);
free(info.icon_name);
free(info.chassis);
+free(info.kernel_name);
+free(info.kernel_release);
free(info.os_pretty_name);
free(info.os_cpe_name);
free(info.virtualization);
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/2] hostnamed: expose KernelVersion on the bus
This is needed to fix bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76498
Reported-by: Zach zachcook1...@gmail.com
---
src/hostname/hostnamed.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 2be6dcd..a798f16 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -43,6 +43,7 @@ enum {
PROP_CHASSIS,
PROP_KERNEL_NAME,
PROP_KERNEL_RELEASE,
+PROP_KERNEL_VERSION,
PROP_OS_PRETTY_NAME,
PROP_OS_CPE_NAME,
_PROP_MAX
@@ -82,7 +83,9 @@ static int context_read_data(Context *c) {
assert_se(uname(u) = 0);
c-data[PROP_KERNEL_NAME] = strdup(u.sysname);
c-data[PROP_KERNEL_RELEASE] = strdup(u.release);
-if (!c-data[PROP_KERNEL_NAME] || !c-data[PROP_KERNEL_RELEASE])
+c-data[PROP_KERNEL_VERSION] = strdup(u.version);
+if (!c-data[PROP_KERNEL_NAME] || !c-data[PROP_KERNEL_RELEASE] ||
+!c-data[PROP_KERNEL_VERSION])
return -ENOMEM;
c-data[PROP_HOSTNAME] = gethostname_malloc();
@@ -567,6 +570,7 @@ static const sd_bus_vtable hostname_vtable[] = {
SD_BUS_PROPERTY(Chassis, s, property_get_chassis, 0,
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(KernelName, s, NULL, offsetof(Context, data) +
sizeof(char*) * PROP_KERNEL_NAME, SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KernelRelease, s, NULL, offsetof(Context, data) +
sizeof(char*) * PROP_KERNEL_RELEASE, SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(KernelVersion, s, NULL, offsetof(Context, data) +
sizeof(char*) * PROP_KERNEL_VERSION, SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(OperatingSystemPrettyName, s, NULL,
offsetof(Context, data) + sizeof(char*) * PROP_OS_PRETTY_NAME,
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(OperatingSystemCPEName, s, NULL, offsetof(Context,
data) + sizeof(char*) * PROP_OS_CPE_NAME, SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_METHOD(SetHostname, sb, NULL, method_set_hostname,
SD_BUS_VTABLE_UNPRIVILEGED),
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/2] analyze: read host and system information from remote
This makes systemd-analyze plot read host information from remote.
While we are it show if this is a virtualized system.
https://bugs.freedesktop.org/show_bug.cgi?id=76498
Reported-by: Zach zachcook1...@gmail.com
---
src/analyze/analyze.c | 109 +++---
1 file changed, 85 insertions(+), 24 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index ebaa9d0..4c5fcfe 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -100,6 +100,16 @@ struct unit_times {
usec_t time;
};
+struct host_info {
+char *hostname;
+char *kernel_name;
+char *kernel_release;
+char *kernel_version;
+char *os_pretty_name;
+char *virtualization;
+char *architecture;
+};
+
static void pager_open_if_enabled(void) {
if (arg_no_pager)
@@ -170,21 +180,6 @@ static int compare_unit_start(const void *a, const void
*b) {
((struct unit_times *)b)-activating);
}
-static int get_os_name(char **_n) {
-char *n = NULL;
-int r;
-
-r = parse_env_file(/etc/os-release, NEWLINE, PRETTY_NAME, n,
NULL);
-if (r 0)
-return r;
-
-if (!n)
-return -ENOENT;
-
-*_n = n;
-return 0;
-}
-
static void free_unit_times(struct unit_times *t, unsigned n) {
struct unit_times *p;
@@ -372,6 +367,63 @@ finish:
return 0;
}
+static void free_host_info(struct host_info *hi) {
+free(hi-hostname);
+free(hi-kernel_name);
+free(hi-kernel_release);
+free(hi-kernel_version);
+free(hi-os_pretty_name);
+free(hi-virtualization);
+free(hi-architecture);
+free(hi);
+}
+
+static int acquire_host_info(sd_bus *bus, struct host_info **hi) {
+int r;
+struct host_info *host;
+
+static const struct bus_properties_map hostname_map[] = {
+{ Hostname, s, NULL, offsetof(struct host_info, hostname)
},
+{ KernelName, s, NULL, offsetof(struct host_info,
kernel_name) },
+{ KernelRelease, s, NULL, offsetof(struct host_info,
kernel_release) },
+{ KernelVersion, s, NULL, offsetof(struct host_info,
kernel_version) },
+{ OperatingSystemPrettyName, s, NULL, offsetof(struct
host_info, os_pretty_name) },
+{}
+};
+
+static const struct bus_properties_map manager_map[] = {
+{ Virtualization, s, NULL, offsetof(struct host_info,
virtualization) },
+{ Architecture, s, NULL, offsetof(struct host_info,
architecture) },
+{}
+};
+
+host = new0(struct host_info, 1);
+if (!host)
+return log_oom();
+
+r = bus_map_all_properties(bus,
+ org.freedesktop.hostname1,
+ /org/freedesktop/hostname1,
+ hostname_map,
+ host);
+if (r 0)
+goto fail;
+
+r = bus_map_all_properties(bus,
+ org.freedesktop.systemd1,
+ /org/freedesktop/systemd1,
+ manager_map,
+ host);
+if (r 0)
+goto fail;
+
+*hi = host;
+return 0;
+fail:
+free_host_info(host);
+return r;
+}
+
static int pretty_boot_time(sd_bus *bus, char **_buf) {
char ts[FORMAT_TIMESPAN_MAX];
struct boot_times *t;
@@ -437,10 +489,10 @@ static void svg_graph_box(double height, double begin,
double end) {
static int analyze_plot(sd_bus *bus) {
struct unit_times *times;
struct boot_times *boot;
-struct utsname name;
+struct host_info *host = NULL;
int n, m = 1, y=0;
double width;
-_cleanup_free_ char *pretty_times = NULL, *osname = NULL;
+_cleanup_free_ char *pretty_times = NULL;
struct unit_times *u;
n = acquire_boot_times(bus, boot);
@@ -451,12 +503,13 @@ static int analyze_plot(sd_bus *bus) {
if (n 0)
return n;
-get_os_name(osname);
-assert_se(uname(name) = 0);
+n = acquire_host_info(bus, host);
+if (n 0)
+return n;
n = acquire_time_data(bus, times);
if (n = 0)
-return n;
+goto out;
qsort(times, n, sizeof(struct unit_times), compare_unit_start);
@@ -551,9 +604,14 @@ static int analyze_plot(sd_bus *bus) {
svg(rect class=\background\ width=\100%%\ height=\100%%\
/\n);
svg(text x=\20\ y=\50\%s/text, pretty_times);
-svg(text x=\20\ y=\30\%s %s (%s %s) %s/text,
-isempty(osname) ? Linux : osname,
-name.nodename, name.release, name.version,
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Mon, Apr 21, 2014 at 07:59:52PM +0200, Kay Sievers wrote:
On Sun, Apr 20, 2014 at 8:08 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Sun, Apr 20, 2014 at 03:53:05PM +0200, Kay Sievers wrote:
On Sun, Apr 20, 2014 at 5:36 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
Hi Kay,
it seems that handles are not crucial, and the simplified version below
works too. Is there something I'm missing?
The name_to_handle API works properly with bind mounts, it's the more
reliable API.
It also was intentional to support any filesystem with the prefix
devtmpfs*, like devtmpfs2 or whatever it might be named in the
future.
What actual problem are we trying to solve here with not requiring a
common kernel config option? We want/need it in other places too, and
the current fallback logic to figure out the mount point is really not
that great with bind mounts. We just need the fallback for filesystems
which do not support the API, but most common and tmpfs/devtmpfs do.
I don't necessarily see the point in supporting the idea of the
kernel's uber-configurability and the massive pain it causes for tools
to make things work.
Yeah, I'm just trying to reduce the confusion that people experience
on kernels without CONFIG_FHANDLE.
What about this:
8-
Subject: [PATCH] udev: assume /dev is devtmpfs if name_to_handle_at is not
implemented
We have a bunch of reports from people who have a custom kernel and
are confused why udev is not running. This raises the possibility of a
false positive when running on a kernel without CONFIG_FHANDLE but in a
container. Nevertheless, this caes should be easier to diagnose than
the opposite of running on bare metal with the same kernel.
I really don't see the problem with hard-requiring a commonly
available kernel feature, especially if it involves returning results
which might be incorrect.
+log_warning(name_to_handle_at syscall failed,
assuming /dev is volatile.);
Libraries should never log for normal operation, only debugging is ok.
+return true;
+}
+return false;
+}
f = fopen(/proc/self/mountinfo, re);
if (!f)
@@ -139,8 +146,7 @@ static bool udev_has_devtmpfs(struct udev *udev) {
continue;
/* accept any name that starts with the currently expected
type */
-if (startswith(e + 3, devtmpfs))
-return true;
+return startswith(e + 3, devtmpfs);
}
If we really wanted that kind of fallback, we should falling back to
parsing mountinfo for devtmpfs and ignoring the mount_id in this
loop. But since we need that syscall not only here, I don't think we
should do that. We should just explain what we need and simply refuse
to bootup, just like we should refuse to bootup without cgroups
available.
Supporting less reliable operation modes for something that just needs
to be configured in the kernel seems the wrong approach, especially
when it involves filesystem operations on user data like tmpfiles
does, we just depend on CONFIG_FHANDLE.
OK, what about this:
---8--
udev: warn when name_to_handle_at is not implemented
We have a bunch of reports from people who have a custom kernel and
are confused why udev is not running. Issue a warning on
error. Barring an error in the code, the only error that is possible
is ENOSYS.
https://bugzilla.redhat.com/show_bug.cgi?id=1072966
diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 0a2ab82..b9972c9 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -115,9 +115,11 @@ static bool udev_has_devtmpfs(struct udev *udev) {
int r;
r = name_to_handle_at(AT_FDCWD, /dev, h.handle, mount_id, 0);
-if (r 0)
+if (r 0) {
+if (errno != EOPNOTSUPP)
+udev_err(udev, name_to_handle_at on /dev: %m\n);
return false;
-
+}
f = fopen(/proc/self/mountinfo, re);
if (!f)
---8--
Note that this makes missing name_to_handle_at behave similar to failing
socket(), etc, so seems to be in line with surrounding code.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Revisiting the ExecRestart issue
On Wed, Apr 23, 2014 at 1:18 AM, Lennart Poettering lenn...@poettering.netwrote: UDP is lossy anyway, and a startup delay of a few seconds shouldn't be an issue at all. If we are speaking of 15min or so here, that might be a problem, but otherwise this really sounds fine. And if your daemon really takes 15min this sounds like something to look into... There are many values between a few seconds and 15 minutes that are both (a) reasonable startup times given the user's large configuration and (b) undesirable downtime for a critical service like DNS. At this point in time I am quite sure that ExecReload= should simply be used for this. That's an acceptable answer, although I think in the long term it poses some questions about additional custom verbs, since at least gdnsd now really wants two different reload-like actions (a simple SIGHUP that reloads zone data vs the overlapped-restart under discussion here). But for now, the easy case (SIGHUP) can just be done outside of systemd/systemctl without any ill effects. -- Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Revisiting the ExecRestart issue
On Wed, Apr 23, 2014 at 3:06 PM, Lennart Poettering lenn...@poettering.netwrote: To recap my results: there were primarily two things in the way of naively using ExecReload to trigger gdnsd's overlapped restart: 1) gdnsd wants to use sd_notifyf() to indicate the MAINPID switch in the new daemon, which is a descendant of the ExecReload process. The ExecReloadprocess doesn't get a copy of $NOTIFY_SOCKET even with NotifyAccess=all. So I hacked around that by having the daemon set $NOTIFY_SOCKET for itself, to the value @/org/freedesktop/systemd1/notify, which seems semi-standard for the moment. 2) ExecReload control processes can't become the MAINPID even after notification because they're not in the correct cgroup (or subgroup, or whatever it is that's special about most control procs), unlike Start'scontrol process, which is in the right cgroup for its descendants to become MAINPID successfully. This was hacked around by grabbing the basic unit name from sd_pid_get_unit() (let's call the result $U) and then writing our pid to /sys/fs/cgroup/systemd /system.slice/$U/cgroup.procs from the new daemon before it drops root privs and later notifies about the MAINPID switch. Hmm, yeah, the new process really needs to be forked off the original main process. The problem here is that the daemon performs operations that require root privilege on startup, and then dumps its privileges for runtime, and thus its execve'd child won't have the root privs it would need to start everything over again. In theory some of these privileged things, like listening sockets, could be handed to the exec child, but that assumes the configured set of listening sockets hasn't changed (which might be the reason for the restart). Other things like mlockall() can't be handed off over fork/execve once privileges are gone. Control processes really can't become the main process I fear... They can; I've already done it by writing to /sys as documented above, but that doesn't seem like a reliable API for doing so going forward on all platforms and in all situations. What's the fundamental problem with officially letting a control process from ExecReload= become the main process via some reasonably-standard mechanism? That's already what happens to the control process for ExecStart=. I'd propose two changes (and work on the patches myself) that would make this case work for me reliably, if they're acceptable: 1) Can we get $NOTIFY_SOCKET set for control procs like ExecReload when NotifyAccess=all ? That's what I initially thought that setting would do, but apparently it doesn't. Or any other standard mechanism I could rely on so that I'm not hardcoding a fallback socket path. 2) Given the above, would it be reasonable that if a control process from a verb like ExecReload sent a MAINPID= message over the control socket, systemd would accept this as the new main pid *and* internally take care of promoting the specified PID to the proper cgroup? -- Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
В Wed, 23 Apr 2014 20:30:35 +0200 Lennart Poettering lenn...@poettering.net пишет: On Wed, 23.04.14 13:15, Leonid Isaev (lis...@umail.iu.edu) wrote: Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... Hmm, thinking about this: the problem is actually not restricted to persistent timers, any timer that has OnBootSec=10ms or so is also affected by this, should the boot take longer than 10ms... Another option might be to change what Type=idle means: instead of making it wait until the job queue is empty it might be better to simply make it wait until the default job is finished (with other words, until graphical.target is reached). I think it was discussed in the past and it was exact reason Idle was introduced - because default.target is not accurate representation of finished startup sequence. Is it technically possible to track jobs that resulted from dependency closure of default.target? I.e. all units pulled in (directly or indirectly) by default target? This would probably be more accurate approximation of at the end of startup and automatically fix problem discussed here. It would also provide more or less useful startup finished synchronization point. That way it doesn't matter what services are added in by timers... Somehow this appears like the better solution to me. This probably also means changing the manager state machine, and splitting its starting state into two: one state for the time until the default target is not yet reached, and a second state for the time until the job queue is actually empty. I added this to the TODO list now. I'd be happy to take a patch for this though! Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit configuration for S3QL filesystem
On Wed, 23.04.14 20:39, Nikolaus Rath (nikol...@rath.org) wrote: Lennart Poettering lenn...@poettering.net writes: systemd will invoke /bin/mount when mounting a file system, and /bin/umount when unmountin it. fuse file systems may fork off background processes from there, that will be kept around while the file system is mounted, and terminated atfer the file system is unmounted again. Is there any way to avoid that, and give the background process some time to terminate on its own? It has that. We always send SIGTERM first, and after a timeout of 90s (by default) this is followed by SIGKILL if the process didn't exit on its own by then. Apologies, I couldn't deduce that from your above statement, nor was I able to find this in systemd.mount(5). The latter only talks about processes being killed when the mount command did not return after TimeoutSec seconds. Does this mean (hypothetically, I know it wouldn't be helpful) that I could also use the other options from systemd.kill(5), so that if e.g. I set KillMode=process any child processes of the mount helper will actually be left alive? Yes, the system.mount(5) man page is actually pretty clear that the options from system.kill(5) apply too. It references that man page at least four times... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Thu, Apr 24, 2014 at 06:35:58AM +0200, Lennart Poettering wrote:
On Thu, 24.04.14 02:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
Supporting less reliable operation modes for something that just needs
to be configured in the kernel seems the wrong approach, especially
when it involves filesystem operations on user data like tmpfiles
does, we just depend on CONFIG_FHANDLE.
OK, what about this:
---8--
udev: warn when name_to_handle_at is not implemented
We have a bunch of reports from people who have a custom kernel and
are confused why udev is not running. Issue a warning on
error. Barring an error in the code, the only error that is possible
is ENOSYS.
https://bugzilla.redhat.com/show_bug.cgi?id=1072966
diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 0a2ab82..b9972c9 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -115,9 +115,11 @@ static bool udev_has_devtmpfs(struct udev *udev) {
int r;
r = name_to_handle_at(AT_FDCWD, /dev, h.handle, mount_id, 0);
-if (r 0)
+if (r 0) {
+if (errno != EOPNOTSUPP)
+udev_err(udev, name_to_handle_at on /dev: %m\n);
return false;
-
+}
f = fopen(/proc/self/mountinfo, re);
if (!f)
---8--
Note that this makes missing name_to_handle_at behave similar to failing
socket(), etc, so seems to be in line with surrounding code.
Have you checked that EOPNOTSUPP is really the error that is returned by
name_to_handle_at() if the kernel has the entire syscall disabled? Note
that there are two different cases to distuingish here: a file system
not supporting the operation, and the kernel not supporting the
syscal...
It's warning on everything except EOPNOTSUPP. My reasoning is:
EOPNOTSUPP - syscall supported, but wrong fs type, - return false
ENOSYS - syscall not supported - warn and return false
any other error - memory error or other major screw-up - warn and return false
Looking at path_is_mount_point() suggests ENOSYS is used? Or is that
function checking for the wrong error code?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Thu, 24.04.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Have you checked that EOPNOTSUPP is really the error that is returned by name_to_handle_at() if the kernel has the entire syscall disabled? Note that there are two different cases to distuingish here: a file system not supporting the operation, and the kernel not supporting the syscal... It's warning on everything except EOPNOTSUPP. My reasoning is: EOPNOTSUPP - syscall supported, but wrong fs type, - return false ENOSYS - syscall not supported - warn and return false any other error - memory error or other major screw-up - warn and return false Looks good to me then, Kay? Though I still wonder about the difference between ENOTSUP and EOPNOTSUPP. path_is_mount_point() expectes the former, your patch the latter? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Thu, 24.04.14 07:35, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 24.04.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Have you checked that EOPNOTSUPP is really the error that is returned by name_to_handle_at() if the kernel has the entire syscall disabled? Note that there are two different cases to distuingish here: a file system not supporting the operation, and the kernel not supporting the syscal... It's warning on everything except EOPNOTSUPP. My reasoning is: EOPNOTSUPP - syscall supported, but wrong fs type, - return false ENOSYS - syscall not supported - warn and return false any other error - memory error or other major screw-up - warn and return false Looks good to me then, Kay? Though I still wonder about the difference between ENOTSUP and EOPNOTSUPP. path_is_mount_point() expectes the former, your patch the latter? Got it, on Linux ENOTSUP is simply an alias for EOPNOTSUPP... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
