Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
Le lundi 24 mars 2014 à 19:24 +0100, Lennart Poettering a écrit : On Mon, 24.03.14 19:20, Frederic Crozat (fcro...@suse.com) wrote: Le lundi 24 mars 2014 à 18:58 +0100, Lennart Poettering a écrit : It's simply that the PID file info in the chkconfig header is just increadibly useful (since it allows us to identify the main process of a service) and I'd really like to make sure we make use of it wherever possible. So that chkconfig header bit is what I am interested in, not the priority number... I must confess I stole the PID file info part and added it in the LSB header parsing, because we sometime have initscripts which such informations (which is good) and we also sometime would like to have this information handy, despite the fact we use LSB headers (and not Fedora ones).. I can't and won't make you stop doing this, but let me just say that I really don't like that you do this, and that this is something I would never merge upstream: We really don't want to extend old standards with private systemd extensions, if we consider those old standards obsolete anyway. If people want to use systemd features they should use systemd files. Compatibility we do for the sake of compatibility only, not do extend standards we consider deeply flawed, and that we'd prfer if they went away sooner rather than later. Unfortunately, reality not always mixes well with such principles. You are fortunate to have support for this particular header in your flavor of initscripts and we aren't. And there has some particular times where we need this information and we can't just replace initscripts with a service counterpart (specially when you find issues during maintenance update). I'll be happy when we are able to drop those changes (or move them to generator) but we aren't there yet. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add keyhandler support to cryptsetup
* On Monday, 24 March 2014 23:24, Lennart Poettering lenn...@poettering.net wrote: No grokking what this is about really? What do you need the param for, why isn't the existing agent logic good enough for this? Do you need some identifier to pass across, or what is supposed to be included there? The goal here is to be able to reuse handlers that have been developed for Debian. The original keyscript options comes from them and this implementation uses the key_file field of the crypttab as an argument to the keyscript. This key_file does not have necessary to be a real key_file. For instance, you could have something like that in your crypttab: crypt1 /dev/sda UUID=----,FILE=toto.key luks,keyscript=/usr/bin/mykeyscript crypt2 /dev/sdb UUID=----,FILE=tata.key luks,keyscript=/usr/bin/mykeyscript So here we use the same keyscript with a variable key_file located on different devices. Another usecase might be to have a keyscript that ask for a vocal passphrase, and the compares the vocal signature with a database that might be different from one device to another. Supporting an automatic fallback to asking for a password interactively when a file doesn't exist on disk is something we should anyway do in systemd-cryptsetup, this shouldn#t need any special scrip hookup. (Note however that we nowadays add RequiresMountsFor= for the file specified in cryptsetup so that we'll wait for any USB disk mentioned therein anyway, which means we'd delay the cryptsetup logic untilt he device has shown up.) Well that's exactly what the patch does. The fallback IS in systemd-cryptsetup. But that should probably be enhanced. It would also be good if we could spawn another agent from an agent. For example if our keyfile is encrypted via GPG, we could be able to ask the GPG passphrase from another agent so that our main agent can decrypt the keyfile and then decrypt the device. But anyway, for this specific usecase, I'd really like to see a patch for systemd that makes this standard behaviour. Well, firstly, I'd have to udnerstand the concept. ;-) Also, all patches need to be submitted against systemd git... Thanks -- Benjamin SANS signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] sd-rtnl: add support for tunnel attributes
Added support for tunneling netlink attrributes (ipip, gre, sit).
These works with kernel module ipip, gre and sit . The test cases are
moved to a separate file and manual test as well because they require
respective kernel modules as well.
---
Makefile.am | 11 ++-
src/libsystemd/sd-rtnl/rtnl-message.c | 37 +++-
src/test/test-rtnl-manual.c | 154 ++
3 files changed, 197 insertions(+), 5 deletions(-)
create mode 100644 src/test/test-rtnl-manual.c
diff --git a/Makefile.am b/Makefile.am
index 2cb0f2a..27c7685 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1175,7 +1175,8 @@ manual_tests += \
test-install \
test-watchdog \
test-log \
- test-ipcrm
+ test-ipcrm \
+ test-rtnl-manual
tests += \
test-job-type \
@@ -1398,6 +1399,14 @@ test_ipcrm_LDADD = \
libsystemd-shared.la \
-lrt
+test_rtnl_manual_SOURCES = \
+ src/test/test-rtnl-manual.c
+
+test_rtnl_manual_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-shared.la \
+ -lkmod
+
test_ellipsize_SOURCES = \
src/test/test-ellipsize.c
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 652dc6e..ff09051 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -24,6 +24,9 @@
#include stdbool.h
#include unistd.h
#include linux/veth.h
+#include linux/if.h
+#include linux/ip.h
+#include linux/if_tunnel.h
#include linux/if_bridge.h
#include util.h
@@ -456,6 +459,12 @@ int sd_rtnl_message_append_u8(sd_rtnl_message *m, unsigned
short type, uint8_t d
case IFLA_CARRIER:
case IFLA_OPERSTATE:
case IFLA_LINKMODE:
+case IFLA_IPTUN_TTL:
+case IFLA_IPTUN_TOS:
+case IFLA_IPTUN_PROTO:
+case IFLA_IPTUN_PMTUDISC:
+case IFLA_IPTUN_ENCAP_LIMIT:
+case IFLA_GRE_TTL:
break;
default:
return -ENOTSUP;
@@ -493,12 +502,22 @@ int sd_rtnl_message_append_u16(sd_rtnl_message *m,
unsigned short type, uint16_t
case RTM_DELLINK:
if (m-n_containers == 2
GET_CONTAINER(m, 0)-rta_type == IFLA_LINKINFO
-GET_CONTAINER(m, 1)-rta_type == IFLA_INFO_DATA
-type == IFLA_VLAN_ID)
-break;
-else
+GET_CONTAINER(m, 1)-rta_type == IFLA_INFO_DATA) {
+switch (type) {
+ case IFLA_VLAN_ID:
+ case IFLA_IPTUN_FLAGS:
+ case IFLA_GRE_IFLAGS:
+ case IFLA_GRE_OFLAGS:
+ case IFLA_IPTUN_6RD_PREFIXLEN:
+ case IFLA_IPTUN_6RD_RELAY_PREFIXLEN:
+ break;
+ default:
+return -ENOTSUP;
+}
+} else
return -ENOTSUP;
+break;
default:
return -ENOTSUP;
}
@@ -539,7 +558,12 @@ int sd_rtnl_message_append_u32(sd_rtnl_message *m,
unsigned short type, uint32_t
case IFLA_PROMISCUITY:
case IFLA_NUM_TX_QUEUES:
case IFLA_NUM_RX_QUEUES:
+case IFLA_IPTUN_LOCAL:
+case IFLA_IPTUN_REMOTE:
case IFLA_MACVLAN_MODE:
+case IFLA_IPTUN_FLAGS:
+case IFLA_IPTUN_FLOWINFO:
+case IFLA_GRE_FLOWINFO:
break;
default:
return -ENOTSUP;
@@ -594,6 +618,8 @@ int sd_rtnl_message_append_in_addr(sd_rtnl_message *m,
unsigned short type, cons
case IFA_LOCAL:
case IFA_BROADCAST:
case IFA_ANYCAST:
+case IFLA_GRE_LOCAL:
+case IFLA_GRE_REMOTE:
ifa = NLMSG_DATA(m-hdr);
if (ifa-ifa_family != AF_INET)
@@ -656,6 +682,9 @@ int
Re: [systemd-devel] sudo -u app_user systemctl --user
On 24.03.2014 20:27, Lennart Poettering wrote: On Thu, 20.03.14 12:43, David Schmitt (da...@dasz.at) wrote: The systemd --user stuff is not complete yet, and will likely be complete only when kdbus support is completed too. Note that systemd --user is only for real login users though, and the systemd instance is a singleton that is refcounted by all active sessions of its user. It isn't really something you want to make use for servers hence really. (or at least, it's not designed for that...) Well, it works out quite well for my use-case, except for this interesting nit with not being able to enter the session with sudo. Tangentially this also raises the question whether I'm the only one who wants to have a unprivileged systemd instances for users and if not, what are they doing? Namespaces and booting a full systemd instance in a container? If that is a better supported way of achieving my goal of giving a set of users the power to manage their own services... Regards, David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] Add binary password agent protocol
On Tue, Mar 25, 2014 at 01:58:27AM +0100, Lennart Poettering wrote: On Tue, 04.02.14 00:57, David Härdeman (da...@hardeman.nu) wrote: Sorry for the later review! Add binary string handling functions and extend the password agent protocol to support binary strings (using = as a string prefix instead of +). Hmm, I wished there was a different way to implement this, rather than having to introduce bstrv... But I see no other way, I fear.. :-( (Well, we could always just pass an escaped string around, never the binary data, and then only convert to binary data only as last step. But I figure that would just lying to ourselves...) I figure this has to do then. Could you please rebase to current git? This one will take a bit longer. First I wanted to see that you agree with the direction of the patch. Since you do, I'll spend the time to write up some test cases before I resubmit this patch. -- David Härdeman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: refuse to do kexec, if no kernel is loaded
Am 24.03.2014 20:43, schrieb Lennart Poettering: On Tue, 18.03.14 14:14, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com Doing a kexec with no kernel loaded would currently issue a normal reboot. This might not be wanted, if the goal of kexec is to circumvent the boot loader. Better fail to kexec, than to reboot into a maybe broken setup. Hmm, my assumption was always that we should support uploading a kernel from a service at shutdown kexed. THis patch of yours would break a setup like that? Lennart Ok, makes sense... I modified dracut to do a reboot, if no kexec kernel is loaded. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Requiring hardware device and escaping device names
Hi, I have a keyboard daemon that sometimes fails to come up, I guess because the device is not there. However my current attempt does not work: [hendry@alarmpi ~]$ cat /usr/lib/systemd/system/shkd.service [Unit] Description=Simple HotKey Daemon Requires=dev-input-by\x2did-usb\x2d13ba_0001\x2devent\x2dkbd.device [Service] Type=simple Restart=always ExecStart=/usr/local/bin/shkd /dev/input/by-id/usb-13ba_0001-event-kbd [Install] WantedBy=multi-user.target Is Requires= incorrect? Is my escaping correct? Do I need to actually escape in the first place? Btw I quickly put together a escaping and un-escaping tool here: http://systemd.dabase.com/ I'd really appreciate a review. Many thanks, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] Add more password agent information
On Tue, Mar 25, 2014 at 09:50:10AM +0100, Benjamin SANS wrote: * On Tuesday, 25 March 2014 01:46, David Härdeman da...@hardeman.nu wrote: Bejamin's approach does not seem to solve the binary key part of the puzzle either...(passing binary keys from the keyscript, as opposed to passphrases). Actually it does, but I'm not very proud of the fix... Here is an explanation: - When using a keyscript, the agent creates a temporary file like so: char temp[] = /run/systemd/ask-password/tmp.XX; int fd = mkostemp(temp, O_WRONLY|O_CLOEXEC); - It then forks, redirect the standard output of the child to this temporary file, and execv the keyscript. - Finally, it returns via the socket the path of this temporary file. But all of this is based on the assumption that /run is a tmpfs and that it is safe enough to temporary store the key. Ah, mea culpa. I missed that you proposed changes to systemd's own agent as well. Myopia, since my approach was to use an additional (new) agent which only handles the keyscript= case, I just assumed you did as well :) BTW, it should be noted that since the agent API allows for concurrent agents, it's still possible to use e.g. both a keyscript and keyboard input as a backup with my approach...the systemd agent is smart enough to remove the TTY passphrase prompt once an answer has been provided via the other agent. -- David Härdeman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] Fix keysize handling in cryptsetup (bits vs. bytes)
The command line key-size is in bits but the libcryptsetup API expects bytes.
Note that the modulo 8 check is in the original cryptsetup binary as well, so
it's no new limitation.
(v2: changed the point at which the /= 8 is performed, rebased, removed tabs)
---
src/cryptsetup/cryptsetup.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index a647a94..812b32f 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -88,6 +88,13 @@ static int parse_one_option(const char *option) {
return 0;
}
+if (arg_key_size % 8) {
+log_error(size= not a multiple of 8, ignoring.);
+return 0;
+}
+
+arg_key_size /= 8;
+
} else if (startswith(option, key-slot=)) {
arg_type = CRYPT_LUKS1;
@@ -414,7 +421,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
/* for CRYPT_PLAIN limit reads
* from keyfile to key length, and
* ignore keyfile-size */
-arg_keyfile_size = arg_key_size / 8;
+arg_keyfile_size = arg_key_size;
/* In contrast to what the name
* crypt_setup() might suggest this
@@ -577,7 +584,7 @@ int main(int argc, char *argv[]) {
else
until = 0;
-arg_key_size = (arg_key_size 0 ? arg_key_size : 256);
+arg_key_size = (arg_key_size 0 ? arg_key_size : (256 / 8));
if (key_file) {
struct stat st;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/2] Password agent fixes
The following series contains patch 1 - 2 of the previous patchset that I've posted, hopefully all of Lennart's comments should have been taken into account (patch 3 was already applied in a reworked fashion). I've left out the binary protocol patch until I've written unit tests. --- David Härdeman (2): Add more password agent information Fix keysize handling in cryptsetup (bits vs. bytes) src/ask-password/ask-password.c | 14 +++--- src/cryptsetup/cryptsetup.c | 25 + src/shared/ask-password-api.c |9 +++-- src/shared/ask-password-api.h |6 -- 4 files changed, 43 insertions(+), 11 deletions(-) -- David Härdeman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] Add more password agent information
Add an (optional) Id key in the password agent .ask files. The Id is
supposed to be a simple string in subsystem:target form which
is used to provide more information on what the requested passphrase
is to be used for (which e.g. allows an agent to only react to cryptsetup
requests).
(v2: rebased, fixed indentation, escape name, use strappenda)
---
src/ask-password/ask-password.c | 14 +++---
src/cryptsetup/cryptsetup.c | 14 --
src/shared/ask-password-api.c |9 +++--
src/shared/ask-password-api.h |6 --
4 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index ea0c623..4d5690c 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -43,6 +43,7 @@
#include def.h
static const char *arg_icon = NULL;
+static const char *arg_id = NULL;
static const char *arg_message = NULL;
static bool arg_use_tty = true;
static usec_t arg_timeout = DEFAULT_TIMEOUT_USEC;
@@ -58,7 +59,8 @@ static int help(void) {
--timeout=SEC Timeout in sec\n
--no-ttyAsk question via agent even on TTY\n
--accept-cached Accept cached passwords\n
---multiple List multiple passwords if available\n,
+--multiple List multiple passwords if available\n
+--id=ID Query identifier (e.g.
cryptsetup:/dev/sda5)\n,
program_invocation_short_name);
return 0;
@@ -71,7 +73,8 @@ static int parse_argv(int argc, char *argv[]) {
ARG_TIMEOUT,
ARG_NO_TTY,
ARG_ACCEPT_CACHED,
-ARG_MULTIPLE
+ARG_MULTIPLE,
+ARG_ID
};
static const struct option options[] = {
@@ -81,6 +84,7 @@ static int parse_argv(int argc, char *argv[]) {
{ no-tty,no_argument, NULL, ARG_NO_TTY
},
{ accept-cached, no_argument, NULL, ARG_ACCEPT_CACHED
},
{ multiple, no_argument, NULL, ARG_MULTIPLE
},
+{ id,required_argument, NULL, ARG_ID
},
{}
};
@@ -119,6 +123,10 @@ static int parse_argv(int argc, char *argv[]) {
arg_multiple = true;
break;
+case ARG_ID:
+arg_id = optarg;
+break;
+
case '?':
return -EINVAL;
@@ -162,7 +170,7 @@ int main(int argc, char *argv[]) {
} else {
char **l;
-if ((r = ask_password_agent(arg_message, arg_icon, timeout,
arg_accept_cached, l)) = 0) {
+if ((r = ask_password_agent(arg_message, arg_icon, arg_id,
timeout, arg_accept_cached, l)) = 0) {
char **p;
STRV_FOREACH(p, l) {
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 9b9074c..a647a94 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -257,6 +257,8 @@ static int get_password(const char *name, usec_t until,
bool accept_cached, char
int r;
char **p;
_cleanup_free_ char *text = NULL;
+_cleanup_free_ char *escaped_name = NULL;
+char *id;
assert(name);
assert(passwords);
@@ -264,7 +266,13 @@ static int get_password(const char *name, usec_t until,
bool accept_cached, char
if (asprintf(text, Please enter passphrase for disk %s!, name) 0)
return log_oom();
-r = ask_password_auto(text, drive-harddisk, until, accept_cached,
passwords);
+escaped_name = cescape(name);
+if (!escaped_name)
+return log_oom();
+
+id = strappenda(cryptsetup:, escaped_name);
+
+r = ask_password_auto(text, drive-harddisk, id, until,
accept_cached, passwords);
if (r 0) {
log_error(Failed to query password: %s, strerror(-r));
return r;
@@ -278,7 +286,9 @@ static int get_password(const char *name, usec_t until,
bool accept_cached, char
if (asprintf(text, Please enter passphrase for disk %s!
(verification), name) 0)
return log_oom();
-r = ask_password_auto(text, drive-harddisk, until, false,
passwords2);
+id = strappenda(cryptsetup-verification:, escaped_name);
+
+r = ask_password_auto(text, drive-harddisk, id, until,
false, passwords2);
if (r 0) {
log_error(Failed to query verification password: %s,
strerror(-r));
return r;
diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index eb40995..c3c78b6 100644
--- a/src/shared/ask-password-api.c
+++
Re: [systemd-devel] sudo -u app_user systemctl --user
On 03/25/2014 08:42 AM, David Schmitt wrote: If that is a better supported way of achieving my goal of giving a set of users the power to manage their own services... Can you further explain why you want to do that? What's the use case here for embedded/server/desktop? What are you trying to achieve? What behavior do you want? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sudo -u app_user systemctl --user
On 25.03.2014 12:59, Jóhann B. Guðmundsson wrote: On 03/25/2014 08:42 AM, David Schmitt wrote: If that is a better supported way of achieving my goal of giving a set of users the power to manage their own services... Can you further explain why you want to do that? What's the use case here for embedded/server/desktop? What are you trying to achieve? I've built a small shared hosting setup where I'm managing customer's applications with private nginx and (php|mono|...)-fastcgi instances. This allows the customers to flexibly configure application instances using the power of systemd, while everything is still running under the UID of the customer. Currently all customer services are running under a --user instance, which I've got to run by enabling the proper user@.service and using enable-linger on the user. Finally I wanted to delegate service restart privileges to other users within a customer, but stumbled upon sudo's peculiar behaviour. Currently I'm working around this with a sudo/su combination. The more I think about it, the more I realize I might be happier with some kind of ultra-thin containerization of customers. That would also reduce information leakage between customers (running procs, etc). On the other hand, the current solution with --user is pretty simple all around, so adding a container layer might be too much complexity for the gain. What behavior do you want? The requirement I initially asked about, is this: given the proper sudoers entry allow user alice to run $ sudo -u bob systemctl --user reload nginx.service and have it work. My analysis ended at the point that even when using pam_systemd, sudo does not provide the proper XDG_SESSION* environment variables to the executed command. For a more general analysis of my situation, please see above. Regards, David Regards, David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] service: add support for reboot argument when triggered by StartLimitAction=
When rebooting with systemctl, an optional argument can be passed to the
reboot system call. This makes it possible the specify the argument in a
service file and use it when the service triggers a restart.
This is useful to distinguish between manual reboots and reboots caused by
failing services.
---
man/systemd.service.xml | 13 +
src/core/dbus-service.c | 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/service.c| 16
src/core/service.h| 1 +
5 files changed, 32 insertions(+)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 5b3afb8..a2a1b6b 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -1017,6 +1017,19 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}/programlisting
optionnone/option./para/listitem
/varlistentry
+varlistentry
+termvarnameRebootArgument=/varname/term
+listitemparaConfigure the optional
+argument for the
+
citerefentryrefentrytitlereboot/refentrytitlemanvolnum2/manvolnum/citerefentry
+system call if
+varnameStartLimitAction=/varname
+is a reboot action. This works just
+like the optional argument to
+commandsystemctl reboot/command
+command./para/listitem
+/varlistentry
+
/variablelist
paraCheck
diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
index 0451790..45bfecf 100644
--- a/src/core/dbus-service.c
+++ b/src/core/dbus-service.c
@@ -50,6 +50,7 @@ const sd_bus_vtable bus_service_vtable[] = {
SD_BUS_PROPERTY(StartLimitInterval, t, bus_property_get_usec,
offsetof(Service, start_limit.interval), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(StartLimitBurst, u, bus_property_get_unsigned,
offsetof(Service, start_limit.burst), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(StartLimitAction, s,
property_get_start_limit_action, offsetof(Service, start_limit_action),
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(RebootArgument, s, NULL, offsetof(Service,
reboot_arg), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(PermissionsStartOnly, b, bus_property_get_bool,
offsetof(Service, permissions_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(RootDirectoryStartOnly, b, bus_property_get_bool,
offsetof(Service, root_directory_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(RemainAfterExit, b, bus_property_get_bool,
offsetof(Service, remain_after_exit), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index dbb5d13..cb98c83 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -180,6 +180,7 @@ Service.WatchdogSec, config_parse_sec,
0,
Service.StartLimitInterval, config_parse_sec, 0,
offsetof(Service, start_limit.interval)
Service.StartLimitBurst, config_parse_unsigned, 0,
offsetof(Service, start_limit.burst)
Service.StartLimitAction,config_parse_start_limit_action,0,
offsetof(Service, start_limit_action)
+Service.RebootArgument, config_parse_string,0,
offsetof(Service, reboot_arg)
Service.Type,config_parse_service_type, 0,
offsetof(Service, type)
Service.Restart, config_parse_service_restart, 0,
offsetof(Service, restart)
Service.PermissionsStartOnly,config_parse_bool, 0,
offsetof(Service, permissions_start_only)
diff --git a/src/core/service.c b/src/core/service.c
index ae3695a..4ebce6a 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -24,6 +24,8 @@
#include dirent.h
#include unistd.h
#include sys/reboot.h
+#include linux/reboot.h
+#include sys/syscall.h
#include manager.h
#include unit.h
@@ -300,6 +302,9 @@ static void service_done(Unit *u) {
free(s-status_text);
s-status_text = NULL;
+free(s-reboot_arg);
+s-reboot_arg = NULL;
+
s-exec_runtime = exec_runtime_unref(s-exec_runtime);
exec_command_free_array(s-exec_command, _SERVICE_EXEC_COMMAND_MAX);
s-control_command = NULL;
@@ -2372,6 +2377,10 @@ static int service_start_limit_test(Service *s) {
if (ratelimit_test(s-start_limit))
return
Re: [systemd-devel] [RFC PATCH] service: add Restart option to execute StartLimitAction immediately
Hi, On Mon, Mar 24, 2014 at 08:30:09PM +0100, Lennart Poettering wrote: On Thu, 20.03.14 12:52, Michael Olbrich (m.olbr...@pengutronix.de) wrote: The idea is to reboot immediately when a service crashes or the watchdog triggers. This is useful in embedded scenarios when there is only one important service. There are use-cases where rebooting immediately instead of trying to restart the application first makes sense. The environment of the restarted application is not well defined. The watchdog is for unexpected failures. So making sure that the application behaves correctly can be difficult. When rebooting only takes a few seconds, doing so may be more robust than trying to recover from an undefined state. This is an RFC for now. Mostly because I think the configuration is rather awkward like this. Hooking into Restart/StartLimitAction was the easiest way to handle this in the code. But it doesn't feel natural to configure it like this. Any Ideas on how to express this in the unit file? Sounds useful, but I think it would be better to generalize the action concept and then expose FailureAction= in addition to StartLimitAction=. So basically in service_enter_dead(): if (s-result != SERVICE_SUCCESS) execute_failure_action(...); Right? Hmmm, that would mean, I need to make sure that my application can never stop successfully on its own. That's not possible right now, right? I can redefine failures as success with SuccessExitStatus= but not the other way around. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Documentation error for systemctl kill?
On Tue, 25 Mar 2014, Lennart Poettering wrote: On Thu, 13.03.14 14:54, Alan Stern (st...@rowland.harvard.edu) wrote: In systemd 208 (the version currently distributed in Fedora 20), the man page for the systemctl(1) kill command says: Send a signal to one or more processes of the unit. Use --kill-who= to select which process to kill. Use --kill-mode= to select the kill mode and --signal= to select the signal to send. ... And what about the --kill-mode= option? According to the output from systemctl --help, it doesn't exist. Is it a relic from an earlier version of systemctl? Yes it is. But no longer! Thanks for reporting this! Much appreciated! Thank _you_ for the detailed explanation and the documentation update. Alan Stern ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] sd-rtnl: Introduce container parsing
On Tue, Mar 25, 2014 at 3:16 AM, Susant Sahani sus...@redhat.com wrote: I now pushed an alternative patch. Could you have a look if it makes sense to you? If am not wrong *sd_rtnl_message_enter_container* trying to parse (rtnl_message_parse) every time a attribute is requested which is inside nested attribute. Well, usually one would only enter a container once, and then read all one wants from it, rather than entering/exiting for each attribute, so in practice every container should only be parsed once. It would be better to parse only once and keep the data structures ready for reading so that the parsing does not happen each time a attribute is requested. More like from receiving side from kernel should have some intelligence to know what context it's in. If there is a usecase where the current parser turns out to be inefficient, I'd be happy to take a patch to optimize it by doing all the parsing up front (not sure it is worth it though). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sudo -u app_user systemctl --user
On Mar 25, 2014 2:33 PM, David Schmitt da...@dasz.at wrote: On 25.03.2014 12:59, Jóhann B. Guðmundsson wrote: On 03/25/2014 08:42 AM, David Schmitt wrote: If that is a better supported way of achieving my goal of giving a set of users the power to manage their own services... Can you further explain why you want to do that? What's the use case here for embedded/server/desktop? What are you trying to achieve? I've built a small shared hosting setup where I'm managing customer's applications with private nginx and (php|mono|...)-fastcgi instances. This allows the customers to flexibly configure application instances using the power of systemd, while everything is still running under the UID of the customer. Currently all customer services are running under a --user instance, which I've got to run by enabling the proper user@.service and using enable-linger on the user. Finally I wanted to delegate service restart privileges to other users within a customer, but stumbled upon sudo's peculiar behaviour. Currently I'm working around this with a sudo/su combination. The more I think about it, the more I realize I might be happier with some kind of ultra-thin containerization of customers. That would also reduce information leakage between customers (running procs, etc). On the other hand, the current solution with --user is pretty simple all around, so adding a container layer might be too much complexity for the gain. What behavior do you want? The requirement I initially asked about, is this: given the proper sudoers entry allow user alice to run $ sudo -u bob systemctl --user reload nginx.service and have it work. My analysis ended at the point that even when using pam_systemd, sudo does not provide the proper XDG_SESSION* environment variables to the executed command. The only important variable here is XDG_RUNTIME_DIR, as systemctl looks there for the user instance's private socket. I think in later versions it *is* exported by pam_systemd – that your example has the username and not the UID in this variable shows that it's a quite old systemd version. The other two variables identify the login session – XDG_SESSION_ID is set by pam_systemd to the logind session ID (for scripts and informational purposes mostly), and XDG_SESSION_COOKIE comes from ConsoleKit (which actually depends on the variable). I am not sure why the latter two are set at all in your case – 'su' probably should not create a new login session, it should remain in the previous one. On the other hand, there were a few threads about just how much 'su' and 'sudo' are meant to change...It also depends on whether su/sudo are invoked *from* within an existing session (they should always be). -- 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] [PATCH] core: add startup resource control option
On 03/25/2014 05:01 AM, Lennart Poettering wrote:
On Tue, 25.03.14 01:03, WaLyong Cho (walyong@samsung.com) wrote:
/* Figure out which controllers we need */
-if (c-cpu_accounting || c-cpu_shares != 1024)
+if (c-cpu_accounting ||
+c-startup_cpu_shares != 1024 ||
+(manager_state(m) != MANAGER_STARTING c-cpu_shares !=
1024))
This looks incorrect. Shouldn't it be like this:
...
if (c-cpu_accounting ||
(manager-state(m) == MANAGER_STARTING ? c-startup_cpu_shares :
c-cpu_shares) != 1024)
At previous patch, I also wrote similar with your thought. Assume, some
of units just only specified StartupCPUShares=(or
StartupBlockIOWeight=). In this case, that unit will not be changed to
default weight because global state is already changed to running. So I
put startup_cpu_shares condition alone.
Obviously, if we just only check condition for c-startup_cpu_shares !=
1024 then that cgroup will always return mask with CGROUP_CPUACCT |
CGROUP_CPU.
If should be NOT then we can make contition using boolean set like this:
if (c-cpu_accounting ||
(manager_state(m) == MANAGER_STARTING ? c-startup_cpu_shares :
c-cpu_shares) != 1024 ||
(manager_state(m) != MANAGER_STARTING c-startup_cpu_shares_set
c-startup_cpu_shares != c-cpu_shares)) {
mask |= CGROUP_CPUACCT | CGROUP_CPU;
if (manager_state(m) != MANAGER_STARTING)
c-startup_cpu_shares_set = false;
}
But it looks not so good idea.
Is there any good option?
...
Best Regards, WaLyong Cho
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix permissions on new journal files
On Tue, Mar 25, 2014 at 01:40:18AM +0100, Lennart Poettering wrote: On Fri, 14.03.14 03:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Mar 14, 2014 at 12:07:35AM +, Greg KH wrote: When starting up journald on a new system, set the proper permissions on the system.journal file, not only on the journal directory. diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index 7c6d6b9099b9..1aeb5e40f1ee 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -24,5 +24,7 @@ d /run/systemd/shutdown 0755 root root - m /var/log/journal 2755 root systemd-journal - - m /var/log/journal/%m 2755 root systemd-journal - - +m /var/log/journal/%m/system.journal 2755 root systemd-journal - - m /run/log/journal 2755 root systemd-journal - - m /run/log/journal/%m 2755 root systemd-journal - - +m /run/log/journal/%m/system.journal 2755 root systemd-journal - - This is just a kludge... Why is system.journal to be treated differently? It seems that the proper fix is to set the mode on the directory properly during installation. Precisely, packaging script are expected to properly chown and setfacl the directory on install. From the .spec file in Fedora: # Make sure new journal files will be owned by the systemd-journal group chgrp systemd-journal /var/log/journal/ /var/log/journal/`cat /etc/machine-id 2 /dev/null` /dev/null 21 || : chmod g+s /var/log/journal/ /var/log/journal/`cat /etc/machine-id 2 /dev/null` /dev/null 21 || : # Apply ACL to the journal directory setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/ /dev/null 21 || : Or something similar. Unfortunately we never documented this explicitly anywhere (for example in some INSTALL document), and we probably should. So far people had to figure thisout by looking at the NEWS file closely... Ok, thanks, there's probably a bug in the ebuild I'm using to lay down the journal files on the system, I'll dig into it some more later this week... greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix permissions on new journal files
Am 25.03.2014 01:40, schrieb Lennart Poettering: This is just a kludge... Why is system.journal to be treated differently? It seems that the proper fix is to set the mode on the directory properly during installation. Precisely, packaging script are expected to properly chown and setfacl the directory on install. From the .spec file in Fedora: This completely ignores the problem Dave mentions in his earlier post: Volatile journals are owned by root:root. 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] [PATCH] Fix permissions on new journal files
On Tue, Mar 25, 2014 at 04:54:34PM +0100, Thomas Bächler wrote: Am 25.03.2014 01:40, schrieb Lennart Poettering: This is just a kludge... Why is system.journal to be treated differently? It seems that the proper fix is to set the mode on the directory properly during installation. Precisely, packaging script are expected to properly chown and setfacl the directory on install. From the .spec file in Fedora: This completely ignores the problem Dave mentions in his earlier post: Volatile journals are owned by root:root. I talked to Lennart about this last night on IRC -- we agreed that the solution here is to introduce an 'M' action in the tmpfiles language which is a recursive version of 'm'. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix permissions on new journal files
On Tue, Mar 25, 2014 at 12:01:01PM -0400, Dave Reisner wrote: On Tue, Mar 25, 2014 at 04:54:34PM +0100, Thomas Bächler wrote: Am 25.03.2014 01:40, schrieb Lennart Poettering: This is just a kludge... Why is system.journal to be treated differently? It seems that the proper fix is to set the mode on the directory properly during installation. Precisely, packaging script are expected to properly chown and setfacl the directory on install. From the .spec file in Fedora: This completely ignores the problem Dave mentions in his earlier post: Volatile journals are owned by root:root. I talked to Lennart about this last night on IRC -- we agreed that the solution here is to introduce an 'M' action in the tmpfiles language which is a recursive version of 'm'. Cool, want me to code this up? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix permissions on new journal files
On Tue, Mar 25, 2014 at 09:09:57AM -0700, Greg KH wrote: On Tue, Mar 25, 2014 at 12:01:01PM -0400, Dave Reisner wrote: On Tue, Mar 25, 2014 at 04:54:34PM +0100, Thomas Bächler wrote: Am 25.03.2014 01:40, schrieb Lennart Poettering: This is just a kludge... Why is system.journal to be treated differently? It seems that the proper fix is to set the mode on the directory properly during installation. Precisely, packaging script are expected to properly chown and setfacl the directory on install. From the .spec file in Fedora: This completely ignores the problem Dave mentions in his earlier post: Volatile journals are owned by root:root. I talked to Lennart about this last night on IRC -- we agreed that the solution here is to introduce an 'M' action in the tmpfiles language which is a recursive version of 'm'. Cool, want me to code this up? Go right ahead! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] sd-rtnl: add support for tunnel attributes
On Tue, Mar 25, 2014 at 9:43 AM, Susant Sahani sus...@redhat.com wrote:
Added support for tunneling netlink attrributes (ipip, gre, sit).
These works with kernel module ipip, gre and sit . The test cases are
moved to a separate file and manual test as well because they require
respective kernel modules as well.
Applied. Thanks!
Cheers,
Tom
---
Makefile.am | 11 ++-
src/libsystemd/sd-rtnl/rtnl-message.c | 37 +++-
src/test/test-rtnl-manual.c | 154
++
3 files changed, 197 insertions(+), 5 deletions(-)
create mode 100644 src/test/test-rtnl-manual.c
diff --git a/Makefile.am b/Makefile.am
index 2cb0f2a..27c7685 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1175,7 +1175,8 @@ manual_tests += \
test-install \
test-watchdog \
test-log \
- test-ipcrm
+ test-ipcrm \
+ test-rtnl-manual
tests += \
test-job-type \
@@ -1398,6 +1399,14 @@ test_ipcrm_LDADD = \
libsystemd-shared.la \
-lrt
+test_rtnl_manual_SOURCES = \
+ src/test/test-rtnl-manual.c
+
+test_rtnl_manual_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-shared.la \
+ -lkmod
+
test_ellipsize_SOURCES = \
src/test/test-ellipsize.c
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 652dc6e..ff09051 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -24,6 +24,9 @@
#include stdbool.h
#include unistd.h
#include linux/veth.h
+#include linux/if.h
+#include linux/ip.h
+#include linux/if_tunnel.h
#include linux/if_bridge.h
#include util.h
@@ -456,6 +459,12 @@ int sd_rtnl_message_append_u8(sd_rtnl_message *m,
unsigned short type, uint8_t d
case IFLA_CARRIER:
case IFLA_OPERSTATE:
case IFLA_LINKMODE:
+case IFLA_IPTUN_TTL:
+case IFLA_IPTUN_TOS:
+case IFLA_IPTUN_PROTO:
+case IFLA_IPTUN_PMTUDISC:
+case IFLA_IPTUN_ENCAP_LIMIT:
+case IFLA_GRE_TTL:
break;
default:
return -ENOTSUP;
@@ -493,12 +502,22 @@ int sd_rtnl_message_append_u16(sd_rtnl_message *m,
unsigned short type, uint16_t
case RTM_DELLINK:
if (m-n_containers == 2
GET_CONTAINER(m, 0)-rta_type == IFLA_LINKINFO
-GET_CONTAINER(m, 1)-rta_type == IFLA_INFO_DATA
-type == IFLA_VLAN_ID)
-break;
-else
+GET_CONTAINER(m, 1)-rta_type == IFLA_INFO_DATA)
{
+switch (type) {
+ case IFLA_VLAN_ID:
+ case IFLA_IPTUN_FLAGS:
+ case IFLA_GRE_IFLAGS:
+ case IFLA_GRE_OFLAGS:
+ case IFLA_IPTUN_6RD_PREFIXLEN:
+ case IFLA_IPTUN_6RD_RELAY_PREFIXLEN:
+ break;
+ default:
+return -ENOTSUP;
+}
+} else
return -ENOTSUP;
+break;
default:
return -ENOTSUP;
}
@@ -539,7 +558,12 @@ int sd_rtnl_message_append_u32(sd_rtnl_message *m,
unsigned short type, uint32_t
case IFLA_PROMISCUITY:
case IFLA_NUM_TX_QUEUES:
case IFLA_NUM_RX_QUEUES:
+case IFLA_IPTUN_LOCAL:
+case IFLA_IPTUN_REMOTE:
case IFLA_MACVLAN_MODE:
+case IFLA_IPTUN_FLAGS:
+case IFLA_IPTUN_FLOWINFO:
+case IFLA_GRE_FLOWINFO:
break;
default:
return -ENOTSUP;
@@ -594,6 +618,8 @@ int sd_rtnl_message_append_in_addr(sd_rtnl_message *m,
unsigned short type, cons
case IFA_LOCAL:
case IFA_BROADCAST:
case IFA_ANYCAST:
+case IFLA_GRE_LOCAL:
+
[systemd-devel] System locale not set in tty
Hello there, I'm using stock systemd-211 release and I have noticed today that locale isn't set anymore in tty. My X session, which runs on tty1 has the locale correctly set up, but when I swich to tty2 and log in, the locale is set to POSIX, LANG isn't set at all. Is this expected behaviour or what? Do I still need shell scripts for parsing /etc/locale.conf and setting it like that in /etc/profile* scripts? $ locale -a bs_BA bs_BA.iso88592 bs_BA.utf8 C croatian en_US en_US.iso88591 en_US.utf8 hr_HR hr_HR.iso88592 hr_HR.utf8 hrvatski POSIX $ locale (from X11 terminal emulator) LANG=en_US.utf8 LC_CTYPE=en_US.utf8 LC_NUMERIC=en_US.utf8 LC_TIME=en_US.utf8 LC_COLLATE=en_US.utf8 LC_MONETARY=en_US.utf8 LC_MESSAGES=en_US.utf8 LC_PAPER=en_US.utf8 LC_NAME=en_US.utf8 LC_ADDRESS=en_US.utf8 LC_TELEPHONE=en_US.utf8 LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=en_US.utf8 LC_ALL= $ locale (from tty prompt) LANG= LC_CTYPE=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=POSIX LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= $ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: croat X11 Layout: hr X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp Cheers. -- Note: My last name is not Krejzi. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sudo -u app_user systemctl --user
On 25.03.2014 15:10, Mantas Mikulėnas wrote: What behavior do you want? The requirement I initially asked about, is this: given the proper sudoers entry allow user alice to run $ sudo -u bob systemctl --user reload nginx.service and have it work. My analysis ended at the point that even when using pam_systemd, sudo does not provide the proper XDG_SESSION* environment variables to the executed command. The only important variable here is XDG_RUNTIME_DIR, as systemctl looks there for the user instance's private socket. I think in later versions it *is* exported by pam_systemd – that your example has the username and not the UID in this variable shows that it's a quite old systemd version. The other two variables identify the login session – XDG_SESSION_ID is set by pam_systemd to the logind session ID (for scripts and informational purposes mostly), and XDG_SESSION_COOKIE comes from ConsoleKit (which actually depends on the variable). I am not sure why the latter two are set at all in your case – 'su' probably should not create a new login session, it should remain in the previous one. On the other hand, there were a few threads about just how much 'su' and 'sudo' are meant to change...It also depends on whether su/sudo are invoked *from* within an existing session (they should always be). Thank you for your clarification. Iff the XDG_RUNTIME_DIR is the only required thing, I can probably force that to the correct value via an sudo env_file. I'll test. Regards, David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-25 0:14 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 23:59, Michael Biebl (mbi...@gmail.com) wrote: I think the priority information is irrelevant in this particular issue. It's the discrepancy regarding runlevel information. So I doubt your patch makes a difference, but I'll double check. I am tempted to also drop the runlevel parsing from the LSB and chkconfig headers. After all they are mostly irrelevant since what is linked in /etc/rc?.d/ is what matters, and not the stuff in the init script themselves. Let me now if this would make things work then for you. If so, I'll drop this too then. I think this might work, without having actually tested it. That said, if you drop runlevel and priority parsing from the chkconfig header, is there anything useful left in # chkconfig: ? Regarding # pidfile:, it's basically the same problem, ie. the mere existence (on Debian) doesn't necessarily mean it is correct. The result could be, that we mark a service as Type=forking pointing it at the wrong pid file, leading to the service not being tracked properly. I'd have to check all packages affected by this [0], to see if the information in there is actually correct. [0] http://codesearch.debian.net/search?q=%23+pidfile%3A -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default
2014-03-20 20:29 GMT+01:00 Lennart Poettering lenn...@poettering.net: TO figure out what we can do in Fedora I have now started a discussion on fedora-devel, about getting rid of tcpwrap system-wide. Let's see where this goes. Would be interested in feedback about this from other distros too. I don't really have an opinion on this, just wanted to share that on Debian apparently there is no unit file using TCPWrapName [0] so it's probably not going to be a big deal for us. That said, you mentioned that packages still can utilise tcpd. How exactly would that work for a socket-activated service? Michael [0] http://codesearch.debian.net/search?q=TCPWrapName ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default
On Mon, Mar 24, 2014 at 12:16 PM, Lennart Poettering lenn...@poettering.net wrote: So on Fedora tcpwrap is unlikely to go away soon. Not necessarily. We just decided this morning in the server working group that we would only include it if base OS insists: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-25/fedora-meeting-1.2014-03-25-15.00.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 212
Many bugfixes, and a number of new features:
http://www.freedesktop.org/software/systemd/systemd-212.tar.xz
CHANGES WITH 212:
* When restoring the screen brightness at boot, stay away from
the darkest setting or from the lowest 5% of the available
range, depending on which is the larger value of both. This
should effectively protect the user from rebooting into a
black screen, should the brightness have been set to minimum
by accident.
* sd-login gained a new sd_machine_get_class() call to
determine the class (vm or container) of a machine
registered with machined.
* sd-login gained new calls
sd_peer_get_{session,owner_uid,unit,user_unit,slice,machine_name}(),
to query the identity of the peer of a local AF_UNIX
connection. They operate similar to their sd_pid_get_xyz()
counterparts.
* PID 1 will now maintain a system-wide system state engine
with the states starting, running, degraded,
maintenance, stopping. These states are bound to system
startup, normal runtime, runtime with at least one failed
service, rescue/emergency mode and system shutdown. This
state is shown in the systemctl status output when no unit
name is passed. It is useful to determine system state, in
particularly when doing so for many systems or containers at
once.
* A new command list-machines has been added to systemctl
that lists all local OS containers and shows their system
state (see above), if systemd runs inside of them.
* systemctl gained a new -r switch to recursively enumerate
units on all local containers, when used with the
list-unit command (which is the default one that is
executed when no parameters are specified).
* The GPT automatic partition discovery logic will now honour
two GPT partition flags: one may be set on a partition to
cause it to be mounted read-only, and the other may be set
on a partition to ignore it during automatic discovery.
* Two new GPT type UUIDs have been added for automatic root
partition discovery, for 32bit and 64bit ARM. This is not
particularly useful for discovering the root directory on
these architectures during bare-metal boots (since UEFI is
not common there), but still very useful to allow booting of
ARM disk images in nspawn with the -i option.
* MAC addresses of interfaces created with nspawn's
--network-interface= switch will now be generated from the
machine name, and thus be stable between multiple invocations
of the container.
* logind will now automatically remove all IPC objects owned
by a user if she or he fully logs out. This makes sure that
users who are logged out cannot continue to consume IPC
resources. This covers SysV memory, semaphores and message
queues as well as POSIX shared memory and message
queues. Traditionally SysV and POSIX IPC had no life-cycle
limits, with this functionality this is corrected. This may
be turned off using the RemoveIPC= switch of logind.conf.
* The systemd-machine-id-setup and tmpfiles tools gained a
--root= switch to operate on a specific root directory,
instead of /.
* journald can now forward logged messages to the TTYs of all
logged in users (wall). This is the default for all
emergency messages now.
* A new tool systemd-journal-remote has been added to stream
journal log messages across the network.
* /sys/fs/cgroup/ is now mounted read-only after all cgroup
controller trees are mounted into it. Note that the
directories mounted beneath it are not read-only. This is a
security measure and is particularly useful because glibc
actually includes a search logic to pick any tmpfs it can
find to implement shm_open() if /dev/shm is not available
(which it might very well be in namespaced setups).
* machinectl gained a new poweroff command to cleanly power
down a local OS container.
* The PrivateDevices= unit file setting will now also drop the
CAP_MKNOD capability from the capability bound set, and
imply DevicePolicy=closed.
* PrivateDevices=, PrivateNetwork= and PrivateTmp= is now used
comprehensively on all long-running systemd services where
this is appropriate.
* systemd-udevd will now run in a disassociated mount
namespace. To mount directories from udev rules make sure to
pull in mount units via SYSTEMD_WANTS properties.
* The kdbus support gained support for uploading policy
Re: [systemd-devel] Topics for the Linux Storage, Filesystem MM Summit
Other than for zswap discussions, I spent the whole time on the storage and file system side. I've filled in the topics that came up (or I could topically ask about), and I have some good contacts now if answering any others proves essential. Outside the file system/MM space, at least one Ganesha developer is working on a comprehensive credential-setting/caching syscall that might be useful for systemd's privilege dropping for starting services. It would set credentials and return an fd that is usable to rapidly set the same credentials again. He's planning on stuffing the file descriptors into an LRU cache to both reduce syscalls and accelerate the application of credentials in the kernel. His work is focused on FS permissions, but it would make sense for it to be available for general ones, too. It may be useful to see if we can use Trinity for kdbus and systemd testing. On Thu, Feb 27, 2014 at 3:09 PM, Lennart Poettering lenn...@poettering.net wrote: - quota for tmpfs - saner autofs elapse logic (no blocking ioctls...) - uuids for btrfs subvols - a umount (or maybe last-change) timestamp in the btrfs superblock, which we can use to initialize the system clock from if a machine lacks RTC or has a dead battery. Even better: a unified ioctl() to query this from all file systems the same way. - fanotify: accessible to unprivileged users I asked about the state of this given Ganesha's userspace operation. I don't think there are any changes. Many services using fanotify seem to require root privileges for other reasons, too. - fanotify: events for renames - fanotify: pass info about open() flags to monitoring processes - fanotify: when getting getting a notification for close, actually get information whether the file was changed or not - an ioctl-based way to change FAT file system labels - cheaper xattrs. currently querying xattrs on most file systems is prohibitively slow, since it results in seeks and whatnot. Which has the result that pretty nobody uses them. One way to make things better would be to maybe expose in some fstat2() call a flag whether there even are xattrs, so that apps could check for that flag before actually trying to read them This is being suggested as a readdir+ enhancement for Ganesha's sake. It would only be a flag that xattrs exist. - An API to query the birthtime of files. ext234 actually stores that and keeps it up-to-date, but there's no API to get to this data - An fsetxattrat() call, so that race-free selinux relabelling can be done - a way to mark an entire tree of mounts read-only with one call. i.e. a working combination of MS_REC|MS_RDONLY - Allow creating read-only bind mounts in a single mount() invocation, instead of requiring two. Similar, a way to set the propagation settings for a mount when one creates it, rather than requiring two mount() invocations for that. - Swappiness control for individual pages via madvise() - volatile ranges There was a session on this, but I went to Direct I/O instead. - A better SIGBUS/SIGSEGV API (for accessing invalidated memory maps), that actually works for libraries. i.e. a sane way how libraries can register handlers for specific memory regions they maage. Currently there can only be one handler for the entire process which makes this totally unavailable for libraries, since they'd always step on each others toes. Probably hard one to get into the brains of kernel guys, since for them that is a userspace problem. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 212
Hi,
systemd-212 breaks if we run autoreconf before configuring and building
with:
autoreconf: running:
/home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake
--add-missing --copy --force-missing
Makefile.am:36: warning: user target '.PRECIOUS' defined here ...
/home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/share/automake-1.14/am/configure.am:
... overrides Automake target '.PRECIOUS' defined here
docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL
docs/gudev/Makefile.am:98: 'docs/gtk-doc.make' included from here
docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL
docs/libudev/Makefile.am:92: 'docs/gtk-doc.make' included from here
autoreconf:
/home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake
failed with exit status: 1
even if there is no change in docs/gtk-doc.make between 211 and 212 the
files differs in the tarball. using this patch:
https://github.com/OpenELEC/OpenELEC.tv/blob/ae1cb224141c8e7b179619285333fc0dc741b0ac/packages/sysutils/systemd/patches/systemd-212-GTK_DOC.patch
fixes the problem here. (note, we dont build with gtk support and dont
have any gtk devel packages installed)
greetings
Stephan
Am 26.03.2014 00:28, schrieb Kay Sievers:
Many bugfixes, and a number of new features:
http://www.freedesktop.org/software/systemd/systemd-212.tar.xz
CHANGES WITH 212:
* When restoring the screen brightness at boot, stay away from
the darkest setting or from the lowest 5% of the available
range, depending on which is the larger value of both. This
should effectively protect the user from rebooting into a
black screen, should the brightness have been set to minimum
by accident.
* sd-login gained a new sd_machine_get_class() call to
determine the class (vm or container) of a machine
registered with machined.
* sd-login gained new calls
sd_peer_get_{session,owner_uid,unit,user_unit,slice,machine_name}(),
to query the identity of the peer of a local AF_UNIX
connection. They operate similar to their sd_pid_get_xyz()
counterparts.
* PID 1 will now maintain a system-wide system state engine
with the states starting, running, degraded,
maintenance, stopping. These states are bound to system
startup, normal runtime, runtime with at least one failed
service, rescue/emergency mode and system shutdown. This
state is shown in the systemctl status output when no unit
name is passed. It is useful to determine system state, in
particularly when doing so for many systems or containers at
once.
* A new command list-machines has been added to systemctl
that lists all local OS containers and shows their system
state (see above), if systemd runs inside of them.
* systemctl gained a new -r switch to recursively enumerate
units on all local containers, when used with the
list-unit command (which is the default one that is
executed when no parameters are specified).
* The GPT automatic partition discovery logic will now honour
two GPT partition flags: one may be set on a partition to
cause it to be mounted read-only, and the other may be set
on a partition to ignore it during automatic discovery.
* Two new GPT type UUIDs have been added for automatic root
partition discovery, for 32bit and 64bit ARM. This is not
particularly useful for discovering the root directory on
these architectures during bare-metal boots (since UEFI is
not common there), but still very useful to allow booting of
ARM disk images in nspawn with the -i option.
* MAC addresses of interfaces created with nspawn's
--network-interface= switch will now be generated from the
machine name, and thus be stable between multiple invocations
of the container.
* logind will now automatically remove all IPC objects owned
by a user if she or he fully logs out. This makes sure that
users who are logged out cannot continue to consume IPC
resources. This covers SysV memory, semaphores and message
queues as well as POSIX shared memory and message
queues. Traditionally SysV and POSIX IPC had no life-cycle
limits, with this functionality this is corrected. This may
be turned off using the RemoveIPC= switch of logind.conf.
* The systemd-machine-id-setup and tmpfiles tools gained a
--root= switch to operate on a specific root directory,
instead of /.
* journald can now forward logged
Re: [systemd-devel] [ANNOUNCE] systemd 212
On Wed, Mar 26, 2014 at 1:45 AM, Stephan Raue mailingli...@openelec.tv wrote: systemd-212 breaks if we run autoreconf before configuring and building with: autoreconf: running: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake --add-missing --copy --force-missing Makefile.am:36: warning: user target '.PRECIOUS' defined here ... /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/share/automake-1.14/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/gudev/Makefile.am:98: 'docs/gtk-doc.make' included from here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/libudev/Makefile.am:92: 'docs/gtk-doc.make' included from here autoreconf: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake failed with exit status: 1 Have you tried passing --disable-gtk-doc to configure? Check ./configure --help. even if there is no change in docs/gtk-doc.make between 211 and 212 the files differs in the tarball. using this patch: https://github.com/OpenELEC/OpenELEC.tv/blob/ae1cb224141c8e7b179619285333fc0dc741b0ac/packages/sysutils/systemd/patches/systemd-212-GTK_DOC.patch This file in not in git, and cannot be patched upstream, it is added by gtk-doc itself. fixes the problem here. (note, we dont build with gtk support and dont have any gtk devel packages installed) It's just a common html doc generator, used for libudev's and gudev's docs, there is no gtk code in systemd. http://www.freedesktop.org/software/systemd/libudev/index.html Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 212
On Wed, Mar 26, 2014 at 2:37 AM, Stephan Raue mailingli...@openelec.tv wrote: Am 26.03.2014 02:16, schrieb Kay Sievers: On Wed, Mar 26, 2014 at 1:45 AM, Stephan Raue mailingli...@openelec.tv wrote: systemd-212 breaks if we run autoreconf before configuring and building with: autoreconf: running: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake --add-missing --copy --force-missing Makefile.am:36: warning: user target '.PRECIOUS' defined here ... /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/share/automake-1.14/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/gudev/Makefile.am:98: 'docs/gtk-doc.make' included from here docs/gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL docs/libudev/Makefile.am:92: 'docs/gtk-doc.make' included from here autoreconf: /home/stephan/projects/openelec-master/build.OpenELEC-Generic.x86_64-devel/toolchain/bin/automake failed with exit status: 1 Have you tried passing --disable-gtk-doc to configure? Check ./configure --help. yes we are building with --disable-gtk-doc see: https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/sysutils/systemd/package.mk#L41 but the problem is not at configure time, we do a autoreconf before configuring for every package even if there is no change in docs/gtk-doc.make between 211 and 212 the files differs in the tarball. using this patch: https://github.com/OpenELEC/OpenELEC.tv/blob/ae1cb224141c8e7b179619285333fc0dc741b0ac/packages/sysutils/systemd/patches/systemd-212-GTK_DOC.patch This file in not in git, and cannot be patched upstream, it is added by gtk-doc itself. yes but its part of the tarball, and it seems to be wrong (HAVE_GTK_DOC vs. ENABLE_GTK_DOC) - at least if we compare the file from 211 with the one from 212. It might be a change in upstream gtk-doc, I don't know, I built the tarball with: gtk-doc-1.20-1.fc21.noarch installed, maybe something has change there, we need to find out ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
On 25 March 2014 18:01, Kai Hendry hen...@webconverger.com wrote: Requires=dev-input-by\x2did-usb\x2d13ba_0001\x2devent\x2dkbd.device On #systemd IRC I was recommended After=, and I think it's working as it should! After=dev-input-by\x2did-usb\x2d13ba_0001\x2devent\x2dkbd.device Is Requires= incorrect? Is my escaping correct? Do I need to actually escape in the first place? Btw I quickly put together a escaping and un-escaping tool here: http://systemd.dabase.com/ I'd really appreciate a review. I still don't quite understand why systemd can't take /dev/input/by-id/usb-13ba_0001-event-kbd and realise it's a device. I.e. the need for it to be escaped. Kind regards, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [patch] Add -lresolv to libsystemd_intenal_la_LIBADD to prevent underlinking issues
On 26/03/14 03:38, Kay Sievers wrote: On Mon, Mar 17, 2014 at 1:43 AM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 16.03.14 19:49, Samuli Suominen (ssuomi...@gentoo.org) wrote: On 16/03/14 15:52, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Mar 16, 2014 at 10:10:15AM +0200, Samuli Suominen wrote: Since -Wl,-fuse-ld=gold addition, this happens on IA64 arch where binutils's ld gold doesn't support --gc-sections yet: Maybe you should just use bfd linker then? Gold was only necessary for the ifunc stuff, which is gone anyway. This might to be a better solution, since otherwise everything gets an extra lib. -lresolv is used elsewhere in Makefile.am too, like in libsystemd_la_LIBADD and test_resolve_LDADD src/libsystemd/sd-resolve/sd-resolve.c: ret = res_search at line 432 src/libsystemd/sd-resolve/sd-resolve.c: ret = res_query at line 430 then sd-resolve.c is in libsystemd_internal_la_SOURCES, so adding -lresolv to libsystemd_internal_la_LIBADD is not a workaround, but the correct thing to do We probably should much rather create a separate internal convenience lib for sd-resolve so that the -lresolv dep isn't pulled into everything that uses any API of sd-id128, sd-login, sd-bus, ... A workaround should be in the current release. Kay I was worried about this one. Thanks! It's really appericiated! - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
