Re: [systemd-devel] 'is-enabled' supported for legacy sysvinit scripts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 В Sun, 12 Apr 2015 21:00:38 + Nusenu пишет: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, > > I'm trying to find out whether I'm looking at an ansible or systemctl > bug. > > Does systemctl aim to support the 'is-enabled' command for legacy sysv > initscripts? > systemctl should still support it if your system supports chkconfig to manage initscripts. > Output in such cases: > > "Failed to get unit file state for FOO.service: No such file or director > y" > > > Context: ansible uses 'is-enabled' to find out about the current state > of a service. In such cases it always believes the service is disabled > already due to systemctl's return code. > > I had a short look at: > http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ > but I didn't find an answer to my question. > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlUrS0wACgkQR6LMutpd94yxWwCgmcbREiJ8u29HMzSe3tPQzQMc jXoAnR+Rimc17TPzd22Jb9jrJ+ImXrah =xeWl -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
В Sun, 12 Apr 2015 12:12:45 -0700 lynd...@your-mail.com пишет: > Hi Lennart > > On Sun, Apr 12, 2015, at 11:06 AM, Lennart Poettering wrote: > > This looks like Fedora/Red Hat initscripts networking? > > Close; same style. But it's opensuse networking. > > > If so, please file a bug against the initscripts package. It's up to > > the networking management solution to fill network-line.target with > > something useful, and in your case that appears to be the initscripts > > implementation. > > Since I wasn't sure where the problem starts, I'd got that already going here > > Bug 926835 - sshd.service (openssh) fails on boot when primary listener is a > bridge (br0) instead of real interface (eth0) > https://bugzilla.opensuse.org/show_bug.cgi?id=926835 > > So far the advice there is to increase the value of WAIT_FOR_INTERFACES in > /etc/sysconfig/network/config from 30 sec to > 40 secs. > > Seems to me that there should be *some* real check for the 'up' state of the > bridge, not just "waiting long enough" and hoping. You need to have upper limit, otherwise your system will hang indefinitely when booting if interface is not present. Today we probably can remove this upper limit in networking layer and simply rely on systemd standard timeout. In any case - you managed to NEVER say whether increasing above mentioned timeout solved your problem or not. Neither here not in bug report. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sun, Apr 12, 2015 at 07:19:07PM +0200, Lennart Poettering wrote: > On Sun, 12.04.15 14:11, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > I'm wondering if we should provide better per-user tmpfiles support. > > For example, if we allowed a set of "user" tmpfiles, which would > > be executed by the system instance, but would be considered relative to > > the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home > > directory, > > %t to XDG_RUNTIME_DIR, ...). We would execute that for every user. > > I'd be careful with this. I mean, I generally think that the fact that > we need tmpfiles is not a strength, but really just a work-around > for limitations of Linux. The tool covers four major usecases: > > 1. set up the work environment for daemons which are too dumb to do >this on their own > > 2. set up the work environment for daemins that never run privileged, >and hence cannot set up their work environment > > 3. Reserve a few file/directory names, to avoid namespace clashes in >world-writable directories. Most notably that's the X11 stuff in >/tmp. > > 4. Do "aging/clean-up" of /tmp. > > Now, of these the first item is a work-around for broken daemons, and > this should really be better fixed in the daemons themselves. A daemon > that does not require tmpfiles is a good daemon. The third item is a > work-around against really broken semantics of X11, that cannot really > be fixed without breaking compat... But this issue is certainly not > something new code will fall for (hopefully)... The fourth item is a > work-around for broken semantics of UNIX, where files cannot be bound > to proper lifecycles of other objects, such as processes... "Aging" > these dirs is actually really nasty, since its cleanups are in no way > bound to the actual algorithms creating the files: code that generates > a lot of files in a short time, will be cleaned up only much later, > when the tmpfiles job happens to runs again... But /tmp is also used for shared state (between services, but also between different applications run by the same user, different sessions of the same user, etc.). Such files are not bound to any process, or any session, and should not be. For example, when I download stuff I often stick it in /tmp, so that it stays around if I need it, but goes away without me taking any concious action after some time. Gnome's thumbnails are a bit like this: they are not bound to the life cycle of anything, we just want them to go away when they have not been used for a while. The application which creates thumbnails (or other similar caches) *should* take care to not use to much space when creating things rapidly. I assume that gnome does that already. But the application cannot really implement good time based cleanup, especially that time based cleanup is especially useful when the application is *not* running. I'm aware of various short-comings of shared spaces and time-based cleanup, but I don't think there's a better alternative for many cases. Or more precisely: it works best for cooperative sharing, where various entities involved are not malign, but not omniscient either. [snip] > The fact that tmpfiles exists is sad, and we shouldn't add this to the > session, so that the same sad practices we see on system daemons are > also adopted by desktop software... Agreed, for 1-3, but not yet for 4. > Moreover, I'd always be careful with adding privileged code that > operates on unprivileged files, based on unprivileged configuration. I > mean, the cleaning of /tmp has always been a source of security > issues, it's really hard not to do things wrong when operating as > privileged code on unprivileged files (think symlink attacks!), but > it's a whole new dimension of risk, if we not only operate on those > unprivileged files, but also use unprivileged user-supplied configuration... > > Hence, if this is done at all, it really should be the user's code > that runs this, not the system code. Well, the whole discussion started with the fact that this cannot be implemented as user code without being crippled. > > gnome could possibly replace its custom thumbnails cleaner with a few > > lines of tmpfiles config. There would be two advantages: creation time > > cleanup could be replaced with access time cleanup, cleanup wouldn't > > be dependent on the session running. > > I think it would be a good idea if the thumbnailing code of GNOME > would clean up the thumbnails stuff properly on its own, and that from > the same code that writes the thumbnails, in a similar way as journald > keeps track of its journal directory. That's the only way to make this > robust: don't clean it up triggered on time, but closely bound to the > algorithm that might fill it up. sd-journald is a bit different: it is always around, and is important for security, so normal "cooperative" cleanup rules don't apply to it. OTOH, there are many user space caches (browser cache, image viewe
Re: [systemd-devel] sd_event_run
On Sun, Apr 12, 2015 at 06:42:45PM +0200, Lennart Poettering wrote: > On Sat, 11.04.15 23:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > On Fri, Apr 10, 2015 at 06:14:40PM +0200, Lennart Poettering wrote: > > > On Sat, 14.03.15 12:19, Tom Gundersen (t...@jklm.no) wrote: > > > > > > > > 1. shouldn't SD_EVENT_PASSIVE become SD_EVENT_INITIAL? "passive" > > > > > seems strange > > > > >in this context. > > > > > > I found it weird to name this INITIAL (or "INIT" or something like > > > that) since we would return to it every single iteration... For me > > > "init" kinda implies it's something "fresh", "unused", and hence not > > > really something we routinely come back to... > > In a sense it is "fresh" and "unused", because the state after doing > > an interation of the loop is exactly the same as if the loop never run. > > (E.g. I don't think it would be wrong to say "I cleaned the couch and > > restored it to its initial state", even though it obviously has been used.) > > > > "Passive" was confusing, so "initial", even if imperfect, seems an > > improvement. We really want to say "the state in which you started", > > without implying whether we have been there the whole time or not. > > I don't know if there's a better word. > > glib calls the respective state "initial" btw... I didn't like the > name though, when I got inspiration from it... > > > > > >Similarly, SD_EVENT_ARMED seems more self-explanatory than > > > > > PREPARED. > > > > >(I don't like PREPARED because it is not obvious whether sources > > > > > are > > > > >prepared to wait on, or events are prepared to be reaped.) > > > > > > I called this "prepared" since it what's _prepare() is supposed to get > > > into... > > > > > > But ARMED is fine too... > > > > We really should get some native speakers to help out with this :) > > > > Maybe sd_event_prepare should be renamed to sd_event_arm? > > The "prepare" state I stole from glib: > > https://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html > > It's probably a good idea to not invent new naming here, if glib > already established the name. OK. I added the link you posted to sd_event_run(3) — it might be a useful resource for somebody trying to wrap their head around this. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/6] network: fix strict aliasing issue
On Sun, Apr 12, 2015 at 12:43 PM, Lennart Poettering
wrote:
> On Wed, 11.03.15 08:13, Shawn Landden (sh...@churchofgit.com) wrote:
>
>> We shouldn't assume 64-bit arch with the way we do math either.
>> (although I will submit a patch to glibc to add a uint64_t union
>> alias)
>
> Hmm? uint64_t works fine on 32bit too. The compiler can do the
> necessary emulation on its own... I don't see the need to change
> anything here.
Its also an unaligned access. in_addr.in6 is only 32-bit aligned. (in
addition to being a strict aliasing violation.)
>
>> diff --git a/src/network/networkd-address.c b/src/network/networkd-address.c
>> index 0be6165..4b7f451 100644
>> --- a/src/network/networkd-address.c
>> +++ b/src/network/networkd-address.c
>> @@ -605,12 +605,12 @@ bool address_equal(Address *a1, Address *a2) {
>> }
>>
>> case AF_INET6: {
>> -uint64_t *b1, *b2;
>> +uint32_t *b1, *b2;
>>
>> -b1 = (uint64_t*)&a1->in_addr.in6;
>> -b2 = (uint64_t*)&a2->in_addr.in6;
>> +b1 = &a1->in_addr.in6.s6_addr32[0];
>> +b2 = &a2->in_addr.in6.s6_addr32[0];
>>
>> -return (((b1[0] ^ b2[0]) | (b1[1] ^ b2[1])) == 0UL);
>> +return (((b1[0] ^ b2[0]) | (b1[1] ^ b2[1]) | (b1[2] ^
>> b2[2]) | (b1[3] ^ b2[3])) == 0);
>> }
>>
>> default:
>> --
>> 2.2.1.209.g41e5f3a
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Shawn Landden
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] efi-boot-generator: Continue if /boot does not exist
On Sun, Apr 12, 2015 at 06:49:41PM +0200, Lennart Poettering wrote:
> On Sat, 11.04.15 02:13, Tobias Hunger (tobias.hun...@gmail.com) wrote:
>
> > /boot does not exist on a stateless system, so do not get
> > confused by that.
> > ---
> > src/efi-boot-generator/efi-boot-generator.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/efi-boot-generator/efi-boot-generator.c
> > b/src/efi-boot-generator/efi-boot-generator.c
> > index 58c4cc2..5a9bfd3 100644
> > --- a/src/efi-boot-generator/efi-boot-generator.c
> > +++ b/src/efi-boot-generator/efi-boot-generator.c
> > @@ -68,7 +68,10 @@ int main(int argc, char *argv[]) {
> > return EXIT_SUCCESS;
> > }
> >
> > -if (path_is_mount_point("/boot", true) <= 0 &&
> > +r = path_is_mount_point("/boot", true);
> > +if (r == -ENOENT) {
> > +log_debug("/boot does not exist, continuing.");
> > +} else if (r <= 0 &&
> > dir_is_empty("/boot") <= 0) {
> > log_debug("/boot already populated, exiting.");
> > return EXIT_SUCCESS;
>
> This was merged by Zbigniew earlier today.
Yeah, sorry I forgot to write to the mailing list.
I reformatted the patch a bit, I think it is more readable without
splitting the condition in two lines.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Sun, Apr 12, 2015 at 02:12:06PM -0700, lynd...@your-mail.com wrote: > Hi > > On Sun, Apr 12, 2015, at 02:08 PM, Cameron Norman wrote: > > It's probably just a race that you see with the bridge because the > > bridge is up at a later time than the ethernet device. > > I guess that's kindof the point here. > > Using network.target and network-online.target doesn't apparently cause a > unit's exec to wait for the race to resolve, and for the specific bridge(s) > to be up. > > If those targets don't, is there one that does? It was already pointed out by Lennart above in this thread, but let me try again: network-online.target provides a point after which servcies can be ordered, but it is up to individual services which bring up the network (e.g. NetworkManager, systemd-networkd, ...) to order themselves before this target. The target by itself is meaningless, it needs support from the servcie managing the network. Like Reindl and others pointed out above, waiting for the network to be "up" is in general the wrong thing to do. IP_FREEBINDand/or listening on 0.0.0.0. are much better solutions. But if you really want the ordering, figure out what needs to be done for the network managing service that you are using to do this. For example, for NetworkManager you need to enable NetworkManager-wait-online.service, for systemd-network you need to enable systemd-networkd-wait-online.service, etc. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] input_id: Identify scroll-wheel device on Trust TB7300 tablet as keyboard
On Sat, Apr 11, 2015 at 03:27:46PM +0200, Hans de Goede wrote: > The Trust TB7300 (relabelled Waltop?) tablet has a scrollwheel which shows > up as a /dev/input/event# node all by itself. Currently input_id does not > set any ID_INPUT_FOO attr on this causing it it to not be recognized by > Xorg / libinput. > > This commit fixes this by marking it with ID_INPUT_KEY. > > Cc: Sjoerd Timmer > Reported-by: Sjoerd Timmer > Signed-off-by: Hans de Goede > --- > src/udev/udev-builtin-input_id.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/src/udev/udev-builtin-input_id.c > b/src/udev/udev-builtin-input_id.c > index ecfc447..f07f86e 100644 > --- a/src/udev/udev-builtin-input_id.c > +++ b/src/udev/udev-builtin-input_id.c > @@ -262,6 +262,13 @@ static int builtin_input_id(struct udev_device *dev, int > argc, char *argv[], boo > test_pointers(dev, bitmask_ev, bitmask_abs, bitmask_key, >bitmask_rel, bitmask_props, test); > test_key(dev, bitmask_ev, bitmask_key, test); > +/* > + * The scrollwheel on some devices is a device all by itself, > + * treat this as a keyboard with just a scrollwheel. > + */ > +if (bitmask_ev[0] == (BIT(EV_REL) | BIT(EV_SYN)) && > +bitmask_rel[0] == (bitmask_rel[0] & (BIT(REL_WHEEL) | > BIT(REL_HWHEEL > +udev_builtin_add_property(dev, test, "ID_INPUT_KEY", > "1"); A simpler approach would be to return a value from test_pointers() if we set anything there and then use that: is_pointer = test_pointers(.); is_keyboard = test_key(); if (!is_pointer && !is_keyboard && test_bit(EV_REL) && (test_bit(REL_WHEEL) || test_bit(REL_HWHEEL))) udev_builtin_add_property(); I also wonder what the side effect is of setting ID_INPUT_KEY on a device without EV_KEY but I can't really come up with a better tag (short of introducing a completely new one). Cheers, Peter > } > > devnode = udev_device_get_devnode(dev); > -- > 2.3.4 > ___ 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] [PATCH 6/6] hwdb: set the resoluton for a couple of bcm5974 touchpads
On Tue, Apr 07, 2015 at 12:08:00PM +0200, David Herrmann wrote: > Hi > > On Mon, Mar 23, 2015 at 2:30 AM, Peter Hutterer > wrote: > > Verified for the 5,1 Macbook, the others are guesses based on the list of > > supported devices of the moshi trackpad protector. > > http://www.moshi.com/trackpad-protector-trackguard-macbook-pro#silver > > > > Resolution calculated based on the min/max settings set in the kernel > > driver, > > divided by the physical size. This is probably slightly off, but still > > better > > than no resolution at all. > > > > Signed-off-by: Peter Hutterer > > --- > > hwdb/60-evdev.hwdb | 40 > > 1 file changed, 40 insertions(+) > > > > diff --git a/hwdb/60-evdev.hwdb b/hwdb/60-evdev.hwdb > > index 0d67f87..9a9018f 100644 > > --- a/hwdb/60-evdev.hwdb > > +++ b/hwdb/60-evdev.hwdb > > @@ -35,3 +35,43 @@ > > # fields of the struct input_absinfo as listed in linux/input.h. > > # If a field is missing the field will be left as-is. Not all fields need > > to > > # be present. e.g. ::45 sets the resolution to 45 units/mm. > > + > > +# Macbook5,1 (unibody), aka wellspring3 > > +evdev:input:b0003v05ACp0236* > > +evdev:input:b0003v05ACp0237* > > +evdev:input:b0003v05ACp0238* > > + EV_ABS_OVERRIDE_00=::92 > > + EV_ABS_OVERRIDE_01=::90 > > + EV_ABS_OVERRIDE_35=::92 > > + EV_ABS_OVERRIDE_36=::90 > > So the keyboard properties were prefixed by our fake subsystem > 'KEYBOARD_', and the entry we change 'KEY_foobar'. Can we do the same > for the ABS override? 'EVDEV_ABS_foo=bar'? > I don't think 'override' should be in the name. The hwdb simply stores > axis information, it's the hwdb-user (builtin-input_id) which decides > to override device-values with the hwdb-values. The hwdb doesn't > define the policy. > > Anyway, patches 4+5+6 look good to me! If Kay doesn't have any ideas > for a better prefix than 'EVDEV_', I think you can go ahead an push > it. for the archives: pushed, commits up to 3ebc2dc49837e38288e1 Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Check if systems is container in "systemd-remount-fs.service"
On 2015-04-09 at 10:04 +0200, Lennart Poettering wrote: > [...] > Also, current versions of fstab-generator skip device entries in > containers anyway, so I am not sure how you even managed to generate > an error in this case, unless you run a really old version of > systemd. Hmm, well, systemd-remount-fs.service is enabled statically, it doesn't use systemd-fstab-generator... -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: don't complain about audit socket errors in a container.
I'm terribly sorry for the broken patch. The webmailer messed up. You can find the clean patch here https://clbin.com/0BhmC to make sure the webmailer won't interfere again. I'm terribly sorry for the inconvenience and promise to look for a better mail provider that allows me to directly use smtp so I can use git send-mail. Best Regards, Frank. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] automount: add expire support
On Sun, 12.04.15 22:33, Jan Luca Naumann (j.naum...@fu-berlin.de) wrote: > Hey Michael, > > it is very nice that you add this missing but useful feature :-) > > I'm not a systemd-developer so I want to ask you if it is possible to > add a hook for execute something after the unmount (for example to > delete the mount directory)? Well, we don't really want logic like that in systemd I fear. Generally, with mounts we want to ensure that invoking /bin/mount or /bin/umount on a directory isn't too different in its effect than executing the same operations with systemd's own logic using "systemctl". That said, I must be convinced that we should add a high-level setting to mount units for removing directories after umount. Can you elaborate on the usecase please? 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] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
Hi On Sun, Apr 12, 2015, at 02:08 PM, Cameron Norman wrote: > It's probably just a race that you see with the bridge because the > bridge is up at a later time than the ethernet device. I guess that's kindof the point here. Using network.target and network-online.target doesn't apparently cause a unit's exec to wait for the race to resolve, and for the specific bridge(s) to be up. If those targets don't, is there one that does? LT ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Sun, Apr 12, 2015 at 12:49 PM, Lennart Poettering wrote: > On Sun, 12.04.15 12:35, lynd...@your-mail.com (lynd...@your-mail.com) wrote: > >> If interface:IP = eno1:192.168.1.1, then it's all good. >> >> But, if interface:IP = br0(attached to eno1):192.168.1.1, then there's a >> fail of sshd.service on boot. > > Hmm? why that? why does sshd care? What precisely fails? I mean, if > the ip addres 192.168.1.1 is bound to a local interface, then sshd > really should work, it shouldn't matter what kind of interface that > is. It's probably just a race that you see with the bridge because the bridge is up at a later time than the ethernet device. -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal: don't complain about audit socket errors in a container.
This fixes an issue within journald aborting when running inside
archlinux container via systemd-nspawn on a debian host with audit
enabled kernel.
The journald binary in the archlinux container would try to bind an
audit netlink socket which isn't allowed from within containers.
The failed bind call then leads to a abort of journald which in turn
disables loggingfor the whole container.
This commit fixes this by logging and ignoring the EPERM error raised
from the kernel after the bind call if it detects that it's running
inside a container.
---
src/journal/journald-audit.c | 8 +++-
src/journal/journald-server.c | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/journal/journald-audit.c b/src/journal/journald-audit.c
index 46eb82f..1b36984 100644
--- a/src/journal/journald-audit.c
+++ b/src/journal/journald-audit.c
@@ -20,6 +20,7 @@
***/
#include "missing.h"
+#include "virt.h"
#include "journald-audit.h"
typedef struct MapField {
@@ -533,8 +534,13 @@ int server_open_audit(Server *s) {
}
r = bind(s->audit_fd, &http://sa.sa, sizeof(http://sa.nl));
- if (r < 0)
+ if (r < 0) {
+ if (errno == EPERM && detect_container(NULL) > 0) {
+ log_debug("Audit not supported in
containers.");
+ return 0;
+ }
return log_error_errno(errno, "Failed to join audit
multicast group: %m");
+ }
} else
fd_nonblock(s->audit_fd, 1);
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 5e07ce3..21f383a 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1585,9 +1585,11 @@ int server_init(Server *s) {
if (r < 0)
return r;
+#ifdef HAVE_AUDIT
r = server_open_audit(s);
if (r < 0)
return r;
+#endif
r = server_open_kernel_seqnum(s);
if (r < 0)
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] 'is-enabled' supported for legacy sysvinit scripts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I'm trying to find out whether I'm looking at an ansible or systemctl bug. Does systemctl aim to support the 'is-enabled' command for legacy sysv initscripts? Output in such cases: "Failed to get unit file state for FOO.service: No such file or director y" Context: ansible uses 'is-enabled' to find out about the current state of a service. In such cases it always believes the service is disabled already due to systemctl's return code. I had a short look at: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ but I didn't find an answer to my question. thanks, Nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVKtz2AAoJEFv7XvVCELh0VhIP/RaV7gf779K4dzWUYJHA29ks d14KxPa7JPgn9RKfbq+wi1ZE84v+l5g6Gy5lR+3dMwJC8lj2mJxSlRYyynhIpCnf dHpwMAdAMZxgXpRgLBew0wLLbYpV+UjSLwXndqdf0ZJynwyIJAWQvwREo7CZrDXy LKEz1L7iAgSpjLvGyzrTabmZuTHIAlMGns1Q4UMJbMRhgm/wgxpFnKfZERDo5s6b hql4FydFoIQea9b+yIjh3Gid8ymk+SLprPrEtJZeIIlb0yJUj4f5WDfkopGtvqCR Pl1N0q8Lu8bhqHMpczF3MHrpSlm2Hzap89I7dVHFxxiyz2fYqZeJLLRQEoqcKDXO q328JSj1EbL/BZU6qlDf8ykMG4cB/y8t4lE2kvtLO2WsKUhX1zWSkEIPwVwlc0QI WNawRXGoUY2uLT1NuwbQw4LKnABQMWXi+2TOYfgvl/heeRiVUle9/23pWcjofxNk AlUc+CJFEQnc2cmrZdXU/echZPM3V90Uq/ramgUsmI1KiQqMTLoi1wJ9/neiU/hT ZQexWyejCD1vqwTzUVhkUpLg/90ig2C/KbvNpzwRHWSSTVMy62agbOQth6ar99Y8 tUIUHWwXH9txHlEPBGovs951FgDlMbeG6IGseM1j+K14bMMdjmCtNGa7X6JGcDVJ geJYr+PjlhFsIhjOVu1M =jxrl -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
> On Sun, Apr 12, 2015, at 12:49 PM, Lennart Poettering wrote:
> > Hmm? why that? why does sshd care?
opensuse has a convenient interface status tool
rpm -q --whatprovides `which ifstatus `
wicked-service-0.6.17-12.1.x86_64
ifstatus br0
br0 up
link: #6, state up, mtu 1500
type: bridge
config: compat:/etc/sysconfig/network/ifcfg-br0
leases: ipv4 static granted
leases: ipv6 static granted
addr: ipv4 172.30.11.2/22 [static]
addr: ipv6 2001:470:1f05:6a0::2/64 [static]
route:ipv4 default via 172.30.11.100
route:ipv6 default via 2001:470:1f05:6a0::100
In the bridge case, with sshd listening on the br0 IP adddess, with this unit
cat /etc/systemd/system/sshd.service
[Unit]
Description=OpenSSH Daemon
After=syslog.target network.target network-online.target
[Service]
EnvironmentFile=-/etc/sysconfig/ssh
ExecStartPre=/usr/sbin/sshd-gen-keys-start
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
[Install]
WantedBy=multi-user.target
SSHD fails to launch on boot, firing the error I shared above.
But if a force a dependency check
cat << EOF > /usr/local/scripts/wait-for-br0.sh
#!/bin/bash
while [[ \$(ifstatus br0 | grep ^br0 | awk '{print \$2}') !=
'up' ]]; do
sleep 1
done
EOF
cat /etc/systemd/system/sshd.service
[Unit]
Description=OpenSSH Daemon
After=syslog.target network.target network-online.target
[Service]
EnvironmentFile=-/etc/sysconfig/ssh
ExecStartPre=/usr/sbin/sshd-gen-keys-start
+ ExecStartPre=sh /usr/local/scripts/wait-for-br0.sh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
[Install]
WantedBy=multi-user.target
Then reboot, SSHD boots up correctly . It's available as you'd expect.
It sure looks like a depdenency issue.
And even though the unit's waiting for
network.target network-online.target
it doesn't seem to consider br0 being up as prereqs for those targets.
So, if NOT those targets, which one? How do I convince the sshd unit to
correctly wait for BRIDGES being up using systemd's ntaive dependency
management?
Or is the only way to assume that systemd can't detect the bridges and handle
it manually like I did above?
LT
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] automount: add expire support
Hey Michael, it is very nice that you add this missing but useful feature :-) I'm not a systemd-developer so I want to ask you if it is possible to add a hook for execute something after the unmount (for example to delete the mount directory)? Thank you very much and best regards, Jan signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes
Hi Lennart,
On 2015-04-08 20:36, Lennart Poettering wrote:
>> +
>> > +static int path_set_attrib(Item *item, const char *path) {
>> > +_cleanup_close_ int fd = -1;
>> > +int r;
>> > +unsigned f;
>> > +struct stat st;
>> > +
>> > +/* do nothing */
>> > +if (item->attrib_mask == 0 || !item->attrib_set)
>> > +return 0;
>> > +/*
>> > + * It is OK to ignore an lstat() error, because the error
>> > + * will be catch by the open() below anyway
>> > + */
>> > +if (lstat(path, &st) == 0 &&
>> > +!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) {
>> > +return 0;
>> > +}
> Why do we need this check? What happens if we apply this onto
> a device node, or socket, or whatever?
>
> I really don#t like this seperate lstat() + open(). If it all it
> should be open() + fstat(), to avoid TTOCTOU issues...
I am checking your changes; you modified the code above in :
fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
if (fd < 0)
return log_error_errno(errno, "Cannot open '%s': %m", path);
if (fstat(fd, &st) < 0)
return log_error_errno(errno, "Cannot stat '%s': %m", path);
/* Issuing the file attribute ioctls on device nodes is not
* safe, as that will be delivered to the drivers, not the
* file system containing the device node. */
if (!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) {
log_error("Setting file flags is only supported on regular
files and directories, cannot set on '%s'.", path);
return -EINVAL;
}
However the original code catch also the case where the file is a soft-link.
The same check is performed also by chattr(1); I suggest to leave the original
behavior, changing
fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
in
fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_NOFOLLOW);
and checking if the errno is ELOOP. In this case a further check is performed
to
verify if the file is a link or the error is due to a too many symbolic link.
Then an appropriate message error is printed.
What do you think ?
Goffredo
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
___
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
Hi Lennart, > As it has been discussed in the systemd hackfest during the Linux > Conference > Europe, one daemon could centralize the management of all network proxy > configurations. Idea is something user can do per-application (like in > firefox for instance) or broader (per-DM like in Gnome), user could do it > once and for all through such daemon and applications would then request > it > to know whether or not a proxy has to be used and which one. > > 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. Hi, the idea of having centralized proxy config is certainly nice. But the PAC files make me shiver. So the first question: is it really necessary to support PAC files? >>> >>> Yes, it's kinda necessary. PAC is pretty widely used in corporate >>> setting. Windows does the WPAD stuff (the protocol to discover PAD) in >>> all its versions since a long time. In fact, it immediately issues the >>> wpad requests as first thing when you plug in an ethernet cable, in >>> addition to DHCP. >>> Are they widely used in corporate setting or something? Is there no saner standard? >>> >>> Nope, not really, I fear. >>> If the PAC files must be interpreted, I think this is the hardest part. FindProxyForURL is started for every request, potentially hundreds of times per second and more. This means that starting a process per invocation is out of the question, and even starting a thread per invocation seems to be too much. But each call fall into an infinite loop and hang. So the run time of FindProxyForURL should be bounded. FindProxyForURL can also resolve names over the network, which would best be done asynchronously. Things in systemd are usually implemented through poll loops, which makes it easy to support thousands of concurrent "jobs". I'd think that this would be the best option here too, with a number of "workers" executing FindProxyForURL()s and stopping when name resolution is requested and continuing when the name is resolved. >>> >>> Well, it's Java script code. People can just add code like "for (;;); >>> ", and we must be able to cancel the lookup then safely. I doubt >>> that's cleanly doable with either thread-based or event loop based >>> solutions. I am pretty sure a worker process logic is the way to >>> go. The worker process should get the PAC data when it is forked off, >>> and then read FindProxyForURL data from a pipe and output the result >>> on another, or something similar, and easily sandboxable... >> >> are you sure that you are not overthinking this? I think that >> duktape actually allows just canceling the JS engine execution, no >> matter what operation it runs. So you could just cancel the JS >> context. > > How is this implemented in duktype? I mean, cancelling threads is > fricking awful. POSIX thread cancellation is awful, and I am pretty > sure NSS calls are incompatible with it anway. Which means you have to > check flags after each javascript instruction -- which however doesn't > really work too well either, since NSS calls will block as long as > they want, hence you couldn't use this to cancel those... I am not saying that we cancel the thread. I know that this is painful. I am saying that we just cancel the duktape context and its execution, then the thread would just yield all by itself. So I think the question is if a master thread could just tell the duktape context to quit. That is something we might want to figure out. > I really would prefer doing this out-of-process. Then we can kill the > stuff, regardless what it is doing, without interfering with anything > else. Heck, we can even let the kernel help us with the timeout thing > with RLIMIT_CPU... We would need to define some IPC and managing the pool of these processes. Of course this is possible since almost any browser does it this way. It however sounds like a lot of effort and complexity if we can do the same with threads and just cancel the duktape execution instead. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
Am 12.04.2015 um 22:08 schrieb lynd...@your-mail.com: I can replicate the exact same error message, "Cannot assign requested address", in BOTH cases -- eno1 and br0 -- by simply having sshd listen on a non-existent IP, e.g. 10.1.1.1 and why in the world don't you just configure sshd to listen on 0.0.0.0 and restrict access (if needed at all) by the firewall? 0.0.0.0 is available at *any* time of boot signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Sun, Apr 12, 2015, at 12:49 PM, Lennart Poettering wrote: > Hmm? why that? why does sshd care? Iiuc, sshd's LISTENER ip's must exist & be available I am not having sshd listen on 0.0.0.0. I am specifying that it listens on 192.168.1.1 > What precisely fails? I don't KNOW precisely, other than what I shared in my original post journalctl -b | grep -i sshd ... Apr 10 15:30:49 xen01 sshd[1345]: error: Bind to port 22 on 192.168.1.1 failed: Cannot assign requested address. ... sshd.service seems like it's trying to launch sshd BEFORE that interface -- defined in br0 config -- is available. I can replicate the exact same error message, "Cannot assign requested address", in BOTH cases -- eno1 and br0 -- by simply having sshd listen on a non-existent IP, e.g. 10.1.1.1 > I mean, if > the ip addres 192.168.1.1 is bound to a local interface, then sshd > really should work, it shouldn't matter what kind of interface that > is. It's bound to an EXTERNAL, interface eno1 (or br0) -- attached in this case to the LAN. The only internal interface, 'lo', has 127.0.0.1 & :: bound. LT ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 2/6] proxy-discoveryd: Add the basics for parsing the default configuration
Hi Lennart, The config file will be in /etc/systemd/proxy/.conf It currently only load "Proxy" parts, with the key PAC. Rest is ignored. The PAC keyword is a path to a .pac file (a specific js script for proxy configuration). Only one PAC based proxy configuration will be loaded at a time. >>> >>> (Just a side note: I figure in the long run we should probably track >>> PAC data per-interface (plus maybe one global setting), so that >>> clients can query this specifically for an interface, and so that we >>> can search PAC data over the right network. But I figure for now this >>> doesn't matter too much.). >> >> why would you have a global PAC file. I think they should be all per >> interface and nothing else. > > Well, maybe not a global PAC file, but probably an explicitly > configurable global HTTP proxy, if people want that... I mean, it is a > pretty common setting to have I figure, and the daemon should > proibably cover both PAC and straightforward proxy config... yes that makes sense. So what we have done in PACrunner was that instead of a PAC file you could just give it the HTTP proxy address. And that would also work per interface. When then libproxy or someone did FindProxyForURL, the configured HTTP proxy URL was returned. Of course in these situations, no PAC files are executed, but the D-Bus API for talking to systemd-proxydiscoverd to get the proxy to use can be still used. I still wonder if it is a good idea to have a global proxy there. I would assume you just configure the proxy per interface in your network configuration file. This should be treated similar to DNS configuration. You want this per interface. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods
On Sun, 12.04.15 12:53, Marcel Holtmann (mar...@holtmann.org) wrote:
> Hi Lennart,
>
> +
> +static int method_find_proxy(sd_bus *bus, sd_bus_message *message, void
> *userdata, sd_bus_error *error) {
> +_cleanup_free_ char *p = strdup("DIRECT");
> >>>
> >>> Please don't mix variable declarations and function invocations in one
> >>> line (also see CODING_STYLE). Also, missing OOM check...
> >>>
> +Manager *m = userdata;
> +int r;
> +
> +assert(bus);
> +assert(message);
> +assert(m);
> +
> +r = proxy_execute(m->default_proxies, message);
> +if (r < 0)
> +sd_bus_reply_method_return(message, "s", p);
> >>>
> >>> Hmm, is this right? Shouldn't we return the error code to the client
> >>> instead of eating up and returning "DIRECT"?
> >>>
> >>> Also, why allocate "DIRECT" with strdup() at all?
> >>
> >> There are no errors. Either you get a proxy directive or you return
> >> DIRECT to indicate no proxy. What would you do in an error case
> >> anyway. The backup is always assume no proxy.
> >
> > Well, so far it has been our coding styles to propagate errors up if
> > they cause the invoked operations to fail, and allow the higher up
> > code deal with them and possibly eat them up. I mean, the HTTP client
> > can eat the error up and downgrade to DIRECT on its own, there's no
> > need to do this from our side already.
>
> of course it can, but it also does not help you at all. You are not making
> anything better here.
>
> I think that one clean interface to this needs to be a API
> compatible libproxy. Similar to what we did in PACrunner since that
> allows existing application to just use systemd-proxydiscoverd.
Well, clients have to deal with errors anyway, since they are talking
to this via dbus. I mean, the service might simply be missing on the
system, and the client code should then downgrade to DIRECT
anyway... Hence, the right client side behaviour is to eat up *all*
error conditions, regardless if they stem from the dbus code, the
socket calls used by dbus or ultimately from the proxy discovery
daemon...
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] [RFC 4/6] proxy-discoveryd: Execute the PAC based proxy in a thread
Hi Lennart, >>> sd-bus is not thread-safe. You cannot send messages from different >>> threads at the same time... >>> >>> Why precisely do you need threads here? Because the PAC programs might >>> be slow? >> >> the Javascript execution is normally blocking and it can do whatever >> it wants. If it wants to draw a smiley face, while looking up the >> proxy, it can do that. >> >> I think the PAC execution needs to be done in a thread, but not the >> D-Bus message handling. >> >>> WHat about unbounded loops in PAC programs? We need to protect from >>> that, which kinda suggests we muight want to run the PAC stuff out of >>> process so that we can neatly kill the program when it runs for too >>> long? >> >> Remember that in theory for every HTTP request a browser makes it is >> suppose to ask the PAC file first. Meaning it will run this a >> lot. So spawning processes might be not really useful. Even if we >> start one PAC processing process for each interface, you still want >> threads since you might have multiple requests from different >> application. And if one can be answered from a cache, then you do >> not want to wait until the Javascript execution finished. > > Hmm, this really feels like we should still do this out-of-process > with a worker process logic. Reuse processes to keep the cost down, > and run up to a fixed number of them in parallel to allow multiple > sumultaneous requests. THis would have have the major added benefit > that we could lock the worker threads down with seccomp and whatnot, > which is certainly a good thing given that we'll execute foreign, > untrusted code we downloaded from the network with this. And we can > easily kill the execution with a time limit if we desir to do so... I get the feeling that this needs to be measured and someone has to write some performance tool around this. So while you have only seen tiny PAC files, I am seen ours. And that one is massive. I bet that other corporation have similar large ones. Regards Marcel ___ 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 Sun, 12.04.15 12:51, Marcel Holtmann (mar...@holtmann.org) wrote: > Hi Lennart, > > >>> As it has been discussed in the systemd hackfest during the Linux > >>> Conference > >>> Europe, one daemon could centralize the management of all network proxy > >>> configurations. Idea is something user can do per-application (like in > >>> firefox for instance) or broader (per-DM like in Gnome), user could do it > >>> once and for all through such daemon and applications would then request > >>> it > >>> to know whether or not a proxy has to be used and which one. > >>> > >>> 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. > >> Hi, > >> > >> the idea of having centralized proxy config is certainly nice. But the > >> PAC files make me shiver. So the first question: is it really necessary > >> to support PAC files? > > > > Yes, it's kinda necessary. PAC is pretty widely used in corporate > > setting. Windows does the WPAD stuff (the protocol to discover PAD) in > > all its versions since a long time. In fact, it immediately issues the > > wpad requests as first thing when you plug in an ethernet cable, in > > addition to DHCP. > > > >> Are they widely used in corporate setting or something? > >> Is there no saner standard? > > > > Nope, not really, I fear. > > > >> > >> If the PAC files must be interpreted, I think this is the hardest > >> part. FindProxyForURL is started for every request, potentially > >> hundreds of times per second and more. This means that starting a > >> process per invocation is out of the question, and even starting a > >> thread per invocation seems to be too much. But each call fall into an > >> infinite loop and hang. So the run time of FindProxyForURL should be > >> bounded. FindProxyForURL can also resolve names over the network, > >> which would best be done asynchronously. > >> > >> Things in systemd are usually implemented through poll loops, which > >> makes it easy to support thousands of concurrent "jobs". I'd think > >> that this would be the best option here too, with a number of "workers" > >> executing FindProxyForURL()s and stopping when name resolution is > >> requested and continuing when the name is resolved. > > > > Well, it's Java script code. People can just add code like "for (;;); > > ", and we must be able to cancel the lookup then safely. I doubt > > that's cleanly doable with either thread-based or event loop based > > solutions. I am pretty sure a worker process logic is the way to > > go. The worker process should get the PAC data when it is forked off, > > and then read FindProxyForURL data from a pipe and output the result > > on another, or something similar, and easily sandboxable... > > are you sure that you are not overthinking this? I think that > duktape actually allows just canceling the JS engine execution, no > matter what operation it runs. So you could just cancel the JS > context. How is this implemented in duktype? I mean, cancelling threads is fricking awful. POSIX thread cancellation is awful, and I am pretty sure NSS calls are incompatible with it anway. Which means you have to check flags after each javascript instruction -- which however doesn't really work too well either, since NSS calls will block as long as they want, hence you couldn't use this to cancel those... I really would prefer doing this out-of-process. Then we can kill the stuff, regardless what it is doing, without interfering with anything else. Heck, we can even let the kernel help us with the timeout thing with RLIMIT_CPU... 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] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods
Hi Lennart,
+
+static int method_find_proxy(sd_bus *bus, sd_bus_message *message, void
*userdata, sd_bus_error *error) {
+_cleanup_free_ char *p = strdup("DIRECT");
>>>
>>> Please don't mix variable declarations and function invocations in one
>>> line (also see CODING_STYLE). Also, missing OOM check...
>>>
+Manager *m = userdata;
+int r;
+
+assert(bus);
+assert(message);
+assert(m);
+
+r = proxy_execute(m->default_proxies, message);
+if (r < 0)
+sd_bus_reply_method_return(message, "s", p);
>>>
>>> Hmm, is this right? Shouldn't we return the error code to the client
>>> instead of eating up and returning "DIRECT"?
>>>
>>> Also, why allocate "DIRECT" with strdup() at all?
>>
>> There are no errors. Either you get a proxy directive or you return
>> DIRECT to indicate no proxy. What would you do in an error case
>> anyway. The backup is always assume no proxy.
>
> Well, so far it has been our coding styles to propagate errors up if
> they cause the invoked operations to fail, and allow the higher up
> code deal with them and possibly eat them up. I mean, the HTTP client
> can eat the error up and downgrade to DIRECT on its own, there's no
> need to do this from our side already.
of course it can, but it also does not help you at all. You are not making
anything better here.
I think that one clean interface to this needs to be a API compatible libproxy.
Similar to what we did in PACrunner since that allows existing application to
just use systemd-proxydiscoverd.
Regards
Marcel
___
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 Sun, 12.04.15 12:49, Marcel Holtmann (mar...@holtmann.org) wrote: > PACrunner is an existing implementation of this concept. It uses > threads and seems to work just fine. We bridged libproxy API > compatible library that talks to the PACrunner over D-Bus. How does the abort-after-max-runtime logic work in PACrunner? How do you abort the thread? Do you use POSIX thread cancellation (yuck!), or do you check a cancelation flag after each javascript instruction? or what do you do? 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] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Lennart, >>> As it has been discussed in the systemd hackfest during the Linux Conference >>> Europe, one daemon could centralize the management of all network proxy >>> configurations. Idea is something user can do per-application (like in >>> firefox for instance) or broader (per-DM like in Gnome), user could do it >>> once and for all through such daemon and applications would then request it >>> to know whether or not a proxy has to be used and which one. >>> >>> 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. >> Hi, >> >> the idea of having centralized proxy config is certainly nice. But the >> PAC files make me shiver. So the first question: is it really necessary >> to support PAC files? > > Yes, it's kinda necessary. PAC is pretty widely used in corporate > setting. Windows does the WPAD stuff (the protocol to discover PAD) in > all its versions since a long time. In fact, it immediately issues the > wpad requests as first thing when you plug in an ethernet cable, in > addition to DHCP. > >> Are they widely used in corporate setting or something? >> Is there no saner standard? > > Nope, not really, I fear. > >> >> If the PAC files must be interpreted, I think this is the hardest >> part. FindProxyForURL is started for every request, potentially >> hundreds of times per second and more. This means that starting a >> process per invocation is out of the question, and even starting a >> thread per invocation seems to be too much. But each call fall into an >> infinite loop and hang. So the run time of FindProxyForURL should be >> bounded. FindProxyForURL can also resolve names over the network, >> which would best be done asynchronously. >> >> Things in systemd are usually implemented through poll loops, which >> makes it easy to support thousands of concurrent "jobs". I'd think >> that this would be the best option here too, with a number of "workers" >> executing FindProxyForURL()s and stopping when name resolution is >> requested and continuing when the name is resolved. > > Well, it's Java script code. People can just add code like "for (;;); > ", and we must be able to cancel the lookup then safely. I doubt > that's cleanly doable with either thread-based or event loop based > solutions. I am pretty sure a worker process logic is the way to > go. The worker process should get the PAC data when it is forked off, > and then read FindProxyForURL data from a pipe and output the result > on another, or something similar, and easily sandboxable... are you sure that you are not overthinking this? I think that duktape actually allows just canceling the JS engine execution, no matter what operation it runs. So you could just cancel the JS context. Regards Marcel ___ 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
Hi Zbyszek, >> As it has been discussed in the systemd hackfest during the Linux Conference >> Europe, one daemon could centralize the management of all network proxy >> configurations. Idea is something user can do per-application (like in >> firefox for instance) or broader (per-DM like in Gnome), user could do it >> once and for all through such daemon and applications would then request it >> to know whether or not a proxy has to be used and which one. >> >> 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. > Hi, > > the idea of having centralized proxy config is certainly nice. But the > PAC files make me shiver. So the first question: is it really necessary > to support PAC files? Are they widely used in corporate setting or something? > Is there no saner standard? > > If the PAC files must be interpreted, I think this is the hardest > part. FindProxyForURL is started for every request, potentially > hundreds of times per second and more. This means that starting a > process per invocation is out of the question, and even starting a > thread per invocation seems to be too much. But each call fall into an > infinite loop and hang. So the run time of FindProxyForURL should be > bounded. FindProxyForURL can also resolve names over the network, > which would best be done asynchronously. > > Things in systemd are usually implemented through poll loops, which > makes it easy to support thousands of concurrent "jobs". I'd think > that this would be the best option here too, with a number of "workers" > executing FindProxyForURL()s and stopping when name resolution is > requested and continuing when the name is resolved. PACrunner is an existing implementation of this concept. It uses threads and seems to work just fine. We bridged libproxy API compatible library that talks to the PACrunner over D-Bus. I am confused why everybody worries about DNS here. Just use C library name resolving calls. Let it resolve it and be done with it. You are synchronous anyway since the name resolving happens as a Javascript function call. It just happens that this is mapping to actually system code internally. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Sun, 12.04.15 12:35, lynd...@your-mail.com (lynd...@your-mail.com) wrote: > On Sun, Apr 12, 2015, at 12:25 PM, Lennart Poettering wrote: > > > Seems to me that there should be *some* real check for the 'up' > > > state of the bridge, not just "waiting long enough" and hoping. > > > > Well, I mean, the entire logic of delaying the boot for external > > conditions is already pretty wrong. If you want to fix this, then > > make sure sshd doesn't need the network to be up to start up (for > > example by using socket activation, or by using IP_FREEBIND). > > > > But I mean, what you are asking for is basically delaying boot > > completion indefinitely. I doubt that that'd be a good mechanism to > > have... > > I don't think so. Or at least that's not my intention, or my need. > > Let me try to resimplify. > > sshd.service starts fine on boot when using ethX, and fails when using br0. > > Specifically, sshd listens on IP = 192.168.1.1 > > If interface:IP = eno1:192.168.1.1, then it's all good. > > But, if interface:IP = br0(attached to eno1):192.168.1.1, then there's a fail > of sshd.service on boot. Hmm? why that? why does sshd care? What precisely fails? I mean, if the ip addres 192.168.1.1 is bound to a local interface, then sshd really should work, it shouldn't matter what kind of interface that is. 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 5/6] network: fix strict aliasing issue
On Wed, 11.03.15 08:13, Shawn Landden (sh...@churchofgit.com) wrote:
> We shouldn't assume 64-bit arch with the way we do math either.
> (although I will submit a patch to glibc to add a uint64_t union
> alias)
Hmm? uint64_t works fine on 32bit too. The compiler can do the
necessary emulation on its own... I don't see the need to change
anything here.
> diff --git a/src/network/networkd-address.c b/src/network/networkd-address.c
> index 0be6165..4b7f451 100644
> --- a/src/network/networkd-address.c
> +++ b/src/network/networkd-address.c
> @@ -605,12 +605,12 @@ bool address_equal(Address *a1, Address *a2) {
> }
>
> case AF_INET6: {
> -uint64_t *b1, *b2;
> +uint32_t *b1, *b2;
>
> -b1 = (uint64_t*)&a1->in_addr.in6;
> -b2 = (uint64_t*)&a2->in_addr.in6;
> +b1 = &a1->in_addr.in6.s6_addr32[0];
> +b2 = &a2->in_addr.in6.s6_addr32[0];
>
> -return (((b1[0] ^ b2[0]) | (b1[1] ^ b2[1])) == 0UL);
> +return (((b1[0] ^ b2[0]) | (b1[1] ^ b2[1]) | (b1[2] ^ b2[2])
> | (b1[3] ^ b2[3])) == 0);
> }
>
> default:
> --
> 2.2.1.209.g41e5f3a
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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] fix strict aliasing violations in src/udev/udev-builtin-usb_id.c
On Tue, 10.03.15 19:13, Shawn Landden (sh...@churchofgit.com) wrote:
> @@ -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));
This part has already been fixed with a different patch.
>
> if (asprintf(&filename, "%s/descriptors",
> udev_device_get_syspath(dev)) < 0)
> @@ -179,21 +180,20 @@ 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;
> +char *desc = &buf[pos];
> char if_str[8];
>
> -desc = (struct usb_interface_descriptor *) &buf[pos];
> -if (desc->bLength < 3)
> +if (desc[offsetof(struct usb_interface_descriptor, bLength)]
> < 3)
> break;
> -pos += desc->bLength;
> +pos += desc[offsetof(struct usb_interface_descriptor,
> bLength)];
>
> -if (desc->bDescriptorType != USB_DT_INTERFACE)
> +if (desc[offsetof(struct usb_interface_descriptor,
> bDescriptorType)] != USB_DT_INTERFACE)
> continue;
>
> if (snprintf(if_str, 8, ":%02x%02x%02x",
> - desc->bInterfaceClass,
> - desc->bInterfaceSubClass,
> - desc->bInterfaceProtocol) != 7)
> + desc[offsetof(struct usb_interface_descriptor,
> bInterfaceClass)],
> + desc[offsetof(struct usb_interface_descriptor,
> bInterfaceSubClass)],
> + desc[offsetof(struct usb_interface_descriptor,
> bInterfaceProtocol)]) != 7)
> continue;
This call doesn't look pretty. I don#t really care too much about the
strict aliasing issues, but if you really want to fix this, then this
should probably be done with a union, like the other cases.
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] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Sun, Apr 12, 2015, at 12:25 PM, Lennart Poettering wrote: > > Seems to me that there should be *some* real check for the 'up' > > state of the bridge, not just "waiting long enough" and hoping. > > Well, I mean, the entire logic of delaying the boot for external > conditions is already pretty wrong. If you want to fix this, then > make sure sshd doesn't need the network to be up to start up (for > example by using socket activation, or by using IP_FREEBIND). > > But I mean, what you are asking for is basically delaying boot > completion indefinitely. I doubt that that'd be a good mechanism to > have... I don't think so. Or at least that's not my intention, or my need. Let me try to resimplify. sshd.service starts fine on boot when using ethX, and fails when using br0. Specifically, sshd listens on IP = 192.168.1.1 If interface:IP = eno1:192.168.1.1, then it's all good. But, if interface:IP = br0(attached to eno1):192.168.1.1, then there's a fail of sshd.service on boot. There's lots of comments online about bridges being 'different' than physical ethernet interfaces -- some were yours, IIRC. No problem that they're different. I just want sshd.service to start correctly when listening on a bridge interface IP. I'm completely open on how to get there. THe only thing I can think of so far is adding whatever the right dependency is. If there's a better method, I'm all ears. > Yes, sorry for the typos! whew! :-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Sun, 12.04.15 12:12, lynd...@your-mail.com (lynd...@your-mail.com) wrote: > Hi Lennart > > On Sun, Apr 12, 2015, at 11:06 AM, Lennart Poettering wrote: > > This looks like Fedora/Red Hat initscripts networking? > > Close; same style. But it's opensuse networking. > > > If so, please file a bug against the initscripts package. It's up to > > the networking management solution to fill network-line.target with > > something useful, and in your case that appears to be the initscripts > > implementation. > > Since I wasn't sure where the problem starts, I'd got that already going here > > Bug 926835 - sshd.service (openssh) fails on boot when primary listener is a > bridge (br0) instead of real interface (eth0) > https://bugzilla.opensuse.org/show_bug.cgi?id=926835 > > So far the advice there is to increase the value of WAIT_FOR_INTERFACES in > /etc/sysconfig/network/config from 30 sec to > 40 secs. > > Seems to me that there should be *some* real check for the 'up' > state of the bridge, not just "waiting long enough" and hoping. Well, I mean, the entire logic of delaying the boot for external conditions is already pretty wrong. If you want to fix this, then make sure sshd doesn't need the network to be up to start up (for example by using socket activation, or by using IP_FREEBIND). But I mean, what you are asking for is basically delaying boot completion indefinitely. I doubt that that'd be a good mechanism to have... > > systemd just provides the the name network-ionline.target really. > > You mentioned both > > network-line.target > > and > > network-ionline.target > > Just to be sure, are those just typos for 'network-online.target'? Yes, sorry for the typos! 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] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
Hi Lennart On Sun, Apr 12, 2015, at 11:06 AM, Lennart Poettering wrote: > This looks like Fedora/Red Hat initscripts networking? Close; same style. But it's opensuse networking. > If so, please file a bug against the initscripts package. It's up to > the networking management solution to fill network-line.target with > something useful, and in your case that appears to be the initscripts > implementation. Since I wasn't sure where the problem starts, I'd got that already going here Bug 926835 - sshd.service (openssh) fails on boot when primary listener is a bridge (br0) instead of real interface (eth0) https://bugzilla.opensuse.org/show_bug.cgi?id=926835 So far the advice there is to increase the value of WAIT_FOR_INTERFACES in /etc/sysconfig/network/config from 30 sec to > 40 secs. Seems to me that there should be *some* real check for the 'up' state of the bridge, not just "waiting long enough" and hoping. > systemd just provides the the name network-ionline.target really. You mentioned both network-line.target and network-ionline.target Just to be sure, are those just typos for 'network-online.target'? LT ___ 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 Sat, 11.04.15 19:41, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Fri, Apr 10, 2015 at 03:17:37PM +0300, Tomasz Bursztyka wrote: > > Hi, > > > > As it has been discussed in the systemd hackfest during the Linux Conference > > Europe, one daemon could centralize the management of all network proxy > > configurations. Idea is something user can do per-application (like in > > firefox for instance) or broader (per-DM like in Gnome), user could do it > > once and for all through such daemon and applications would then request it > > to know whether or not a proxy has to be used and which one. > > > > 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. > Hi, > > the idea of having centralized proxy config is certainly nice. But the > PAC files make me shiver. So the first question: is it really necessary > to support PAC files? Yes, it's kinda necessary. PAC is pretty widely used in corporate setting. Windows does the WPAD stuff (the protocol to discover PAD) in all its versions since a long time. In fact, it immediately issues the wpad requests as first thing when you plug in an ethernet cable, in addition to DHCP. > Are they widely used in corporate setting or something? > Is there no saner standard? Nope, not really, I fear. > > If the PAC files must be interpreted, I think this is the hardest > part. FindProxyForURL is started for every request, potentially > hundreds of times per second and more. This means that starting a > process per invocation is out of the question, and even starting a > thread per invocation seems to be too much. But each call fall into an > infinite loop and hang. So the run time of FindProxyForURL should be > bounded. FindProxyForURL can also resolve names over the network, > which would best be done asynchronously. > > Things in systemd are usually implemented through poll loops, which > makes it easy to support thousands of concurrent "jobs". I'd think > that this would be the best option here too, with a number of "workers" > executing FindProxyForURL()s and stopping when name resolution is > requested and continuing when the name is resolved. Well, it's Java script code. People can just add code like "for (;;); ", and we must be able to cancel the lookup then safely. I doubt that's cleanly doable with either thread-based or event loop based solutions. I am pretty sure a worker process logic is the way to go. The worker process should get the PAC data when it is forked off, and then read FindProxyForURL data from a pipe and output the result on another, or something similar, and easily sandboxable... 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] [RFC 5/6] proxy-discoveryd: Add the basic parts for handling DBus methods
On Fri, 10.04.15 15:33, Marcel Holtmann (mar...@holtmann.org) wrote:
> Hi Lennart,
>
> >> +
> >> +static int method_find_proxy(sd_bus *bus, sd_bus_message *message, void
> >> *userdata, sd_bus_error *error) {
> >> +_cleanup_free_ char *p = strdup("DIRECT");
> >
> > Please don't mix variable declarations and function invocations in one
> > line (also see CODING_STYLE). Also, missing OOM check...
> >
> >> +Manager *m = userdata;
> >> +int r;
> >> +
> >> +assert(bus);
> >> +assert(message);
> >> +assert(m);
> >> +
> >> +r = proxy_execute(m->default_proxies, message);
> >> +if (r < 0)
> >> +sd_bus_reply_method_return(message, "s", p);
> >
> > Hmm, is this right? Shouldn't we return the error code to the client
> > instead of eating up and returning "DIRECT"?
> >
> > Also, why allocate "DIRECT" with strdup() at all?
>
> There are no errors. Either you get a proxy directive or you return
> DIRECT to indicate no proxy. What would you do in an error case
> anyway. The backup is always assume no proxy.
Well, so far it has been our coding styles to propagate errors up if
they cause the invoked operations to fail, and allow the higher up
code deal with them and possibly eat them up. I mean, the HTTP client
can eat the error up and downgrade to DIRECT on its own, there's no
need to do this from our side already.
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] [RFC 4/6] proxy-discoveryd: Execute the PAC based proxy in a thread
On Fri, 10.04.15 15:31, Marcel Holtmann (mar...@holtmann.org) wrote: > > sd-bus is not thread-safe. You cannot send messages from different > > threads at the same time... > > > > Why precisely do you need threads here? Because the PAC programs might > > be slow? > > the Javascript execution is normally blocking and it can do whatever > it wants. If it wants to draw a smiley face, while looking up the > proxy, it can do that. > > I think the PAC execution needs to be done in a thread, but not the > D-Bus message handling. > > > WHat about unbounded loops in PAC programs? We need to protect from > > that, which kinda suggests we muight want to run the PAC stuff out of > > process so that we can neatly kill the program when it runs for too > > long? > > Remember that in theory for every HTTP request a browser makes it is > suppose to ask the PAC file first. Meaning it will run this a > lot. So spawning processes might be not really useful. Even if we > start one PAC processing process for each interface, you still want > threads since you might have multiple requests from different > application. And if one can be answered from a cache, then you do > not want to wait until the Javascript execution finished. Hmm, this really feels like we should still do this out-of-process with a worker process logic. Reuse processes to keep the cost down, and run up to a fixed number of them in parallel to allow multiple sumultaneous requests. THis would have have the major added benefit that we could lock the worker threads down with seccomp and whatnot, which is certainly a good thing given that we'll execute foreign, untrusted code we downloaded from the network with this. And we can easily kill the execution with a time limit if we desir to do so... 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] [RFC 3/6] proxy-discoveryd: Add PAC support through duktape js engine
On Fri, 10.04.15 15:26, Marcel Holtmann (mar...@holtmann.org) wrote:
> >> +static int pac_dns_resolve(duk_context *ctx) {
> >> +_cleanup_free_ char *address = NULL;
> >> +struct addrinfo hints = {};
> >> +struct addrinfo *res, *addr;
> >> +const char *hostname;
> >> +int r;
> >> +
> >> +hostname = duk_require_string(ctx, 0);
> >> +
> >> +hints.ai_family = AF_INET;
> >> +
> >> +r = getaddrinfo(hostname, NULL, &hints, &res);
> >> +if (r != 0)
> >> +return 0;
> >
> > Hm, synchronous getaddrinfo() is nasty... Please use sd-resolve for
> > this, which adds asynchronous getaddrinfo() for cases like this...
>
> you do realize that you want this synchronous. These are the magic
> dnsResolve and myIpAddress Javascript functions that are expected to
> be present when executing the PAC file. There are a few more, but
> they can be implemented in Javascript and don't need a C
> backend. These two actually need that. So you need to report the
> result.
Ah I see, this function is only ever called from the PAC javascript
code? OK, in that case it should be synchronous indeed.
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] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
On Fri, 10.04.15 14:05, Dan Williams (d...@redhat.com) wrote: > > > > So idea would basically be that we provide in all three daemons calls > > > > like: > > > > > > > > SetAdditionalNTP(ias) > > > > SetAdditionalDNS(ia(uay)) > > > > > > I would strongly suggest using strings in the API for IP addresses, not > > > byte arrays. > > > > Why so? > > It's much easier to use for languages other than C, like Python or JS or > Ruby or dbus-send or even C in many cases. We originally used binary > addresses in the D-Bus interface for NetworkManager, and eventually > found that was the wrong choice for these reasons. It's also easier to > pull in and out of D-Bus, with dbus-glib or GIO. I'm not sure about > sd_bus though. I am very much convinced that passing normalized data through dbus is the right thing. And that implies byte arrays for binary data such as IP addresses... We have structured data in dbus, that's pretty much the biggest benefit of dbus over raw sockets. We should use it and not chicken out, because our bindings suck and encode everything in formatted strings after all... If it's not easy to decode structured data with your bus binding, then the answer is to fix the bus binding, not to just revert to unstructured data. > > > Also, remember that we want to push domains too, for split > > > DNS in the VPN or other cases. So it really should be something like: > > > > > > SetAdditionalDNS(ia(sas)) (index, array[domain, array[server]]) > > > > > > what were the (uay) arguments you proposed? > > > > resolved supprots split DNS, but it will not allow multiple DNS > > servers with different domains on the same interface. Instead, you > > bind a set of DNS servers and a set of domains to an interface, and > > that's it, there's no further connection between servers and domains. > > If I understand correctly, this means you cannot direct *.foobar.com to > one set of DNS servers,and *.baz.com to another set, assuming those are > bound to the same interface? Why not allow that? Well, resolved is not supposed to support every crazy set up people can think of. I mean, if they want that they can certainly run their own local DNS server. resolved is about figuring out the common usecases and covering them nicely and automatically, and little else. > > I fail to see the strong usecase for allowing per-server domains. I > > mean in the VPn case you have one explicit interface for the VPN > > connection, so this should be covered with the current design. > > IPSec doesn't give you an kernel netdev at all, it's just routing on an > existing interface. So for that interface, you'd have both the VPN > servers and upstream servers, all bound to the same interface, and no > ability to direct VPN domains to the VPN servers since they are all on > the same interface? IPSec used in that mode does not convey DNS server info, does it? In that case it's supposed to be transparent, but with such domain server config it wouldn't be transparent after all... 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 1/2] Partially revert patch 11689d2a which force the NOCOW attribute.
From: Goffredo Baroncelli
Partially revert patch 11689d2a, which force the NOCOW attribute for the
journal files. This patch was introduced to allievate the perfomances
problem that journald shows on the BTRFS filesystem.
Because the NOCOW attribute is forced the user can't revert to
the old behavior. However NOCOW attribute disables the btrfs checksums,
which prevent BTRFS to rebuild a currupted file in an RAIDx filesystem.
To continue to set the NOCOW attribute, use the h|H command of
systemd-tmpfile.
---
src/journal/journal-file.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 2845e05..65e3e38 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -2602,18 +2602,6 @@ int journal_file_open(
goto fail;
if (f->last_stat.st_size == 0 && f->writable) {
-
-/* Before we write anything, turn off COW logic. Given
- * our write pattern that is quite unfriendly to COW
- * file systems this should greatly improve
- * performance on COW file systems, such as btrfs, at
- * the expense of data integrity features (which
- * shouldn't be too bad, given that we do our own
- * checksumming). */
-r = chattr_fd(f->fd, true, FS_NOCOW_FL);
-if (r < 0)
-log_warning_errno(errno, "Failed to set file
attributes: %m");
-
/* Let's attach the creation time to the journal file,
* so that the vacuuming code knows the age of this
* file even if the file might end up corrupted one
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] Add +C attrib to the journal files directories
From: Goffredo Baroncelli Add +C attrib to the journal files directories. The journal file format behaves bad on a BTRFS filesystem: the performances decrease during the time. To avoid this issue, this tmpfile.d snippet sets the NOCOW attribute to the journal files directories, so newly created journal files inherit the NCOOW attribute. Be aware that the NOCOW attribute disables the BTRFS checksums, prevent BTRFS to rebuild a corrupted file in a RAIDx filesystem. However the perfomances increase. In a single disk filesystem (or a filesystem without redundancy) it is safe to use the NOCOW flags. --- tmpfiles.d/journal-nocow.conf | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 tmpfiles.d/journal-nocow.conf diff --git a/tmpfiles.d/journal-nocow.conf b/tmpfiles.d/journal-nocow.conf new file mode 100644 index 000..493 --- /dev/null +++ b/tmpfiles.d/journal-nocow.conf @@ -0,0 +1,22 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +# See tmpfiles.d(5) for details + +# Set the NOCOW attribute for directories of journal files; this flag is +# inheredited by their new files and sub-directories; valid only for a BTRFS +# filesystem +# WARNING: enabling the NOCOW attribute improves the perfomance, but also +#disables the BTRFS checksums. In a RAID BTRFS filesystem, the checksums +#are needed to rebuild a corrupted file; without checksums a rebuild is +#not possible. +# In a single-disk filesystem (or a filesystem without redundancy) enabling +# the NOCOW attribute for the journal files is safe, because these have their +# own checksums and a rebuilding wouldn't be possible in any case + +h /var/log/journal/%m - - - - +C +h /var/log/journal/remote - - - - +C -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH V2] Set the NOCOW flag for the journal via the tmpfiles
Hi all, these patches set partially reverts the commit 11689d2 "journald: turn off COW for journal files on btrfs" which enables *unconditionally* the NOCOW flag for the journal files. The reason was that the performances of the journal file format are very bad on btrfs, and decrease during the time. Disabling the COW behavior, the perfomances increase. Unfortunately disabling the COW behavior leads to disable the BTRFS checksums, which in turn prevents BTRFS to rebuild a corrupted file in a RAID filesystem [3]. To avoid that I proposed a patch which introduces a configurable option to disables the "turn off COW" behavior[1]. Lennart commented that instead he prefer to set the NOCOW attribute via tmpfile.d snippets. A further patches set was proposed and accepted [2] to extend systemd-tmpfiles to change the file attributes. This last patches set removes the "turn off COW" behavior (patch #1) and introduces a new tmpfiles.d snippet which enable the NOCOW beahvior for the journal files (patch #2). So a sysadmin can disable this setting overriding this file configuration. BR G.Baroncelli Changelog: v1: first issue v2: revert only the part related to SETTING the NOCOW attribute of the commit 11689d2 update the comment in the "tmpfile snippet" [1] Re: [systemd-devel] [RFC][PATCH] Add option to enable COW for journal file https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg28724.html [2] https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg29313.html [3] http://en.wikipedia.org/wiki/Btrfs#Checksum_tree_and_scrubbing -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ 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 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.
On Sun, 12.04.15 20:19, Goffredo Baroncelli (kreij...@libero.it) wrote: > >> After the work that I done to the tmpfiles, I have to agree with > >> Zbyszek. Adding an option to the journal.conf file is the more > >> reasonable thing to do. > > > > You mean journald.conf I figure? That's not even read by the remoting > > tools, so how is that a solution? > > In my first attempt, I added a switch to the command line. So we'd even have two new options where we'd know now that they would go away? And one of them isn't even persistent? This really sounds wrong. We should be frugal with adding new options, and this case is extraordinarily weak I think... > Even if I agree with you about the points above, I am not fully > convinced about changing the NOCOW attribute via tmpfile snippet: > it seems to me an overkill solution.. > > But I prefer the snippet solution to the old behavior (set the NOCOW attribute > coded in systemd-journald). If you rebase the patches, and fix the issues I pointed out I am happy to merge patches that set the c bit on the dirs via tmpfiles, and prints a warning when creating a new journal file on btrfs where the flag is off... 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 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.
On 2015-04-12 18:06, Lennart Poettering wrote: > On Sun, 12.04.15 17:29, Goffredo Baroncelli (kreij...@inwind.it) wrote: > >> On 2015-04-12 15:12, Lennart Poettering wrote: >>> On Sat, 11.04.15 17:07, Zbigniew JÄdrzejewski-Szmek (zbys...@in.waw.pl) >>> wrote: >>> >> That's the problem: current functionality works no matter where you >> store the files, but it's hard to provide the same level of >> flexibility with the tmpfiles-based solution. > > Well, but we never store files outside of /var/log/journal, > /var/log/journal/%m and /var/log/journal/remote/, do we? We can, if instructed to do so. journal-remote can store files wherever. Original motivation for this patch was to make the NOCOW on journal files configurable without too much fuss and without making it an explicit option. Journal files on btrfs without NOCOW are rather slow, so it seems that most people will want NOCOW on. But with the proposed patch, people would want to add the tmpfile snippet to set NOCOW for every location they write too, which is very visible and requires explicit configuration. Doing this in journal-file directly was simple, synchronous, and worked everywhere, and we are replacing this with a more complicated and more brittle scheme. Dunno, if you think things are better this way, I'm fine with that, since both schemes should get the job done. But in the end, adding a switch in journald.conf seems more in the systemd spirit of doing the right thing automatically and also less work for both sides... >>> >>> What about this solution: let's go the tmpfiles way, but also add some >>> code to the journal file writer to log at INFO level an actionable >>> recommendation to turn on the c flag on the directory if we notice >>> that the newly created file doesn't have it, and it is located on >>> btrfs? >> >> After the work that I done to the tmpfiles, I have to agree with >> Zbyszek. Adding an option to the journal.conf file is the more >> reasonable thing to do. > > You mean journald.conf I figure? That's not even read by the remoting > tools, so how is that a solution? In my first attempt, I added a switch to the command line. > >> If we add code that performs only a check in the code of journal, I think >> that we have the worst solution: >> - journal code is still aware of the NOCOW attribute (== more code >> complexity) >> - the user had to update/manage a tmpfile.d manually > > Well, again: the nocow thing is a work-around around a design issue > with btrfs, and btrfs is working on correcting that, by adding > auto-defrag to deal better with write patterns such as this. > > We should not add new explicit config options for things we already > know *now* that they are a stopgap, and will go away eventually. > > With the solution I propose (which is tmpfiles snippet + warning if > non-enabled) we get: > > - default behaviour is fast > > - default behaviour is easy to override > > - specialist users who use the remoting feature and use the thing on a > non-default directory, are notified about the issue at hand. > > - we can easily get rid of it eventually, simply by dropping one > config line and the generation of a warning. There's no option to > deprecate then, and keep compat for. Even if I agree with you about the points above, I am not fully convinced about changing the NOCOW attribute via tmpfile snippet: it seems to me an overkill solution.. But I prefer the snippet solution to the old behavior (set the NOCOW attribute coded in systemd-journald). > >> Let me to suggest the opposite solution: >> - add a switch in the journald.conf file >> - add a check that raise a warning if the NOCOW flag is not-used/used >> > > This does not fix the remoting issue, since journald.conf isn't read > by those tools. Also, it adds a setting we'll eventuall have to get > rid of again. > > Sorry, but I am really against a solution like that. I don't want to > litter the config file with options that are hacks and will go away > one day... > > Lennart > -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: shutup gcc aliasing warning
On Sat, 11.04.15 18:39, Shawn Landden (sh...@churchofgit.com) wrote:
> we only access this as void* so there is no violation
> ---
> src/libsystemd-network/sd-dhcp-client.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/libsystemd-network/sd-dhcp-client.c
> b/src/libsystemd-network/sd-dhcp-client.c
> index c44392e..bf57d4b 100644
> --- a/src/libsystemd-network/sd-dhcp-client.c
> +++ b/src/libsystemd-network/sd-dhcp-client.c
> @@ -1470,7 +1470,7 @@ static int client_receive_message_udp(sd_event_source
> *s, int fd,
> _cleanup_free_ DHCPMessage *message = NULL;
> int buflen = 0, len, r;
> const struct ether_addr zero_mac = { { 0, 0, 0, 0, 0, 0 } };
> -const struct ether_addr *expected_chaddr = NULL;
> +const void *expected_chaddr = NULL;
> uint8_t expected_hlen = 0;
>
> assert(s);
> @@ -1515,7 +1515,7 @@ static int client_receive_message_udp(sd_event_source
> *s, int fd,
>
> if (client->arp_type == ARPHRD_ETHER) {
> expected_hlen = ETH_ALEN;
> -expected_chaddr = (const struct ether_addr *)
> &client->mac_addr;
> +expected_chaddr = &client->mac_addr;
> } else {
> /* Non-ethernet links expect zero chaddr */
> expected_hlen = 0;
The right way to fix aliasing issues are unions. In this case, I
figure sd_dhcp_client should contain a union for the ethernet address,
containing the array for MAX_MAC_ADDR_LEN as well as a proper struct
ether_addr. it can even be an anonymous union. With that all aliasing
issues are gone, it would stay typesafe, and more elegant anyway.
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] sshd.service fails on boot when primary listener is a bridge (br0) instead of real interface (eth0). What dependency is needed?
On Fri, 10.04.15 15:52, lynd...@your-mail.com (lynd...@your-mail.com) wrote: > My /etc/systemd/system/sshd.service has a > > After=network-online.target > > dependency. > > When my ethernet interface, eno1, is the primary 'net listener, > > cat /etc/sysconfig/network/ifcfg-eno1 > STARTMODE='auto' > BOOTPROTO='static' > IPADDR='192.168.1.1/24' This looks like Fedora/Red Hat initscripts networking? If so, please file a bug against the initscripts package. It's up to the networking management solution to fill network-line.target with something useful, and in your case that appears to be the initscripts implementation. systemd just provides the the name network-ionline.target really. 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 v2] gpt-generator: Find device on a stateless system
On Sat, 11.04.15 01:52, Tobias Hunger (tobias.hun...@gmail.com) wrote:
> A stateless system has a tmpfs as root file system. That obviously
> does not have any block device associated with it. So try falling back
> to the device of the /usr filesystem if the root filesystem fails.
Thanks! Applied!
> ---
> src/gpt-auto-generator/gpt-auto-generator.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/gpt-auto-generator/gpt-auto-generator.c
> b/src/gpt-auto-generator/gpt-auto-generator.c
> index 99dc50f..96a8447 100644
> --- a/src/gpt-auto-generator/gpt-auto-generator.c
> +++ b/src/gpt-auto-generator/gpt-auto-generator.c
> @@ -658,8 +658,13 @@ static int add_mounts(void) {
> if (r < 0)
> return log_error_errno(r, "Failed to determine block device
> of root file system: %m");
> else if (r == 0) {
> -log_debug("Root file system not on a (single) block
> device.");
> -return 0;
> +r = get_block_device("/usr", &devno);
> +if (r < 0)
> +return log_error_errno(r, "Failed to determine block
> device of /usr file system: %m");
> +else if (r == 0) {
> +log_debug("Neither root nor /usr file system are on
> a (single) block device.");
> +return 0;
> +}
> }
>
> return enumerate_partitions(devno);
> --
> 2.3.5
>
>
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] SystemD, Gnome permission problems
Elias Probst schrieb: > On 04/12/2015 05:47 PM, Kai Krakow wrote: >> Elias Probst schrieb: >> >>> On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: I'm wondering if we should provide better per-user tmpfiles support. For example, if we allowed a set of "user" tmpfiles, which would be executed by the system instance, but would be considered relative to the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home directory, %t to XDG_RUNTIME_DIR, ...). We would execute that for every user. >>> >>> Which makes me wonder again, why tmpfiles.d was never implemented in the >>> way all other units are implemented. >>> Currently, it's impossible to declare a dependency of a service upon a >>> tmpdir, which feels out of line with the way things are usually handled >>> in a systemd-based system. >>> >>> For example: >>> OpenVPN requires /run/openvpn/ to exist before being able to start. >>> This leads to the following possible scenarios to make OpenVPN usable on >>> a system where OpenVPN was just installed (and there was no reboot to >>> trigger tmpfiles.d creation) yet: >>> >>> A# >>> - the package manager creates /run/openvpn as part of of its postinst >>> routine. This is duplicated effort and could easily go out of sync with >>> the definition in OpenVPN's tmpfiles.d configuration >>> >>> B# >>> - the package manager calls "systemd-tmpfiles --create …" whenever a >>> tmpfiles.d configuration was installed. This might still be the most >>> straightforward way, but it could still happen that a user manually >>> deletes the directory and than at a later point attempts to start a >>> service depending on it >>> >>> C# >>> - the user has to create /run/openvpn manually (I don't think I have to >>> outline why this is no "correct" solution) >>> >>> D# >>> - creation of tmpfile directories is left to the application (again >>> duplicated effort and the wrong place to do it, when there is a >>> centralized mechanism for handling this properly) >>> >>> E# >>> - the service unit contains something like "ExecPre=/bin/mkdir …". Again >>> duplicated effort and the wrong place to do it. >> >> F# >> - the service file contains a RuntimeDirectory directive. >> >> ;-) >> > > Ha! Perfect! Thanks a lot for pointing this out. You're welcome... > My initial bugreport against Gentoo [1] regarding this issue is older > than the implementation of RuntimeDirectory [2] - time for updating the > bugreport + getting upstream (OpenVPN) involved to ship an updated > service unit and get rid of their tmpfiles.d conf. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=462118 > [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=e66cf1a3 A lot of packages should use this directive in Gentoo if I looked at /usr/lib/tmpfiles.d... There seem to be a lot of Gentoo-generated files (those without any comments) which could by migrated into the service file instead. But, as Lennart pointed out, it would really be better if daemons created those directories by themselves. I'd not put that under the term "duplicated effort" - indeed you are having duplicated effort currently because every init system has to take care of creating those directories, sometimes even depending on configuration files, e.g. mysql configures this in the configuration file but also in the init file. As a sysadmin I have to take care to change all possible places. If, in this example, mysql would simply create this directory on its own, all would be good - no more duplicated effort. Well, OTOH mysql isn't started as root, thus it cannot create this directory. So, such services are dependent on duplicated work - but at least RuntimeDirectory is the right place to do it then. I'd really prefer systemd's idea of services should create their runtime environment themselves on first start as complete as possible. Letting the package manager create all those empty runtime directories with .keep files so they become part of backups and do not become cleaned up, is really cumbersome and incomplete, and duplicate work because you have configuration in two places: the config file and the package manager. If I wanted to move runtime directories I'd have to configure the new directories but also create them or move them. Upon update, the package manager will recreate empty bogus directories. This should really go away. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd_event_run
On Sat, 11.04.15 18:24, Shawn Landden (shawnland...@gmail.com) wrote: > On Sat, Apr 11, 2015 at 6:01 PM, Shawn Landden wrote: > > On Sat, Apr 11, 2015 at 4:52 PM, Zbigniew Jędrzejewski-Szmek > > wrote: > >> On Fri, Apr 10, 2015 at 06:14:40PM +0200, Lennart Poettering wrote: > >>> On Sat, 14.03.15 12:19, Tom Gundersen (t...@jklm.no) wrote: > >>> > >>> > > 1. shouldn't SD_EVENT_PASSIVE become SD_EVENT_INITIAL? "passive" > >>> > > seems strange > >>> > >in this context. > > How about SD_EVENT_STALE? Stale things are distasteful unless they are > > freshened up. > Nah, Prepared is good. > > But this SD_EVENT_PASSIVE and SD_EVENT_RUNNING is incompatible with > making this multithreaded. Instead there could be a function (int > sd_event_references(sd_event *e)) that returns e->n_ref. This is never going to be multithreaded. We strictly dispatch in order, and this is not going to change. This behaviour is visible pretty much everywhere in the API, already because we have priorities and stuff. In fact, none of our library code is thread-safe, but all is threads-aware, and that's not going to change, sorry... 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] SystemD, Gnome permission problems
On Sun, 12.04.15 16:46, Elias Probst (m...@eliasprobst.eu) wrote: > On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: > > I'm wondering if we should provide better per-user tmpfiles support. > > For example, if we allowed a set of "user" tmpfiles, which would > > be executed by the system instance, but would be considered relative to > > the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home > > directory, > > %t to XDG_RUNTIME_DIR, ...). We would execute that for every user. > > Which makes me wonder again, why tmpfiles.d was never implemented in the > way all other units are implemented. > Currently, it's impossible to declare a dependency of a service upon a > tmpdir, which feels out of line with the way things are usually handled > in a systemd-based system. > > For example: > OpenVPN requires /run/openvpn/ to exist before being able to start. > This leads to the following possible scenarios to make OpenVPN usable on > a system where OpenVPN was just installed (and there was no reboot to > trigger tmpfiles.d creation) yet: It should just create the dir on its own. Invoking the mkdir() syscall is hardly the most complex thing in the world. If it's really about just this dir, it's certainly easier to make openvpn just invoke one more syscall than to add a tmpfiles snippet an RPM scriplet invocation and whatnot else. Also, it's much easier for everybody to grok, and the thing will be a ton more robust... > - creation of tmpfile directories is left to the application (again > duplicated effort and the wrong place to do it, when there is a > centralized mechanism for handling this properly) I strongly disgaree. Invoking "mkdir()" is trivial, openvpn really should do that. (unless it always runs unrpivileged, see below) > are there any real technical/conceptual reasons, why tmpfiles.d handling > wasn't implemented in the "systemd unit" way which would allow a service > to depend on the correct state of one or more tmpfiles.d items, so on > each service startup, the existence + state of the required directories > would be verified and ensured. We have RuntimeDirectory= as a native unit setting. However, it is only really useful for daemons that run unprivileged all the time (i.e. also use User= or so), and cannot create the directory on their own. For all others: they really should create their runtime dirs on their own. Don't bother with tmpfiles for no reason, please... 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] SystemD, Gnome permission problems
On Sun, 12.04.15 14:11, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > I'm wondering if we should provide better per-user tmpfiles support. > For example, if we allowed a set of "user" tmpfiles, which would > be executed by the system instance, but would be considered relative to > the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home > directory, > %t to XDG_RUNTIME_DIR, ...). We would execute that for every user. I'd be careful with this. I mean, I generally think that the fact that we need tmpfiles is not a strength, but really just a work-around for limitations of Linux. The tool covers four major usecases: 1. set up the work environment for daemons which are too dumb to do this on their own 2. set up the work environment for daemins that never run privileged, and hence cannot set up their work environment 3. Reserve a few file/directory names, to avoid namespace clashes in world-writable directories. Most notably that's the X11 stuff in /tmp. 4. Do "aging/clean-up" of /tmp. Now, of these the first item is a work-around for broken daemons, and this should really be better fixed in the daemons themselves. A daemon that does not require tmpfiles is a good daemon. The third item is a work-around against really broken semantics of X11, that cannot really be fixed without breaking compat... But this issue is certainly not something new code will fall for (hopefully)... The fourth item is a work-around for broken semantics of UNIX, where files cannot be bound to proper lifecycles of other objects, such as processes... "Aging" these dirs is actually really nasty, since its cleanups are in no way bound to the actual algorithms creating the files: code that generates a lot of files in a short time, will be cleaned up only much later, when the tmpfiles job happens to runs again... Only the second item is really a genuinely useful thing I believe, all the others are work-arounds around otherwise crappy designed code... And for the second item things like RuntimeDirectory= are probably a much better option, since it has properly synced up lifecycle guarantees... Now, if we look at all of this and how it would apply to the unprivileged user session, then I don't think issue #1 applies, simply because desktop software traditionally always was capable of setting up its own work environment, simply because boot scripts and RPM scripts couldn't cover new, unseen logins. Issue #2 doesn't apply because everything is unprivileged. Issue #3 doesn't apply, either, since this is about protecting system code against unprivileged code, but not unpriviliged code against itself. Finally, the solution for #4 that we apply on the system already covers this for the session too. The fact that tmpfiles exists is sad, and we shouldn't add this to the session, so that the same sad practices we see on system daemons are also adopted by desktop software... Moreover, I'd always be careful with adding privileged code that operates on unprivileged files, based on unprivileged configuration. I mean, the cleaning of /tmp has always been a source of security issues, it's really hard not to do things wrong when operating as privileged code on unprivileged files (think symlink attacks!), but it's a whole new dimension of risk, if we not only operate on those unprivileged files, but also use unprivileged user-supplied configuration... Hence, if this is done at all, it really should be the user's code that runs this, not the system code. > gnome could possibly replace its custom thumbnails cleaner with a few > lines of tmpfiles config. There would be two advantages: creation time > cleanup could be replaced with access time cleanup, cleanup wouldn't > be dependent on the session running. I think it would be a good idea if the thumbnailing code of GNOME would clean up the thumbnails stuff properly on its own, and that from the same code that writes the thumbnails, in a similar way as journald keeps track of its journal directory. That's the only way to make this robust: don't clean it up triggered on time, but closely bound to the algorithm that might fill it up. I hope this makes sense? 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 v2] efi-boot-generator: Continue if /boot does not exist
On Sat, 11.04.15 02:13, Tobias Hunger (tobias.hun...@gmail.com) wrote:
> /boot does not exist on a stateless system, so do not get
> confused by that.
> ---
> src/efi-boot-generator/efi-boot-generator.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/efi-boot-generator/efi-boot-generator.c
> b/src/efi-boot-generator/efi-boot-generator.c
> index 58c4cc2..5a9bfd3 100644
> --- a/src/efi-boot-generator/efi-boot-generator.c
> +++ b/src/efi-boot-generator/efi-boot-generator.c
> @@ -68,7 +68,10 @@ int main(int argc, char *argv[]) {
> return EXIT_SUCCESS;
> }
>
> -if (path_is_mount_point("/boot", true) <= 0 &&
> +r = path_is_mount_point("/boot", true);
> +if (r == -ENOENT) {
> +log_debug("/boot does not exist, continuing.");
> +} else if (r <= 0 &&
> dir_is_empty("/boot") <= 0) {
> log_debug("/boot already populated, exiting.");
> return EXIT_SUCCESS;
This was merged by Zbigniew earlier today.
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] sd_event_run
On Sat, 11.04.15 23:52, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Fri, Apr 10, 2015 at 06:14:40PM +0200, Lennart Poettering wrote: > > On Sat, 14.03.15 12:19, Tom Gundersen (t...@jklm.no) wrote: > > > > > > 1. shouldn't SD_EVENT_PASSIVE become SD_EVENT_INITIAL? "passive" seems > > > > strange > > > >in this context. > > > > I found it weird to name this INITIAL (or "INIT" or something like > > that) since we would return to it every single iteration... For me > > "init" kinda implies it's something "fresh", "unused", and hence not > > really something we routinely come back to... > In a sense it is "fresh" and "unused", because the state after doing > an interation of the loop is exactly the same as if the loop never run. > (E.g. I don't think it would be wrong to say "I cleaned the couch and > restored it to its initial state", even though it obviously has been used.) > > "Passive" was confusing, so "initial", even if imperfect, seems an > improvement. We really want to say "the state in which you started", > without implying whether we have been there the whole time or not. > I don't know if there's a better word. glib calls the respective state "initial" btw... I didn't like the name though, when I got inspiration from it... > > > >Similarly, SD_EVENT_ARMED seems more self-explanatory than PREPARED. > > > >(I don't like PREPARED because it is not obvious whether sources are > > > >prepared to wait on, or events are prepared to be reaped.) > > > > I called this "prepared" since it what's _prepare() is supposed to get > > into... > > > > But ARMED is fine too... > > We really should get some native speakers to help out with this :) > > Maybe sd_event_prepare should be renamed to sd_event_arm? The "prepare" state I stole from glib: https://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html It's probably a good idea to not invent new naming here, if glib already established the name. But then again, I departed from its naming in the first place, as shown above, so I should probably shut up... ;-) 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] network: allow domain names up to 255 characters
On Sun, 12.04.15 09:21, Nick Owens (misch...@offblast.org) wrote: > On Sun, Apr 12, 2015 at 6:35 AM, Lennart Poettering > wrote: > > On Fri, 10.04.15 13:03, Nick Owens (misch...@offblast.org) wrote: > > > >> From: mischief > >> > >> The maximum domain name size is larger than the maximum host name size. > >> The smaller limit causes valid domains provided by DHCP or .network > >> files to be silently ignored. > > > > Hmm? > > > > Can you give an example? > > if you set the Domains key in the [Network] section of a > systemd.network file to a domain longer than a label, then it will be > ignored. the same is true if your DHCP server sends a domain in option > 15 (domain name) that is longer than a label. it will be ignored too. > both of these code paths call 'hostname_is_valid', which will fail if > passed something larger than a label, which a domain name can be. "longer than a label"? What do you mean by that? The function should perfectly consider multi-label names valid? Are you saying you cannot set the domain name "foo.bar."? Hmm, so the DHCP spec explicitly declares that options 15 and 12 are about the DNS hostname, where RFC 1035 is normative. Our function hostname_is_valid() currently does not validate host names according to RFC 1035, but is in some way stricter (by enforcing Linux' own semantics on the length, and by limiting the charset drastically) and in other ways less strict (by not enforce label length.) I am pretty sure we should leave hostname_is_valid() the way it is, to be used when setting local hostnames and things like that. However, the DHCP code should really validate according to RFC 1035 instead, since that's what the spec says... Implementation-wise this probably means we should move src/resolve/resolved-dns-domain.[ch] into src/shared/dns-domain.[ch] and then add a call there that works similar to dns_name_normalize() but doesn't actually normalize, but simply validates. Hope that makes sense? 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] [systemd-commits] 8 commits - src/shared src/test src/tmpfiles
On Sun, 12.04.15 00:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > -if (user && !streq(user, "-")) {
> > +if (!isempty(user) && !streq(user, "-")) {
>
> I think this change is misleading. user/group/mode/age can either be
> NULL or "-" or should be set to a valid value. It should not be possible
> to set them to an empty string. (Not that the change causes any problems,
> just commenting on the fact that the patch description implies that it
> changes stuff, but I don't see that.)
We use unquote_many_words() these days for parsing the tmpfiles
lines. That means the following line will result in user, group and
mode all being set to empty strings:
f "/tmp/foo bar" "" "" ""
I think NULL, "" and "-" should all be considered as "not specified"
and handled accordingly...
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] network: allow domain names up to 255 characters
On Sun, Apr 12, 2015 at 6:35 AM, Lennart Poettering wrote: > On Fri, 10.04.15 13:03, Nick Owens (misch...@offblast.org) wrote: > >> From: mischief >> >> The maximum domain name size is larger than the maximum host name size. >> The smaller limit causes valid domains provided by DHCP or .network >> files to be silently ignored. > > Hmm? > > Can you give an example? if you set the Domains key in the [Network] section of a systemd.network file to a domain longer than a label, then it will be ignored. the same is true if your DHCP server sends a domain in option 15 (domain name) that is longer than a label. it will be ignored too. both of these code paths call 'hostname_is_valid', which will fail if passed something larger than a label, which a domain name can be. > > What is a domain name according to your definition? And what a > hostname? rfc 1035 2.3.4. Size limits describes labels as being 63 octets or less and domain names as 255 octets or less. > > So far, a hostname in my definition was either a single label, or an > fqdn, and a domain name the part of the fqdn with the first label > removed... > > With such a definition I am not sure I understand the patch, hence > please explain, and give a valid example of where this turns out to be > an issue? an easy way to reproduce (for me) is to have networkd do dhcp, and have my dhcp server (dnsmasq) send some domain that is very long (longer than a label) in option 15. try "supercalifragilisticexpialidocioussupercalifragilisticexpialidocious", or the output of `uuidgen`.`uuidgen` as your domain, and networkd will ignore it because hostname_is_valid won't accept it due to the length. > > 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] network: allow domain names up to 255 characters
On Sun, 12.04.15 09:02, Shawn Landden (shawnland...@gmail.com) wrote: > On Sun, Apr 12, 2015 at 6:35 AM, Lennart Poettering > wrote: > > On Fri, 10.04.15 13:03, Nick Owens (misch...@offblast.org) wrote: > > > >> From: mischief > >> > >> The maximum domain name size is larger than the maximum host name size. > >> The smaller limit causes valid domains provided by DHCP or .network > >> files to be silently ignored. > > > > Hmm? > > > > Can you give an example? > > > > What is a domain name according to your definition? And what a > > hostname? > > > > So far, a hostname in my definition was either a single label, or an > > fqdn, and a domain name the part of the fqdn with the first label > > removed... > > > > With such a definition I am not sure I understand the patch, hence > > please explain, and give a valid example of where this turns out to be > > an issue? > > ./x86_64-linux-gnu/bits/posix1_lim.h:#define _POSIX_HOST_NAME_MAX 255 > ./x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64 > ./x86_64-linux-musl/limits.h:#define HOST_NAME_MAX 255 musl is irrelevant for systemd. Also, musl is wrong. The Linux kernel maintains the system hostname as 64 char array, and sethostname() enforces that limit. > Perhaps we need to use _POSIX_HOST_NAME_MAX ?, Not really, that' the "minimal accepted value" for HOST_NAME_MAX and defined to 255. Linux ignores that, and sets HOST_NAME_MAX to 64 anyway... > or redefine HOST_NAME_MAX to 255? No, we will not redefine what the libc provides us with. This can only break. 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] network: allow domain names up to 255 characters
On Sun, Apr 12, 2015 at 6:35 AM, Lennart Poettering wrote: > On Fri, 10.04.15 13:03, Nick Owens (misch...@offblast.org) wrote: > >> From: mischief >> >> The maximum domain name size is larger than the maximum host name size. >> The smaller limit causes valid domains provided by DHCP or .network >> files to be silently ignored. > > Hmm? > > Can you give an example? > > What is a domain name according to your definition? And what a > hostname? > > So far, a hostname in my definition was either a single label, or an > fqdn, and a domain name the part of the fqdn with the first label > removed... > > With such a definition I am not sure I understand the patch, hence > please explain, and give a valid example of where this turns out to be > an issue? ./x86_64-linux-gnu/bits/posix1_lim.h:#define _POSIX_HOST_NAME_MAX 255 ./x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64 ./x86_64-linux-musl/limits.h:#define HOST_NAME_MAX 255 Perhaps we need to use _POSIX_HOST_NAME_MAX ?, or redefine HOST_NAME_MAX to 255? > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Liberty equality fraternity or death, Shawn Landden ChurchOfGit.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.
On Sun, 12.04.15 17:29, Goffredo Baroncelli (kreij...@inwind.it) wrote: > On 2015-04-12 15:12, Lennart Poettering wrote: > > On Sat, 11.04.15 17:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > That's the problem: current functionality works no matter where you > store the files, but it's hard to provide the same level of > flexibility with the tmpfiles-based solution. > >>> > >>> Well, but we never store files outside of /var/log/journal, > >>> /var/log/journal/%m and /var/log/journal/remote/, do we? > >> We can, if instructed to do so. journal-remote can store files wherever. > >> > >> Original motivation for this patch was to make the NOCOW on journal files > >> configurable without too much fuss and without making it an explicit > >> option. > >> Journal files on btrfs without NOCOW are rather slow, so it seems that most > >> people will want NOCOW on. But with the proposed patch, people would want > >> to add the tmpfile snippet to set NOCOW for every location they write too, > >> which is very visible and requires explicit configuration. Doing this in > >> journal-file directly was simple, synchronous, and worked everywhere, and > >> we are replacing this with a more complicated and more brittle scheme. > >> > >> Dunno, if you think things are better this way, I'm fine with that, > >> since both schemes should get the job done. But in the end, adding a > >> switch in journald.conf seems more in the systemd spirit of doing the right > >> thing automatically and also less work for both sides... > > > > What about this solution: let's go the tmpfiles way, but also add some > > code to the journal file writer to log at INFO level an actionable > > recommendation to turn on the c flag on the directory if we notice > > that the newly created file doesn't have it, and it is located on > > btrfs? > > After the work that I done to the tmpfiles, I have to agree with > Zbyszek. Adding an option to the journal.conf file is the more > reasonable thing to do. You mean journald.conf I figure? That's not even read by the remoting tools, so how is that a solution? > If we add code that performs only a check in the code of journal, I think > that we have the worst solution: > - journal code is still aware of the NOCOW attribute (== more code complexity) > - the user had to update/manage a tmpfile.d manually Well, again: the nocow thing is a work-around around a design issue with btrfs, and btrfs is working on correcting that, by adding auto-defrag to deal better with write patterns such as this. We should not add new explicit config options for things we already know *now* that they are a stopgap, and will go away eventually. With the solution I propose (which is tmpfiles snippet + warning if non-enabled) we get: - default behaviour is fast - default behaviour is easy to override - specialist users who use the remoting feature and use the thing on a non-default directory, are notified about the issue at hand. - we can easily get rid of it eventually, simply by dropping one config line and the generation of a warning. There's no option to deprecate then, and keep compat for. > Let me to suggest the opposite solution: > - add a switch in the journald.conf file > - add a check that raise a warning if the NOCOW flag is not-used/used > This does not fix the remoting issue, since journald.conf isn't read by those tools. Also, it adds a setting we'll eventuall have to get rid of again. Sorry, but I am really against a solution like that. I don't want to litter the config file with options that are hacks and will go away one day... 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] network: allow domain names up to 255 characters
On Sun, Apr 12, 2015 at 6:35 AM, Lennart Poettering wrote: > On Fri, 10.04.15 13:03, Nick Owens (misch...@offblast.org) wrote: > >> From: mischief >> >> The maximum domain name size is larger than the maximum host name size. >> The smaller limit causes valid domains provided by DHCP or .network >> files to be silently ignored. > > Hmm? > > Can you give an example? > > What is a domain name according to your definition? And what a > hostname? > > So far, a hostname in my definition was either a single label, or an > fqdn, and a domain name the part of the fqdn with the first label > removed... > > With such a definition I am not sure I understand the patch, hence > please explain, and give a valid example of where this turns out to be > an issue? ./x86_64-linux-gnu/bits/posix1_lim.h:#define _POSIX_HOST_NAME_MAX 255 ./x86_64-linux-gnu/bits/local_lim.h:#define HOST_NAME_MAX 64 ./x86_64-linux-musl/limits.h:#define HOST_NAME_MAX 255 Perhaps we need to use _POSIX_HOST_NAME_MAX ?, or redefine HOST_NAME_MAX to 255? > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Liberty equality fraternity or death, Shawn Landden ChurchOfGit.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On 04/12/2015 05:47 PM, Kai Krakow wrote: > Elias Probst schrieb: > >> On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: >>> I'm wondering if we should provide better per-user tmpfiles support. >>> For example, if we allowed a set of "user" tmpfiles, which would >>> be executed by the system instance, but would be considered relative to >>> the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home >>> directory, %t to XDG_RUNTIME_DIR, ...). We would execute that for every >>> user. >> >> Which makes me wonder again, why tmpfiles.d was never implemented in the >> way all other units are implemented. >> Currently, it's impossible to declare a dependency of a service upon a >> tmpdir, which feels out of line with the way things are usually handled >> in a systemd-based system. >> >> For example: >> OpenVPN requires /run/openvpn/ to exist before being able to start. >> This leads to the following possible scenarios to make OpenVPN usable on >> a system where OpenVPN was just installed (and there was no reboot to >> trigger tmpfiles.d creation) yet: >> >> A# >> - the package manager creates /run/openvpn as part of of its postinst >> routine. This is duplicated effort and could easily go out of sync with >> the definition in OpenVPN's tmpfiles.d configuration >> >> B# >> - the package manager calls "systemd-tmpfiles --create …" whenever a >> tmpfiles.d configuration was installed. This might still be the most >> straightforward way, but it could still happen that a user manually >> deletes the directory and than at a later point attempts to start a >> service depending on it >> >> C# >> - the user has to create /run/openvpn manually (I don't think I have to >> outline why this is no "correct" solution) >> >> D# >> - creation of tmpfile directories is left to the application (again >> duplicated effort and the wrong place to do it, when there is a >> centralized mechanism for handling this properly) >> >> E# >> - the service unit contains something like "ExecPre=/bin/mkdir …". Again >> duplicated effort and the wrong place to do it. > > F# > - the service file contains a RuntimeDirectory directive. > > ;-) > Ha! Perfect! Thanks a lot for pointing this out. My initial bugreport against Gentoo [1] regarding this issue is older than the implementation of RuntimeDirectory [2] - time for updating the bugreport + getting upstream (OpenVPN) involved to ship an updated service unit and get rid of their tmpfiles.d conf. [1] https://bugs.gentoo.org/show_bug.cgi?id=462118 [2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=e66cf1a3 - Elias signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] TODO
Hi Lennart, I just asked about the status of this, so I have links handy: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1423811 https://bugs.archlinux.org/task/44016 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778970 https://bugzilla.redhat.com/show_bug.cgi?id=1201964 All of these distros currently do not ship 219 or have 219 with said patch reverted. First referrence to the issue on this list: http://lists.freedesktop.org/archives/systemd-devel/2015-February/028640.html I was wondering about the status a couple of days ago: http://lists.freedesktop.org/archives/systemd-devel/2015-April/030540.html Best Regards, Tobias On Sun, Apr 12, 2015 at 3:32 PM, Lennart Poettering wrote: > On Sat, 11.04.15 03:13, David Herrmann (dvd...@kemper.freedesktop.org) wrote: > >> Before 220: >> >> +* Figure out why 13790add4 breaks boot across all distributions. Revert it >> if >> + we cannot get it fixed. >> + > > Hmm, what's this about? Works fine here? > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > 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] SystemD, Gnome permission problems
Elias Probst schrieb: > On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: >> I'm wondering if we should provide better per-user tmpfiles support. >> For example, if we allowed a set of "user" tmpfiles, which would >> be executed by the system instance, but would be considered relative to >> the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home >> directory, %t to XDG_RUNTIME_DIR, ...). We would execute that for every >> user. > > Which makes me wonder again, why tmpfiles.d was never implemented in the > way all other units are implemented. > Currently, it's impossible to declare a dependency of a service upon a > tmpdir, which feels out of line with the way things are usually handled > in a systemd-based system. > > For example: > OpenVPN requires /run/openvpn/ to exist before being able to start. > This leads to the following possible scenarios to make OpenVPN usable on > a system where OpenVPN was just installed (and there was no reboot to > trigger tmpfiles.d creation) yet: > > A# > - the package manager creates /run/openvpn as part of of its postinst > routine. This is duplicated effort and could easily go out of sync with > the definition in OpenVPN's tmpfiles.d configuration > > B# > - the package manager calls "systemd-tmpfiles --create …" whenever a > tmpfiles.d configuration was installed. This might still be the most > straightforward way, but it could still happen that a user manually > deletes the directory and than at a later point attempts to start a > service depending on it > > C# > - the user has to create /run/openvpn manually (I don't think I have to > outline why this is no "correct" solution) > > D# > - creation of tmpfile directories is left to the application (again > duplicated effort and the wrong place to do it, when there is a > centralized mechanism for handling this properly) > > E# > - the service unit contains something like "ExecPre=/bin/mkdir …". Again > duplicated effort and the wrong place to do it. F# - the service file contains a RuntimeDirectory directive. ;-) -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.
On 2015-04-12 15:12, Lennart Poettering wrote: > On Sat, 11.04.15 17:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > That's the problem: current functionality works no matter where you store the files, but it's hard to provide the same level of flexibility with the tmpfiles-based solution. >>> >>> Well, but we never store files outside of /var/log/journal, >>> /var/log/journal/%m and /var/log/journal/remote/, do we? >> We can, if instructed to do so. journal-remote can store files wherever. >> >> Original motivation for this patch was to make the NOCOW on journal files >> configurable without too much fuss and without making it an explicit option. >> Journal files on btrfs without NOCOW are rather slow, so it seems that most >> people will want NOCOW on. But with the proposed patch, people would want >> to add the tmpfile snippet to set NOCOW for every location they write too, >> which is very visible and requires explicit configuration. Doing this in >> journal-file directly was simple, synchronous, and worked everywhere, and >> we are replacing this with a more complicated and more brittle scheme. >> >> Dunno, if you think things are better this way, I'm fine with that, >> since both schemes should get the job done. But in the end, adding a >> switch in journald.conf seems more in the systemd spirit of doing the right >> thing automatically and also less work for both sides... > > What about this solution: let's go the tmpfiles way, but also add some > code to the journal file writer to log at INFO level an actionable > recommendation to turn on the c flag on the directory if we notice > that the newly created file doesn't have it, and it is located on > btrfs? After the work that I done to the tmpfiles, I have to agree with Zbyszek. Adding an option to the journal.conf file is the more reasonable thing to do. If we add code that performs only a check in the code of journal, I think that we have the worst solution: - journal code is still aware of the NOCOW attribute (== more code complexity) - the user had to update/manage a tmpfile.d manually Let me to suggest the opposite solution: - add a switch in the journald.conf file - add a check that raise a warning if the NOCOW flag is not-used/used GB > > That way, folks who use the tools on non-default directories will at > least be guided to an explanation of the general problem. > > Lennart > -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- gpg @keyserver.linux.it: Goffredo Baroncelli Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On 04/12/2015 04:11 PM, Zbigniew Jędrzejewski-Szmek wrote: > I'm wondering if we should provide better per-user tmpfiles support. > For example, if we allowed a set of "user" tmpfiles, which would > be executed by the system instance, but would be considered relative to > the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home > directory, > %t to XDG_RUNTIME_DIR, ...). We would execute that for every user. Which makes me wonder again, why tmpfiles.d was never implemented in the way all other units are implemented. Currently, it's impossible to declare a dependency of a service upon a tmpdir, which feels out of line with the way things are usually handled in a systemd-based system. For example: OpenVPN requires /run/openvpn/ to exist before being able to start. This leads to the following possible scenarios to make OpenVPN usable on a system where OpenVPN was just installed (and there was no reboot to trigger tmpfiles.d creation) yet: A# - the package manager creates /run/openvpn as part of of its postinst routine. This is duplicated effort and could easily go out of sync with the definition in OpenVPN's tmpfiles.d configuration B# - the package manager calls "systemd-tmpfiles --create …" whenever a tmpfiles.d configuration was installed. This might still be the most straightforward way, but it could still happen that a user manually deletes the directory and than at a later point attempts to start a service depending on it C# - the user has to create /run/openvpn manually (I don't think I have to outline why this is no "correct" solution) D# - creation of tmpfile directories is left to the application (again duplicated effort and the wrong place to do it, when there is a centralized mechanism for handling this properly) E# - the service unit contains something like "ExecPre=/bin/mkdir …". Again duplicated effort and the wrong place to do it. This leads me to the question: are there any real technical/conceptual reasons, why tmpfiles.d handling wasn't implemented in the "systemd unit" way which would allow a service to depend on the correct state of one or more tmpfiles.d items, so on each service startup, the existence + state of the required directories would be verified and ensured. - Elias 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 v2] udev: settle should return immediately when timeout is 0
udevadm manual says:
A value of 0 will check if the queue is empty and always return
immediately.
However, currently we ignore the deadline if the value is 0, and wait
without any limit.
Zero timeout behaved according to the documentation until commit
ead7c62ab7 (udevadm: settle - kill alarm()). Looking at this patch, it
seems that the behavior change was unintended.
This patch restores the documented behavior.
---
src/udev/udevadm-settle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 2c84ada..437c794 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -142,7 +142,7 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
break;
}
-if (timeout > 0 && now(CLOCK_MONOTONIC) >= deadline)
+if (now(CLOCK_MONOTONIC) >= deadline)
break;
/* wake up when queue is empty */
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] python-systemd: fix is_socket_inet to cope with ports
On Wed, Mar 25, 2015 at 05:00:09PM +, Simon Farnsworth wrote: > Just a couple of trivial oversights. > --- > src/python-systemd/_daemon.c | 2 +- > src/python-systemd/daemon.py | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Applied. Thanks for the fix. We really should have a test suite for the Python code. With systemd-journal-remote available we could now have a sensible one which also tests the python journal wrapper without requiring access to the system journal. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SystemD, Gnome permission problems
On Sun, Apr 12, 2015 at 03:41:31PM +0200, Lennart Poettering wrote: > On Sat, 11.04.15 16:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote: > > > dean schrieb: > > > > > > > Ok thanks for your prompt reply. It is my understanding the the > > > > house-keeping-plugin "cleans" /tmp so does it need access? > > That sounds wrong. First, systemd is already cleaning /tmp, so nothing > > good is going to come out of cleaning it twice. Second, doing cleanup > > as unprivileged user does not really work. If the user is not running, > > the cleanup is not going to happen, so on a multi-user system, when the > > user logs out, files would stay around infinetely. So cleanup from > > the graphical session is ineffective. More importantly, an unprivileged > > user cannot access files without bumping their access time stamp. So > > trying to do the cleanup as an unprivileged user actually interferes > > with systemd-tmpfiles (see df99a9ef5bb7a89b92 and > > https://bugzilla.redhat.com/show_bug.cgi?id=1183684). > > Yes, I figully agree... GNOME shouldn't bother with this, it's > actively harmful to do this. > > I file a bug now: > > https://bugzilla.gnome.org/show_bug.cgi?id=747737 Thanks. I'm wondering if we should provide better per-user tmpfiles support. For example, if we allowed a set of "user" tmpfiles, which would be executed by the system instance, but would be considered relative to the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home directory, %t to XDG_RUNTIME_DIR, ...). We would execute that for every user. gnome could possibly replace its custom thumbnails cleaner with a few lines of tmpfiles config. There would be two advantages: creation time cleanup could be replaced with access time cleanup, cleanup wouldn't be dependent on the session running. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disable dbus-daemon for a service
On Sun, 12.04.15 10:54, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: > When I start Firefox, it starts --config-file=/etc/at-spi2/accessibility.conf>, part of the Gnome's > Accessibility Project. I guess it is tarts with: > > < /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session> That is a private bus started and owned by at-spi. I think they have reasons to (too much traffic), but I doubt you can turn this off without altering at-spi... 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] issuing 'reboot' command does not print the familiar 'Restarting system.' message
On Fri, 10.04.15 12:35, Ani Sinha (a...@arista.com) wrote: > On Fri, Apr 10, 2015 at 10:18 AM, Ani Sinha wrote: > > Thanks Lennart for the clarification. Much appreciated! > > > > Ani > > > > > > On Fri, Apr 10, 2015 at 8:58 AM, Lennart Poettering > > wrote: > >> On Fri, 10.04.15 08:40, Ani Sinha (a...@arista.com) wrote: > >> > >>> On Fri, Apr 10, 2015 at 1:13 AM, Daniel Mack wrote: > >>> > On 04/10/2015 04:18 AM, Ani Sinha wrote: > >>> >> OK I have one more question. Does every call path in the reboot > >>> >> command use the Linux reboot() sys call? I'm not familiar with dbus > >>> >> stuff but looking at the code seems to indicate that there might be > >>> >> some paths where reboot() is not issued. Just wanted to run by you > >>> >> guys since you guys know the code best. > >>> > > >>> > The reboot command is symlinked to systemctl, which is a multi-call > >>> > binary. When invoked as 'reboot', 'shutdown', 'halt', 'poweroff' etc, it > >>> > communicates with PID1 and tells it to start one of the shutdown > >>> > targets. This way, the system will shut down and stop services in a > >>> > clean way. Once the target is reached, the reboot() syscall is issued to > >>> > the kernel. > >>> > >>> Can you please point me to the code and function call that processes > >>> the 'reboot' target from PID 1? > >> > >> reboot.target pulls in systemd-reboot.service, which wraps > >> "/usr/bin/systemctl --force reboot", which issues the Reboot() call on > >> PID1's bus API, which causes it to execute /usr/lib/systemd-shutdown > >> as PID 1 which then kills everything and reboots. > > OK I see it now. shutdownd.c eventually issues 'shutdown -r now'. This > gets parsed by shutdown_parse_argv(). Eventually we end up calling > halt_main() ->halt_now() ->reboot(RB_AUTOBOOT). Hmm? shutdownd's only raison d'etre is to support scheduled shutdowns. It's not used unless you actually use scheduled shutdowns. If you just use "systemctl poweroff" or so, then it will *not* be used at all, and is not involved at all in the shutdown logic. And no! shutdownd will never call halt_main(), nor halt_now(), nor reboot(RB_AUTOBOUT). If you use shutdownd, then this will result in the equiavlent of "systemctl poweroff" and so on, just delayed a bit. Please don't confuse shutdownd.c and shutdown.c. The former is just there for the scheduled shutdown bits, the latter is the always used last part of the shutdown logic. 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] SystemD, Gnome permission problems
On Sat, 11.04.15 16:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Sat, Apr 11, 2015 at 02:26:57PM +0200, Kai Krakow wrote: > > dean schrieb: > > > > > Ok thanks for your prompt reply. It is my understanding the the > > > house-keeping-plugin "cleans" /tmp so does it need access? > That sounds wrong. First, systemd is already cleaning /tmp, so nothing > good is going to come out of cleaning it twice. Second, doing cleanup > as unprivileged user does not really work. If the user is not running, > the cleanup is not going to happen, so on a multi-user system, when the > user logs out, files would stay around infinetely. So cleanup from > the graphical session is ineffective. More importantly, an unprivileged > user cannot access files without bumping their access time stamp. So > trying to do the cleanup as an unprivileged user actually interferes > with systemd-tmpfiles (see df99a9ef5bb7a89b92 and > https://bugzilla.redhat.com/show_bug.cgi?id=1183684). Yes, I figully agree... GNOME shouldn't bother with this, it's actively harmful to do this. I file a bug now: https://bugzilla.gnome.org/show_bug.cgi?id=747737 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] network: allow domain names up to 255 characters
On Fri, 10.04.15 13:03, Nick Owens (misch...@offblast.org) wrote: > From: mischief > > The maximum domain name size is larger than the maximum host name size. > The smaller limit causes valid domains provided by DHCP or .network > files to be silently ignored. Hmm? Can you give an example? What is a domain name according to your definition? And what a hostname? So far, a hostname in my definition was either a single label, or an fqdn, and a domain name the part of the fqdn with the first label removed... With such a definition I am not sure I understand the patch, hence please explain, and give a valid example of where this turns out to be an issue? 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] [systemd-commits] TODO
On Sat, 11.04.15 03:13, David Herrmann (dvd...@kemper.freedesktop.org) wrote: > Before 220: > > +* Figure out why 13790add4 breaks boot across all distributions. Revert it if > + we cannot get it fixed. > + Hmm, what's this about? Works fine here? 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 1/2] Revert patch 11689d2a which force the NOCOW attribute
On Sat, 11.04.15 14:29, Goffredo Baroncelli (kreij...@libero.it) wrote:
> Hi Lennart,
>
> On 2015-04-08 23:12, Lennart Poettering wrote:
> >> --- a/src/journal/journalctl.c
> >> > +++ b/src/journal/journalctl.c
> >> > @@ -1290,7 +1290,7 @@ static int setup_keys(void) {
> >> > size_t mpk_size, seed_size, state_size, i;
> >> > uint8_t *mpk, *seed, *state;
> >> > ssize_t l;
> >> > -int fd = -1, r;
> >> > +int fd = -1, r, attr = 0;
> >> > sd_id128_t machine, boot;
> >> > char *p = NULL, *k = NULL;
> >> > struct FSSHeader h;
> >> > @@ -1385,9 +1385,13 @@ static int setup_keys(void) {
> >> >
> >> > /* Enable secure remove, exclusion from dump, synchronous
> >> > * writing and in-place updating */
> >> > -r = chattr_fd(fd, true,
> >> > FS_SECRM_FL|FS_NODUMP_FL|FS_SYNC_FL|FS_NOCOW_FL);
> >> > -if (r < 0)
> >> > -log_warning_errno(errno, "Failed to set file
> >> > attributes: %m");
> >> > +if (ioctl(fd, FS_IOC_GETFLAGS, &attr) < 0)
> >> > +log_warning_errno(errno, "FS_IOC_GETFLAGS failed: %m");
> >> > +
> >> > +attr |= FS_SECRM_FL|FS_NODUMP_FL|FS_SYNC_FL|FS_NOCOW_FL;
> >> > +
> >> > +if (ioctl(fd, FS_IOC_SETFLAGS, &attr) < 0)
> >> > +log_warning_errno(errno, "FS_IOC_SETFLAGS failed: %m");
> > This is unrelated, and should not be reverted at all.
> >
> > Lennart
>
> Ok, this was a my fault to revert this chunk; anyway I would like to
> know which is the purpose of the FS_NOCOW_FL flag here. If I read
> the code, the file is few hundred bytes long, so in BTRFS this would
> be stored in the metadata chunk, and I am not sure if FS_NOCOW_FL is
> honored at all...
The FSS key file stores a generation key that is replaced by the next
generation in regular intervals. The old key should be flushed out at
that time, forgotten, and non-recoverable (because otherwise the
concept of FSS would be pointless...). COW file systems have the
tendency of being bad at "fogetting" things... Hence we set a variety
of bits to tell the filesystem to really get rid of the data when we
rewrite the file, including NOCOW, to avoid that the file is copied
when we write a newer key into...
Also, even if some file systems don't understand some of the bits, we
still should pass all that are appropriate to ensure that we make this
as good as we can even on (future) file systems whose behaviour we
don't know yet... (Let's not forget that the FS_NOCOW_FL is generic,
and could even be implemented by a new file system, maybe ZFS. It's
not called FS_BTRFS_NOCOW_FL after all..)
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 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.
On Sat, 11.04.15 17:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > That's the problem: current functionality works no matter where you > > > store the files, but it's hard to provide the same level of > > > flexibility with the tmpfiles-based solution. > > > > Well, but we never store files outside of /var/log/journal, > > /var/log/journal/%m and /var/log/journal/remote/, do we? > We can, if instructed to do so. journal-remote can store files wherever. > > Original motivation for this patch was to make the NOCOW on journal files > configurable without too much fuss and without making it an explicit option. > Journal files on btrfs without NOCOW are rather slow, so it seems that most > people will want NOCOW on. But with the proposed patch, people would want > to add the tmpfile snippet to set NOCOW for every location they write too, > which is very visible and requires explicit configuration. Doing this in > journal-file directly was simple, synchronous, and worked everywhere, and > we are replacing this with a more complicated and more brittle scheme. > > Dunno, if you think things are better this way, I'm fine with that, > since both schemes should get the job done. But in the end, adding a > switch in journald.conf seems more in the systemd spirit of doing the right > thing automatically and also less work for both sides... What about this solution: let's go the tmpfiles way, but also add some code to the journal file writer to log at INFO level an actionable recommendation to turn on the c flag on the directory if we notice that the newly created file doesn't have it, and it is located on btrfs? That way, folks who use the tools on non-default directories will at least be guided to an explanation of the general problem. 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] [RFC 2/6] proxy-discoveryd: Add the basics for parsing the default configuration
On Fri, 10.04.15 15:22, Marcel Holtmann (mar...@holtmann.org) wrote: > Hi Lennart, > > >> The config file will be in /etc/systemd/proxy/.conf > >> > >> It currently only load "Proxy" parts, with the key PAC. Rest is ignored. > >> The PAC keyword is a path to a .pac file (a specific js script for proxy > >> configuration). > >> > >> Only one PAC based proxy configuration will be loaded at a time. > > > > (Just a side note: I figure in the long run we should probably track > > PAC data per-interface (plus maybe one global setting), so that > > clients can query this specifically for an interface, and so that we > > can search PAC data over the right network. But I figure for now this > > doesn't matter too much.). > > why would you have a global PAC file. I think they should be all per > interface and nothing else. Well, maybe not a global PAC file, but probably an explicitly configurable global HTTP proxy, if people want that... I mean, it is a pretty common setting to have I figure, and the daemon should proibably cover both PAC and straightforward proxy config... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Disable dbus-daemon for a service
When I start Firefox, it starts , part of the Gnome's Accessibility Project. I guess it is tarts with: < /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session> I would like to get rid of this dbus daemon. I found one solution was to export NOT_AT_BRIDGE=1, but it doesn't work for me. I can of course remove/rename , but it is not a clean solution. I tried playing with /etc/dbus-1/session-local.conf with adding some policy: --- -- But it didn't work. So may someone please tell me how to prevent a service, in general, to start a dbus session? Thank you -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] udev: settle should return immediately when timeout is 0
udevadm manual says:
A value of 0 will check if the queue is empty and always return
immediately.
However, currently we ignore the deadline if the value is 0, and wait
without any limit.
Zero timeout behaved according to the documentation until commit
ead7c62ab7 (udevadm: settle - kill alarm()). Looking at this patch, it
seems that the behavior change was unintended.
This patch restores the documented behavior.
---
src/udev/udevadm-settle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 2c84ada..437c794 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -142,7 +142,7 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
break;
}
-if (timeout > 0 && now(CLOCK_MONOTONIC) >= deadline)
+if (now(CLOCK_MONOTONIC) >= deadline)
break;
/* wake up when queue is empty */
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
