Re: [systemd-devel] systemd not in a steady state, although system is fine.
On Tue, Mar 31, 2015 at 7:46 AM, kenneth topp wrote: >> В Mon, 30 Mar 2015 19:35:21 -0400 >> "kenneth topp" пишет: >> >>> >>> Hi, >>> >>> My system appears healthy, but for some reason systemd not in a good >>> state. >>> >>> From the commands and their output, I have two concerns. >>> 1) why is the state "starting" and not finished? >>> 2) what are these "jobs" that are running? >>> >> >> systemctl list-jobs >> > > Hi, Thanks, I see these jobs, I just don't know why the jobs are running. > They don't seem to be doing anything, and the unit doesn't offer any clue, > and the block device is up. > > ken > > [root@static ~]# systemctl list-jobs > JOB UNIT TYPE STATE > 208 dev-mapper-hp22.cfs.device start running > 205 dev-mapper-hp27.cfs.device start running > 199 dev-mapper-hp29.cfs.device start running > 196 dev-mapper-hp30.cfs.device start running > > 4 jobs listed. > Do you have any mount points or crypto units using these devices? What systemctl show -p RequiredBy -p WantedBy dev-mapper-hp22.cfs.device dev-mapper-hp27.cfs.device dev-mapper-hp29.cfs.device dev-mapper-hp30.cfs.device show? > [root@static ~]# systemctl status dev-mapper-hp22.cfs.device > ● dev-mapper-hp22.cfs.device >Loaded: loaded > Drop-In: /run/systemd/generator/dev-mapper-hp22.cfs.device.d >└─90-device-timeout.conf >Active: inactive (dead) > > > [root@static ~]# lsblk /dev/mapper/hp27.cfs > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > hp27.cfs 253:70 2.7T 0 crypt > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-run and waiting for initialization
It would be really nice to have an utility that waits until a unit is transitioned from the activating state. My problem is that I wanted to replace in a shell script a sequence like: sudo -u some_user ssh -f port_forwarding host use_forwarded_ports kill hopefully rightly guessed ssh PID with something like sudo systemd-run --uid user --service-type=forking ... ssh -f port_forwarding host use_forwarded_ports sudo systemctl stop unit_name as that is easier to make reliable. However, this does not work as I expected as systemd-run does not wait for the ssh -f unit to transition from the activating state indicating that port forwarding is established. So I need to implement own wait or polling. On 31 March 2015 at 05:51, Andrei Borzenkov wrote: > В Mon, 30 Mar 2015 09:48:25 +0200 > Igor Bukanov пишет: > > > As I understand, the systemd-run utility returns immediately even with > > --service-type=forking. What is the proper way then to wait using a shell > > until the main service process forks the child and exists signaling > > initialization? > > It is not limited to forking. systemd-run simply queues request to > start unit, same as systemctl does. It would need to actually wait > until systemd reports that unit is started. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl not showing most boots/logs
2015-03-27 22:58 GMT+01:00 Michael Biebl : > After moving away all ~ files: > # journalctl --list-boots | wc -l > 100 > # journalctl -F _BOOT_ID | wc -l > 104 > > It also scares me a bit, that journald is so prone to create those ~ > files that often. My system is not particularly unstable or crashing > in any way. > Any further ideas? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On 03/31/2015 05:13 AM, David Timothy Strauss wrote: > On Fri, Mar 27, 2015 at 7:56 PM, WaLyong Cho wrote: >> Hmm, it seems not. When I added MemoryLimit= option to just one service, >> cgroups for every unit were generated on memory cgroup. > > It looks like memory_limit and cpu_quota_per_sec_usec both have this > potential issue. The other four controllers managed this way are > clearly proportional (using weights or shares). > Then, is this patch able to be a solution? http://lists.freedesktop.org/archives/systemd-devel/2015-March/029885.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd not in a steady state, although system is fine.
> Ð Mon, 30 Mar 2015 19:35:21 -0400 > "kenneth topp" пиÑеÑ: > >> >> Hi, >> >> My system appears healthy, but for some reason systemd not in a good >> state. >> >> From the commands and their output, I have two concerns. >> 1) why is the state "starting" and not finished? >> 2) what are these "jobs" that are running? >> > > systemctl list-jobs > Hi, Thanks, I see these jobs, I just don't know why the jobs are running. They don't seem to be doing anything, and the unit doesn't offer any clue, and the block device is up. ken [root@static ~]# systemctl list-jobs JOB UNIT TYPE STATE 208 dev-mapper-hp22.cfs.device start running 205 dev-mapper-hp27.cfs.device start running 199 dev-mapper-hp29.cfs.device start running 196 dev-mapper-hp30.cfs.device start running 4 jobs listed. [root@static ~]# systemctl status dev-mapper-hp22.cfs.device ● dev-mapper-hp22.cfs.device Loaded: loaded Drop-In: /run/systemd/generator/dev-mapper-hp22.cfs.device.d └─90-device-timeout.conf Active: inactive (dead) [root@static ~]# lsblk /dev/mapper/hp27.cfs NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT hp27.cfs 253:70 2.7T 0 crypt ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Drop systemd-ui
On Mon, Mar 30, 2015 at 8:34 PM, Andrei Borzenkov wrote: > В Mon, 30 Mar 2015 19:30:02 -0700 > Shawn Landden пишет: > >> > >> > What do you feel is missing from systemctl show? >> It is only suppose to show fields that have been changed by humans >> (even the developer) not systemd defaults. >> > > > From its appearance it was supposed to show current unit properties in > machine parseable format. Are you sure you do not confused it with > "systemd cat"? Yes I am sure, I wrote "systemctl cat". -- Liberty equality fraternity or death, Shawn Landden ChurchOfGit.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-run and waiting for initialization
В Mon, 30 Mar 2015 09:48:25 +0200 Igor Bukanov пишет: > As I understand, the systemd-run utility returns immediately even with > --service-type=forking. What is the proper way then to wait using a shell > until the main service process forks the child and exists signaling > initialization? It is not limited to forking. systemd-run simply queues request to start unit, same as systemctl does. It would need to actually wait until systemd reports that unit is started. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd not in a steady state, although system is fine.
В Mon, 30 Mar 2015 19:35:21 -0400 "kenneth topp" пишет: > > Hi, > > My system appears healthy, but for some reason systemd not in a good state. > > From the commands and their output, I have two concerns. > 1) why is the state "starting" and not finished? > 2) what are these "jobs" that are running? > systemctl list-jobs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Drop systemd-ui
В Mon, 30 Mar 2015 19:30:02 -0700 Shawn Landden пишет: > > > > What do you feel is missing from systemctl show? > It is only suppose to show fields that have been changed by humans > (even the developer) not systemd defaults. > > From its appearance it was supposed to show current unit properties in machine parseable format. Are you sure you do not confused it with "systemd cat"? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] macro: allow assert_se() assertions to also be optimized when NDEBUG is set
replaces log with assert() to remove strings.
saves 3kB from text section of systemd.
---
src/shared/macro.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/shared/macro.h b/src/shared/macro.h
index 7f89951..8cbff01 100644
--- a/src/shared/macro.h
+++ b/src/shared/macro.h
@@ -212,17 +212,21 @@ static inline unsigned long ALIGN_POWER2(unsigned long u)
{
(__x / __y + !!(__x % __y));\
})
-#define assert_se(expr) \
-do {\
-if (_unlikely_(!(expr)))\
-log_assert_failed(#expr, __FILE__, __LINE__,
__PRETTY_FUNCTION__); \
-} while (false) \
-
/* We override the glibc assert() here. */
#undef assert
#ifdef NDEBUG
+#define assert_se(expr) \
+do {\
+if (_unlikely_(!(expr)))\
+abort();\
+} while (false)
#define assert(expr) do {} while(false)
#else
+#define assert_se(expr) \
+do {\
+if (_unlikely_(!(expr)))\
+log_assert_failed(#expr, __FILE__, __LINE__,
__PRETTY_FUNCTION__); \
+} while (false)
#define assert(expr) assert_se(expr)
#endif
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] macro: allow assert_se() assertions to also be optimized out when NDEBUG is set
On Mon, Mar 30, 2015 at 5:04 PM, Djalal Harouni wrote: > On Fri, Mar 27, 2015 at 09:51:26AM -0700, Shawn Landden wrote: >> On Fri, Mar 27, 2015 at 8:16 AM, Tom Gundersen wrote: > [...] >> >> * Current expression may modify/interact with a global state which may >> >> cause a fatal error, and if the caller wants to know if that failed, >> >> then abort(), your patch just introduced a regression, without the >> >> explicit abort(), all callers now have to call abort(). >> > >> > Yeah, this is the point I think. I still think the patch makes sense >> > though, it really don't see why there should be a distinction between >> > assert_se() and assert() when it comes to logging and aborting. >> > >> > If assert_se() fails it indicates we may have messed up the global >> > state, and if assert() fails it indicates that the global state may be >> > messed up (by someone else). Either way the global state is >> > potentially messed up and not logging/aborting seems as (un)safe in >> > both situations. >> > >> > Another way of seeing it, intuitively I don't see why we should >> > distinguish between >> > >> > assert_se(foo() >= 0); >> > >> > and >> > >> > r = foo(); >> > assert(r >= 0); >> Yes. The use case is that embedded people don't want all the strings >> that the logging adds to their binaries when these are ASSERTS, they >> are only expected to catch programming errors. It is not to make it >> faster, I think that is negligible. > Hmm embedded cases are real, I had to deal with some in the past. But > not sure here since I didn't see any numbers before/after stripping, but > perhaps you can start by updating the callers and their semantics if you > think that the code there is robust and it's worth it... ? How about we leave the abort() and just drop the logging with NDEBUG set? I think the performance impact is negligible, I just want to drop all the strings. Perhaps we could replace the logging with backtrace() in this case? > > Thanks! > > -- > Djalal Harouni > http://opendz.org > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Shawn Landden ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Drop systemd-ui
On Mon, Mar 30, 2015 at 4:02 PM, "Jóhann B. Guðmundsson" wrote: > > > On 03/30/2015 10:32 PM, Shawn Landden wrote: >> >> On Mon, Mar 30, 2015 at 1:35 PM, "Jóhann B. Guðmundsson" >> wrote: >>> >>> Heyja >>> >>> Should this not be dropped and *DE write,integrate/implement an graphical >>> frontend to systemd for themselves? >>> >>> It's not like this is receiving the love it needs, hence I'm pretty sure >>> nobody is using this. >> >> Parts of systemd arn't getting the love they need either, such as >> systemctl show. > > > For systemd ui the *DE communities are better suited to implement, integrate > and maintain an ui on top of systemd for their *DE. https://wiki.gnome.org/Apps/Logs I see the dbus type problems you are probably getting. Isn't this actually a bug in systemd as we are still exporting as systemd1? If we are incompatible shouldn't we be systemd2? > > What do you feel is missing from systemctl show? It is only suppose to show fields that have been changed by humans (even the developer) not systemd defaults. > > JBG -- Liberty equality fraternity or death, Shawn Landden ChurchOfGit.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] macro: allow assert_se() assertions to also be optimized out when NDEBUG is set
On Fri, Mar 27, 2015 at 09:51:26AM -0700, Shawn Landden wrote: > On Fri, Mar 27, 2015 at 8:16 AM, Tom Gundersen wrote: [...] > >> * Current expression may modify/interact with a global state which may > >> cause a fatal error, and if the caller wants to know if that failed, > >> then abort(), your patch just introduced a regression, without the > >> explicit abort(), all callers now have to call abort(). > > > > Yeah, this is the point I think. I still think the patch makes sense > > though, it really don't see why there should be a distinction between > > assert_se() and assert() when it comes to logging and aborting. > > > > If assert_se() fails it indicates we may have messed up the global > > state, and if assert() fails it indicates that the global state may be > > messed up (by someone else). Either way the global state is > > potentially messed up and not logging/aborting seems as (un)safe in > > both situations. > > > > Another way of seeing it, intuitively I don't see why we should > > distinguish between > > > > assert_se(foo() >= 0); > > > > and > > > > r = foo(); > > assert(r >= 0); > Yes. The use case is that embedded people don't want all the strings > that the logging adds to their binaries when these are ASSERTS, they > are only expected to catch programming errors. It is not to make it > faster, I think that is negligible. Hmm embedded cases are real, I had to deal with some in the past. But not sure here since I didn't see any numbers before/after stripping, but perhaps you can start by updating the callers and their semantics if you think that the code there is robust and it's worth it... ? Thanks! -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd not in a steady state, although system is fine.
Hi, My system appears healthy, but for some reason systemd not in a good state. From the commands and their output, I have two concerns. 1) why is the state "starting" and not finished? 2) what are these "jobs" that are running? This happens to be four luks partitions that go into a btrfs filesystem (which is mounted fine). I also have another btrfs filesystem made of two luks partitions that aren't showing this issue (and is also mounted fine) Any documentation or pointers as to how to debug would be nice. running systemd-216-24.fc21.x86_64. ken [root@static ~]# systemctl status | head -3 ● static.bllue.org State: starting Jobs: 4 queued [root@static ~]# systemctl --state=dead UNIT LOAD ACTIVE SUB JOB DESCRIPTION dev-mapper-hp22.cfs.device loaded inactive dead start dev-mapper-hp22.cfs.device dev-mapper-hp28.cfs.device loaded inactive dead start dev-mapper-hp28.cfs.device dev-mapper-hp29.cfs.device loaded inactive dead start dev-mapper-hp29.cfs.device dev-mapper-hp30.cfs.device loaded inactive dead start dev-mapper-hp30.cfs.device LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. JOB = Pending job for the unit. 4 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. [root@static ~]# btrfs fi show Label: 't2' uuid: cf65d309-0792-4f6b-b802-8e99509410b6 Total devices 2 FS bytes used 672.00KiB devid1 size 447.13GiB used 2.03GiB path /dev/mapper/hp30.cfs devid2 size 447.13GiB used 2.01GiB path /dev/mapper/hp31.cfs Label: 'tm' uuid: 95fbdd87-16f0-4297-a847-ef0ea2cdcbf2 Total devices 4 FS bytes used 8.00TiB devid2 size 1.82TiB used 1.76TiB path /dev/mapper/hp22.cfs devid3 size 2.73TiB used 2.65TiB path /dev/mapper/hp27.cfs devid4 size 1.82TiB used 1.77TiB path /dev/mapper/hp28.cfs devid5 size 2.73TiB used 2.54TiB path /dev/mapper/hp29.cfs btrfs-progs v3.19.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Drop systemd-ui
On 03/30/2015 10:32 PM, Shawn Landden wrote: On Mon, Mar 30, 2015 at 1:35 PM, "Jóhann B. Guðmundsson" wrote: Heyja Should this not be dropped and *DE write,integrate/implement an graphical frontend to systemd for themselves? It's not like this is receiving the love it needs, hence I'm pretty sure nobody is using this. Parts of systemd arn't getting the love they need either, such as systemctl show. For systemd ui the *DE communities are better suited to implement, integrate and maintain an ui on top of systemd for their *DE. What do you feel is missing from systemctl show? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Drop systemd-ui
On Mon, Mar 30, 2015 at 1:35 PM, "Jóhann B. Guðmundsson" wrote: > Heyja > > Should this not be dropped and *DE write,integrate/implement an graphical > frontend to systemd for themselves? > > It's not like this is receiving the love it needs, hence I'm pretty sure > nobody is using this. Parts of systemd arn't getting the love they need either, such as systemctl show. > > JBG > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Liberty equality fraternity or death, Shawn Landden ChurchOfGit.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Drop systemd-ui
Heyja Should this not be dropped and *DE write,integrate/implement an graphical frontend to systemd for themselves? It's not like this is receiving the love it needs, hence I'm pretty sure nobody is using this. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] regarding to cgroup siblings mask
On Fri, Mar 27, 2015 at 7:56 PM, WaLyong Cho wrote: > Hmm, it seems not. When I added MemoryLimit= option to just one service, > cgroups for every unit were generated on memory cgroup. It looks like memory_limit and cpu_quota_per_sec_usec both have this potential issue. The other four controllers managed this way are clearly proportional (using weights or shares). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/3] [RFT] ARM: detect-virt: detect Xen and QEMU/KVM
On Mon, Mar 30, 2015 at 09:15:52PM +0200, Andrew Jones wrote: > This series adds support for detecting if an arm or aarch64 > deployment is a Xen or QEMU/KVM guest. I've tested the QEMU/KVM > detection on an AArch64 guest. The Xen detection has *not* been > tested, thus the RFT. I should not that the testing I did was with a backported version of this series to an older version of systemd. This series hasn't even been compile tested. > > Thanks for reviews and testing. Please keep me on CC as I'm not > subscribed to the list. > > drew > > Andrew Jones (3): > detect-virt: use /proc/device-tree > ARM: detect-virt: detect Xen > ARM: detect-virt: detect QEMU/KVM > > src/shared/virt.c | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > -- > 1.9.3 > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] ARM: detect-virt: detect QEMU/KVM
QEMU/KVM guests do not have hypervisor nodes, but they do have
fw-cfg nodes (since qemu v2.3.0-rc0). fw-cfg nodes are documented,
see kernel doc Documentation/devicetree/bindings/arm/fw-cfg.txt,
and therefore we should be able to rely on it in this detection.
Unfortunately, we currently don't have enough information in the
DT, or elsewhere, to determine if we're using KVM acceleration
with QEMU or not, so we can only report 'qemu' at this time, even
if KVM is in use. This shouldn't really matter in practice though,
because if detect-virt is used interactively it will be clear to
the user whether or not KVM acceleration is present by the overall
speed of the guest. If used by a script, then the script's behavior
should not change whether it's 'qemu' or 'kvm'. QEMU emulated
guests and QEMU/KVM guests of the same type should behave
identically, only the speed at which they run should differ.
---
src/shared/virt.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/shared/virt.c b/src/shared/virt.c
index 712523210d720..ddb76687975ba 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -115,6 +115,20 @@ static int detect_vm_devicetree(const char **_id) {
*_id = "xen";
return 1;
}
+} else if (r == -ENOENT) {
+_cleanup_closedir_ DIR *dir = NULL;
+struct dirent *dent;
+
+dir = opendir("/proc/device-tree");
+if (!dir)
+return 0;
+
+for (dent = readdir(dir); dent != NULL; dent = readdir(dir)) {
+if (strstr(dent->d_name, "fw-cfg")) {
+*_id = "qemu";
+return 1;
+}
+}
}
#endif
return 0;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] ARM: detect-virt: detect Xen
---
src/shared/virt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/shared/virt.c b/src/shared/virt.c
index aa3501f42916c..712523210d720 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -102,7 +102,7 @@ static int detect_vm_cpuid(const char **_id) {
}
static int detect_vm_devicetree(const char **_id) {
-#if defined(__powerpc__) || defined(__powerpc64__)
+#if defined(__arm__) || defined(__aarch64__) || defined(__powerpc__) ||
defined(__powerpc64__)
_cleanup_free_ char *hvtype = NULL;
int r;
@@ -111,6 +111,9 @@ static int detect_vm_devicetree(const char **_id) {
if (streq(hvtype, "linux,kvm")) {
*_id = "kvm";
return 1;
+} else if (strstr(hvtype, "xen")) {
+*_id = "xen";
+return 1;
}
}
#endif
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] detect-virt: use /proc/device-tree
Kernel doc Documentation/ABI/testing/sysfs-firmware-ofw says that
the /proc/device-tree symlink should be used, as opposed to
directly accessing /sys/firmware/devicetree/base. The former is
ABI, but not the later.
---
src/shared/virt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/virt.c b/src/shared/virt.c
index 7c1381f4b8114..aa3501f42916c 100644
--- a/src/shared/virt.c
+++ b/src/shared/virt.c
@@ -106,7 +106,7 @@ static int detect_vm_devicetree(const char **_id) {
_cleanup_free_ char *hvtype = NULL;
int r;
-r =
read_one_line_file("/sys/firmware/devicetree/base/hypervisor/compatible",
&hvtype);
+r = read_one_line_file("/proc/device-tree/hypervisor/compatible",
&hvtype);
if (r >= 0) {
if (streq(hvtype, "linux,kvm")) {
*_id = "kvm";
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/3] [RFT] ARM: detect-virt: detect Xen and QEMU/KVM
This series adds support for detecting if an arm or aarch64 deployment is a Xen or QEMU/KVM guest. I've tested the QEMU/KVM detection on an AArch64 guest. The Xen detection has *not* been tested, thus the RFT. Thanks for reviews and testing. Please keep me on CC as I'm not subscribed to the list. drew Andrew Jones (3): detect-virt: use /proc/device-tree ARM: detect-virt: detect Xen ARM: detect-virt: detect QEMU/KVM src/shared/virt.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] possible to detect journald rate limiting?
On Mon, Mar 23, 2015 at 8:09 PM, Chris Morgan wrote: > Hello. > > I have a journal test that fails periodically. When observing the test > with journalctl -f in the cases that fail I don't see any journal > entries from the journalctl -f. I'm wondering if I'm hitting rate > limiting here on F21 (systemd 216). > > Is there some way to detect at the application that I'm being rate > limited? I'm getting 0 back from sd_journal_sendv(). Or some other > mechanism to detect? > > Chris Anyone? Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] mount: don't run quotaon only for network filesystems
If you havei for example ext4 on iscsi devices it is possible to setup
qoutas there. Unfortunatelly because such fstab entry contains _netdev,
systemd will not add dependency to quotaon.service.
---
src/core/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index 1251c94..f7633b7 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -102,7 +102,7 @@ static bool mount_is_auto(const MountParameters *p) {
static bool needs_quota(const MountParameters *p) {
assert(p);
-if (mount_is_network(p))
+if (p->fstype && fstype_is_network(p->fstype))
return false;
if (mount_is_bind(p))
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] activate on DBus signal
On 24 March 2015 at 05:53, Cameron Norman wrote: > On Mon, Mar 23, 2015 at 1:54 AM, WaLyong Cho wrote: >> Hi, >> >> Now, I'm looking for a method to a service be activated on special DBus >> signal. If a process is running for waiting some of DBus signal this can >> be useful. > > Obviously you want to use systemd, but you may want look at prior art > in Upstart with the upstart-dbus-bridge: > http://upstart.ubuntu.com/cookbook/#upstart-dbus-bridge > With my upstart upstream hat on, I can honestly say that in practice that was a costly implementation, at least as implemented in upstart. As we would launch a capture all dbus monitor and re-emit everything that's broadcasted by the daemon into essentially fire-hose of events spamming all upstart event listeners. A solution for DBus events would be nice. E.g. it would be nice to be able to "bind" jobs to certain DBus properties and start/stop instance jobs based on them (e.g. ofono SIM modems appearing and disappearing on the DBus). Also to fully convert Ubuntu user session to use systemd, I am leaning towards having some way for user session units to bind to system level units... At the moment I am ignoring that part of integration, or hoping that I can resolve it with cunning ways of using generators and runtime created "dummy" units rather than inventing / adding new unit types. Regards, Dimitri. >> >> I already told with Simon in DBus mailing list. >> >> see this thread: >> http://lists.freedesktop.org/archives/dbus/2015-March/016607.html >> >> Simon said: >> "If it did, there are some nasty ordering constraints - I certainly >> wouldn't want to have to delay delivery of a broadcast until all >> interested services had started up! - so I don't think adding this >> feature would be a good idea." >> >> How about also support for DBus signal? >> >> My idea is... >> Add new configuration directory. (e.g. "/etc/systemd/active-by-signal") >> And service can install its configuration file on there with below >> format. (Please don't care of its detail. It just a example.) > > I would think this fits better as a new unit type. These units would > act just like socket, path, or timer units, in that they launch > services (default of service of the same name) when an event occurs. > > Regardless of implementation, this is definitely a useful feature that > I can see being used in a few situations already. For example, in > elementary OS we use a NM dispatcher script to detect captive logins > and autoprompt users, but this requires hacky setting of DISPLAY > variables in that script. It would be cleaner if we could just launch > a script when NM signals the connection coming. This would be a > user/session service so there would be no need to manually set env > variables like DISPLAY. > > Here is the script for reference: > http://bazaar.launchpad.net/~elementary-apps/capnet-assist/trunk/view/head:/90captive_portal_test > > Cheers, > -- > Cameron Norman > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Regards, Dimitri. https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Add reboot to EFI support
I like this. +1
On 26 March 2015 at 15:09, Jan Janssen wrote:
> ---
> man/systemctl.xml | 6 +++-
> src/libsystemd/sd-bus/bus-common-errors.h | 1 +
> src/login/logind-dbus.c | 49 +++--
> src/login/org.freedesktop.login1.conf | 8 +
> src/shared/efivars.c | 52
> +++
> src/shared/efivars.h | 2 ++
> src/systemctl/systemctl.c | 16 --
> 7 files changed, 127 insertions(+), 7 deletions(-)
>
> diff --git a/man/systemctl.xml b/man/systemctl.xml
> index 50e6bc9..eafdd73 100644
> --- a/man/systemctl.xml
> +++ b/man/systemctl.xml
> @@ -1538,7 +1538,11 @@ kobject-uevent 1 systemd-udevd-kernel.socket
> systemd-udevd.service
> systems. This may result in data loss.
>
> If the optional argument
> -arg is given, it will be passed
> +arg is given and is equal to
> +efi, the system will be rebooted to
> +the EFI firmware interface on machines that support it.
> +Note that this requires the system to be booted in EFI mode.
> +Otherwise, the argument will be passed
> as the optional argument to the
>
> reboot2
> system call. The value is architecture and firmware
> diff --git a/src/libsystemd/sd-bus/bus-common-errors.h
> b/src/libsystemd/sd-bus/bus-common-errors.h
> index b17b62a..3019140 100644
> --- a/src/libsystemd/sd-bus/bus-common-errors.h
> +++ b/src/libsystemd/sd-bus/bus-common-errors.h
> @@ -57,6 +57,7 @@
> #define BUS_ERROR_DEVICE_IS_TAKEN "org.freedesktop.login1.DeviceIsTaken"
> #define BUS_ERROR_DEVICE_NOT_TAKEN "org.freedesktop.login1.DeviceNotTaken"
> #define BUS_ERROR_OPERATION_IN_PROGRESS
> "org.freedesktop.login1.OperationInProgress"
> +#define BUS_ERROR_REBOOT_TO_EFI_NOT_SUPPORTED
> "org.freedesktop.login1.RebootToEfiNotSupported"
> #define BUS_ERROR_SLEEP_VERB_NOT_SUPPORTED
> "org.freedesktop.login1.SleepVerbNotSupported"
>
> #define BUS_ERROR_AUTOMATIC_TIME_SYNC_ENABLED
> "org.freedesktop.timedate1.AutomaticTimeSyncEnabled"
> diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
> index a3d49ef..8fec90f 100644
> --- a/src/login/logind-dbus.c
> +++ b/src/login/logind-dbus.c
> @@ -38,8 +38,11 @@
> #include "bus-common-errors.h"
> #include "udev-util.h"
> #include "selinux-util.h"
> +#include "efivars.h"
> #include "logind.h"
>
> +#define SPECIAL_REBOOT_TO_EFI_TARGET "x-logind-reboot-to-efi.target"
> +
> int manager_get_session_from_creds(Manager *m, sd_bus_message *message,
> const char *name, sd_bus_error *error, Session **ret) {
> _cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
> Session *session;
> @@ -1422,6 +1425,13 @@ static int execute_shutdown_or_sleep(
> assert(w < _INHIBIT_WHAT_MAX);
> assert(unit_name);
>
> +if (streq(unit_name, SPECIAL_REBOOT_TO_EFI_TARGET)) {
> +unit_name = SPECIAL_REBOOT_TARGET;
> +r = efi_indicate_reboot_to_fw();
> +if (r < 0)
> +return r;
> +}
> +
> bus_manager_log_shutdown(m, w, unit_name);
>
> r = sd_bus_call_method(
> @@ -1563,6 +1573,9 @@ static int method_do_shutdown_or_sleep(
> if (m->action_what)
> return sd_bus_error_setf(error,
> BUS_ERROR_OPERATION_IN_PROGRESS, "There's already a shutdown or sleep
> operation in progress");
>
> +if (streq(unit_name, SPECIAL_REBOOT_TO_EFI_TARGET) &&
> !is_efi_reboot_to_fw_supported())
> +return sd_bus_error_setf(error,
> BUS_ERROR_REBOOT_TO_EFI_NOT_SUPPORTED, "Reboot to EFI not supported");
> +
> if (sleep_verb) {
> r = can_sleep(sleep_verb);
> if (r < 0)
> @@ -1648,6 +1661,21 @@ static int method_reboot(sd_bus *bus, sd_bus_message
> *message, void *userdata, s
> error);
> }
>
> +static int method_reboot_to_efi(sd_bus *bus, sd_bus_message *message, void
> *userdata, sd_bus_error *error) {
> +Manager *m = userdata;
> +
> +return method_do_shutdown_or_sleep(
> +m, message,
> +SPECIAL_REBOOT_TO_EFI_TARGET,
> +INHIBIT_SHUTDOWN,
> +"org.freedesktop.login1.reboot",
> +"org.freedesktop.login1.reboot-multiple-sessions",
> +"org.freedesktop.login1.reboot-ignore-inhibit",
> +NULL,
> +method_reboot_to_efi,
> +error);
> +}
> +
> static int method_suspend(sd_bus *bus, sd_bus_message *message, void
> *userdata, sd_bus_error *error) {
> Manager *m = userdata;
>
> @@ -1700,7 +1728,7 @@ static int method_can_shutdown_or_sleep(
> const char *action,
> const char *action_multi
Re: [systemd-devel] What requires kmod
On Mon, 30.03.15 00:00, Jan Engelhardt (jeng...@inai.de) wrote: > > systemd/configure.ac has a > > AC_CHECK_PROG([KMOD]...) > > but what actually *uses* this? The way it looks, it's all (udev rules) > using libkmod directly. Let me "git grep kmod" that for you: src/core/kmod-setup.c src/modules-load/modules-load.c src/udev/udev-builtin-kmod.c units/kmod-static-nodes.service.in You're welcome! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-run and waiting for initialization
As I understand, the systemd-run utility returns immediately even with --service-type=forking. What is the proper way then to wait using a shell until the main service process forks the child and exists signaling initialization? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-bootchart: Repair Entropy Graph
On 03/29/2015 08:46 PM, Alexander Sverdlin wrote:
> Entropy Graph code doesn't handle the error condition if open() of /proc entry
> fails. Moreover, the file is only opened once and only first sample will
> contain
> the correct value because the return value of pread() is also not handled
> properly and file is not re-opened. Fix both problems.
Applied, thanks!
> ---
> src/bootchart/store.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/src/bootchart/store.c b/src/bootchart/store.c
> index 8e9a62f..fb3dc9a 100644
> --- a/src/bootchart/store.c
> +++ b/src/bootchart/store.c
> @@ -119,7 +119,7 @@ void log_sample(int sample, struct list_sample_data
> **ptr) {
> int c;
> int p;
> int mod;
> -static int e_fd;
> +static int e_fd = -1;
> ssize_t s;
> ssize_t n;
> struct dirent *ent;
> @@ -215,16 +215,21 @@ schedstat_next:
> }
>
> if (arg_entropy) {
> -if (!e_fd) {
> +if (e_fd < 0) {
> e_fd = openat(procfd,
> "sys/kernel/random/entropy_avail", O_RDONLY);
> +if (e_fd == -1) {
> +log_error_errno(errno, "Failed to open
> /proc/sys/kernel/random/entropy_avail: %m");
> +exit(EXIT_FAILURE);
> +}
> }
>
> -if (e_fd) {
> -n = pread(e_fd, buf, sizeof(buf) - 1, 0);
> -if (n > 0) {
> -buf[n] = '\0';
> -sampledata->entropy_avail = atoi(buf);
> -}
> +n = pread(e_fd, buf, sizeof(buf) - 1, 0);
> +if (n <= 0) {
> +close(e_fd);
> +e_fd = -1;
> +} else {
> +buf[n] = '\0';
> +sampledata->entropy_avail = atoi(buf);
> }
> }
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-bootchart: Prevent leaking file descriptors in open-fdopen combination
On 03/29/2015 08:44 PM, Alexander Sverdlin wrote:
> Correctly handle the potential failure of fdopen() (because of OOM, for
> instance)
> after potentially successful open(). Prevent leaking open fd in such case.
Applied, thanks!
> ---
> src/bootchart/store.c | 12 ++--
> src/bootchart/svg.c | 9 +
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/src/bootchart/store.c b/src/bootchart/store.c
> index 3900936..8e9a62f 100644
> --- a/src/bootchart/store.c
> +++ b/src/bootchart/store.c
> @@ -330,9 +330,13 @@ schedstat_next:
> /* ppid */
> sprintf(filename, "%d/stat", pid);
> fd = openat(procfd, filename, O_RDONLY);
> +if (fd == -1)
> +continue;
> st = fdopen(fd, "r");
> -if (!st)
> +if (!st) {
> +close(fd);
> continue;
> +}
> if (!fscanf(st, "%*s %*s %*s %i", &p)) {
> continue;
> }
> @@ -432,9 +436,13 @@ schedstat_next:
> if (!ps->smaps) {
> sprintf(filename, "%d/smaps", pid);
> fd = openat(procfd, filename, O_RDONLY);
> +if (fd == -1)
> +continue;
> ps->smaps = fdopen(fd, "r");
> -if (!ps->smaps)
> +if (!ps->smaps) {
> +close(fd);
> continue;
> +}
> setvbuf(ps->smaps, smaps_buf, _IOFBF,
> sizeof(smaps_buf));
> }
> else {
> diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
> index e1fc531..5412915 100644
> --- a/src/bootchart/svg.c
> +++ b/src/bootchart/svg.c
> @@ -170,6 +170,9 @@ static void svg_title(const char *build) {
> if (!fgets(cmdline, 255, f))
> sprintf(cmdline, "Unknown");
> fclose(f);
> +} else {
> +if (fd >= 0)
> +close(fd);
> }
>
> /* extract root fs so we can find disk model name in sysfs */
> @@ -185,6 +188,9 @@ static void svg_title(const char *build) {
> if (!fgets(model, 255, f))
> fprintf(stderr, "Error reading disk model
> for %s\n", rootbdev);
> fclose(f);
> +} else {
> +if (fd >= 0)
> +close(fd);
> }
> }
>
> @@ -208,6 +214,9 @@ static void svg_title(const char *build) {
> }
> }
> fclose(f);
> +} else {
> +if (fd >= 0)
> +close(fd);
> }
>
> svg("Bootchart for %s -
> %s\n",
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
