Re: [systemd-devel] How to use machinectl to get a running centos container?
On 3 March 2017 at 20:58, Lennart Poettering wrote: > On Fri, 03.03.17 12:34, Daurnimator (q...@daurnimator.com) wrote: > >> I'm trying to set up a centos 7 container with machinectl. >> I've tried to run: >> >> machinectl pull-raw --verify=no >> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1701.raw.tar.gz > > Hmm, what is a ".raw.tar.gz" file? That suffix makes no sense to me... *shrugs* it's what I saw available for download from http://cloud.centos.org/centos/7/images/ Apparently it's a gziped tar with a single file inside: CentOS-7-x86_64-GenericCloud-20170131_01.raw This .raw file is a disk image. >> This downloads the image, but then dies with: >> >> File overly large, refusing >> Failed to retrieve image file. (Wrong URL?) >> Exiting. > > How large is the file? - The .gz is 581M - The .tar is 8.1G - The .raw is 8.0G (8388608 K) >> Is there some other way I should be doing this? > > We support raw disk images and tarballs with OS trees in them, both > compressed and non-compressed. > > There's currently a safety limit against overly large images enforced, > of 8GiB. If the indicated image is larger than that, and that's > intended we should probably bump this safety limit substantially (32G? > 64G?), please file a github issue asking for this if this is the > case. Or even better prep a PR, the fix is trivial: > > https://github.com/systemd/systemd/blob/master/src/import/pull-job.c#L530 Looks like it's *equal* to the limit. Before I make a PR here, am I going about running a centos container with machinectl the best way here? How are other people doing this? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to use machinectl to get a running centos container?
I'm trying to set up a centos 7 container with machinectl. I've tried to run: machinectl pull-raw --verify=no http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1701.raw.tar.gz This downloads the image, but then dies with: File overly large, refusing Failed to retrieve image file. (Wrong URL?) Exiting. Is there some other way I should be doing this? $ machinectl --version systemd 232 +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-resolved: Using different dns server for a certain suffix
I'm trying to add tor support to a system that uses systemd for network configuration. I have configured tor to listen for local DNS queries on 127.0.0.2. Now I'd like systemd-resolved to resolve queries that end in ".onion" to go to that DNS server. See what I've tried: 02-08 05:59:39 daurnimator@daurn-vultr /etc/systemd/network $ cat tor.network [Match] Name=lo [Network] DNS=127.0.0.2 Domains=~onion 02-08 06:00:23 daurnimator@daurn-vultr /etc/systemd/network $ dig @127.0.0.2 frxleqtzgvwkv7oz.onion ; <<>> DiG 9.11.0-P2 <<>> @127.0.0.2 frxleqtzgvwkv7oz.onion ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;frxleqtzgvwkv7oz.onion. IN A ;; ANSWER SECTION: frxleqtzgvwkv7oz.onion. 60 IN A 127.192.40.24 ;; Query time: 0 msec ;; SERVER: 127.0.0.2#53(127.0.0.2) ;; WHEN: Wed Feb 08 06:00:28 UTC 2017 ;; MSG SIZE rcvd: 56 02-08 06:00:28 daurnimator@daurn-vultr /etc/systemd/network $ dig @127.0.0.53 frxleqtzgvwkv7oz.onion ; <<>> DiG 9.11.0-P2 <<>> @127.0.0.53 frxleqtzgvwkv7oz.onion ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25762 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;frxleqtzgvwkv7oz.onion. IN A ;; Query time: 14 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Wed Feb 08 06:00:31 UTC 2017 ;; MSG SIZE rcvd: 51 02-08 06:00:31 daurnimator@daurn-vultr /etc/systemd/network $ sudo systemctl status systemd-resolved ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2017-02-08 05:52:04 UTC; 9min ago Docs: man:systemd-resolved.service(8) http://www.freedesktop.org/wiki/Software/systemd/resolved http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients Main PID: 29816 (systemd-resolve) Status: "Processing requests..." Tasks: 1 (limit: 4915) CGroup: /system.slice/systemd-resolved.service └─29816 /usr/lib/systemd/systemd-resolved Feb 08 05:52:03 daurn-vultr systemd[1]: Starting Network Name Resolution... Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: Positive Trust Anchors: Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21 Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: Using system hostname 'daurn-vultr'. Feb 08 05:52:04 daurn-vultr systemd[1]: Started Network Name Resolution. Feb 08 05:52:06 daurn-vultr systemd-resolved[29816]: Switching to DNS server 108.61.10.10 for interface ens3. Feb 08 06:00:31 daurn-vultr systemd-resolved[29816]: Processing query... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Method to solve a "ordering cycle"
On 8 September 2015 at 16:16, Daniel Spannbauer wrote: > Can I test the system without rebooting it to > find ordering cycles? Try `systemd-analyze verify myfile.someunit` ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] grant users access to certain services only
On 21 August 2015 at 19:57, Dominick Grift wrote: > i think it kind of sucks that systemctl --user list-units can be used to > determine who is currently logged in. You can see with `loginctl list-users` too I once tried to prevent getting a list of users, but it's hard... I locked out: - `w` and `who` (uses /var/run/utmp; do chmod o-r) - `grep -h '^Uid:' /proc/*/status | sort -u` (prevent with procfs option hidepid=2) - ls /run/user (do chmod o-r) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Looking for experiences formalizing an API for journal messages
On 23 July 2015 at 23:17, Anne Mulhern wrote: > Hi! > > We all know that using the journald native API it is possible to enrich the > log > entry data w/ key/value pairs, although this facility is Linux only. > The set of key/value pairs which a message may log to the journal can > constitute an API with which a logging entity can communicate alerts to > consumers > of this information. Clearly this requires an agreement on an API between the > logging > entity and the consumer of the journal entries. > > Are there existing projects that have used this facility in a principled, > coordinated way with some success or have there been any interesting failures > along those same lines? > > Thanks for your help, > > - mulhern The newer syslog standard (RFC 5424) defines a key/value area. See https://tools.ietf.org/html/rfc5424#section-6.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On 23 July 2015 at 04:41, Lennart Poettering wrote: > Maybe we can change the manager core to propagate Reload() calls > for unit type that do not support it natively to other units listed in > PropagateReloadsTo= and then become a NOP. > > Or in other words: invoking reload on a target that knows no > PropagateReloadsTo= should continue to return an error. But if such > deps are defined, it should become a silent NOP and propagate the > event. > > Could you file an RFP issue on github asking for this? [or even better, > send a PR with a patch... ;-) ] ReloadPropagatedFrom= would seem to be more useful here. Why should reloading a target error in the first place? ==> why not just a NOP? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] HEADS-UP: splitting python-systemd out
On 7 July 2015 at 12:50, Zbigniew Jędrzejewski-Szmek wrote: >> Do you intend to publish release tarballs somewhere or should we get one from >> https://github.com/systemd/python-systemd/releases ? > I was hoping that the signed tags and tarballs created by github would > be enough. I built the Fedora package from that. I didn't see a way to > upload a tarball to github. I think they removed the ability > to do that a while back. But if it is necessary, I can publish > the tarballs somewhere. You can do a manual release on github: https://github.com/systemd/systemd/releases/new Also see https://developer.github.com/v3/repos/releases/#upload-a-release-asset ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] systemd-222 around the corner
On 7 July 2015 at 03:54, David Herrmann wrote: > Hi > > We intend to release v222 tomorrow. If anyone has open issues that > need to be in that release, please speak up. Right now, the release > consists almost exclusively of bug-fixes, and we want to get those > into distributions. > > Thanks > David > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel FWIW I'm still holding boxes back on 219 because of https://github.com/systemd/systemd/issues/487 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-resolved as dnsmasq replacement
On 18 Jun 2015 3:51 am, "Lennart Poettering" wrote: > > On Wed, 17.06.15 19:48, Igor Bukanov (i...@mir2.org) wrote: > > > On 17 June 2015 at 15:27, Lennart Poettering wrote: > > > To hook up local name service > > > clients people should use the "nss-resolve" NSS module, which ensures > > > that gethostbyname() and friends use resolved as backend. > > > > I suppose then non-glibc clients should deal with that on its own. I > > thought converting LLMNR into DNS would be a reasonable hack, but then > > if the translation requires too much insanity, then indeed it is > > better not to do that. > > If people use libraries to do DNS manually, then they'll do *DNS* > manually, and we shouldn't interfere with that really. > > Usually people pick non-libc DNS libraries because they need async > behaviour. I am pretty sure that's a pretty bad reason though and if > you want async behaviour you should use sd-resolve or so. I've also used them because I - need other record types (e.g. SRV) - want to use DNSSEC - Want to choose between recursive and stub resolvers FWIW, I use http://25thandclement.com/~william/projects/dns.c.html in many projects. It parses nsswitch.conf, but only cares about a few predetermined values. Maybe it should gain some features in this area? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nss-myhostname: why don't loopback interfaces appear?
On 9 June 2015 at 20:36, Lennart Poettering wrote: > On Wed, 03.06.15 16:31, Daurnimator (q...@daurnimator.com) wrote: > >> On 3 June 2015 at 16:01, Lennart Poettering wrote: >> > On Wed, 03.06.15 15:40, Daurnimator (q...@daurnimator.com) wrote: >> > >> >> I was playing around with nss, and found that my loopback interface ip >> >> doesn't appear from nss-myhostname. >> >> Rather, my other ones do. >> >> Furthermore, unless I request IPv4, link-local IPv6 addresses are >> >> returned. Is this expected? >> > >> > We order the returned addresses by scope. Global addresses are >> > placed first, local ones last. >> >> Then why are link local IPv6 addresses returned first? >> >> If this was the case, I would expect to see: >> >> 192.168.2.229 >> 192.168.2.21 >> fe80::aed1:b8ff:fec0:d113 >> fe80::9eeb:e8ff:fe1b:f42d >> 127.0.0.1 >> ::1 > > Currently the first ordering key is the address family (ipv4 before > ipv6), the second ordering key is the scope (global before > link-local). > > Are you suggesting we should turn this around, and sort by scope > first, and by address family then? I might be open to such a change. Here I was just observing that in my mind, a scope local ipv6 address is less "global" than an ipv4 address; and hence doubting your statement that things are ordered "most global" to "least global" >> > We return addresses on the loopback device only when there's no other >> > address known. >> >> What's the rationale for this? (i.e. why not always just include >> 127.0.0.1 and ::1 last?) > > Because they are an implementation detail I think. If something wants > to know the local IP address, then returning that information is > really useless... > > 127.0.0.x is really an address we should never present to the user > ever, unless there#s no better way... I mean, I am pretty sure I could > explain a non-technical person off the streat what an IP address is, > but I am pretty sure I'd had quite some trouble explaining what the > purpose of 127.0.0.1 is on top of that... example use case, I'm testing a client/server protocol: - the server is running locally; and because it shouldn't be exposed to the internet, it is bound to localhost. - I start the client and tell it to connect to $HOSTNAME - This should find it's way to the loopback interface. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nss-myhostname: why don't loopback interfaces appear?
On 3 June 2015 at 16:01, Lennart Poettering wrote: > On Wed, 03.06.15 15:40, Daurnimator (q...@daurnimator.com) wrote: > >> I was playing around with nss, and found that my loopback interface ip >> doesn't appear from nss-myhostname. >> Rather, my other ones do. >> Furthermore, unless I request IPv4, link-local IPv6 addresses are >> returned. Is this expected? > > We order the returned addresses by scope. Global addresses are > placed first, local ones last. Then why are link local IPv6 addresses returned first? If this was the case, I would expect to see: 192.168.2.229 192.168.2.21 fe80::aed1:b8ff:fec0:d113 fe80::9eeb:e8ff:fe1b:f42d 127.0.0.1 ::1 > We return addresses on the loopback device only when there's no other > address known. What's the rationale for this? (i.e. why not always just include 127.0.0.1 and ::1 last?) > And even then we'll return 127.0.0.2 rather than > 127.0.0.1, to avoid confusing software that expects "localhost" mapping > only to 127.0.0.1 and vice versa. > > Also see nss-myhostname(8). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] nss-myhostname: why don't loopback interfaces appear?
I was playing around with nss, and found that my loopback interface ip doesn't appear from nss-myhostname. Rather, my other ones do. Furthermore, unless I request IPv4, link-local IPv6 addresses are returned. Is this expected? $ uname -n daurn-m3800 $ getent hosts daurn-m3800 fe80::aed1:b8ff:fec0:d113 daurn-m3800 fe80::9eeb:e8ff:fe1b:f42d daurn-m3800 $ getent ahostsv4 daurn-m3800 192.168.2.229 STREAM daurn-m3800 192.168.2.229 DGRAM 192.168.2.229 RAW 192.168.2.21STREAM 192.168.2.21DGRAM 192.168.2.21RAW $ getent ahostsv6 daurn-m3800 fe80::aed1:b8ff:fec0:d113 STREAM daurn-m3800 fe80::aed1:b8ff:fec0:d113 DGRAM fe80::aed1:b8ff:fec0:d113 RAW fe80::9eeb:e8ff:fe1b:f42d STREAM fe80::9eeb:e8ff:fe1b:f42d DGRAM fe80::9eeb:e8ff:fe1b:f42d RAW # For reference, my current network setup: $ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: wlp6s0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether ac:d1:b8:c0:d1:13 brd ff:ff:ff:ff:ff:ff inet 192.168.2.229/24 brd 192.168.2.255 scope global dynamic wlp6s0 valid_lft 64025sec preferred_lft 64025sec inet6 fe80::aed1:b8ff:fec0:d113/64 scope link valid_lft forever preferred_lft forever 5: enp0s20u2u4u4: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 9c:eb:e8:1b:f4:2d brd ff:ff:ff:ff:ff:ff inet 192.168.2.21/24 brd 192.168.2.255 scope global dynamic enp0s20u2u4u4 valid_lft 64025sec preferred_lft 64025sec inet6 fe80::9eeb:e8ff:fe1b:f42d/64 scope link valid_lft forever preferred_lft forever ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] nspawn/networkd: moving from iptables to nftables
On 2 June 2015 at 06:11, Ian Pilcher wrote: > Is this going to make nspawn/networkd fundamentally incompatible with > distributions that use iptables-based tools (such as firewalld)? nftables provides a backward compatible 'iptables' command. Most services (including firewalld) just use the 'iptables' command line program, and hence should continue to work. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] cgtop: support time header with user-specified format string
On 28 May 2015 at 09:58, Filipe Brandenburger wrote: > Though I'm not sure whether taking a strftime format as a command line > argument is really a good idea... But I'll defer that to other > reviewers. From working with lua, I recall that accepting arbitary strftime format strings is unsafe in general. Behaviour for non-spec'd format specifiers is undefined. However, all of the linux libcs handle it correctly. ==> I remember that Microsoft's libc in particular had issues. Of course, this isn't an issue for systemd (as it's linux only), so it's more of a theoretical concern. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/5] systemd-importd - support for pulling from V2 Dkr registries
On 8 May 2015 at 01:46, Pavel Odvody wrote: > - To access the V2 registry we need to send a special User-Agent >docker/1.6.0 Is this really required? Can we request they change something server side? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
On 13 April 2015 at 07:12, Cameron Norman wrote: > On Fri, Apr 10, 2015 at 5:17 AM, Tomasz Bursztyka > wrote: >> Hi, >> >> [snip] >> >> As a notice, this is nothing new. Such standalone daemon has been already >> done by the past, pacrunner. systemd-proxy-discoveryd will more or less >> implement the same ideas with improvements. It will get rid of big JS >> engines like spidermonkey or v8 which are overkill for the tiny PAC files >> to be executed on, for instance. From pacrunner experience, APIs will be >> also improved. >> >> This one is using - at least in this RFC - the duktape JS engine to run >> the PAC files. Note it is not provided in this patchset. Latest version >> 1.2.x was used. >> > > It seems that duktape is really not in a suitable shape to be packaged > in distributions (https://github.com/svaarala/duktape/issues/94). Do > you have any plans to get it into shape? > > Also, and I am just curious, what is the specific reasoning duktape is > preferred? Smaller memory footprint? > > Thanks, > -- > Cameron Norman Have you looked into MuJS instead of duktape? http://mujs.com/ It has a C api similar to Lua, with all state encapsulated in an opaque structure, that you interface with via a virtual stack. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug blocking service start?
On 27 March 2015 at 13:32, Kai Hendry wrote: > It's still getting stuck with Type=simple. > > http://s.natalian.org/2015-03-27/simple.png > > Isn't there a better way to debug than running journalctl -u > -f in parallel? > > The frustrating thing is that the SAME service file works fine on > another rpi2. What does your .service file currently look like? My first guess based on that screenshot is case: Simple vs simple. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] order of sd_journal_query_unique()?
On 6 March 2015 at 14:38, Daurnimator wrote: > sd_journal_query_unique() finds unique *field names*. > Not journal entries. Apologies, I described this incorrectly. sd_journal_query_unique() takes a field name, and allows you to iterate over all different values that field has taken. To accomplish a wildcard or pattern matched search, you can iterate through unique fields, adding all that meet your pattern as matches. Here is an example lua program that will print (in reverse) matches for the given field and (lua) pattern: #!/usr/bin/env lua --[[ Depends on lua-systemd: https://github.com/daurnimator/lua-systemd ]] local sj = require "systemd.journal" local field = assert(arg[1], "need to provide field name") local patt = assert(arg[2], "need to provide a pattern") local j = assert(sj.open()) assert(j:seek_tail()) assert(j:flush_matches()) local has_at_least_one = false for value in j:each_unique(field) do if value:match(patt) then has_at_least_one = true assert(j:add_match(field.."="..value)) end end if not has_at_least_one then io.stderr:write("no matches found\n") os.exit(1) end assert(j:add_disjunction()) while j:previous() do print(j:get("_SYSTEMD_UNIT"), j:get("MESSAGE")) end ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] tmpfiles: port to unquote_many_words()
--- TODO| 2 -- man/tmpfiles.d.xml | 2 ++ src/tmpfiles/tmpfiles.c | 21 +++-- 3 files changed, 9 insertions(+), 16 deletions(-) diff --git a/TODO b/TODO index 60efaaf..4d5e2b6 100644 --- a/TODO +++ b/TODO @@ -226,8 +226,6 @@ Features: * exponential backoff in timesyncd and resolved when we cannot reach a server -* tmpfiles: port to unquote_many_words(), similar to sysusers - * unquote_many_words() should probably be used by a lot of code that currently uses FOREACH_WORD and friends. For example, most conf parsing callbacks should use it. diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml index 4bd0fcf..bc98d8b 100644 --- a/man/tmpfiles.d.xml +++ b/man/tmpfiles.d.xml @@ -118,6 +118,8 @@ d/run/user 0755 root root 10d - L/tmp/foobar ---- /dev/null +Fields may be enclosed within quotes and contain C-style escapes. + Type diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c index 652fe5f..10c5a63 100644 --- a/src/tmpfiles/tmpfiles.c +++ b/src/tmpfiles/tmpfiles.c @@ -1506,23 +1506,25 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) { _cleanup_(item_free_contents) Item i = {}; ItemArray *existing; Hashmap *h; -int r, c = -1, pos; +int r, pos; bool force = false, boot = false; assert(fname); assert(line >= 1); assert(buffer); -r = sscanf(buffer, - "%ms %ms %ms %ms %ms %ms %n", +r = unquote_many_words(&buffer, &action, &path, &mode, &user, &group, &age, - &c); -if (r < 2) { + &i.argument, + NULL); +if (r < 0) +return log_error_errno(r, "[%s:%u] Failed to parse line: %m", fname, line); +else if (r < 2) { log_error("[%s:%u] Syntax error.", fname, line); return -EIO; } @@ -1559,15 +1561,6 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) { return r; } -if (c >= 0) { -c += strspn(buffer+c, WHITESPACE); -if (buffer[c] != 0 && (buffer[c] != '-' || buffer[c+1] != 0)) { -i.argument = unquote(buffer+c, "\""); -if (!i.argument) -return log_oom(); -} -} - switch (i.type) { case CREATE_FILE: -- 2.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: port to unquote_many_words()
--- TODO| 2 -- man/tmpfiles.d.xml | 2 ++ src/tmpfiles/tmpfiles.c | 24 ++-- 3 files changed, 12 insertions(+), 16 deletions(-) diff --git a/TODO b/TODO index 60efaaf..4d5e2b6 100644 --- a/TODO +++ b/TODO @@ -226,8 +226,6 @@ Features: * exponential backoff in timesyncd and resolved when we cannot reach a server -* tmpfiles: port to unquote_many_words(), similar to sysusers - * unquote_many_words() should probably be used by a lot of code that currently uses FOREACH_WORD and friends. For example, most conf parsing callbacks should use it. diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml index 4bd0fcf..c1c4a44 100644 --- a/man/tmpfiles.d.xml +++ b/man/tmpfiles.d.xml @@ -118,6 +118,8 @@ d/run/user 0755 root root 10d - L/tmp/foobar ---- /dev/null +Fields can contain C-style escapes + Type diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c index 652fe5f..e6ee5b8 100644 --- a/src/tmpfiles/tmpfiles.c +++ b/src/tmpfiles/tmpfiles.c @@ -1502,27 +1502,30 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) { {} }; -_cleanup_free_ char *action = NULL, *mode = NULL, *user = NULL, *group = NULL, *age = NULL, *path = NULL; +_cleanup_free_ char *action = NULL, *mode = NULL, *user = NULL, *group = NULL, *age = NULL, *path = NULL, *argument = NULL; _cleanup_(item_free_contents) Item i = {}; ItemArray *existing; Hashmap *h; -int r, c = -1, pos; +int r, pos; bool force = false, boot = false; assert(fname); assert(line >= 1); assert(buffer); -r = sscanf(buffer, - "%ms %ms %ms %ms %ms %ms %n", +r = unquote_many_words(&buffer, &action, &path, &mode, &user, &group, &age, - &c); -if (r < 2) { + &argument, + NULL); +if (r < 0) { +log_error_errno(r, "[%s:%u] Failed to parse line: %m", fname, line); +return r; +} else if (r < 2) { log_error("[%s:%u] Syntax error.", fname, line); return -EIO; } @@ -1559,14 +1562,7 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) { return r; } -if (c >= 0) { -c += strspn(buffer+c, WHITESPACE); -if (buffer[c] != 0 && (buffer[c] != '-' || buffer[c+1] != 0)) { -i.argument = unquote(buffer+c, "\""); -if (!i.argument) -return log_oom(); -} -} +i.argument = argument; switch (i.type) { -- 2.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] order of sd_journal_query_unique()?
On 6 March 2015 at 16:13, Chris Morgan wrote: > So is SD_JOURNAL_FOREACH_BACKWARDS the fastest way to find the newest > journal entry with a given field? journalctl seems a ton faster than > my c application is when I search for a given field that is not > present. And by search I'm doing: > > journalctl --user BLAH=1 > > Chris To find the newest journal entry: - sd_journal_seek_tail - sd_journal_add_match and similar to add criteria - sd_journal_previous ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] order of sd_journal_query_unique()?
On 6 March 2015 at 14:25, Chris Morgan wrote: > I was using a journal iterator to search from the newest journal entry > backwards for a matching field, using SD_JOURNAL_FOREACH_BACKWARDS. > This appears to be pretty slow but journalctl is really fast. I went > looking and found sd_journal_query_unique() (although I'm not 100% > positive this is why journalctl is faster). > > Looking at > http://www.freedesktop.org/software/systemd/man/sd_journal_query_unique.html > there isn't any mention of ordering or direction. > > Is this search finding journal entries that are newest to oldest or??? sd_journal_query_unique() finds unique *field names*. Not journal entries. ___ 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
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 On 2 March 2015 at 17:45, Erik Johnson wrote: > The machinectl pull-* commands allow you to download container images, > but no such option (yet) exists for deploying from an image or tar file > on your local filesystem. > > Are there plans to expand the machinectl pull-* commands to support > either absolute file paths or file:/// URLs? > > My current dirty hack is to run an nginx instance that listens only on > localhost, and pull from http://localhost/path/to/container.tar.gz, but > this is far from ideal. > > -- > > Erik Johnson | Senior Engineer > > 3400 North Ashton Blvd, Suite 110 | Lehi, UT 84043 > e...@saltstack.com | http://saltstack.com > > ___ > 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] looking for an 'uptime' value from a journal entry
On 25 February 2015 at 20:50, Chris Morgan wrote: > From > http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#__MONOTONIC_TIMESTAMP= > it looks like __MONOTONIC_TIMESTAMP might be just what I'm looking for > but the information at the start of that section has me wondering if I > can rely on this __MONOTONIC_TIMESTAMP being present for all entries > and use this as the system uptime. > Those three fields will always be present. They are not *in* the data, but metadata kept for every journal entry. At the libsystemd level, you access them via their own apis, see http://www.freedesktop.org/software/systemd/man/sd_journal_get_cutoff_monotonic_usec.html Please refer to `man 2 clock_gettime` on whether CLOCK_MONOTONIC suits your needs for an 'uptime' clock. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-run fails with certain properties
Trying to use systemd-run with certain properties consistently fails, e.g.: $ systemd-run --scope --nice 18 --property=NoNewPrivileges=true echo test Unknown assignment NoNewPrivileges=true. Failed to create bus message: No such device or address $ systemd-run --scope --user --nice 18 -p User=nobody echo hi Failed to create bus message: Read-only file system ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/shared
On 20 October 2014 15:11, Lennart Poettering wrote: > On Wed, 15.10.14 01:58, Michal Sekletar (msekl...@kemper.freedesktop.org) > wrote: > > -mycon = context_str(bcon); > > +mycon = strdup(context_str(bcon)); > > This looks wrong! > > I meanm what is mycon? a string or a security_context_t? If it's the > latter (which it appears to be according to its type), then it should > not be assigned a string as returned by strdup(). (i figure internally > they might be the same, but if they do the dance with two distinct > types we should follow this non-sense here too...) > >From man page: const char * context_str(context_t con ); context_str Return a pointer to the string value of the context_t Valid until the next call to context_str or context_free for the same context_t* This diff seems to simply be copying the string, so that it does not become > invalid. > Shouldn't this be context_new() rather than strdup()? > > libselinux definitely has one of the most horrible APIs around! Yuck, > just yuck! Confusingly, mycon is a 'security_context_t', which is defined as: typedef char *security_context_t; I'm not sure what additional conversion is recommended/possible here. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] odd seek_tail behaviour
On 13 October 2014 07:22, Sascha Kattelmann wrote: > here is a related "bug" report: > https://bugs.freedesktop.org/show_bug.cgi?id=64614 sd_journal_next() is documented as returning '0' if there are no more entries available after the current position. So this sounds like a bug to me. > Doing a "next" after "seek_tail" ends up in some unexpected behaviour. > Just do a "previous" after seeking the tail and everything works fine. > The problem is symmetrical: Same goes for "previous" after "seek_head". > You need to do a "next" immediately after "seek_head". > If this is the API contract; why not perform "next's" functionality inside of seek_head? Thanks for the work around. I just commited an example script: https://github.com/daurnimator/lua-systemd/blob/master/examples/tail_logs.lua ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] odd seek_tail behaviour
Hi All, I was trying to write a program that tailed the journal, but found that sd_journal_seek_tail() didn't work as expected. That is: that it would seek to the last/most recent thing in the journal, and I could tail things from there. I whipped up a quick demonstration program, that shows that messages I 'next' through, are before the 'cutoff': #include #include #include "systemd/sd-journal.h" int main() { sd_journal* j; assert(sd_journal_open(&j, 0)==0); uint64_t from, to; assert(sd_journal_get_cutoff_realtime_usec(j, &from, &to)==1); printf("CUTOFF = %llu\n", to); printf("TAIL = %d\n", sd_journal_seek_tail(j)); for (int i=0; i<10; i++) { printf("NEXT = %lld\n", sd_journal_next(j)); assert(sd_journal_get_realtime_usec(j, &from)==0); printf("FOUND from %llu\n", from); } return 0; } Compiled with: gcc -std=c99 tail_logs.c -l systemd Example output: CUTOFF = 1413177397982789 TAIL = 0 NEXT = 1 FOUND from 1400437372012374 NEXT = 1 FOUND from 1400438753925868 NEXT = 1 FOUND from 1400438753926192 NEXT = 1 FOUND from 1400438753926257 NEXT = 1 FOUND from 1400438753926289 NEXT = 1 FOUND from 1400438753926309 NEXT = 1 FOUND from 1400438753926330 NEXT = 1 FOUND from 1400438753926353 NEXT = 1 FOUND from 1400438753926373 NEXT = 1 FOUND from 1400438753926395 Is this behaviour expected? I'm using systemd 216. Regards, Daurn. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Intent to remove readahead from systemd
On 25 September 2014 10:44, Tom Gundersen wrote: > I pushed the patch deleting it. Please ensure http://www.freedesktop.org/software/systemd/man/sd-readahead.html is updated ASAP with a deprecation note. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: allow customizable output formats
On 22 September 2014 11:33, Daniel P. Berrange wrote: > The current '--output FORMAT' argument defines a number of > common output formats, but there are some useful cases it > does cover. In particular when reading application logs it > is often desirable to display the code file name, line number > and function name. Rather than defining yet more fixed output > formats, this patch introduces user defined output formats. > > The format string is an arbitrary string which contains a > mixture of literal text and variable subsistitions. Each > variable name corresponds to a journal field name. A variable > name can be optionally followed by a data type, and in the > case of string types, a length limit. > As an opposing point of view, I've been accomplishing this by piping output through a script that parses and displays JSON. I rather this style of composability than passing format strings to journalctl itself. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel