[systemd-devel] libsystemd-bus and glib port - problem with GVariant Serialization
Hi,
I'm working on port gdbus natively onto kdbus. I've already done most
part of this project - Hello, RequestName, ReleaseName, List*, Get*,
NameHasOwner and others org.freedesktop.DBus methods are implemented and
works great, what is still missing at this moment are AddMatch and
RemoveMatch, but it shouldn't be problem and it will be done as soon as
I solve the current problem with serialization. So...
In glib, I changed header protocol version to '2' (header already has
field with information about length of the additional header fields
array - everything is as described it in GVARIANT-SERIALIZATION
document), but if I try send method call from my gio test apllication to
second application (which uses libsystemd-bus) I get Bad message from
libsystemd-bus. It is probably problem with serialization in my glib...
I did some research. I prepared two applications - first uses my glib
with kdbus interface, second uses libsystemd-bus. Both applications
invoke the same method call as below:
1) Application 1 (GLIB)
result = g_dbus_connection_call_sync (connection,
org.freedesktop.systemd.test,
/,
org.freedesktop.systemd.test,
Slow,
NULL,
NULL,
G_DBUS_CALL_FLAGS_NONE,
-1,
NULL,
error);
2) Application 2 (LIBSYSTEMD-BUS)
r = sd_bus_message_new_method_call(
bus,
org.freedesktop.systemd.test,
/,
org.freedesktop.systemd.test,
Slow,
m);
if (r 0) {
log_error(Failed to allocate method call: %s,
strerror(-r));
goto finish;co je
}
sd_bus_message_unref(reply);
reply = NULL;
r = sd_bus_call(bus, m, 0, error, reply);
After that I added hexdump() function to libsystemd-bus and compared the
same method invocation in glib and libsystemd-bus after serialization:
1) Application 1 (GLIB)
: 6c 01 00 02 00 00 00 00 02 00 00 00 6d 00 00 00 l...m...
0010: 01 01 6f 00 01 00 00 00 2f 00 00 00 00 00 00 00 ..o./...
0020: 03 01 73 00 04 00 00 00 53 6c 6f 77 00 00 00 00 ..s.Slow
0030: 02 01 73 00 1c 00 00 00 6f 72 67 2e 66 72 65 65 ..s.org.free
0040: 64 65 73 6b 74 6f 70 2e 73 79 73 74 65 6d 64 2e desktop.systemd.
0050: 74 65 73 74 00 00 00 00 06 01 73 00 1c 00 00 00 test..s.
0060: 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 6f 70 2e org.freedesktop.
0070: 73 79 73 74 65 6d 64 2e 74 65 73 74 00 00 00 00 systemd.test
2) Application 2 (LIBSYSTEMD-BUS)
: 6c 01 00 02 00 00 00 00 01 00 00 00 73 00 00 00 l...s...
0010: 01 00 00 00 00 00 00 00 2f 00 00 6f 00 00 00 00 /..o
0020: 03 00 00 00 00 00 00 00 53 6c 6f 77 00 00 73 00 Slow..s.
0030: 02 00 00 00 00 00 00 00 6f 72 67 2e 66 72 65 65 org.free
0040: 64 65 73 6b 74 6f 70 2e 73 79 73 74 65 6d 64 2e desktop.systemd.
0050: 74 65 73 74 00 00 73 00 06 00 00 00 00 00 00 00 test..s.
0060: 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 6f 70 2e org.freedesktop.
0070: 73 79 73 74 65 6d 64 2e 74 65 73 74 00 00 73 0c systemd.test..s.
0080: 1f 47 6f 00 00 00 00 00 .Go.
As you can see above, path name, interface name and others string are in
the same place. Problem is with signature positions. Any ideas on what
could be causing the problem?
BR,
--
Lukasz Skalski
Samsung RD Institute Poland
Samsung Electronics
l.skal...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
On Thu, Jan 2, 2014 at 3:43 AM, Kay Sievers k...@vrfy.org wrote: On Wed, Jan 1, 2014 at 4:41 PM, Tom Gundersen t...@jklm.no wrote: I just pushed the last couple of patches to enable DHCPv4 support in networkd[0]. Testing and feedback would be greatly appreciated. It is still very basic, but I'm personally using it full-time on my laptop (replacing NetworkManager/ConnMan), so it should be complete enough to at least start testing. If you want to use it with wifi (as I'm doing), just (e.g.) enable wpa_supplicant-nl80211@.service for your device and configure that for your networks manually. I have a wired e1000e connection to a DSL router. I removed NetworkManager and added that: $ cat /etc/systemd/network/wired.network [Match] Name=enp0s25 [Network] DHCP=yes $ journalctl -b -o short-monotonic -u systemd-networkd.service [1.318123] lon systemd[1]: Started Network Service. [3.073097] lon systemd-networkd[205]: Network '(null)' being applied to link 'enp0s25' [3.301739] lon systemd-networkd[205]: Interface 'enp0s25' is up [4.815708] lon systemd-networkd[205]: Interface 'enp0s25' is connected [8.943769] lon systemd-networkd[205]: Received config over DHCPv4 [8.952326] lon systemd-networkd[205]: Addresses set for link 'enp0s25' [8.952614] lon systemd-networkd[205]: Routes set for link 'enp0s25' [8.952957] lon systemd-networkd[205]: Link 'enp0s25' configured Any idea why it takes 4 seconds? Do you have any numbers for your setup? Depending on the network I'm connecting to it takes between 200 ms and 5 seconds (the numbers seem to be stable for any given network). As far as I have been able to tell we are not doing anything wrong (i.e., it simply takes the dhcp server that long to send us a reply). It has been some time since I tried with debug output from the dhcp library though, so should re-test to verify. And there is a (null) in the log output. Ah, that should be changed (it tries to print the Description). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
AFAIK Mac OSX does a trick here: it uses the last IP (still in the old lease file) and immediately configures the network with that. *) Then it does the DHCP, asking for the same IP. If the IP returned was changed, it will re-change. But usually it's the same IP address, and therefore on this OS DHCP doesn't take longer than static IP. Strictly speaking the DHCP protocol is not violated that way: DHCP itself works as expected, e.g. the DHCP packets are following the RFC. And ip clients should copy with changed IP addresses anyway, because DHCP can assign any IP address at renogiation time. *) it might do an RARP to find out if the IP is available ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig holgerschu...@gmail.com wrote: AFAIK Mac OSX does a trick here Yeah, and we should do the same: http://tools.ietf.org/search/rfc4436. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is there any way to stop services in cgroup?
Hello. I wonder that systemd has a method to stop all services in specific cgroup. Actually, I have looked for a method to stop all services as the same time. I have searched many manual in systemd site. I couldn't find any method to stop all services which I want to stop. I need some advices for solving this problem. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there any way to stop services in cgroup?
On 01/02/2014 02:02 PM, Tony Seo wrote: Hello. I wonder that systemd has a method to stop all services in specific cgroup. Actually, I have looked for a method to stop all services as the same time. I have searched many manual in systemd site. I couldn't find any method to stop all services which I want to stop. I need some advices for solving this problem. You would create a custom target and have all services bind to that target then you can simply run systemctl stop my-custom.target which would stop a.service b.service c.service that are bound to that target as opposed to having to run systemctl stop a.service b.service c.service JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
Am 02.01.2014 13:55, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig holgerschu...@gmail.com wrote: AFAIK Mac OSX does a trick here Yeah, and we should do the same: http://tools.ietf.org/search/rfc4436 because this explains why i sometimes see firewall logs in the company network where all severs are blocking private ranges as spoofed address i would be thankful not starting the same odd behavior with linux clients this is also really funny if it leads calling your ISP names because it appears that the managed router let public IP's connect to the fileserver in a non-public range until you find out that was the public home IP of a employer please don't do that - thank you! signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
Hei Reindl, On Thu, Jan 2, 2014 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.01.2014 13:55, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig holgerschu...@gmail.com wrote: AFAIK Mac OSX does a trick here Yeah, and we should do the same: http://tools.ietf.org/search/rfc4436 because this explains why i sometimes see firewall logs in the company network where all severs are blocking private ranges as spoofed address i would be thankful not starting the same odd behavior with linux clients this is also really funny if it leads calling your ISP names because it appears that the managed router let public IP's connect to the fileserver in a non-public range until you find out that was the public home IP of a employer please don't do that - thank you! I'm not sure I fully understand what you are referring to. Did you read the RFC? Could you explain a bit more precisely what setups causes problems under that RFC? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [Bug] minor typo on systemd wiki page
On http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ To create and start a unit in the cgroup tree use the StartTransientUnit() method on the Manager object exposed by systemd's PID 1 on the bus, see the Bus API Documentation for details. This call takes for arguments. The last for should be four. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
Am 02.01.2014 16:29, schrieb Tom Gundersen: Hei Reindl, On Thu, Jan 2, 2014 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.01.2014 13:55, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig holgerschu...@gmail.com wrote: AFAIK Mac OSX does a trick here Yeah, and we should do the same: http://tools.ietf.org/search/rfc4436 because this explains why i sometimes see firewall logs in the company network where all severs are blocking private ranges as spoofed address i would be thankful not starting the same odd behavior with linux clients this is also really funny if it leads calling your ISP names because it appears that the managed router let public IP's connect to the fileserver in a non-public range until you find out that was the public home IP of a employer please don't do that - thank you! I'm not sure I fully understand what you are referring to. Did you read the RFC? Could you explain a bit more precisely what setups causes problems under that RFC? the problems are that if someone comes back with his Apple notebook this crap starts to using the old ip-address and triggering all sorts of alarms, firewall-rules and so on at least in one case i called our ISP names because i did not imagine that any operating system may be that stupid to use the public IP of the users home-internet to re-connect to the fileserver and after that failed ask our DHCP for a correct IP signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
On Thu, Jan 2, 2014 at 4:37 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.01.2014 16:29, schrieb Tom Gundersen: Hei Reindl, On Thu, Jan 2, 2014 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.01.2014 13:55, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig holgerschu...@gmail.com wrote: AFAIK Mac OSX does a trick here Yeah, and we should do the same: http://tools.ietf.org/search/rfc4436 because this explains why i sometimes see firewall logs in the company network where all severs are blocking private ranges as spoofed address i would be thankful not starting the same odd behavior with linux clients this is also really funny if it leads calling your ISP names because it appears that the managed router let public IP's connect to the fileserver in a non-public range until you find out that was the public home IP of a employer please don't do that - thank you! I'm not sure I fully understand what you are referring to. Did you read the RFC? Could you explain a bit more precisely what setups causes problems under that RFC? the problems are that if someone comes back with his Apple notebook this crap starts to using the old ip-address and triggering all sorts of alarms, firewall-rules and so on Hm, sounds odd. This protocol is precisely meant to avoid that sort of problem (by detecting whether or not you are connecting to the same network). I heard that some old Apple devices used a more naive protocol that would indeed just reuse the old IP... When did you last experience this? Any clue about what hardware/software version it was causing the problem? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there any way to stop services in cgroup?
On Thu, Jan 2, 2014 at 4:02 PM, Tony Seo tonys...@gmail.com wrote: Hello. I wonder that systemd has a method to stop all services in specific cgroup. Actually, I have looked for a method to stop all services as the same time. I have searched many manual in systemd site. I couldn't find any method to stop all services which I want to stop. If you're trying to stop all instances of a service, systemd-git recently had wildcard support added, so `systemctl stop sshd@*.service` will now work. Otherwise, use a .target and BindsTo. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
Am 02.01.2014 16:41, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 4:37 PM, Reindl Harald h.rei...@thelounge.net wrote: the problems are that if someone comes back with his Apple notebook this crap starts to using the old ip-address and triggering all sorts of alarms, firewall-rules and so on Hm, sounds odd. This protocol is precisely meant to avoid that sort of problem (by detecting whether or not you are connecting to the same network). I heard that some old Apple devices used a more naive protocol that would indeed just reuse the old IP... When did you last experience this? Any clue about what hardware/software version it was causing the problem? 2013, OSX 10.6, the first Mac Book Pro generation not supported by OSX 10.6 as far as i know, one bought a few months later would be supported given that this machines are not that old and expensive they will exist longer here and there (yes i know about the securtiy nightmare but in that context OSX should be banned at all) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
On Thu, Jan 2, 2014 at 4:48 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.01.2014 16:41, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 4:37 PM, Reindl Harald h.rei...@thelounge.net wrote: the problems are that if someone comes back with his Apple notebook this crap starts to using the old ip-address and triggering all sorts of alarms, firewall-rules and so on Hm, sounds odd. This protocol is precisely meant to avoid that sort of problem (by detecting whether or not you are connecting to the same network). I heard that some old Apple devices used a more naive protocol that would indeed just reuse the old IP... When did you last experience this? Any clue about what hardware/software version it was causing the problem? 2013, OSX 10.6, the first Mac Book Pro generation not supported by OSX 10.6 as far as i know, one bought a few months later would be supported given that this machines are not that old and expensive they will exist longer here and there (yes i know about the securtiy nightmare but in that context OSX should be banned at all) Thanks, I'll try to dig into this a bit before implementing anything (and anyway, I expect this to be configurable if we add it). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Bug] minor typo on systemd wiki page
On Thu, Jan 02, 2014 at 04:31:41PM +0100, Holger Schurig wrote: On http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ To create and start a unit in the cgroup tree use the StartTransientUnit() method on the Manager object exposed by systemd's PID 1 on the bus, see the Bus API Documentation for details. This call takes for arguments. The last for should be four. Fixed. Thanks. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/28/2013 11:47 AM, Michael Scherer wrote: Le samedi 28 décembre 2013 à 14:30 +0100, Lennart Poettering a écrit : On Fri, 27.12.13 23:26, m...@zarb.org (m...@zarb.org) wrote: From: Michael Scherer m...@zarb.org This permit to let system administrators decide of the domain of a service. This can be used with templated units to have each service in a différent domain ( for example, a per customer database, using MLS or anything ), or can be used to force a non selinux enabled system (jvm, erlang, etc) to start in a different domain for each service. Hmm, so far (as I understood it) the SELinux guys always wanted to make sure that label configuration stays in the the selinux database and nowhere else. Yep, I know and they are right, we shouldn't put configuration everywhere in the system. But there is a few cases where the selinux policy cannot express what we want ( or at least, I do not know how to do it ). First case is doing something like openshift, with 1 different domain per user. Since the transitions are mostly handled in kernel space ( except for specific case like sepostgresql ), it kinda restrict what we can do in term of smart transition. In the case of openshift, this use a specific pam module (pam_openshift) and specific plugins in the code, because the policy is a bit too static to handle that. So using templated units, we could do for example : SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023 or similar tricks. Or just handle things manually, with static SELinuxContext ( or include, or anything ). The second case is caused by a limitation of the current way of doing transition. My main motivation is to solve https://bugzilla.redhat.com/show_bug.cgi?id=969757 , because right now, we cannot ask to erlang to run in a different domain unless if we write 1 shell wrapper per erlang application just to trigger the transition, or until we make erlang selinux-aware, like postgresql is. So rather than duplicate shell wrappers or adding code everywhere, I was thinking doing it in systemd directly would be beneficial for everybody by reducing needed changes to the only stuff that matter, having the context we want to switch to. I do not expect SELinuxContext to be used by upstream units, and I guess that a distribution can decide to have them being unused by policy if that's a issue. It should also be noted that upstart do support a similar configuration for apparmor, https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/+merge/164169 And I was pondering on adding it as well to systemd, since some systemd consumers are using apparmor, and because feature parity is IMHO important if we want to let people use systemd on Ubuntu. I'd like Dan Walsh's opinion whether this addition fits into what the SELinux guys want or not. Dan? Patch looks fine though. I like this patch, and I have seen people saying we have this capability in RHEL7 :^( Currently people in a sysvinit scripts are using runcon for similar features. And as someone described handling of java, mono, erlang type scripts where the command is not easy to differentiate. We also allow people to do something similar with sudo. ROLE=unconfined_r TYPE=unconfined_t. I would prefer if app writers do not start hard coding SELinux contexts into the unit files, but allowing administrators or third parties like openshift to override I do not have a problem with it. It could allow a administrator to say run this script as unconfined_t, which may or may not cause other problems. We might want to allow more granularity on this then just context.Since we allow sudo to specify role and type and we allow runcon to specify all fields of SELinux. BTW Use dwa...@redhat.com for my email, not my private (Not so private) home email. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLFlCoACgkQrlYvE4MpobMVZgCghr6UOCybitcKKqV5HKISjKDc EhoAn36vppR/4zrjhBeyypzlWqawDxdn =3jEw -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
Le jeudi 02 janvier 2014 à 11:30 -0500, Daniel J Walsh a écrit : On 12/28/2013 11:47 AM, Michael Scherer wrote: Le samedi 28 décembre 2013 à 14:30 +0100, Lennart Poettering a écrit : On Fri, 27.12.13 23:26, m...@zarb.org (m...@zarb.org) wrote: From: Michael Scherer m...@zarb.org This permit to let system administrators decide of the domain of a service. This can be used with templated units to have each service in a différent domain ( for example, a per customer database, using MLS or anything ), or can be used to force a non selinux enabled system (jvm, erlang, etc) to start in a different domain for each service. Hmm, so far (as I understood it) the SELinux guys always wanted to make sure that label configuration stays in the the selinux database and nowhere else. Yep, I know and they are right, we shouldn't put configuration everywhere in the system. But there is a few cases where the selinux policy cannot express what we want ( or at least, I do not know how to do it ). First case is doing something like openshift, with 1 different domain per user. Since the transitions are mostly handled in kernel space ( except for specific case like sepostgresql ), it kinda restrict what we can do in term of smart transition. In the case of openshift, this use a specific pam module (pam_openshift) and specific plugins in the code, because the policy is a bit too static to handle that. So using templated units, we could do for example : SELinuxContext=staff_u:staff_r:%s_t:s0-s0:c0.c1023 or similar tricks. Or just handle things manually, with static SELinuxContext ( or include, or anything ). The second case is caused by a limitation of the current way of doing transition. My main motivation is to solve https://bugzilla.redhat.com/show_bug.cgi?id=969757 , because right now, we cannot ask to erlang to run in a different domain unless if we write 1 shell wrapper per erlang application just to trigger the transition, or until we make erlang selinux-aware, like postgresql is. So rather than duplicate shell wrappers or adding code everywhere, I was thinking doing it in systemd directly would be beneficial for everybody by reducing needed changes to the only stuff that matter, having the context we want to switch to. I do not expect SELinuxContext to be used by upstream units, and I guess that a distribution can decide to have them being unused by policy if that's a issue. It should also be noted that upstart do support a similar configuration for apparmor, https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/+merge/164169 And I was pondering on adding it as well to systemd, since some systemd consumers are using apparmor, and because feature parity is IMHO important if we want to let people use systemd on Ubuntu. I'd like Dan Walsh's opinion whether this addition fits into what the SELinux guys want or not. Dan? Patch looks fine though. I like this patch, and I have seen people saying we have this capability in RHEL7 :^( Currently people in a sysvinit scripts are using runcon for similar features. And as someone described handling of java, mono, erlang type scripts where the command is not easy to differentiate. We also allow people to do something similar with sudo. ROLE=unconfined_r TYPE=unconfined_t. I would prefer if app writers do not start hard coding SELinux contexts into the unit files, but allowing administrators or third parties like openshift to override I do not have a problem with it. It could allow a administrator to say run this script as unconfined_t, which may or may not cause other problems. We might want to allow more granularity on this then just context.Since we allow sudo to specify role and type and we allow runcon to specify all fields of SELinux. IE, you would like to have something like SELinuxRole, SELinuxType, SELinuxRange and SELinuxUser, each permitting to override 1 single field of the context ? It shouldn't be that hard to do ( a bit longer to properly test maybe ), I am however not sure if we should keep the 2 styles of configuration For example, in what order would the different field be applied, if I set SELinuxuser and the context etc. And if we use 4 configurations directives instead of 1, it also make the request for a default SELinux context asked by David a bit harder and a bit less elegant ( since that would mean 4 directive for the settings, 1 directive for disabling, and 4 directive for each default of the field, unless we only offer default context ). I will try to cook a new version of the patch with 4 splitted fields for next week while we discuss the proposal -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there any way to stop services in cgroup?
В Чт, 02/01/2014 в 17:43 +0200, Mantas Mikulėnas пишет: On Thu, Jan 2, 2014 at 4:02 PM, Tony Seo tonys...@gmail.com wrote: Hello. I wonder that systemd has a method to stop all services in specific cgroup. Actually, I have looked for a method to stop all services as the same time. I have searched many manual in systemd site. I couldn't find any method to stop all services which I want to stop. If you're trying to stop all instances of a service, systemd-git recently had wildcard support added, so `systemctl stop sshd@*.service` will now work. Otherwise, use a .target and BindsTo. PartOf is probably more appropriate here. But the practical problem is that both must be specified for each unit explicitly, which simply does not scale for future unknown services. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
On Wed, Dec 11, 2013 at 2:41 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 11.12.13 02:13, Daniel Buch (boogiewasth...@gmail.com) wrote:
Heya,
Hmm, so thinking about it I have the suspicion this should probably be
linked into libsystemd-bus, and thus live in src/libsystemd-bus/. The
reason for this is cyclic deps: libsystemd-bus really should make use of
this to resolve host names when used in tcp mode. However, this stuff
really should come with integration into sd-event out of the box too
which is already part of libsystemd-bus (for similar reasons). So we'd
have asyncns both as consumer of APIs of libsystemd-bus and as
provider of APIs to it.
Of course, one could argue that DNS is hardly part of bus access but
then again, sd-event is neither. Maybe we should just start treating
libsystemd-bus as that library where everything we expose ends up in,
except when it is really clear that it's only consumer, never provider
to stuff in libsystemd-bus.
Reindentation is done to fit systemd
---
Makefile.am | 23 +
src/libsystemd-asyncns/asyncns.c | 1513
+
src/libsystemd-asyncns/asyncns.h | 163
src/libsystemd-asyncns/test-asyncns.c | 178
4 files changed, 1877 insertions(+)
create mode 100644 src/libsystemd-asyncns/asyncns.c
create mode 100644 src/libsystemd-asyncns/asyncns.h
create mode 100644 src/libsystemd-asyncns/test-asyncns.c
diff --git a/Makefile.am b/Makefile.am
index 19da6ea..a0564b5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -659,6 +659,29 @@ tests += test-rtnl
#
--
noinst_LTLIBRARIES += \
+ libsystemd-asyncns.la
+
+libsystemd_asyncns_la_SOURCES = \
+ src/libsystemd-asyncns/asyncns.c \
+ src/libsystemd-asyncns/asyncns.h
To follow the naming scheme of the other libs we should probably call
this sd-asyncs.c, and the header file should be in src/systemd/
together with the other public APIs.
Hm, the fact that this is async is sort of a detail, is it not? I
mean, all our libs are async... How about sd-dns? It is slightly
wrong, but sd-ns could mean anything...
+
+libsystemd_asyncns_la_CFLAGS = \
+ -pthread
+
+test_asyncns_SOURCES = \
+ src/libsystemd-asyncns/test-asyncns.c
+
+test_asyncns_LDADD = \
+ libsystemd-asyncns.la
+
+test_asyncns_LDFLAGS = \
+ -lresolv \
+ -pthread
I figure the -lresolv thing will eventually need a configure.ac check,
but for now I'd just leave it like this, when this breaks for people I
am sure they will cook up a patch quickly...
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
Unnecessary, we do this on the gcc cmdline implicitly far all our files...
+
+/* #undef HAVE_PTHREAD */
+
+#include assert.h
+#include fcntl.h
+#include signal.h
+#include unistd.h
+#include sys/select.h
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include errno.h
+#include sys/wait.h
+#include sys/types.h
+#include pwd.h
+#include netinet/in.h
+#include arpa/nameser.h
+#include resolv.h
+#include dirent.h
+#include sys/time.h
+#include sys/resource.h
+#include stdint.h
+
+#ifdef HAVE_SYS_PRCTL_H
+#include sys/prctl.h
+#endif
This file isn't optional for us...
+
+#if HAVE_PTHREAD
+#include pthread.h
+#endif
+
+#include asyncns.h
+
+#ifndef MSG_NOSIGNAL
+#define MSG_NOSIGNAL 0
+#endif
This is non-Linux compat and should go i figure...
+struct asyncns {
probably should be called sd_asyncns now...
+int fds[MESSAGE_FD_MAX];
+
+#ifndef HAVE_PTHREAD
+pid_t workers[MAX_WORKERS];
+#elseso, you just suggested pthreads is the way to go. any strong reasons?
+pthread_t workers[MAX_WORKERS];
+#endif
We should probably stick to one implementation here... Either with
process or with threads, but not chicken out anymore like I did
before...
Every other day I come to different conclusions which one would be the
one and only mode we should support.
The big advantage of the process option is that things are neatly
isolated from the parent. THe big disadvantages are that it pollutes the
ps output and might generate page faults in the parent all the time,
since we fork and don't exec().
Right now I am more leaning towards the thread option. But maybe that
changes tomorrow again. Other opinions? Kay?
glib is embedding a copy of libasyncns currently, they opted for the
thread solution. Maybe we should follow suit.
Doesn't seem to be any strong arguments either way... So shall we just
go with pthreads, if that's what's used elsewhere...?
(Actually, it might be worth checking the glib copy, and see if they
made any changes to the sources, which we might want to steal back for us.
+#ifndef HAVE_PTHREAD
+
+static int close_allv(const int except_fds[]) {
We already have this in close_many() in util.h. This function can go away
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
On Thu, Jan 2, 2014 at 10:53 PM, Tom Gundersen t...@jklm.no wrote:
On Wed, Dec 11, 2013 at 2:41 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Wed, 11.12.13 02:13, Daniel Buch (boogiewasth...@gmail.com) wrote:
Heya,
Hmm, so thinking about it I have the suspicion this should probably be
linked into libsystemd-bus, and thus live in src/libsystemd-bus/. The
reason for this is cyclic deps: libsystemd-bus really should make use of
this to resolve host names when used in tcp mode. However, this stuff
really should come with integration into sd-event out of the box too
which is already part of libsystemd-bus (for similar reasons). So we'd
have asyncns both as consumer of APIs of libsystemd-bus and as
provider of APIs to it.
Of course, one could argue that DNS is hardly part of bus access but
then again, sd-event is neither. Maybe we should just start treating
libsystemd-bus as that library where everything we expose ends up in,
except when it is really clear that it's only consumer, never provider
to stuff in libsystemd-bus.
Reindentation is done to fit systemd
---
Makefile.am | 23 +
src/libsystemd-asyncns/asyncns.c | 1513
+
src/libsystemd-asyncns/asyncns.h | 163
src/libsystemd-asyncns/test-asyncns.c | 178
4 files changed, 1877 insertions(+)
create mode 100644 src/libsystemd-asyncns/asyncns.c
create mode 100644 src/libsystemd-asyncns/asyncns.h
create mode 100644 src/libsystemd-asyncns/test-asyncns.c
diff --git a/Makefile.am b/Makefile.am
index 19da6ea..a0564b5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -659,6 +659,29 @@ tests += test-rtnl
#
--
noinst_LTLIBRARIES += \
+ libsystemd-asyncns.la
+
+libsystemd_asyncns_la_SOURCES = \
+ src/libsystemd-asyncns/asyncns.c \
+ src/libsystemd-asyncns/asyncns.h
To follow the naming scheme of the other libs we should probably call
this sd-asyncs.c, and the header file should be in src/systemd/
together with the other public APIs.
Hm, the fact that this is async is sort of a detail, is it not? I
mean, all our libs are async... How about sd-dns? It is slightly
wrong, but sd-ns could mean anything...
+
+libsystemd_asyncns_la_CFLAGS = \
+ -pthread
+
+test_asyncns_SOURCES = \
+ src/libsystemd-asyncns/test-asyncns.c
+
+test_asyncns_LDADD = \
+ libsystemd-asyncns.la
+
+test_asyncns_LDFLAGS = \
+ -lresolv \
+ -pthread
I figure the -lresolv thing will eventually need a configure.ac check,
but for now I'd just leave it like this, when this breaks for people I
am sure they will cook up a patch quickly...
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
Unnecessary, we do this on the gcc cmdline implicitly far all our files...
+
+/* #undef HAVE_PTHREAD */
+
+#include assert.h
+#include fcntl.h
+#include signal.h
+#include unistd.h
+#include sys/select.h
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include errno.h
+#include sys/wait.h
+#include sys/types.h
+#include pwd.h
+#include netinet/in.h
+#include arpa/nameser.h
+#include resolv.h
+#include dirent.h
+#include sys/time.h
+#include sys/resource.h
+#include stdint.h
+
+#ifdef HAVE_SYS_PRCTL_H
+#include sys/prctl.h
+#endif
This file isn't optional for us...
+
+#if HAVE_PTHREAD
+#include pthread.h
+#endif
+
+#include asyncns.h
+
+#ifndef MSG_NOSIGNAL
+#define MSG_NOSIGNAL 0
+#endif
This is non-Linux compat and should go i figure...
+struct asyncns {
probably should be called sd_asyncns now...
+int fds[MESSAGE_FD_MAX];
+
+#ifndef HAVE_PTHREAD
+pid_t workers[MAX_WORKERS];
+#elseso, you just suggested pthreads is the way to go. any strong reasons?
+pthread_t workers[MAX_WORKERS];
+#endif
We should probably stick to one implementation here... Either with
process or with threads, but not chicken out anymore like I did
before...
Every other day I come to different conclusions which one would be the
one and only mode we should support.
The big advantage of the process option is that things are neatly
isolated from the parent. THe big disadvantages are that it pollutes the
ps output and might generate page faults in the parent all the time,
since we fork and don't exec().
Right now I am more leaning towards the thread option. But maybe that
changes tomorrow again. Other opinions? Kay?
glib is embedding a copy of libasyncns currently, they opted for the
thread solution. Maybe we should follow suit.
Doesn't seem to be any strong arguments either way... So shall we just
go with pthreads, if that's what's used elsewhere...?
Kay says:
yeah, a thread. seems natural, we do not share data with the main process
really
robusteness should not be an argument, for something rather trivial
-t
___
systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
On Thu, Jan 2, 2014 at 10:53 PM, Tom Gundersen t...@jklm.no wrote: On Wed, Dec 11, 2013 at 2:41 AM, Lennart Poettering lenn...@poettering.net wrote: To follow the naming scheme of the other libs we should probably call this sd-asyncs.c, and the header file should be in src/systemd/ together with the other public APIs. Hm, the fact that this is async is sort of a detail, is it not? I mean, all our libs are async... How about sd-dns? It is slightly wrong, but sd-ns could mean anything... libsystemd-dns sounds good to me. Right now I am more leaning towards the thread option. But maybe that changes tomorrow again. Other opinions? Kay? glib is embedding a copy of libasyncns currently, they opted for the thread solution. Maybe we should follow suit. Doesn't seem to be any strong arguments either way... So shall we just go with pthreads, if that's what's used elsewhere...? Yeah, a thread to call into the nss stuff sound like the better option than a worker process. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemctl: improve readability on failed commands
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
Not long ago a failed command would print:
Failed to start something.service: ...
regardless of whether the command was to start/stop/restart/etc.
With e3e0314 this was improved to print the method used. E.g. for stopping:
Failed to StopUnit something.service: ...
This patch matches the method to a more human readable word. E.g:
Failed to stop something.service: ...
---
src/systemctl/systemctl.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 67bc426..0b50813 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2067,12 +2067,24 @@ static int start_unit_one(
reply,
ss, name, mode);
if (r 0) {
+const char *command;
+
if (r == -ENOENT arg_action != ACTION_SYSTEMCTL)
/* There's always a fallback possible for
* legacy actions. */
return -EADDRNOTAVAIL;
-log_error(Failed to %s %s: %s, method, name,
bus_error_message(error, r));
+command =
+streq(method, StartUnit) ? start :
+streq(method, StopUnit) ? stop :
+streq(method, ReloadUnit) ? reload :
+streq(method, RestartUnit)? restart :
+streq(method, TryRestartUnit) ?
try-restart :
+streq(method, ReloadOrRestartUnit)?
reload-or-restart :
+streq(method, ReloadOrTryRestartUnit) ?
reload-or-try-restart :
+method;
+
+log_error(Failed to %s %s: %s, command, name,
bus_error_message(error, r));
return r;
}
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-logind retrying constantly when operation is denied by selinux
I recently noticed loud and sustained disk noise, and iotop reported that
jdb2 was going full throttle on /dev/sda1 (my root partition). I ran
`journalctl -f` to see if anything obvious was wrong, and was greeted with
the following messages:
Jan 03 10:23:04 meep systemd[1]: SELinux policy denies access.
Jan 03 10:23:04 meep systemd-logind[447]: Failed to query ActiveState:
Access denied
These two messages were appearing constantly - more than 200x per second
each. I quickly ran `setenforce 0`, and everything went quiet.
I think this is due to something I did yesterday - I used `audit2allow` to
allow system-wide systemd unit files to live in a home directory[0]. This
rule added:
allow systemd_logind_t user_home_t:service start;
When I run audit2allow again now (after the errors), it wants to add:
allow systemd_logind_t user_home_t:service { status stop };
I have now changed this to:
allow systemd_logind_t user_home_t:service *;
Which seems to compile, and hopefully won't cause the problem to recur
whenever systemd performs a new operation on this service. But I thought
I'd report my observations here anyway, since it seems pretty drastic for
systemd-logind to be retrying this failed operation 200+ times a second
when the error is access denied (something that is unlikely to be fixed
in the next few milliseconds).
Of course, I don't know if this failure case is distinct from other errors
that *do* benefit from immediate-and-furious-retry, so I'll leave it to the
developers to determine whether something better can / should be done here.
Cheers,
- Tim.
[0] I have a modified user@.service unit file managed in my home partition,
because I want to run `systemd --user` via a wrapper that picks up
additional user config. I symlink it under /etc/systemd/system/ rather than
keeping it in there because / is wiped on OS upgrades, but /home is a
separate partition that I keep between upgrades.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: improve readability on failed commands
On Fri, Jan 03, 2014 at 12:37:32AM +0100, Thomas H.P. Andersen wrote:
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
Not long ago a failed command would print:
Failed to start something.service: ...
regardless of whether the command was to start/stop/restart/etc.
With e3e0314 this was improved to print the method used. E.g. for stopping:
Failed to StopUnit something.service: ...
This patch matches the method to a more human readable word. E.g:
Failed to stop something.service: ...
---
src/systemctl/systemctl.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 67bc426..0b50813 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2067,12 +2067,24 @@ static int start_unit_one(
reply,
ss, name, mode);
if (r 0) {
+const char *command;
+
if (r == -ENOENT arg_action != ACTION_SYSTEMCTL)
/* There's always a fallback possible for
* legacy actions. */
return -EADDRNOTAVAIL;
-log_error(Failed to %s %s: %s, method, name,
bus_error_message(error, r));
+command =
+streq(method, StartUnit) ? start :
+streq(method, StopUnit) ? stop :
+streq(method, ReloadUnit) ? reload :
+streq(method, RestartUnit)? restart :
+streq(method, TryRestartUnit) ?
try-restart :
+streq(method, ReloadOrRestartUnit)?
reload-or-restart :
+streq(method, ReloadOrTryRestartUnit) ?
reload-or-try-restart :
+method;
Hm, we have the opposite mapping done by hand in parse_argv too...
Maybe we could coalesce those two into a single table? I think
reduce the chances of them getting out of sync.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SELinuxContext configuration item
On 12/28/2013 01:30 PM, Lennart Poettering wrote: On Fri, 27.12.13 23:26,m...@zarb.org (m...@zarb.org) wrote: From: Michael Schererm...@zarb.org This permit to let system administrators decide of the domain of a service. This can be used with templated units to have each service in a différent domain ( for example, a per customer database, using MLS or anything ), or can be used to force a non selinux enabled system (jvm, erlang, etc) to start in a different domain for each service. Hmm, so far (as I understood it) the SELinux guys always wanted to make sure that label configuration stays in the the selinux database and nowhere else. Right and if you add this you need to add something for the other security solutions as well ( apparmor etc ). This introduces yet another place for administrators to look at while debugging problems so the question to ask here is. Is adding this ability to unit files the right way to solve what's trying to be solved here? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
Just to consider what other folks are doing, I know Fedora builds libcurl with a thread-isolated, NSS-based resolver. On a less-related note, at Pantheon improve DNS performance on servers by setting resolv.conf to localhost and running Unbound there. Unbound then uses the datacenter's recursive DNS servers for things that miss the local cache. This minimizes the time spent in blocked threads -- and waiting for lookups even with async libraries. As a bonus, you also get DNSSec validation when possible. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
