Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Mon, Jan 13, 2014 at 10:58 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 13, 2014 at 12:10:20PM -0800, Tom Gundersen wrote: >> commit 5681d7fb8be37771c152d21ea6e95597d664e3f1 >> Author: Tom Gundersen >> Date: Mon Jan 13 21:03:28 2014 +0100 >> >> libsystemd-dns: merge into libsystemd >> >> Also rename sd-dns -> sd-resolv. > Looks good. Does -lresolv belong in libsystemd_la_CFLAGS? I would have thought that it should be in LIBADD for the lib and LDADD for the test. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
El 13/01/14 19:42, Dominique Michel escribió: Or I am wrong and systemd will not work without the kernel cgroups? systemd *requires* cgroups, what you can disable are certain controllers. I do not know to which extent this ability to disable controllers will remain in place. Whatever is decided is AFAIK being worked on with the collaboration of cgroup developers. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
El 13/01/14 18:59, Greg KH escribió: On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: I'll have to admit, I don't have a very good understanding of systemd/udev. I am using systemd/udev version 208-15.1 on an openSuSE-13.1 dist and a 3.4.74 kernel. 3.4? That's an incompatible thing right there with openSUSE 13.1, sorry. While off-topic for sure, yes, that is bound to cause issues. we might want to force a minimal kernel version in the systemd spec file. most likely the base release number of the kernel used in the particular product, in this case 3.11 "or later" but not "previous". This may not be enforced at runtime though as multiple kernels including older ones can be installed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Tue, Jan 14, 2014 at 5:58 AM, Zbigniew Jędrzejewski-Szmek >> libsystemd-bus: rename to libsystemd >> >> Documentation was updated to refer to either 'libsystemd' or 'sd-bus' in >> place >> of libsystemd-bus. > Eeeh, why? This new name suggests that this libary is for systemd > functionality. But so far it is a generic. Also, we have > libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library, > I'd much prefer to have it separated, if I'm using it for something > not-systemd > related. We decided that all these libs will all end up in that one single .so, also the journal. Otherwise we will not be able to manage the cyclic deps all this will create with logging and bus communication and name resolving. This lib could be called differently, but it will be the same outcome. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
Le Mon, 13 Jan 2014 19:39:57 +, Colin Guthrie a écrit : > Hello, > > You're approaching this whole thread from a fixed position and > therefore seem to be seeing *everything* as negative and > problematic. Hi, You are partly right on this. In the mean time, I read other things on the cgroups and systemd, and I know realize that things are not as bad I was thinking. I also realize you are working hard to find solutions to many problems. > > Rather than coming here with problem and looking for a solution, > you've arrived with a solution already designed and seem to be > complaining that it won't work. > > There WILL be a solution to your *problem* but it might not be > achieved via the design you have in mind. > > It could be due to the semantics of how you express the requirement > means you have to think about the problem differently. I now understand that. But it was not obvious at all at the time I was fighting with a randomly freezing system. And nobody at that time was able to point me on the right direction. So I must thank the peoples on that list for that. > > Much of what you say below is simply incompatible with the upstream > kernel single-cgroup manager model that is being pushed. You cannot > have a "custom cgroup configuration" directly under this model: the > configuration has to be expressed indirectly as user and administrator > friendly declarative statements in various unit files which ultimately > map to cgroup configurations (mostly as an implementation detail). As a user and administrator, I don't care as long I can make it to suit my needs. > > > > Too late, I shifted the distribution because I was in urgent need > > of a good working system on that box. > > Well, this has obviously given everyone the time to properly respond > and help you with your problem. If I didn't know better this whole > conversation would appear to be just a random complaint FUD email > rather than one seeking to gain knowledge. Before I shifted the distribution, I really try hard to make it to work with systemd, that under a few weeks. That imply this is not a random complain. But you are right on one thing, as I understand that issue now, I was not following the right path and I should have contacted that list at that time. > > >>> Again, the point of the cgroups is to be able to adapt the system > >>> to any kind of workload, and to have systemd that take control of > >>> that good and flexible system, and at the same time, doesn't > >>> provide a way for an user to adapt the default configuration to > >>> its own need, is just a big design bug, which start with Lennart > >>> failure to take in account the fact that all users are corner > >>> cases by definition, because all users are doing different kind > >>> of works with their computers. > >> > >> That's not the goak of cgroups at all, sorry. > > > > Lennart is very clear in his email, "normal" users run a GUI. > > That is completely untrue. You have read far too much into that > statement and the examples provided there. Let Lennart answer for > himself before you make rash generalisations. Maybe I over reacted, but it is what inspire me the lecture of that message. > > > So sure, according to that mail, the goal of the crgoup interface of > > systemd is just to run a GUI > > Completely untrue and certainly not how I read the email. > > > And yes, as I want (my choice) a GUI that is not in my way, I am > > allergic to a GUI that interfere with a good working system (like > > gnome and its *kit madness), but that's another issue. > > Yes, it's another issue and one *completely* irrelevant to this > mailing list. Such negativity in comments is *highly unwelcome* here. > Please keep it to yourself or for slashdot posts. Come on, I don't post to slahdot, I just have better things to do. If I am here, this is because I think it is a problem with the actual state of systemd, and I also think users must be aware of it if they want to avoid issues like freezing computers during a migration to systemd. I was maybe over reacting on a few things, inclusive on Lennart statement and systemd usability, and I apologize for that, but the complete and repetitive system freeze I get was 100% real. > > > The fact is that nobody on the Debian forum was able to help me, or > > even aware of the existence of that documentation. Or they all was > > in holiday at that time. > > Quite possibly. Complaining that nobody held your hand here is > somewhat off topic however. It doesn't change the fact that the > documentation for systemd is extremely extensive and one of the best > documented open source projects I've ever worked with. It may be. But it is something new, something that, as my little experience with it showed me, nobody outside of a little community seam to know and understand. > > > Anyway, I did read it but was completely unable to make it to work, > > whatever I try. It is only when I read Lennart email yesterday, I > >
Re: [systemd-devel] systemd-udevd Oops
On Mon, Jan 13, 2014 at 01:59:39PM -0800, Greg KH wrote: > That really sounds like a driver problem, especially given your trace > shows it is failing somewhere. The udevd PID is probably because udev > loaded your driver. Sorry, not loading it, but rather reading sysfs files that your driver is creating. As your driver isn't a closed source one, have a pointer to the source anywhere that we can see what you are doing in your sysfs callbacks? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: > I'll have to admit, I don't have a very good understanding of > systemd/udev. I am using systemd/udev version 208-15.1 on an > openSuSE-13.1 dist and a 3.4.74 kernel. 3.4? That's an incompatible thing right there with openSUSE 13.1, sorry. > The back trace indicates an out of kernel driver I have to maintain. > Yet this also indicates "Pid: 361, comm: systemd-udevd" caused the > Oops. I don't understand this. I'd blame your driver, as no one can really help you with a tainted kernel like that, there's not much we can do here, sorry. What is keeping your driver from being merged into the main kernel tree? > In any case, this particular driver and systemd/udev (195.x.x) using the > very same kernel work just fine. Also if I only have a single pci card > installed this particular driver and systemd/udev version 208-15.1 work > just fine. It's just when additional pci cards are added I get this > failure. This particular driver takes a few seconds from the time > init_module is called to when it creates all its device entries. The > more pci cards the longer that is. The cards themselves are basically > loaded and booted before the device entries(192 each) are created. This > error seems to be occurring during that load and boot process though. That really sounds like a driver problem, especially given your trace shows it is failing somewhere. The udevd PID is probably because udev loaded your driver. And userspace shouldn't be able to crash the kernel, so you can't really blame udev :) best of luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Mon, Jan 13, 2014 at 12:10:20PM -0800, Tom Gundersen wrote: > commit 5681d7fb8be37771c152d21ea6e95597d664e3f1 > Author: Tom Gundersen > Date: Mon Jan 13 21:03:28 2014 +0100 > > libsystemd-dns: merge into libsystemd > > Also rename sd-dns -> sd-resolv. Looks good. > commit 0b54473e9b73d867ed7807507a0fb5adc8137b10 > Author: Tom Gundersen > Date: Mon Jan 13 20:14:44 2014 +0100 > > libsystemd-rtnl: merge into libsystemd OK. > commit c813ca40c859ff8abc8bc6aabc3f1e896623eb67 > Author: Tom Gundersen > Date: Mon Jan 13 19:12:16 2014 +0100 > > libsystemd-dhcp: merge into libsystemd OK. > commit 6bb648a16ae4a682ad4784412af706d2e6a3e4da > Author: Tom Gundersen > Date: Mon Jan 13 17:30:51 2014 +0100 > > libsystemd-bus: rename to libsystemd > > Documentation was updated to refer to either 'libsystemd' or 'sd-bus' in > place > of libsystemd-bus. Eeeh, why? This new name suggests that this libary is for systemd functionality. But so far it is a generic. Also, we have libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library, I'd much prefer to have it separated, if I'm using it for something not-systemd related. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-udevd Oops
On Mon, Jan 13, 2014 at 04:20:05PM -0500, Mark Hounschell wrote: > Basically, I don't think this problem is the driver. I think the problem > is systemd/udev related so I'm posting this here hoping the get some > input on what the problem is. If the kernel crashes, then it's kernel's fault (usually). Here systemd-udevd triggers the crash in the kernel, by causing it to dereference NULL, when it interacts with it. But it still is a bug in the kernel if a user-space application can crash it in this way. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-udevd Oops
I'll have to admit, I don't have a very good understanding of systemd/udev. I am using systemd/udev version 208-15.1 on an openSuSE-13.1 dist and a 3.4.74 kernel. The back trace indicates an out of kernel driver I have to maintain. Yet this also indicates "Pid: 361, comm: systemd-udevd" caused the Oops. I don't understand this. In any case, this particular driver and systemd/udev (195.x.x) using the very same kernel work just fine. Also if I only have a single pci card installed this particular driver and systemd/udev version 208-15.1 work just fine. It's just when additional pci cards are added I get this failure. This particular driver takes a few seconds from the time init_module is called to when it creates all its device entries. The more pci cards the longer that is. The cards themselves are basically loaded and booted before the device entries(192 each) are created. This error seems to be occurring during that load and boot process though. Basically, I don't think this problem is the driver. I think the problem is systemd/udev related so I'm posting this here hoping the get some input on what the problem is. Thanks and regards Mark [ 29.750112] dgdm: found 3 boards. . . [ 29.769865] osst :I: Tape driver with OnStream support version 0.99.4 [ 29.769866] osst :I: $Id: osst.c,v 1.1.1.1 2013/12/14 10:10:00 markh Exp $ [ 44.884798] systemd-journald[293]: Received request to flush runtime journal from PID 1 [ 47.146535] r8169 :07:00.0: eth0: link down [ 47.146556] r8169 :07:00.0: eth0: link down [ 47.146688] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 47.311163] NET: Registered protocol family 17 [ 48.731553] r8169 :07:00.0: eth0: link up [ 48.731678] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 50.812858] BUG: unable to handle kernel paging request at fac0 [ 50.817114] IP: [] memcpy+0xf/0x20 [ 50.821369] *pde = 2e5d3067 *pte = [ 50.825664] Oops: 0002 [#1] PREEMPT SMP [ 50.830004] Modules linked in: af_packet osst st nvidia(PO) snd_hda_codec_realtek dgdm(O+) snd_hda_intel tnt4882(O) snd_hda_codec snd_hwdep snd_pcm gpiohsd(O) dgap(O) nec7210(O) snd_seq gpib_common(O) snd_timer snd_seq_device synclink_gt aic7xxx 3c59x mxm_wmi hdlc snd lcrsmem(O) aic79xx sr_mod cdrom eprm(O) r8169 scsi_transport_spi shpchp ata_generic crc32c_intel aesni_intel soundcore cryptd serio_raw fam15h_power pci_hotplug snd_page_alloc rtom(O) aes_i586 pcspkr wmi i2c_piix4 k10temp pata_atiixp microcode button sg dm_mod autofs4 ext4 jbd2 crc16 xhci_hcd scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh [ 50.849835] [ 50.854972] Pid: 361, comm: systemd-udevd Tainted: P O 3.4.74-lcrs #1 Gigabyte Technology Co., Ltd. GA-990FXA-UD5/GA-990FXA-UD5 [ 50.860479] EIP: 0060:[] EFLAGS: 00010216 CPU: 0 [ 50.865985] EIP is at memcpy+0xf/0x20 [ 50.871532] EAX: faa02000 EBX: fffc ECX: 3ff807ff EDX: ee834000 [ 50.877169] ESI: eea32000 EDI: fac0 EBP: edc5be28 ESP: edc5be1c [ 50.882729] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 50.888224] CR0: 80050033 CR2: f9ff9b8c CR3: 2e47b000 CR4: 000407d0 [ 50.893685] DR0: DR1: DR2: DR3: [ 50.899076] DR6: 0ff0 DR7: 0400 [ 50.904451] Process systemd-udevd (pid: 361, ti=edc5a000 task=eea18c70 task.ti=edc5a000) [ 50.909961] Stack: [ 50.915418] f95c7fa0 edc09754 ee834000 edc5be58 f9599530 0282 [ 50.921079] f95c7fa0 f95c8920 faa0 edc09754 edc5be88 [ 50.926770] f9597eb3 eea18c70 [ 50.932468] Call Trace: [ 50.938082] [] tb_download+0x220/0x640 [dgdm] [ 50.943732] [] tri_boot+0x643/0x8a0 [dgdm] [ 50.949376] [] init_module+0x458/0x2270 [dgdm] [ 50.955003] [] ? notifier_call_chain+0x41/0x60 [ 50.960624] [] ? dgdm_triboot_cb+0x160/0x160 [dgdm] [ 50.966264] [] do_one_initcall+0x102/0x150 [ 50.971870] [] ? __blocking_notifier_call_chain+0x41/0x50 [ 50.977521] [] sys_init_module+0xef9/0x1cc0 [ 50.983160] [] sysenter_do_call+0x12/0x28 [ 50.988740] Code: 54 2b 43 50 88 43 4e 5b 5d c3 66 90 e8 7b fc ff ff eb eb 90 90 90 90 90 90 90 90 90 55 89 e5 57 89 c7 56 89 d6 53 89 cb c1 e9 02 a5 89 d9 83 e1 03 74 02 f3 a4 5b 5e 5f 5d c3 90 55 89 e5 57 [ 51.000644] EIP: [] memcpy+0xf/0x20 SS:ESP 0068:edc5be1c [ 51.006524] CR2: fac0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH/RFC] gudev: add device::get_sysfs_attr_keys() and device::has_sysfs_attr()
For gudev -> gudevdevice:
- Add support for get_sysfs_attr_keys()
- Add support for has_sysfs_attr()
Note: Only tested against systemd-204 on Ubuntu 13.10's patch-set...
RFC1: For some reason libudev cosiders every link or file as sysfs
attribute (opposed to udevadm). Is this intended ?
RFC2: Since this is my first patch, please comment on any changes it needs
and I'll iterate. Thank you...
Signed-off-by: Andreas Fuchs
---
src/gudev/gudevdevice.c | 53
+
src/gudev/gudevdevice.h | 3 +++
2 files changed, 56 insertions(+)
diff --git a/src/gudev/gudevdevice.c b/src/gudev/gudevdevice.c
index 6c9e0f5..2c768b7 100644
--- a/src/gudev/gudevdevice.c
+++ b/src/gudev/gudevdevice.c
@@ -59,6 +59,8 @@
* g_udev_device_get_property_as_strv().
*
* To access sysfs attributes for the device, use
+ * g_udev_device_get_sysfs_attr_keys(),
+ * g_udev_device_has_sysfs_attr(),
* g_udev_device_get_sysfs_attr(),
* g_udev_device_get_sysfs_attr_as_int(),
* g_udev_device_get_sysfs_attr_as_uint64(),
@@ -84,6 +86,7 @@ struct _GUdevDevicePrivate
/* computed ondemand and cached */
gchar **device_file_symlinks;
gchar **property_keys;
+ gchar **sysfs_attr_keys;
gchar **tags;
GHashTable *prop_strvs;
GHashTable *sysfs_attr_strvs;
@@ -98,6 +101,7 @@ g_udev_device_finalize (GObject *object)
g_strfreev (device->priv->device_file_symlinks);
g_strfreev (device->priv->property_keys);
+ g_strfreev (device->priv->sysfs_attr_keys);
g_strfreev (device->priv->tags);
if (device->priv->udevice != NULL)
@@ -699,6 +703,55 @@ out:
/*
*/
/**
+ * g_udev_device_get_sysfs_attr_keys:
+ * @device: A #GUdevDevice.
+ *
+ * Gets all keys for sysfs attributes on @device.
+ *
+ * Returns: (transfer none) (array zero-terminated=1) (element-type utf8):
A %NULL terminated string array of sysfs attribute keys. This array is
owned by @device and should not be freed by the caller.
+ */
+const gchar * const *
+g_udev_device_get_sysfs_attr_keys (GUdevDevice *device)
+{
+ struct udev_list_entry *l;
+ GPtrArray *p;
+
+ g_return_val_if_fail (G_UDEV_IS_DEVICE (device), NULL);
+
+ if (device->priv->sysfs_attr_keys != NULL)
+goto out;
+
+ p = g_ptr_array_new ();
+ for (l = udev_device_get_sysattr_list_entry (device->priv->udevice); l
!= NULL; l = udev_list_entry_get_next (l))
+{
+ g_ptr_array_add (p, g_strdup (udev_list_entry_get_name (l)));
+}
+ g_ptr_array_add (p, NULL);
+ device->priv->sysfs_attr_keys = (gchar **) g_ptr_array_free (p, FALSE);
+
+ out:
+ return (const gchar * const *) device->priv->sysfs_attr_keys;
+}
+
+/**
+ * g_udev_device_has_sysfs_attr:
+ * @device: A #GUdevDevice.
+ * @key: Name of sysfs attribute.
+ *
+ * Check if a the sysfs attribute with the given key exists.
+ *
+ * Returns: %TRUE only if the value for @key exist.
+ */
+gboolean
+g_udev_device_has_sysfs_attr (GUdevDevice *device,
+const gchar *key)
+{
+ g_return_val_if_fail (G_UDEV_IS_DEVICE (device), FALSE);
+ g_return_val_if_fail (key != NULL, FALSE);
+ return udev_device_get_sysattr_value (device->priv->udevice, key) !=
NULL;
+}
+
+/**
* g_udev_device_get_sysfs_attr:
* @device: A #GUdevDevice.
* @name: Name of the sysfs attribute.
diff --git a/src/gudev/gudevdevice.h b/src/gudev/gudevdevice.h
index 457b961..72ec180 100644
--- a/src/gudev/gudevdevice.h
+++ b/src/gudev/gudevdevice.h
@@ -108,6 +108,9 @@ gboolean
g_udev_device_get_property_as_boolean (GUdevDevice *devic
const gchar* const *g_udev_device_get_property_as_strv (GUdevDevice
*device,
const gchar
*key);
+const gchar* const *g_udev_device_get_sysfs_attr_keys (GUdevDevice
*device);
+gbooleang_udev_device_has_sysfs_attr(GUdevDevice
*device,
+ const gchar
*key);
const gchar*g_udev_device_get_sysfs_attr(GUdevDevice
*device,
const gchar
*name);
gintg_udev_device_get_sysfs_attr_as_int (GUdevDevice
*device,
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] sd-dns: rename structs and functions with sd_ prefix
On Mon, Jan 13, 2014 at 2:43 PM, Daniel Buch wrote: > Ohh.. that sounds reasonable, i can do the git mv and renameig (And squash > to a single commit) when the decision is set :) I was doing a lot of "git mv" anyway now, so I went ahead and moved the files to sd-resolv. If you could rebase your renaming patch on top of that (and rename stuff to sd_resolv instead), that would be awesome. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl [en|dis]able weirdness + reload (writes /run/nologin)
'Twas brillig, and Colin Guthrie at 13/01/14 15:33 did gyre and gimble:
> 'Twas brillig, and Colin Guthrie at 13/01/14 15:08 did gyre and gimble:
>> 'Twas brillig, and Colin Guthrie at 13/01/14 11:30 did gyre and gimble:
>>> 'Twas brillig, and Colin Guthrie at 13/01/14 11:16 did gyre and gimble:
2. This is the much odder part of the problem I'm seeing. The call to
daemon_reload() at the end of the enable_unit() seems to trigger some
kind of broken daemon reload that puts things into a bad state,
including a stale /run/nologin file.
I'm not sure WHY this does this, but it's very reliably reproducible. I
have a native sysvinit script called numlock. All I need to do to
trigger the bad state is "systemctl disable numlock". After the call,
the systemd daemon is reloaded and it goes into this bad state
completely with /run/nologin file.
If I comment out call or use --no-reload, then all is well. If I call
"systemctl daemon-reload" on it's own, all seems well. It just seems to
be this reload call specifically at the end of enable_unit() that
triggers the bad state.
I'm going to try reverting some of the patches I have applied to see
where I get with things, as I see Zbigniew backed a few out of fedora
due to freeze rules, but I did also see some threads from Zbigniew about
the whole /run/nologin, so I suspect he may be interested in this.
>>>
>>> I reverted the same patches that were reverted in Fedora so our builds
>>> should be quite similar.
>>>
>>> I really hope fedora has this same issue otherwise my debugging just got
>>> more confusing.
>>>
>>> Zbigniew can you reproduce this on F20?
>>
>> It seems to be specifically related to chkconfig. If I shell out instead
>> to something different (e.g. "whoami") all runs fine.
>>
>> I'm wondering if it's something related to semi-systemd stuff supported
>> in our chkconfig... Perhaps our patches are out of date compared to
>> fedora...
>>
>> Still hunting :)
>
> OK, so it seems that chkconfig will these days notify systemd to reload
> itself.
>
> static void reloadSystemd(void) {
> if (systemdActive())
> system("systemctl daemon-reload > /dev/null 2>&1");
> }
>
> For whatever reason, doing this in the forked off process AND in systemd
> itself leads to some kind of race.
>
> Perhaps this happens if two reload operations come in in very quick
> succession, or perhaps the use of system() (and it's subsequent fork) in
> chkconfig just somehow messes up our signal handling in systemctl?
>
> Either way, commenting this out in systemctl avoids the problem.
>
> I would suggest three possible fixes:
>
>
> 1. Find out why this is racey and fix it.
> 2. Add an option to chkconfig to disable the reload.
> 3. Just drop the reload completely from chkconfig.
>
> I would suspect that the option route is the best way forward but
> chkconfig will bail out of unsupported options so we should either use
> an ENV var or make sure systemd and chkconfig are updated in lockstep.
>
> Thoughts?
OK, I've added both an env var and a new option to chkconfig and then
call chkconfig with the appropriate arguments from systemctl.
Attached are my two patches (keep in mind that the earlier patch to
avoid bogus warnings about [Install] sections is still valid too.
Seems to solve the issue for me (at least in my test case).
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/
>From 0db8cef7a80ea001f3798c4384ffcbe287eb405e Mon Sep 17 00:00:00 2001
From: Colin Guthrie
Date: Mon, 13 Jan 2014 19:14:40 +
Subject: [PATCH 514/514] systemctl: Ensure the --no-reload and --no-redirect
options are passed to chkconfig
We want to ensure that chkconfig won't create any circular loops incase
it mistakenly things we're in control. Thus the --no-redirect argument
is a good safety net.
The --no-reload prevents a very strange case where the the shelled
out chkconfig will trigger a systemd daemon-reload (by itself shelling
out to systemctl) and then we also reload ourselves very shortly after
and this causes systemd to get into a very strange state whereby it
basically crashes (I suspect a serialisation race of some kind) and
as one of the symptoms it writes out a /run/nologin file which is
what most people notice.
A patch has been added to chkconfig to add the --no-reload behaviour.
---
src/systemctl/systemctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 9ff4350..a459a6c 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4248,8 +4248,8 @@ static int enable_sysv_units(const char *verb, char **args) {
const char *name;
Re: [systemd-devel] systemd and cgroups
Hello, You're approaching this whole thread from a fixed position and therefore seem to be seeing *everything* as negative and problematic. Rather than coming here with problem and looking for a solution, you've arrived with a solution already designed and seem to be complaining that it won't work. There WILL be a solution to your *problem* but it might not be achieved via the design you have in mind. It could be due to the semantics of how you express the requirement means you have to think about the problem differently. Much of what you say below is simply incompatible with the upstream kernel single-cgroup manager model that is being pushed. You cannot have a "custom cgroup configuration" directly under this model: the configuration has to be expressed indirectly as user and administrator friendly declarative statements in various unit files which ultimately map to cgroup configurations (mostly as an implementation detail). > Too late, I shifted the distribution because I was in urgent need of a > good working system on that box. Well, this has obviously given everyone the time to properly respond and help you with your problem. If I didn't know better this whole conversation would appear to be just a random complaint FUD email rather than one seeking to gain knowledge. >>> Again, the point of the cgroups is to be able to adapt the system to >>> any kind of workload, and to have systemd that take control of that >>> good and flexible system, and at the same time, doesn't provide >>> a way for an user to adapt the default configuration to its own >>> need, is just a big design bug, which start with Lennart failure to >>> take in account the fact that all users are corner cases by >>> definition, because all users are doing different kind of works with >>> their computers. >> >> That's not the goak of cgroups at all, sorry. > > Lennart is very clear in his email, "normal" users run a GUI. That is completely untrue. You have read far too much into that statement and the examples provided there. Let Lennart answer for himself before you make rash generalisations. > So sure, according to that mail, the goal of the crgoup interface of > systemd is just to run a GUI Completely untrue and certainly not how I read the email. > And yes, as I want (my choice) a GUI that is not in my way, I am > allergic to a GUI that interfere with a good working system (like gnome > and its *kit madness), but that's another issue. Yes, it's another issue and one *completely* irrelevant to this mailing list. Such negativity in comments is *highly unwelcome* here. Please keep it to yourself or for slashdot posts. > The fact is that nobody on the Debian forum was able to help me, or > even aware of the existence of that documentation. Or they all was in > holiday at that time. Quite possibly. Complaining that nobody held your hand here is somewhat off topic however. It doesn't change the fact that the documentation for systemd is extremely extensive and one of the best documented open source projects I've ever worked with. > Anyway, I did read it but was completely unable to make it to work, > whatever I try. It is only when I read Lennart email yesterday, I > understand why it was not working: systemd is designed to not work with > custom cgroup configurations. No, systemd is designed to *manage* your custom cgroup configurations. It abstracts cgroups away to pretty much an implementation detail. You can still get the needed *solution* to your problem. > And if it is already stated in the doc that systemd will not work with > custom cgroup configurations, you must emphasis more on that issue, so > that worried users doesn't miss it, and doesn't waste their time with > this. Keep in mind that the single-writer principle is still relatively new. Everything has to be adapted to it and systemd has moved very quickly to match the upstream kernel needs. As time goes on, documentation in this area will improve. >>> So, don't say me I could have done this or that, that's not my >>> point. My major point is GNU/Linux have always been about choices, >> >> That's not true at all, it's never been about choices. > > Well, you don't need to say anything more, we just don't have the > same conception of Free Software. For me, Free Software is about 5 > fundamental liberties, and liberty is all about choices. Your "choice" exists in your ability to view, understand and write the code yourself. Whether someone's crazy whim or configuration (not necessarily referring to your current requirement) has to be supported by every utility in the open source stack is completely different. People hear the word "choice" and build up a whole expectation around it's dictionary definition to the extent that they presume everyone must bend over backwards to support any crazy idea they come up with. I'm sorry, but this has never and will never be true. http://islinuxaboutchoice.com/ >> If you wish to use your own cgroup configurations, y
Re: [systemd-devel] systemd and cgroups
Le Sun, 12 Jan 2014 16:07:45 -0800, Greg KH a écrit : > On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: > > I need that pc for production, so I rapidly installed another > > distribution without systemd. So this problem is solved for me, but > > that doesn't solve that to force any user to use a default > > configuration without any possibility of user setup, and without > > documentation that can allow an user to do that, is just a design > > fault. > > That sounds like a distro issue, please take this up with your distro > developers, this isn't a systemd issue. Too late, I shifted the distribution because I was in urgent need of a good working system on that box. > > > Again, the point of the cgroups is to be able to adapt the system to > > any kind of workload, and to have systemd that take control of that > > good and flexible system, and at the same time, doesn't provide > > a way for an user to adapt the default configuration to its own > > need, is just a big design bug, which start with Lennart failure to > > take in account the fact that all users are corner cases by > > definition, because all users are doing different kind of works with > > their computers. > > That's not the goak of cgroups at all, sorry. Lennart is very clear in his email, "normal" users run a GUI. Sorry, but I am not abnormal and I do some work with my computer. The GUI is just an accessory for me, and as long it is not in my way and provide me a decent mouse focus policy and plenty of keyboard short cuts, 2 things essential for my work flow, I am happy with it. So sure, according to that mail, the goal of the crgoup interface of systemd is just to run a GUI, and this is precisely why it doesn't work for me: it doesn't allow custom cgroup configuration for people that want to do something more than running a GUI. And yes, as I want (my choice) a GUI that is not in my way, I am allergic to a GUI that interfere with a good working system (like gnome and its *kit madness), but that's another issue. > > > Today, during a forum discussion on the cgroups, someone gave > > the link above with the different Lennart's statements. I begun to > > understand. Later also today, I finally find some documentation on > > the freedesktop web site. But that's too late, I need this pc for > > production, and I have other things to do than risking a hard disk > > failure because of a freezing system, so I will not reinstall > > Debian. And for that, I didn't even read more of that doc than a few > > lines. I just lost the interest of the good idea that systemd is, > > that because of its catastrophic implementation that can cause so > > severe regression like system freeze, and its almost complete lack > > of documentation. > > I don't think you have looked, systemd is the best documented piece of > software I've ever seen. The fact is that nobody on the Debian forum was able to help me, or even aware of the existence of that documentation. Or they all was in holiday at that time. Anyway, I did read it but was completely unable to make it to work, whatever I try. It is only when I read Lennart email yesterday, I understand why it was not working: systemd is designed to not work with custom cgroup configurations. The least you could do is to tell that in the documentation. I wasted a few weeks with that. And if it is already stated in the doc that systemd will not work with custom cgroup configurations, you must emphasis more on that issue, so that worried users doesn't miss it, and doesn't waste their time with this. > > > So, don't say me I could have done this or that, that's not my > > point. My major point is GNU/Linux have always been about choices, > > That's not true at all, it's never been about choices. Well, you don't need to say anything more, we just don't have the same conception of Free Software. For me, Free Software is about 5 fundamental liberties, and liberty is all about choices. > > > and the actual systemd implementation and lack of documentation is > > just removing the possibility for the user to choose what he want do > > with the cgroups, which can break the whole system apart when he try > > to do its own cgroup configuration. > > If you wish to use your own cgroup configurations, yes, I would > suggest not using systemd. It is what I have done after formatting and checking my drive. And that's the real problem, systemd is not compatible with custom cgroup configuration. I hope this will change in the future, because this is a choice (again!) I made to use a custom cgroup configuration. And I am sure I am not the only one into a similar case. As an alternative, systemd should at least provide a setup option for it to not interfere with an existing cgroup configuration. > But please work with the kernel cgroup > developers, as the cgroup interface is going to be changing quite a > bit in the future. OK, I will do it. > > This really has nothing to do with systemd on it's
Re: [systemd-devel] systemctl [en|dis]able weirdness + reload (writes /run/nologin)
'Twas brillig, and Colin Guthrie at 13/01/14 15:08 did gyre and gimble:
> 'Twas brillig, and Colin Guthrie at 13/01/14 11:30 did gyre and gimble:
>> 'Twas brillig, and Colin Guthrie at 13/01/14 11:16 did gyre and gimble:
>>> 2. This is the much odder part of the problem I'm seeing. The call to
>>> daemon_reload() at the end of the enable_unit() seems to trigger some
>>> kind of broken daemon reload that puts things into a bad state,
>>> including a stale /run/nologin file.
>>>
>>> I'm not sure WHY this does this, but it's very reliably reproducible. I
>>> have a native sysvinit script called numlock. All I need to do to
>>> trigger the bad state is "systemctl disable numlock". After the call,
>>> the systemd daemon is reloaded and it goes into this bad state
>>> completely with /run/nologin file.
>>>
>>> If I comment out call or use --no-reload, then all is well. If I call
>>> "systemctl daemon-reload" on it's own, all seems well. It just seems to
>>> be this reload call specifically at the end of enable_unit() that
>>> triggers the bad state.
>>>
>>>
>>>
>>> I'm going to try reverting some of the patches I have applied to see
>>> where I get with things, as I see Zbigniew backed a few out of fedora
>>> due to freeze rules, but I did also see some threads from Zbigniew about
>>> the whole /run/nologin, so I suspect he may be interested in this.
>>
>> I reverted the same patches that were reverted in Fedora so our builds
>> should be quite similar.
>>
>> I really hope fedora has this same issue otherwise my debugging just got
>> more confusing.
>>
>> Zbigniew can you reproduce this on F20?
>
> It seems to be specifically related to chkconfig. If I shell out instead
> to something different (e.g. "whoami") all runs fine.
>
> I'm wondering if it's something related to semi-systemd stuff supported
> in our chkconfig... Perhaps our patches are out of date compared to
> fedora...
>
> Still hunting :)
OK, so it seems that chkconfig will these days notify systemd to reload
itself.
static void reloadSystemd(void) {
if (systemdActive())
system("systemctl daemon-reload > /dev/null 2>&1");
}
For whatever reason, doing this in the forked off process AND in systemd
itself leads to some kind of race.
Perhaps this happens if two reload operations come in in very quick
succession, or perhaps the use of system() (and it's subsequent fork) in
chkconfig just somehow messes up our signal handling in systemctl?
Either way, commenting this out in systemctl avoids the problem.
I would suggest three possible fixes:
1. Find out why this is racey and fix it.
2. Add an option to chkconfig to disable the reload.
3. Just drop the reload completely from chkconfig.
I would suspect that the option route is the best way forward but
chkconfig will bail out of unsupported options so we should either use
an ENV var or make sure systemd and chkconfig are updated in lockstep.
Thoughts?
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] systemctl [en|dis]able weirdness + reload (writes /run/nologin)
'Twas brillig, and Colin Guthrie at 13/01/14 11:30 did gyre and gimble: > 'Twas brillig, and Colin Guthrie at 13/01/14 11:16 did gyre and gimble: >> 2. This is the much odder part of the problem I'm seeing. The call to >> daemon_reload() at the end of the enable_unit() seems to trigger some >> kind of broken daemon reload that puts things into a bad state, >> including a stale /run/nologin file. >> >> I'm not sure WHY this does this, but it's very reliably reproducible. I >> have a native sysvinit script called numlock. All I need to do to >> trigger the bad state is "systemctl disable numlock". After the call, >> the systemd daemon is reloaded and it goes into this bad state >> completely with /run/nologin file. >> >> If I comment out call or use --no-reload, then all is well. If I call >> "systemctl daemon-reload" on it's own, all seems well. It just seems to >> be this reload call specifically at the end of enable_unit() that >> triggers the bad state. >> >> >> >> I'm going to try reverting some of the patches I have applied to see >> where I get with things, as I see Zbigniew backed a few out of fedora >> due to freeze rules, but I did also see some threads from Zbigniew about >> the whole /run/nologin, so I suspect he may be interested in this. > > I reverted the same patches that were reverted in Fedora so our builds > should be quite similar. > > I really hope fedora has this same issue otherwise my debugging just got > more confusing. > > Zbigniew can you reproduce this on F20? It seems to be specifically related to chkconfig. If I shell out instead to something different (e.g. "whoami") all runs fine. I'm wondering if it's something related to semi-systemd stuff supported in our chkconfig... Perhaps our patches are out of date compared to fedora... Still hunting :) -- 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] systemd and cgroups
On Mon, Jan 13, 2014 at 5:35 PM, Thomas Bächler wrote: > Am 13.01.2014 02:47, schrieb Kay Sievers: >> On Mon, Jan 13, 2014 at 8:07 AM, Greg KH wrote: >>> On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: I need that pc for production, so I rapidly installed another distribution without systemd. So this problem is solved for me, but that doesn't solve that to force any user to use a default configuration without any possibility of user setup, and without documentation that can allow an user to do that, is just a design fault. >>> >>> That sounds like a distro issue, please take this up with your distro >>> developers, this isn't a systemd issue. >> >> http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ > > Let me quote from that: > > "By default systemd places all system services into their own control > groups in the "cpu" hierarchy." > > That is not true anymore since systemd 207 IIRC (whenever the whole > cgroup rework started, I might have the version number wrong). In fact, > systemd only puts services into the own cpu control group once you > explicitly set the CPUShares for a service. > > "Instead of evening out CPU per process this will cause CPU to be evened > out per service." > > This benefit has been lost with systemd 207, at least it is not the > default behaviour anymore. Yeah, that will all come back this year, when the new kernel cgroup interfaces are ready. The wiki should still apply to the above mentioned, a bit outdated, version in Debian. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] sd-dns: rename structs and functions with sd_ prefix
'Twas brillig, and Tom Gundersen at 13/01/14 13:36 did gyre and gimble: > On Mon, Jan 13, 2014 at 8:56 AM, Daniel Buch wrote: >> Okay, guess thats right? Second opinion, lennart? Kay? > > Yeah, wait a bit with the rename until we have some more feedback, > just heard a suggestion from Kay of calling it sd-resolv instead > (which sounds good to me). FWIW, I think resolv sounds a lot better than both asyncns and dns here. 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] [PATCH 2/2] sd-dns: rename structs and functions with sd_ prefix
Ohh.. that sounds reasonable, i can do the git mv and renameig (And squash to a single commit) when the decision is set :) 2014/1/13 Tom Gundersen > On Mon, Jan 13, 2014 at 8:56 AM, Daniel Buch > wrote: > > Okay, guess thats right? Second opinion, lennart? Kay? > > Yeah, wait a bit with the rename until we have some more feedback, > just heard a suggestion from Kay of calling it sd-resolv instead > (which sounds good to me). > > -t > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] .device units are not showing up on git systemd
On Mon, Jan 13, 2014 at 10:37:58AM +0100, Umut Tezduyar Lindskog wrote:
> Hi,
>
> .device units stopped showing up for me in git systemd since somewhere around
> mid-december. I have noticed that udevd and even udevadm monitor receives the
> kernel events but systemd itself never receives them.
>
> Further debugging, I have found out device_dispatch_io() (src/core/device.c)
> is never being called. It seemed like systemd binary is never aware of kernel
> events. I have proved this by:
>
> 1) strace -p 1
> 2) udevadm monitor
> 3) echo add > /sys/devices/platform/elk/net/eth0/uevent
> 4) Looking at the output of strace, nothing is changed, it is still in
> epoll_wait.
> Process 1 attached - interrupt to quit
> clock_gettime(CLOCK_MONOTONIC, {1030, 364651245}) = 0
> epoll_wait(4,
> 5) Looking at udevadm I can see the event being received.
> monitor will print the received events for:
> UDEV - the event which udev sends out after rule processing
> KERNEL - the kernel uevent
>
> KERNEL[1064.673596] add /devices/platform/elk/net/eth0 (net)
> UDEV [1064.983686] add /devices/platform/elk/net/eth0 (net)
>
> I have asked around in IIRC and seems like no one else is having the same
> problem. Before I further debug it, I wanted to check if something else might
> be stealing the epoll events from systemd or if anyone else has a suggestion.
I'd use lsof to check that PID 1 has KOJBECT_UEVENT open, and then
attach gdb to it is stored in the right places.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] sd-dns: rename structs and functions with sd_ prefix
On Mon, Jan 13, 2014 at 8:56 AM, Daniel Buch wrote: > Okay, guess thats right? Second opinion, lennart? Kay? Yeah, wait a bit with the rename until we have some more feedback, just heard a suggestion from Kay of calling it sd-resolv instead (which sounds good to me). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl [en|dis]able weirdness + reload (writes /run/nologin)
'Twas brillig, and Colin Guthrie at 13/01/14 11:16 did gyre and gimble: > 2. This is the much odder part of the problem I'm seeing. The call to > daemon_reload() at the end of the enable_unit() seems to trigger some > kind of broken daemon reload that puts things into a bad state, > including a stale /run/nologin file. > > I'm not sure WHY this does this, but it's very reliably reproducible. I > have a native sysvinit script called numlock. All I need to do to > trigger the bad state is "systemctl disable numlock". After the call, > the systemd daemon is reloaded and it goes into this bad state > completely with /run/nologin file. > > If I comment out call or use --no-reload, then all is well. If I call > "systemctl daemon-reload" on it's own, all seems well. It just seems to > be this reload call specifically at the end of enable_unit() that > triggers the bad state. > > > > I'm going to try reverting some of the patches I have applied to see > where I get with things, as I see Zbigniew backed a few out of fedora > due to freeze rules, but I did also see some threads from Zbigniew about > the whole /run/nologin, so I suspect he may be interested in this. I reverted the same patches that were reverted in Fedora so our builds should be quite similar. I really hope fedora has this same issue otherwise my debugging just got more confusing. Zbigniew can you reproduce this on F20? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl [en|dis]able weirdness + reload (writes /run/nologin)
Hi,
I've just been debugging a weird problem in my 208 build (which is quite
similar to Fedora's - a lot of the same patches).
So far I've noticed two problems:
1. If I do "systemctl enable sysvinitscript" it will print me a warning
about how the units do not carry [Install] sections. This is
unsurprising as there are no units (the systemctl.c mangled_names - or
just names in git master) left after the enable_sysv_units() method is
called and the first item is a pointer to a null string. I suspect
various bus calls could just be harmlessly skipped if this is the case
(i.e. just don't do the various unit related method calls) as we know
they are handled locally.
I've attached two patches which should solve this (one for 208+patches
and one for git master aka 209) although I've not tested either
directly. Some other eyes on it as to whether it's the correct approach
or not would be appreciated. The only difference between the two
versions is a variable name change.
2. This is the much odder part of the problem I'm seeing. The call to
daemon_reload() at the end of the enable_unit() seems to trigger some
kind of broken daemon reload that puts things into a bad state,
including a stale /run/nologin file.
I'm not sure WHY this does this, but it's very reliably reproducible. I
have a native sysvinit script called numlock. All I need to do to
trigger the bad state is "systemctl disable numlock". After the call,
the systemd daemon is reloaded and it goes into this bad state
completely with /run/nologin file.
If I comment out call or use --no-reload, then all is well. If I call
"systemctl daemon-reload" on it's own, all seems well. It just seems to
be this reload call specifically at the end of enable_unit() that
triggers the bad state.
I'm going to try reverting some of the patches I have applied to see
where I get with things, as I see Zbigniew backed a few out of fedora
due to freeze rules, but I did also see some threads from Zbigniew about
the whole /run/nologin, so I suspect he may be interested in this.
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/
>From 4c9ab5d7d7dc8e18769580fc2f7ac16b6d16bd91 Mon Sep 17 00:00:00 2001
From: Colin Guthrie
Date: Mon, 13 Jan 2014 11:06:35 +
Subject: [PATCH] systemctl: Do not attempt native calls for enable/disable if
sysvinit handleds all units.
If you have sysvinit compat enabled, it might deal with all the passed
in unit names leaving only a null termitated strv structure.
This cannot be iterated (sensibly) and thus we should just bail out
and not bother calling various native methods.
This should prevent a bogus warning regarding the lack of [Install]
sections in systemd units when enabling a sysvinit unit.
---
src/systemctl/systemctl.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index dd95df1..03dc50c 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4677,6 +4677,11 @@ static int enable_unit(sd_bus *bus, char **args) {
return r;
if (!bus || avoid_bus()) {
+/* If the sysvinit compat calls have handled everything we may
+ * have none left to deal with natively... */
+if (!names[0])
+goto finish;
+
if (streq(verb, "enable")) {
r = unit_file_enable(arg_scope, arg_runtime, arg_root, names, arg_force, &changes, &n_changes);
carries_install_info = r;
@@ -4713,6 +4718,11 @@ static int enable_unit(sd_bus *bus, char **args) {
bool send_force = true;
const char *method;
+/* If the sysvinit compat calls have handled everything we may
+ * have none left to deal with natively... */
+if (!names[0])
+goto reload;
+
if (streq(verb, "enable")) {
method = "EnableUnitFiles";
expect_carries_install_info = true;
@@ -4775,6 +4785,7 @@ static int enable_unit(sd_bus *bus, char **args) {
if (r < 0)
return r;
+reload:
/* Try to reload if enabeld */
if (!arg_no_reload)
r = daemon_reload(bus, args);
--
1.8.4.5
>From 75b710994721fd9dd58715765368ef4cde15172b Mon Sep 17 00:00:00 2001
From: Colin Guthrie
Date: Mon, 13 Jan 2014 11:06:35 +
Subject: [PATCH] systemctl: Do not attempt native calls for enable/disable if
sysvinit handleds all units.
If you have sysvinit compat enabled, it might deal with all the passed
in unit names leaving only a null termitated strv structure.
This cannot be iterated (sensibly)
Re: [systemd-devel] [alsa-devel] [PATCH] alsa-restore.rules: refer to correct attr
At Sun, 12 Jan 2014 11:39:29 -0500,
Dave Reisner wrote:
>
> On Sun, Jan 12, 2014 at 11:15:52AM -0500, Dave Reisner wrote:
> > $attr{number} in the RUN rule is an empty expansion. This makes sense,
> > because the path doesn't exist -- i.e., it refers to the path:
> >
> > /sys/devices/pci:00/foo/bar/sound/card0/controlC0/number
> >
> > Instead, refer to $attr{device/number}, which does exist.
> >
> > Signed-off-by: Dave Reisner
> > ---
> > This seems to have been broken when it was first introduced a little over
> > three years ago (de7c3eff0e).
>
> I dug into this a little more to figure out why this potentially *would*
> have worked and found the following advice from udev(7) about $attr{}:
>
> If the matching device does not have such an attribute, and a previous
> KERNELS, SUBSYSTEMS, DRIVERS, or ATTRS test selected a parent device,
> then the attribute from that parent device is used.
>
> So, knowing how RUN expansions work, the simple presence of the
> following rule causes $attr{number} to expand properly
>
> SUBSYSTEM=="sound", ATTRS{id}=="M2496"
>
> I named this /etc/udev/rules/91-alsa-foo.rules -- intentionally after
> the restore rule.
>
> Of course, this specifically matches my system, but one could imagine
> a more general rule which would cause parent matches and thus change the
> behavior of the subsequent $attr{number} expansion. I'm not sure if this
> is intended behavior in udev since the parent match doesn't occur in the
> same rule.
>
> So, $attr{number} is potentially correct (but this seems weird), while
> $attr{device/number} should always be correct.
>
> Hope this makes sense...
Yeah, $attr{device/number} looks definitely better.
I applied the patch now. Thanks.
Takashi
>
> > Please CC me on replies as I am not subscribed to the list.
> >
> > alsactl/90-alsa-restore.rules.in | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/alsactl/90-alsa-restore.rules.in
> > b/alsactl/90-alsa-restore.rules.in
> > index 88e12e0..c68119d 100644
> > --- a/alsactl/90-alsa-restore.rules.in
> > +++ b/alsactl/90-alsa-restore.rules.in
> > @@ -2,7 +2,7 @@ ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*",
> > KERNELS!="card*", GOTO="
> > GOTO="alsa_restore_end"
> >
> > LABEL="alsa_restore_go"
> > -TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl restore $attr{number}"
> > -TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl nrestore $attr{number}"
> > +TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl restore
> > $attr{device/number}"
> > +TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl nrestore
> > $attr{device/number}"
> >
> > LABEL="alsa_restore_end"
> > --
> > 1.8.5.2
> >
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] .device units are not showing up on git systemd
Hi,
.device units stopped showing up for me in git systemd since somewhere around
mid-december. I have noticed that udevd and even udevadm monitor receives the
kernel events but systemd itself never receives them.
Further debugging, I have found out device_dispatch_io() (src/core/device.c) is
never being called. It seemed like systemd binary is never aware of kernel
events. I have proved this by:
1) strace -p 1
2) udevadm monitor
3) echo add > /sys/devices/platform/elk/net/eth0/uevent
4) Looking at the output of strace, nothing is changed, it is still in
epoll_wait.
Process 1 attached - interrupt to quit
clock_gettime(CLOCK_MONOTONIC, {1030, 364651245}) = 0
epoll_wait(4,
5) Looking at udevadm I can see the event being received.
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1064.673596] add /devices/platform/elk/net/eth0 (net)
UDEV [1064.983686] add /devices/platform/elk/net/eth0 (net)
I have asked around in IIRC and seems like no one else is having the same
problem. Before I further debug it, I wanted to check if something else might
be stealing the epoll events from systemd or if anyone else has a suggestion.
Our system is an embedded system with linux 3.10. We do not use hwdb.bin.
Thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
Am 13.01.2014 02:47, schrieb Kay Sievers: > On Mon, Jan 13, 2014 at 8:07 AM, Greg KH wrote: >> On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: >>> I need that pc for production, so I rapidly installed another >>> distribution without systemd. So this problem is solved for me, but >>> that doesn't solve that to force any user to use a default >>> configuration without any possibility of user setup, and without >>> documentation that can allow an user to do that, is just a design fault. >> >> That sounds like a distro issue, please take this up with your distro >> developers, this isn't a systemd issue. > > http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ Let me quote from that: "By default systemd places all system services into their own control groups in the "cpu" hierarchy." That is not true anymore since systemd 207 IIRC (whenever the whole cgroup rework started, I might have the version number wrong). In fact, systemd only puts services into the own cpu control group once you explicitly set the CPUShares for a service. "Instead of evening out CPU per process this will cause CPU to be evened out per service." This benefit has been lost with systemd 207, at least it is not the default behaviour anymore. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
