Re: [systemd-devel] nilfs-cleanerd startup on boot
I had mis-typed the address for the nilfs mail group -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Saturday, February 28, 2015 12:34 PM To: Dennis Murata (WT01 - ENU) Cc: systemd-devel@lists.freedesktop.org; linus-ni...@vger.kernel.org Subject: Re: [systemd-devel] nilfs-cleanerd startup on boot On Fri, 27.02.15 18:31, dennis.mur...@wipro.com (dennis.mur...@wipro.com) wrote: I have a fedora 21 system that where I mount an nilfs2 file system. I use a simple /etc/modules-load.d/nilfs.conf file to load the kernel module and have an entry in the fstab. Creating the modules-load.d snippet should not be necessary, as the kernel should autoload the kernel module for it when it is first required. I did not find this to be the case for fedora 21. Without creating the file to load the module, any attempt I made to mount the file system would get a unknown filetype error. Does this point at adding this module to the initrd file? The file system mounts on boot as it should, but the nilfs-cleanerd program does not startup. If I umount /nilfs then mount /nilfs the nilfs-cleanerd program starts as it should to cleanup the checkpoints. How is that daemon supposed to be started? Is it forked off /bin/mount? Does systemd use a different mount program at boot? It uses /bin/mount for mounting normal file systems. Is there something else that should be included other than the nilfs.conf file? I have just started using a system with systemd as the init so please forgive my ignorance. I have no idea about nilfs really, and we had no reports about any problems with it before. I wanted to look at the performance of nilfs and f2fs. This is my first try at using these file systems Lennart -- Lennart Poettering, Red Hat The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] automatic name resolution of nspawn-machines
Hi,
I'm running systemd-219 on arch linux. The setup is as follows:
- Host (laptop in changing networks) with multiple NICs
- unbound as caching DNS proxy on the host listening on any interface
- NetworkManager for wireless control
- several nspawn-machines using the default systemd-nspawn.service which
configure their net by itself (/28) via systemd-networkd.
In the nspawn-container I added a perl-one-liner as service to set the
default gateway as DNS-server, where unbound is listening (which would
be a nice default feature for networkd, too):
--- /etc/systemd/system/set-gateway-as-dns.service (line broken) ---
[Unit]
Description=Set the default gateway as DNS server
Requires=network-online.target
After=network-online.target
[Service]
Type=oneshot
ExecStart=-/usr/bin/mkdir -p /run/systemd/resolved.conf.d
ExecStart=/usr/bin/perl -e 'open(my $fh, ,
/run/systemd/resolved.conf.d/99-gateway.conf);
print { $fh } [Resolve]\nDNS= . join(, qx(/usr/bin/networkctl
--no-pager --no-legend status host0) =~ /Gateway:
(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/) . \n;
close($fh);'
ExecStart=/usr/bin/systemctl restart systemd-resolved
[Install]
WantedBy=multi-user.target
--- End Of File ---
My goal now: I want that the host can talk to the machines and vice
versa via simple hostnames, so if my nspawn-machine is called web and
the machines hostname is web, too, than http://web/ should talk to the
webserver in this machine. web.local via mdns would be fine, too.
Any advice?
Regards
Silvio Knizek
--
Xfce4.12 is out! Wait until your distributor packaged it for you!
Questions regarding xfce? Meet me at irc://irc.freenode.net/xfce
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/2] some systemd unit changes
Hello NFS developers, reposting the two patches inline as requested by Steve. I'm currently systemd-ifying our nfs-utils Ubuntu package. For testing I put the NFS server and client (i. e. localhost:/foo/bar mounts) on the same machine. With that I get long hangs during shutdown on stopping the NFS .mount units, as when that happens the NFS server is already shut down. This is certainly a corner case as you'd usually not NFS-mount a share from localhost; but fixing it is relatively simple with the first patch, which makes sure that if NFS server and client are installed, the server starts before the client, and the client stops before the server. For a client without installed server this is harmless as Before= does not imply a dependency. Likewise, for an NFS server which does not mount shares by itself, it's also a no-op as remote-fs.target is empty. This would only slightly reorder the boot sequence for machines which both are an NFS server and have some remote NFS mounts, but I don't see an issue with that. The second patch make NFS start earlier in the boot (i. e. before basic.target), so that you can do things like put /var/ on NFS, or have rcS SysV init scripts which depend on $remote_fs work. I tested this on both a server and a client. This is certainly a bit more intrusive, but could be worthwhile; what do you think? Thanks for considering, Martin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] systemd: Order NFS server before client
This makes mounting NFS shares from localhost work reliably, as you need to start the server before attempting (client) mounts, and conversely on shutdown need to unmount all shares before stopping the server to avoid hangs. --- systemd/nfs-server.service | 3 +++ 1 file changed, 3 insertions(+) diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service index 8010aad..b35e193 100644 --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -13,6 +13,9 @@ Before= rpc-statd-notify.service Wants=auth-rpcgss-module.service After=rpc-gssd.service gssproxy.service rpc-svcgssd.service +# start/stop server before/after client +Before=remote-fs-pre.target + Wants=nfs-config.service After=nfs-config.service -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
On 03/03/15 01:28, Jay Faulkner wrote:
Hey,
Lennart reviewed this in IRC and suggested I refactor the change in this
manner. Now, we have an array of capability:sys call pairs, and iterate
through that and then only add the seccomp filter if the capability
doesn’t exist.
The new patch is attached, and available
here: https://github.com/jayofdoom/systemd/pull/5.patch.
+typedef struct CapSeccompPair {
+uint64_t capability;
+int scmp_syscall_num;
+} CapSeccompPair;
...
+static const CapSeccompPair blacklist[] = {
+{ SCMP_SYS(iopl), CAP_SYS_RAWIO },
The fields are swapped.
-Topi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] automatic name resolution of nspawn-machines
On Tue, 03.03.15 14:24, killermoehre (killermoe...@gmx.net) wrote: Hi, I'm running systemd-219 on arch linux. The setup is as follows: - Host (laptop in changing networks) with multiple NICs - unbound as caching DNS proxy on the host listening on any interface - NetworkManager for wireless control - several nspawn-machines using the default systemd-nspawn.service which configure their net by itself (/28) via systemd-networkd. In the nspawn-container I added a perl-one-liner as service to set the default gateway as DNS-server, where unbound is listening (which would be a nice default feature for networkd, too): resolved gets DHCP DNS server info from networkd anyway, and uses it. No need to rewrite anything. My goal now: I want that the host can talk to the machines and vice versa via simple hostnames, so if my nspawn-machine is called web and the machines hostname is web, too, than http://web/ should talk to the webserver in this machine. web.local via mdns would be fine, too. If nss-mymachines is part of your NSS setup, then all locally running containers are resolvable automatically from the host. See the nss-mymachines(8) man page for details how to configure that. To make sure the containers can resolve the host, make sure to enable resolved on both the host and in each container, and that resolve is in the NSS configuration line of each. Their hostnames should then be resolvable automatically, due to the wonders of LLMNR. No further setup required. This will only give you host name resolution between host and containers and vice versa. To get host name resolution to work between multiple containers simply place them on the same bridge, so that they become a single broadcast domain, so that LLMNR then does the right thing automatically. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fail verbosely if acls can't be read
On Tue, Mar 03, 2015 at 12:35:08AM +0100, Hans-Peter Deifel wrote:
If the acls of a file couldn't be retrieved (probably due to missing acl
support in the filesytem), systemd-tmpfiles just silently failed.
Now it logs an error, just as it already does if the acls cannot be set.
Hi,
I solved this in a slightly different way. We do want to warn when getting
the acls fails, but when it is unsupported by the filesystem, log_debug is
enough. People are free to compile systemd with ACL support, and then use
it on a filesystem mounted without. If this confuses people, we could add
a once-per-mount-point warning about ACL not being supported on that fs.
Zbyszek
---
src/tmpfiles/tmpfiles.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 2642934..de8aa76 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -703,7 +703,9 @@ static int path_set_acl(const char *path, acl_type_t
type, acl_t acl, bool modif
if (modify) {
r = acls_for_file(path, type, acl, dup);
if (r 0)
-return r;
+return log_error_errno(r, Getting %s ACL on %s
failed: %m,
+ type == ACL_TYPE_ACCESS ?
access : default,
+ path);
r = calc_acl_mask_if_needed(dup);
if (r 0)
--
2.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] refactored Re: [PATCH] nspawn: Map all seccomp filters to matching capabilities
On Mar 3, 2015, at 8:55 AM, Topi Miettinen
toiwo...@gmail.commailto:toiwo...@gmail.com wrote:
On 03/03/15 01:28, Jay Faulkner wrote:
Hey,
Lennart reviewed this in IRC and suggested I refactor the change in this
manner. Now, we have an array of capability:sys call pairs, and iterate
through that and then only add the seccomp filter if the capability
doesn’t exist.
The new patch is attached, and available
here: https://github.com/jayofdoom/systemd/pull/5.patch.
+typedef struct CapSeccompPair {
+uint64_t capability;
+int scmp_syscall_num;
+} CapSeccompPair;
...
+static const CapSeccompPair blacklist[] = {
+{ SCMP_SYS(iopl), CAP_SYS_RAWIO },
The fields are swapped.
-Topi
Thanks for the review! I’ve corrected the issue, and have the new patch
attached and available here: https://github.com/jayofdoom/systemd/pull/5.patch.
-Jay Faulkner
nspawn-capabilty-seccomp.patch
Description: nspawn-capabilty-seccomp.patch
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: Make DHCP client ID creation configurable
---
man/systemd.network.xml | 8
src/network/networkd-dhcp4.c | 16
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 9 +
src/network/networkd.h | 11 +++
5 files changed, 45 insertions(+)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 60252e5..3522551 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -564,6 +564,14 @@
/listitem
/varlistentry
varlistentry
+ termvarnameClientIdentifier=/varname/term
+ listitem
+paraDHCP client identifier to use. Either literalmac/literal
+to use the MAC address of the link or literalduid/literal
+(the default) to use a RFC4361-complient Client ID./para
+ /listitem
+/varlistentry
+varlistentry
termvarnameVendorClassIdentifier=/varname/term
listitem
paraThe vendor class identifier used to identify vendor
diff --git a/src/network/networkd-dhcp4.c b/src/network/networkd-dhcp4.c
index c3d0e3d..3832190 100644
--- a/src/network/networkd-dhcp4.c
+++ b/src/network/networkd-dhcp4.c
@@ -661,5 +661,21 @@ int dhcp4_configure(Link *link) {
return r;
}
+switch (link-network-dhcp_client_identifier) {
+case DHCP_CLIENT_ID_DUID:
+/* Library defaults to this. */
+break;
+case DHCP_CLIENT_ID_MAC:
+r = sd_dhcp_client_set_client_id(link-dhcp_client,
+ ARPHRD_ETHER,
+ (const uint8_t *) link-mac,
+ sizeof (link-mac));
+if (r 0)
+return r;
+break;
+default:
+assert_not_reached(Unknown client identifier type.);
+}
+
return 0;
}
diff --git a/src/network/networkd-network-gperf.gperf
b/src/network/networkd-network-gperf.gperf
index b0c23a7..93df83a 100644
--- a/src/network/networkd-network-gperf.gperf
+++ b/src/network/networkd-network-gperf.gperf
@@ -58,6 +58,7 @@ Route.Destination, config_parse_destination,
0,
Route.Source,config_parse_destination, 0,
0
Route.Metric,config_parse_route_priority,0,
0
Route.Scope, config_parse_route_scope, 0,
0
+DHCP.ClientIdentifier, config_parse_dhcp_client_identifier,0,
offsetof(Network, dhcp_client_identifier)
DHCP.UseDNS, config_parse_bool, 0,
offsetof(Network, dhcp_dns)
DHCP.UseMTU, config_parse_bool, 0,
offsetof(Network, dhcp_mtu)
DHCP.UseHostname,config_parse_bool, 0,
offsetof(Network, dhcp_hostname)
diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
index 0ba0c75..f7f6eaf 100644
--- a/src/network/networkd-network.c
+++ b/src/network/networkd-network.c
@@ -103,6 +103,7 @@ static int network_load_one(Manager *manager, const char
*filename) {
network-dhcp_routes = true;
network-dhcp_sendhost = true;
network-dhcp_route_metric = DHCP_ROUTE_METRIC;
+network-dhcp_client_identifier = DHCP_CLIENT_ID_DUID;
network-llmnr = LLMNR_SUPPORT_YES;
@@ -600,6 +601,14 @@ int config_parse_dhcp(
return 0;
}
+static const char* const dhcp_client_identifier_table[_DHCP_CLIENT_ID_MAX] = {
+[DHCP_CLIENT_ID_MAC] = mac,
+[DHCP_CLIENT_ID_DUID] = duid
+};
+
+DEFINE_PRIVATE_STRING_TABLE_LOOKUP_FROM_STRING(dhcp_client_identifier,
DCHPClientIdentifier);
+DEFINE_CONFIG_PARSE_ENUM(config_parse_dhcp_client_identifier,
dhcp_client_identifier, DCHPClientIdentifier, Failed to parse client
identifier type);
+
static const char* const llmnr_support_table[_LLMNR_SUPPORT_MAX] = {
[LLMNR_SUPPORT_NO] = no,
[LLMNR_SUPPORT_YES] = yes,
diff --git a/src/network/networkd.h b/src/network/networkd.h
index e75746f..8bdc2be 100644
--- a/src/network/networkd.h
+++ b/src/network/networkd.h
@@ -83,6 +83,13 @@ typedef enum LinkOperationalState {
_LINK_OPERSTATE_INVALID = -1
} LinkOperationalState;
+typedef enum DCHPClientIdentifier {
+DHCP_CLIENT_ID_MAC,
+DHCP_CLIENT_ID_DUID,
+_DHCP_CLIENT_ID_MAX,
+_DHCP_CLIENT_ID_INVALID = -1,
+} DCHPClientIdentifier;
+
struct FdbEntry {
Network *network;
unsigned section;
@@ -115,6 +122,7 @@ struct Network {
NetDev *bond;
Hashmap *stacked_netdevs;
AddressFamilyBoolean dhcp;
+DCHPClientIdentifier
Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target
В Tue, 3 Mar 2015 13:36:43 -0500 Steve Dickson ste...@redhat.com пишет: Its been reported that having the rpc-statd-notify service depend on network.target instead network-online.target decrease boot times as much as 10 seconds on some installs If it does not need network when strting, it should not depend on network at all. This will probably decrease boot time even more. If it does need network, it should depend on network-online, this is correct. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293 Signed-off-by: Steve Dickson ste...@redhat.com Reported-by: Eric Work work.e...@gmail.com --- systemd/rpc-statd-notify.service |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service index a655445..b608a14 100644 --- a/systemd/rpc-statd-notify.service +++ b/systemd/rpc-statd-notify.service @@ -1,6 +1,6 @@ [Unit] Description=Notify NFS peers of a restart -Requires=network-online.target +Requires=network.target After=network.target nss-lookup.target # if we run an nfs server, it needs to be running before we ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemd: Relax dependencies of services
Hello all, Zbigniew Jędrzejewski-Szmek [2015-03-03 19:08 +0100]: Are you sure that all of those nfs daemons do not require sockets.target and other stuff provided by basic.target to be ready? The corresponding upstart jobs trigger on virtual file systems (/sys, etc.) and rpcbind, and we've used them for years. Also, NFS does not yet use socket activation, or talks to other services on sockets (except for rpcbind), so we don't need sockets.target either. The other dependencies (some network.target, some nss-lookup.target, etc.) are already specified explicitly. So I'm quite sure. That said, there's of course always a nonzero chance that this breaks in a case which I haven't tested. In particular, I didn't test kerberos/gssd, I'd appreciate if someone who has a real-world setup with that could give this a spin. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemd: Relax dependencies of services
On Tue, Mar 03, 2015 at 06:28:10PM +0100, Martin Pitt wrote: Stop depending on basic.target in the daemons which still do; i. e. add DefaultDependencies=no. This makes it possible to run NFS during early boot, and helps if you e. g. have /var on NFS. We don't require much else than local-fs. Are you sure that all of those nfs daemons do not require sockets.target and other stuff provided by basic.target to be ready? Zbyszek --- systemd/auth-rpcgss-module.service | 1 + systemd/nfs-config.service | 2 ++ systemd/nfs-idmapd.service | 3 ++- systemd/nfs-mountd.service | 3 ++- systemd/nfs-server.service | 2 ++ systemd/rpc-statd-notify.service | 3 ++- systemd/rpc-svcgssd.service| 3 ++- 7 files changed, 13 insertions(+), 4 deletions(-) diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service index 0355e13..5241f7b 100644 --- a/systemd/auth-rpcgss-module.service +++ b/systemd/auth-rpcgss-module.service @@ -6,6 +6,7 @@ # unit will fail. But that's OK.) [Unit] Description=Kernel Module supporting RPCSEC_GSS +DefaultDependencies=no Before=gssproxy.service rpc-svcgssd.service rpc-gssd.service Wants=gssproxy.service rpc-svcgssd.service rpc-gssd.service ConditionPathExists=/etc/krb5.keytab diff --git a/systemd/nfs-config.service b/systemd/nfs-config.service index 64010e6..7f65305 100644 --- a/systemd/nfs-config.service +++ b/systemd/nfs-config.service @@ -1,5 +1,7 @@ [Unit] Description=Preprocess NFS configuration +After=local-fs.target +DefaultDependencies=no [Service] Type=oneshot diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service index e84f8c8..df3dd9d 100644 --- a/systemd/nfs-idmapd.service +++ b/systemd/nfs-idmapd.service @@ -1,7 +1,8 @@ [Unit] Description=NFSv4 ID-name mapping service +DefaultDependencies=no Requires=var-lib-nfs-rpc_pipefs.mount -After=var-lib-nfs-rpc_pipefs.mount +After=var-lib-nfs-rpc_pipefs.mount local-fs.target BindsTo=nfs-server.service diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service index d908afe..8a39f3e 100644 --- a/systemd/nfs-mountd.service +++ b/systemd/nfs-mountd.service @@ -1,8 +1,9 @@ [Unit] Description=NFS Mount Daemon +DefaultDependencies=no Requires=proc-fs-nfsd.mount After=proc-fs-nfsd.mount -After=network.target +After=network.target local-fs.target BindsTo=nfs-server.service Wants=nfs-config.service diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service index b35e193..db801cb 100644 --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -1,10 +1,12 @@ [Unit] Description=NFS server and services +DefaultDependencies=no Requires= network.target proc-fs-nfsd.mount rpcbind.target Requires= nfs-mountd.service Wants=rpc-statd.service nfs-idmapd.service Wants=rpc-statd-notify.service +After= local-fs.target After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service After= nfs-idmapd.service rpc-statd.service Before= rpc-statd-notify.service diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service index a655445..a7e2f8e 100644 --- a/systemd/rpc-statd-notify.service +++ b/systemd/rpc-statd-notify.service @@ -1,7 +1,8 @@ [Unit] Description=Notify NFS peers of a restart +DefaultDependencies=no Requires=network-online.target -After=network.target nss-lookup.target +After=local-fs.target network.target nss-lookup.target # if we run an nfs server, it needs to be running before we # tell clients that it has restarted. diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service index f7424b0..41177b6 100644 --- a/systemd/rpc-svcgssd.service +++ b/systemd/rpc-svcgssd.service @@ -1,7 +1,8 @@ [Unit] Description=RPC security service for NFS server +DefaultDependencies=no Requires=var-lib-nfs-rpc_pipefs.mount -After=var-lib-nfs-rpc_pipefs.mount +After=var-lib-nfs-rpc_pipefs.mount local-fs.target PartOf=nfs-server.service PartOf=nfs-utils.service -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] sd-dhcp6-client: delay setting the DUID and don't fail constructor
sd_dhcp6_client_new() tried to set the DUID based on the machine id.
If the host has no /etc/machine-id, the constructor would fail
making it impossible to create an sd_dhcp6_client instance.
Relax this and create a DUID only later as needed. This way a caller
caller can workaround a missing machine-id file and set a DUID of his
choosing via sd_dhcp6_client_set_duid().
---
src/libsystemd-network/sd-dhcp6-client.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/libsystemd-network/sd-dhcp6-client.c
b/src/libsystemd-network/sd-dhcp6-client.c
index a432bbf..3db1cb0 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -158,6 +158,13 @@ int sd_dhcp6_client_set_mac(sd_dhcp6_client *client, const
uint8_t *addr,
return 0;
}
+static int client_ensure_duid(sd_dhcp6_client *client)
+{
+if (client-duid_len != 0)
+return 0;
+return dhcp_identifier_set_duid_en(client-duid, client-duid_len);
+}
+
int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, uint16_t type, uint8_t
*duid,
size_t duid_len)
{
@@ -378,6 +385,7 @@ static int client_send_message(sd_dhcp6_client *client,
usec_t time_now) {
if (r 0)
return r;
+assert (client-duid_len);
r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_CLIENTID,
client-duid_len, client-duid);
if (r 0)
@@ -1108,6 +1116,10 @@ int sd_dhcp6_client_start(sd_dhcp6_client *client)
if (r 0)
return r;
+r = client_ensure_duid(client);
+if (r 0)
+return r;
+
r = dhcp6_network_bind_udp_socket(client-index, NULL);
if (r 0)
return r;
@@ -1205,7 +1217,6 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client
*client) {
int sd_dhcp6_client_new(sd_dhcp6_client **ret)
{
_cleanup_dhcp6_client_unref_ sd_dhcp6_client *client = NULL;
-int r;
size_t t;
assert_return(ret, -EINVAL);
@@ -1222,11 +1233,6 @@ int sd_dhcp6_client_new(sd_dhcp6_client **ret)
client-fd = -1;
-/* initialize DUID */
-r = dhcp_identifier_set_duid_en(client-duid, client-duid_len);
-if (r 0)
-return r;
-
client-req_opts_len = ELEMENTSOF(default_req_opts);
client-req_opts = new0(be16_t, client-req_opts_len);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-219: Failed to start Create Volatile...
On Mon, Mar 02, 2015 at 05:07:40PM -0300, RicΛrdo Bastos™ wrote: Hi all, I'm using this tip to solve problem in systemd-TMPFILES-setup.service: http://forums.gentoo.org/viewtopic-t-1011254-view-previous.html?sid=4a7ba76e913f996abfa6e09aee95 http://www.google.com/url?q=http%3A%2F%2Fforums.gentoo.org%2Fviewtopic-t-1011254-view-previous.html%3Fsid%3D4a7ba76e913f996abfa6e09aee95sa=Dsntz=1usg=AFQjCNEAeFsiM_50wA7SSsdJej8T6aPpQA So I commented the following lines in systemd.conf file: # a+ /var/log/journal/%m - - - - d:group:adm:r-x,d:group:wheel:r-x # A+ /var/log/journal/%m - - - - group:adm:r-x,group:wheel:r-x Now the service is starting correctly :) *# **Active: active (exited) since Seg 2015-03-02 13:37:04 BRT; 3h 1min ago* You get the warning most likely because the filesystem that /var/log/journal or /run/log/journal are on does not support ACL. So users in the wheel and adm groups will not be given access to the journal through ACLs. This isn't really a problem — apart from the unsightly warning in the logs, and the missing access, this should not have any other effects. I pushed a commit to reduce the warning to debug level if the fs does not support ACLs. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target
Its been reported that having the rpc-statd-notify service depend on network.target instead network-online.target decrease boot times as much as 10 seconds on some installs Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293 Signed-off-by: Steve Dickson ste...@redhat.com Reported-by: Eric Work work.e...@gmail.com --- systemd/rpc-statd-notify.service |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service index a655445..b608a14 100644 --- a/systemd/rpc-statd-notify.service +++ b/systemd/rpc-statd-notify.service @@ -1,6 +1,6 @@ [Unit] Description=Notify NFS peers of a restart -Requires=network-online.target +Requires=network.target After=network.target nss-lookup.target # if we run an nfs server, it needs to be running before we -- 1.7.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemd: Order NFS server before client
On Tue, Mar 03, 2015 at 06:28:09PM +0100, Martin Pitt wrote: This makes mounting NFS shares from localhost work reliably, as you need to start the server before attempting (client) mounts, and conversely on shutdown need to unmount all shares before stopping the server to avoid hangs. --- systemd/nfs-server.service | 3 +++ 1 file changed, 3 insertions(+) diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service index 8010aad..b35e193 100644 --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -13,6 +13,9 @@ Before= rpc-statd-notify.service Wants=auth-rpcgss-module.service After=rpc-gssd.service gssproxy.service rpc-svcgssd.service +# start/stop server before/after client +Before=remote-fs-pre.target + Wants=nfs-config.service After=nfs-config.service Looks reasonable. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target
On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote: В Tue, 3 Mar 2015 13:36:43 -0500 Steve Dickson ste...@redhat.com пишет: Its been reported that having the rpc-statd-notify service depend on network.target instead network-online.target decrease boot times as much as 10 seconds on some installs If it does not need network when strting, it should not depend on network at all. This will probably decrease boot time even more. If it does need network, it should depend on network-online, this is correct. Indeed. From the man page: -m retry-time Specifies the length of time, in minutes, to continue retry‐ ing notifications to unresponsive hosts. If this option is not specified, sm-notify attempts to send notifications for 15 minutes. Specifying a value of 0 causes sm-notify to continue sending notifications to unresponsive peers until it is manually killed. Notifications are retried if sending fails, the remote does not respond, the remote's NSM service is not registered, or if there is a DNS failure which prevents the remote's mon_name from being resolved to an address. So rpc-statd-notify.service should be fine with being started before the network is up at all. Zbyszek Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293 Signed-off-by: Steve Dickson ste...@redhat.com Reported-by: Eric Work work.e...@gmail.com --- systemd/rpc-statd-notify.service |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service index a655445..b608a14 100644 --- a/systemd/rpc-statd-notify.service +++ b/systemd/rpc-statd-notify.service @@ -1,6 +1,6 @@ [Unit] Description=Notify NFS peers of a restart -Requires=network-online.target +Requires=network.target After=network.target nss-lookup.target # if we run an nfs server, it needs to be running before we ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles.d: only copy /etc/pam.d if PAM is present
On Tue, Mar 03, 2015 at 11:37:52AM +, Ross Burton wrote: If HAVE_PAM isn't set then don't attempt to copy /etc/pam.d from the factory, as it doesn't get installed. Applied. Zbyszek Signed-off-by: Ross Burton ross.bur...@intel.com --- tmpfiles.d/etc.conf.m4 |2 ++ 1 file changed, 2 insertions(+) diff --git a/tmpfiles.d/etc.conf.m4 b/tmpfiles.d/etc.conf.m4 index 9b0e080..ab5cd16 100644 --- a/tmpfiles.d/etc.conf.m4 +++ b/tmpfiles.d/etc.conf.m4 @@ -14,4 +14,6 @@ m4_ifdef(`ENABLE_RESOLVED', L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf )m4_dnl C /etc/nsswitch.conf - - - - +m4_ifdef(`HAVE_PAM', C /etc/pam.d - - - - +)m4_dnl -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to remove images using machinectl
On Mon, Mar 02, 2015 at 11:01:44PM +0100, Lennart Poettering wrote: On Mon, 02.03.15 14:10, Erik Johnson (e...@saltstack.com) wrote: On Mon, Mar 02, 2015 at 07:51:35PM +0100, Lennart Poettering wrote: On Mon, 02.03.15 11:06, Erik Johnson (e...@saltstack.com) wrote: I'm getting a similar error to the one described in the following post from a couple weeks ago: https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28255.html I get an access denied error when running machinectl remove, even as root. This was a bug in the dbus policy. It should be fixed with this commit: http://cgit.freedesktop.org/systemd/systemd/commit/src/machine/org.freedesktop.machine1.conf?id=72c3897f77a7352618ea76b880a6764f52d6327b Lennart -- Lennart Poettering, Red Hat Thanks. I applied the patch, restarted dbus, and now I get the following after a 20-30 second pause: Could not remove image: Activation of org.freedesktop.machine1 timed out dbus is not a service that cannot be restarted during normal operation. This is a well-known limitation of dbus. Reloading configuration should be sufficient. You probably need to reboot now to get back to a working system... Lennart -- Lennart Poettering, Red Hat OK. After rebooting, it's still not working. Were the necessary changes limited to that one commit? I'm demoing nspawn at SaltConf tomorrow (http://eventmobi.com/saltconf15/agenda/94463/505550), and if necessary I can just run machined in the foreground. Continuing to troubleshoot this isn't really that necessary. -- Erik Johnson | Senior Engineer 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 e...@saltstack.com | http://saltstack.com pgpaDsThEmc0j.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target
On 03/03/2015 02:18 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote: Indeed. From the man page: -m retry-time Specifies the length of time, in minutes, to continue retry‐ ing notifications to unresponsive hosts. If this option is not specified, sm-notify attempts to send notifications for 15 minutes. Specifying a value of 0 causes sm-notify to continue sending notifications to unresponsive peers until it is manually killed. Notifications are retried if sending fails, the remote does not respond, the remote's NSM service is not registered, or if there is a DNS failure which prevents the remote's mon_name from being resolved to an address. So rpc-statd-notify.service should be fine with being started before the network is up at all. Right... that's the point... we want the service to fork and keep trying in the background Thanks for the cycles! steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemd: Relax dependencies of services
On 03/03/2015 03:12 PM, Martin Pitt wrote: Hello all, Zbigniew Jędrzejewski-Szmek [2015-03-03 19:08 +0100]: Are you sure that all of those nfs daemons do not require sockets.target and other stuff provided by basic.target to be ready? The corresponding upstart jobs trigger on virtual file systems (/sys, etc.) and rpcbind, and we've used them for years. Also, NFS does not yet use socket activation, or talks to other services on sockets (except for rpcbind), so we don't need sockets.target either. The other dependencies (some network.target, some nss-lookup.target, etc.) are already specified explicitly. So I'm quite sure. You are correct. rpcbind is the only service we have that uses socket activation, which I don't think works very well... Just last week I notice if you reboot a vm and the first command you type is rpcinfo -p. That command will time out trying to talk with rpcbind. After the timeout everything works fine... I thought I opened a bz but I can't seem to find it. steved. That said, there's of course always a nonzero chance that this breaks in a case which I haven't tested. In particular, I didn't test kerberos/gssd, I'd appreciate if someone who has a real-world setup with that could give this a spin. Thanks, Martin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix strict aliasing violations in src/udev/udev-builtin-usb_id.c
also switch to inttypes.h
---
src/udev/udev-builtin-usb_id.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/udev/udev-builtin-usb_id.c b/src/udev/udev-builtin-usb_id.c
index ab0d96e..0223421 100644
--- a/src/udev/udev-builtin-usb_id.c
+++ b/src/udev/udev-builtin-usb_id.c
@@ -28,6 +28,7 @@
#include ctype.h
#include fcntl.h
#include errno.h
+#include inttypes.h
#include udev.h
@@ -153,15 +154,15 @@ static int dev_if_packed_info(struct udev_device *dev,
char *ifs_str, size_t len
int pos = 0;
unsigned strpos = 0;
struct usb_interface_descriptor {
-u_int8_tbLength;
-u_int8_tbDescriptorType;
-u_int8_tbInterfaceNumber;
-u_int8_tbAlternateSetting;
-u_int8_tbNumEndpoints;
-u_int8_tbInterfaceClass;
-u_int8_tbInterfaceSubClass;
-u_int8_tbInterfaceProtocol;
-u_int8_tiInterface;
+uint8_tbLength;
+uint8_tbDescriptorType;
+uint8_tbInterfaceNumber;
+uint8_tbAlternateSetting;
+uint8_tbNumEndpoints;
+uint8_tbInterfaceClass;
+uint8_tbInterfaceSubClass;
+uint8_tbInterfaceProtocol;
+uint8_tiInterface;
} __attribute__((packed));
if (asprintf(filename, %s/descriptors,
udev_device_get_syspath(dev)) 0)
@@ -179,21 +180,21 @@ static int dev_if_packed_info(struct udev_device *dev,
char *ifs_str, size_t len
ifs_str[0] = '\0';
while (pos size strpos+7 len-2) {
-struct usb_interface_descriptor *desc;
+struct usb_interface_descriptor desc;
char if_str[8];
-desc = (struct usb_interface_descriptor *) buf[pos];
-if (desc-bLength 3)
+memcpy(desc, buf[pos], sizeof(desc));
+if (desc.bLength 3)
break;
-pos += desc-bLength;
+pos += desc.bLength;
-if (desc-bDescriptorType != USB_DT_INTERFACE)
+if (desc.bDescriptorType != USB_DT_INTERFACE)
continue;
if (snprintf(if_str, 8, :%02x%02x%02x,
- desc-bInterfaceClass,
- desc-bInterfaceSubClass,
- desc-bInterfaceProtocol) != 7)
+ desc.bInterfaceClass,
+ desc.bInterfaceSubClass,
+ desc.bInterfaceProtocol) != 7)
continue;
if (strstr(ifs_str, if_str) != NULL)
--
2.2.1.209.g41e5f3a
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nilfs-cleanerd startup on boot
-Original Message- From: linux-nilfs-ow...@vger.kernel.org [mailto:linux-nilfs- ow...@vger.kernel.org] On Behalf Of Ryusuke Konishi Sent: Tuesday, March 03, 2015 6:18 PM To: Dennis Murata (WT01 - ENU); lenn...@poettering.net Cc: systemd-devel@lists.freedesktop.org; linux-ni...@vger.kernel.org Subject: Re: [systemd-devel] nilfs-cleanerd startup on boot Hi On 2015/03/04 0:44, dennis.mur...@wipro.com wrote: I had mis-typed the address for the nilfs mail group -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Saturday, February 28, 2015 12:34 PM To: Dennis Murata (WT01 - ENU) Cc: systemd-devel@lists.freedesktop.org; linus-ni...@vger.kernel.org Subject: Re: [systemd-devel] nilfs-cleanerd startup on boot On Fri, 27.02.15 18:31, dennis.mur...@wipro.com (dennis.mur...@wipro.com) wrote: I have a fedora 21 system that where I mount an nilfs2 file system. I use a simple /etc/modules-load.d/nilfs.conf file to load the kernel module and have an entry in the fstab. Creating the modules-load.d snippet should not be necessary, as the kernel should autoload the kernel module for it when it is first required. I did not find this to be the case for fedora 21. Without creating the file to load the module, any attempt I made to mount the file system would get a unknown filetype error. Does this point at adding this module to the initrd file? Is nilfs2.ko installed in your environment? I had to add the kernel-modules-extra package that you list below. This is probably why I also had to add the file in modules-load.d to get this module loaded Try modinfo nilfs2 Older fedora needed kernel-modules-extra package. [1] [1] http://nilfs.sourceforge.net/en/pkg_fedora.html The file system mounts on boot as it should, but the nilfs-cleanerd program does not startup. If I umount /nilfs then mount /nilfs the nilfs-cleanerd program starts as it should to cleanup the checkpoints. How is that daemon supposed to be started? Is it forked off /bin/mount? Does systemd use a different mount program at boot? It uses /bin/mount for mounting normal file systems. nilfs_cleanerd is invoked through /sbin/mount.nilfs2 helper. [2] The helper is called from /sbin/mount if it exists. What is confusing to me, is an umount then a mount will start the nilfs_cleanerd process so it does exist on the system. I had expected it to be started as soon as the file system was mounted the first time. /sbin/mount.nilfs2 is included in nilfs-utils package. nilfs_cleanerd is just a user-land process, so it can be manually invoked if you have root privilege. [3] # /sbin/nilfs_cleanerd device directory But, in this case, you need to kill nilfs_cleanerd manually before umount. So, I recommend running cleanerd through mount.nilfs2. The above explanation may not suit for the recent fedora since nilfs-utils is not yet tuned to systemd environment. [2] http://nilfs.sourceforge.net/en/man8/mount.nilfs2.8.html [3] http://nilfs.sourceforge.net/en/man8/nilfs_cleanerd.8.html Regards, Ryusuke Konishi Is there something else that should be included other than the nilfs.conf file? I have just started using a system with systemd as the init so please forgive my ignorance. I have no idea about nilfs really, and we had no reports about any problems with it before. I wanted to look at the performance of nilfs and f2fs. This is my first try at using these file systems Lennart -- Lennart Poettering, Red Hat -- To unsubscribe from this list: send the line unsubscribe linux-nilfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-nilfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target
On Tue, Mar 03, 2015 at 04:37:24PM -0500, Steve Dickson wrote: On 03/03/2015 02:18 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote: Indeed. From the man page: -m retry-time Specifies the length of time, in minutes, to continue retry‐ ing notifications to unresponsive hosts. If this option is not specified, sm-notify attempts to send notifications for 15 minutes. Specifying a value of 0 causes sm-notify to continue sending notifications to unresponsive peers until it is manually killed. Notifications are retried if sending fails, the remote does not respond, the remote's NSM service is not registered, or if there is a DNS failure which prevents the remote's mon_name from being resolved to an address. So rpc-statd-notify.service should be fine with being started before the network is up at all. Right... that's the point... we want the service to fork and keep trying in the background ...so like Andrei wrote, the dependency on network.target can be removed (I wasn't sure if it was clear what I meant). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-219: Failed to start Create Volatile...
Zbyszek! Thanks for the reply;) Atenciosamente RICARDO BASTOS CAMPOS Análise e Desenvolvimento de Sistemas MS Researcher at INF in Parallel and Distributed Processing Systems (UFRGS) Porto Alegre, RS - Brasil 2015-03-03 14:50 GMT-03:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Mon, Mar 02, 2015 at 05:07:40PM -0300, RicΛrdo Bastos™ wrote: Hi all, I'm using this tip to solve problem in systemd-TMPFILES-setup.service: http://forums.gentoo.org/viewtopic-t-1011254-view-previous.html?sid=4a7ba76e913f996abfa6e09aee95 http://www.google.com/url?q=http%3A%2F%2Fforums.gentoo.org%2Fviewtopic-t-1011254-view-previous.html%3Fsid%3D4a7ba76e913f996abfa6e09aee95sa=Dsntz=1usg=AFQjCNEAeFsiM_50wA7SSsdJej8T6aPpQA So I commented the following lines in systemd.conf file: # a+ /var/log/journal/%m - - - - d:group:adm:r-x,d:group:wheel:r-x # A+ /var/log/journal/%m - - - - group:adm:r-x,group:wheel:r-x Now the service is starting correctly :) *# **Active: active (exited) since Seg 2015-03-02 13:37:04 BRT; 3h 1min ago* You get the warning most likely because the filesystem that /var/log/journal or /run/log/journal are on does not support ACL. So users in the wheel and adm groups will not be given access to the journal through ACLs. This isn't really a problem — apart from the unsightly warning in the logs, and the missing access, this should not have any other effects. I pushed a commit to reduce the warning to debug level if the fs does not support ACLs. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Journalctl Unit Completion Optmization
Hello, I've recently been using journalctl on one of my longer-lived systems, and I'm running into a slight annoyance. Most of the time I'm using `journalctl -u unit -e`. I use tab completion for the unit name, and the annoyance is the long pause journalctl takes to complete a unit. With cold cache (meaning writing 3 to /proc/sys/vm/drop_caches), this takes 23 seconds on a system using Btrfs on a SATA3 SSD. With warm cache, it still takes 3-4 seconds. Both cases are quite a bit slower than normal tab completion behavior. I'm wondering if there has been any discussion or examination on optimizing the bash completion to speed it up. The Bash completion support for journalctl calls `journalctl -F '_SYSTEMD_UNIT'` to assemble a list of acceptable units. That leads to get_possible_units() in src/journal/journalctl.c, which calls the macro SD_JOURNAL_FOREACH_UNIQUE and then sd_journal_enumerate_unique() in sr/journal/sd-journal.c. The problem from the user's perspective is that this scans through all the journals, including user journals, which in my case is 68. That leads me to a few possible optimization strategies, although each has downsides: 1) Instead of scanning through the journals for tab completion, use a more simplistic search that only uses installed units. By installed, I mean that tab completion only provides units that presently have a unit file on the system (/etc/systemd/system/, /lib/systemd/system/, etc.) regardless of enabled or activated state. Basically, just scan those directories for file names. The obvious downside is that the user wouldn't be able to tab complete units which have since been deleted. A simplistic POC solution would be to change L76-78 of shell-completion/bash/journalctl from --unit|-u) comps=$(journalctl -F '_SYSTEMD_UNIT' 2/dev/null) ;; to something like --unit|-u) comps=$(ls /lib/systemd/system /etc/systemd/system | grep '\.service$\|\.timer$\|\.socket$') ;; 2) Have the journal maintain an index of units, which have emitted log messages. That way tab completion would only need to scan this index to populate `journalctl -F '_SYSTEMD_UNIT'`. The index could either be read from disk or kept in memory. The downside is two-fold. First, for every log message the journal would need to account for whether that unit is already in the index. If the index was constantly updated on disk, this adds an amount of addition IO. If it's in memory, the journal would consume additional runtime memory. Second, as old journals are removed due to cleaning, this index would need to be updated. 3) A combination of the two approaches. If this is even possible for shell completion, have the first tab completion attempt use method #1 or #2 and a second tab completion attempt use either #2 or the current behavior. The benefit is that a user using tab completion for convenience (instead of obtaining an exhaustive list of all units) and knows what she is looking for (eg. Networktab for NetworkManager.service) gets a fast answer. The downside is whether shell completion can even handle multiple behaviors and causing user confusion by altering the user interface. Thoughts? Thanks, Justin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] systemd: Relax dependencies of services
Stop depending on basic.target in the daemons which still do; i. e. add DefaultDependencies=no. This makes it possible to run NFS during early boot, and helps if you e. g. have /var on NFS. We don't require much else than local-fs. --- systemd/auth-rpcgss-module.service | 1 + systemd/nfs-config.service | 2 ++ systemd/nfs-idmapd.service | 3 ++- systemd/nfs-mountd.service | 3 ++- systemd/nfs-server.service | 2 ++ systemd/rpc-statd-notify.service | 3 ++- systemd/rpc-svcgssd.service| 3 ++- 7 files changed, 13 insertions(+), 4 deletions(-) diff --git a/systemd/auth-rpcgss-module.service b/systemd/auth-rpcgss-module.service index 0355e13..5241f7b 100644 --- a/systemd/auth-rpcgss-module.service +++ b/systemd/auth-rpcgss-module.service @@ -6,6 +6,7 @@ # unit will fail. But that's OK.) [Unit] Description=Kernel Module supporting RPCSEC_GSS +DefaultDependencies=no Before=gssproxy.service rpc-svcgssd.service rpc-gssd.service Wants=gssproxy.service rpc-svcgssd.service rpc-gssd.service ConditionPathExists=/etc/krb5.keytab diff --git a/systemd/nfs-config.service b/systemd/nfs-config.service index 64010e6..7f65305 100644 --- a/systemd/nfs-config.service +++ b/systemd/nfs-config.service @@ -1,5 +1,7 @@ [Unit] Description=Preprocess NFS configuration +After=local-fs.target +DefaultDependencies=no [Service] Type=oneshot diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service index e84f8c8..df3dd9d 100644 --- a/systemd/nfs-idmapd.service +++ b/systemd/nfs-idmapd.service @@ -1,7 +1,8 @@ [Unit] Description=NFSv4 ID-name mapping service +DefaultDependencies=no Requires=var-lib-nfs-rpc_pipefs.mount -After=var-lib-nfs-rpc_pipefs.mount +After=var-lib-nfs-rpc_pipefs.mount local-fs.target BindsTo=nfs-server.service diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service index d908afe..8a39f3e 100644 --- a/systemd/nfs-mountd.service +++ b/systemd/nfs-mountd.service @@ -1,8 +1,9 @@ [Unit] Description=NFS Mount Daemon +DefaultDependencies=no Requires=proc-fs-nfsd.mount After=proc-fs-nfsd.mount -After=network.target +After=network.target local-fs.target BindsTo=nfs-server.service Wants=nfs-config.service diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service index b35e193..db801cb 100644 --- a/systemd/nfs-server.service +++ b/systemd/nfs-server.service @@ -1,10 +1,12 @@ [Unit] Description=NFS server and services +DefaultDependencies=no Requires= network.target proc-fs-nfsd.mount rpcbind.target Requires= nfs-mountd.service Wants=rpc-statd.service nfs-idmapd.service Wants=rpc-statd-notify.service +After= local-fs.target After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service After= nfs-idmapd.service rpc-statd.service Before= rpc-statd-notify.service diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service index a655445..a7e2f8e 100644 --- a/systemd/rpc-statd-notify.service +++ b/systemd/rpc-statd-notify.service @@ -1,7 +1,8 @@ [Unit] Description=Notify NFS peers of a restart +DefaultDependencies=no Requires=network-online.target -After=network.target nss-lookup.target +After=local-fs.target network.target nss-lookup.target # if we run an nfs server, it needs to be running before we # tell clients that it has restarted. diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service index f7424b0..41177b6 100644 --- a/systemd/rpc-svcgssd.service +++ b/systemd/rpc-svcgssd.service @@ -1,7 +1,8 @@ [Unit] Description=RPC security service for NFS server +DefaultDependencies=no Requires=var-lib-nfs-rpc_pipefs.mount -After=var-lib-nfs-rpc_pipefs.mount +After=var-lib-nfs-rpc_pipefs.mount local-fs.target PartOf=nfs-server.service PartOf=nfs-utils.service -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] po: update Russian translation
On Mon, Mar 02, 2015 at 01:40:49PM +, Dimitri John Ledkov wrote: On 2 March 2015 at 13:04, Sergey Ptashnick 0comff...@inbox.ru wrote: On 02.03.2015 02:26, Ivan Shapovalov wrote: Hmm... Here (and in similar cases below) the comma should not be used, because для is just a preposition and hence для управления does not introduce neither a subordinate clause; it's a word in genitive case. Such form used also in other statements. If you think that removing this comma will improve readability, please prepare patch for all of them. (I don't think so, and leave this to your discretion.) If it was up to me, I'd switch the sentence around: Необходимо пройти аутентификацию для управления виртуальными машинами и контейнерами. I also wouldn't want to see foreign bored terms like менеджер and юнит used in translation and instead use e.g. управляющий and единица. But I'm not a sysadmin in a Russian speaking environment, so I cannot judge whether the foreign terms are actually already wide-spread in IT context and became de-facto terms. If such changes are warranted, please submit them separately. Patch is applied as-is for now. In the meantime, the translation strings were changed again :( But it's just one word: -msgid Manage system services or units +msgid Manage system services or other units -msgid Authentication is required to manage system services or units. +msgid Authentication is required to manage system services or other units. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to remove images using machinectl
On Tue, 03.03.15 07:11, Peter Paule (systemd-de...@fedux.org) wrote: Excerpts from Erik Johnson's message of 2015-03-02 14:10:06 -0700: Thanks. I applied the patch, restarted dbus, and now I get the following after a 20-30 second pause: @Erik Did you use the aur package or did you compile systemd and install it using make? Do you have experience rolling back to the normal package provided by arch? To fix the bus policy it is sufficient to copy that one file in. The policy XML file is not processed any further it's installed as is into the system. I'm just asking because I thought about installing systemd on my arch, but as it is my machine which I use very frequently I don't want to crash it. :-) @Lennart Is is difficult to get rid of a systemd package installed from git? Well if you built systemd with ./autogen.sh c make -j6 sudo make install then you should be able to simply install the original package from your distro again and it should replace everything again. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating containers from local .raw or tar images
On Mon, 02.03.15 23:50, Erik Johnson (e...@saltstack.com) wrote: On Mon, Mar 02, 2015 at 06:03:42PM -0500, Daurnimator wrote: AFAIK, all the pull-* commands do is download into /var/lib/machines. You could easily enough just copy things into there yourself. Or even less work: don't copy them in there at all, and pass your image directly to systemd-nspawn (which is what machinectl uses) See: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html I've done that before, but I am writing nspawn support for SaltStack (http://saltstack.com) and I need to start and stop them unattended. BTW, pretty much everything machinectl does is just invoke a couple of bus calls. If you hack support for nspawn into some software you can thus call the bus calls directly. More specifically, machinectl is primarily just a frontend for some calls from machined, others from importd and finally others from PID 1. Unfortunateky through we currently have no docs for importd's APIs (it's really new), and machined's are slightly incomplete (the newer bits are missing). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles.d: only copy /etc/pam.d if PAM is present
If HAVE_PAM isn't set then don't attempt to copy /etc/pam.d from the factory, as it doesn't get installed. Signed-off-by: Ross Burton ross.bur...@intel.com --- tmpfiles.d/etc.conf.m4 |2 ++ 1 file changed, 2 insertions(+) diff --git a/tmpfiles.d/etc.conf.m4 b/tmpfiles.d/etc.conf.m4 index 9b0e080..ab5cd16 100644 --- a/tmpfiles.d/etc.conf.m4 +++ b/tmpfiles.d/etc.conf.m4 @@ -14,4 +14,6 @@ m4_ifdef(`ENABLE_RESOLVED', L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf )m4_dnl C /etc/nsswitch.conf - - - - +m4_ifdef(`HAVE_PAM', C /etc/pam.d - - - - +)m4_dnl -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
