Re: [systemd-devel] consider renaming -.slice
systemd-journalctl and systemd-systemctl were also renamed to get more convenient ... (But hey, I don't really know what external stuff uses -.slice and -.mount ...) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider renaming -.slice
On Thu, Jan 16, 2014 at 8:59 AM, Holger Schurig holgerschu...@gmail.com wrote: systemd-journalctl and systemd-systemctl were also renamed to get more convenient ... Symlinks are cheap to create, if compat for these rather exotic things is needed. systemctl was always systemctl, but loginctl we also have renamed. (But hey, I don't really know what external stuff uses -.slice and -.mount ...) The problem is that / is escaped as '-, and root is therefore just -. We would need to change all mount unit names, which all have - for the / in it: home-kay-data.mount run-user-2702-gvfs.mount sys-fs-fuse-connections.mount Unlike the name for a rather optional binary, renaming that would cause a lot of things to break. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Patch 0/2] logind: make sure that closed sessions will be cleaned
On Thu, Jan 16, 2014 at 06:01:58AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Jan 12, 2014 at 02:07:32AM +0100, Djalal Harouni wrote: On Sat, Jan 11, 2014 at 10:26:13PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jan 03, 2014 at 02:19:19PM +0100, Djalal Harouni wrote: On logout pam_systemd should ensures the following: If the last concurrent session of a user ends, the $XDG_RUNTIME_DIR directory and all its contents are removed, too. from manpage. Using git HEAD, and a simple systemd-nspawn test will show that the above is not ensured and the sessions will stay! I can't reproduce this (with todays git). In the examples below, I understand that you're logging in through getty. Can you test with current git and/or provide a complete recipe to reproduce this? Yes through getty, and I guess this issue will also be visible for ssh/remote sessions, or sessions where TerminateSession() is not called. Thank you for the recipe. This helps. Indeed, in a container (without your patches), sessions remain in closing state. But with your patches, systemd --user instance is started and killed immediately during login. Not good either :) Ok, ouch! With just the first patch, session still remain as closing. Ok, thanks for the input, I'll work on it soon Also, there seems to be a regression with Fedora installs with yum: I installed a fresh one, and there was no /var/run - /run symlink, the first boot was mostly broken. - https://bugzilla.redhat.com/show_bug.cgi?id=1053983 Oh yes, I forgot about that, yes I fixed it in my install! Indeed, the bug is in yum, totally forget to report it, sorry :-/ Zbyszek Thanks! -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider renaming -.slice
Oh, I confused that with the old /etc/systemd/systemd-journald.conf file, which was renamed. Kay, I only meant to special case the /, e.g. let home-kay-data.mount be it like it is, but rename - to root, so that it is root.mount and root.slice. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider renaming -.slice
On Thu, Jan 16, 2014 at 11:27:42AM +0100, Holger Schurig wrote: Oh, I confused that with the old /etc/systemd/systemd-journald.conf file, which was renamed. Kay, I only meant to special case the /, e.g. let home-kay-data.mount be it like it is, but rename - to root, so that it is root.mount and root.slice. This would still break applications like libvirt which expect the current naming conventions. These naming conventions must be considered to be part of the stable API for apps and so cannot be changed once included in an official release. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider renaming -.slice
'Twas brillig, and Holger Schurig at 16/01/14 10:27 did gyre and gimble: Oh, I confused that with the old /etc/systemd/systemd-journald.conf file, which was renamed. Kay, I only meant to special case the /, e.g. let home-kay-data.mount be it like it is, but rename - to root, so that it is root.mount and root.slice. The problem with special casing it to root.mount is that this would prevent you having a /root mountpoint as it would also be encoded as root.mount So anything you special case it *to* has to be invalid in it's own right. -.mount fits this bill, but not sure if anything else does... Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider renaming -.slice
On Jan 16, 2014 9:34 AM, Holger Schurig holgerschu...@gmail.com wrote: Please consider renamign -.slice, because this sucks: # cd /lib/systemd/system # grep -r user@ * grep: invalid option -- '.' Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. Yes, I know that I can use grep -r -- user@ *, but this is just inconvenient. You can also use `grep -r user@ .` since you're passing -r anyway. (Latest grep even uses . as the default with -r.) Or you can use `grep -r user@ ./*` ___ 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 --user and kdbus
On Sat, Jan 11, 2014 at 7:04 PM, Kay Sievers k...@vrfy.org wrote: We got systemd git working to be able to run a full GNOME (Fedora 20) user session with kdbus now. Instead of dbus-daemon running and activating applications, they are directly started by the systemd --user instance now. Here is the output of ps: http://people.freedesktop.org/~kay/kdbus-user.txt The automatically activated proxies will go away as soon as glib, and possibly libdbus-1, are ported to connect natively to kdbus instead of the unix socket, The X login session needs to export $DISPLAY to systemd --user. Something like this should take care of that: --- $ cat /etc/X11/xinit/xinitrc.d/systemd-user.sh #!/bin/sh systemctl --user set-environment DISPLAY=$DISPLAY --- This got simpler with systemd git now, as: systemctl --user import-environment DISPLAY Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] daemon-reload seems racy
'Twas brillig, and Colin Guthrie at 14/01/14 13:28 did gyre and gimble: 3. Some sort of kernel trigger for me today led it to run two reexecs quite quickly and triggered this problem randomly during runtime. This *might* have come in via telinit u instead. It doesn't appear that the kernel actually execs telinit directly but perhaps userspace can react on it in some way? OK, this, it turns out is a result of running prelink via cron. The prelink package we (Mageia) have is basically the same as the Fedora one. It has a cronjob which calls telinit u but the prelink binary itself calls /sbin/init U which does the same thing, thus two daemon-reexecs in rapid succession which triggers this bug. For now I've disabled the telinit u call in prelink, but the real trick would be fixing the bug/race in serialisation :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider renaming -.slice
On Thu, 16.01.14 11:27, Holger Schurig (holgerschu...@gmail.com) wrote: Oh, I confused that with the old /etc/systemd/systemd-journald.conf file, which was renamed. Kay, I only meant to special case the /, e.g. let home-kay-data.mount be it like it is, but rename - to root, so that it is root.mount and root.slice. This is not reversible as both /root and / would then map to root.slice. We need an bijective mapping here from cgroup/fs paths to unit names... 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] consider renaming -.slice
On Thu, 16.01.14 08:33, Holger Schurig (holgerschu...@gmail.com) wrote: Please consider renamign -.slice, because this sucks: # cd /lib/systemd/system # grep -r user@ * grep: invalid option -- '.' Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information. Yes, I know that I can use grep -r -- user@ *, but this is just inconvenient. Well, it's kinda built into the API for now (as pointed out by others), and it is quite systematic, since / simply maps to - when turning cgroup or file system paths into unit names. That also makes the encoding reversible which we rely on. I understand that this is inconvenient, but then again, -.slice and -.mount are not the most frequently used units, so I am not too concerned. That all said, we could actually change it, and keep compat with an alias name, however, if we do that, we really should have a very good reason, and also, we'd need a convincing encoding, that is also obvious, and reversible, and I see none for that... 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] [PATCHv5] tmpfiles, man: Add xattr support to tmpfiles
11.12.2013 at 15:15 Lennart Poettering lenn...@poettering.net wrote:
On Wed, 11.12.13 14:24, Maciej Wereski (m.were...@partner.samsung.com)
wrote:
+xattr = new0(char, strlen(i-argument)+1);
+if (!xattr)
+return log_oom();
+
+tmp = strv_split(i-argument, WHITESPACE);
+if (!tmp)
+return log_oom();
+
+strv_len = strv_length(tmp);
+for (n = 0; n strv_len; ++n) {
Sounds like a job for the STRV_FOREACH() macro. Since you don't
actually
need the strv as strv here it sounds like you actually really want to
use FOREACH_WORD_QUOTED() for this, which will also do the unquoting
for
you.
Well, FOREACH_WORD_QUOTED() won't work properly, because quotation marks
aren't first chars in strings (e.g. user.name=John Smith). Maybe
better
idea would be to introduce mandatory separator (e.g. semicolon) instead
of
quotation marks.
Yeah, FOREACH_WORD_QUOTED() is quite badly designed. We should fix it to
do somewhat sane quoting and escaping. I'll look into it.
There is one problem with using it in this patch. In my case quotation
mark isn't first char of the string, so using pointer and length won't get
rid of it. String needs to be modified.
regards,
--
Maciej Wereski
Samsung RD Institute Poland
Samsung Electronics
m.were...@partner.samsung.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] why does nofail imply no After= in /etc/fstab
On Wed, 15.01.14 20:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I was a bit surprised that for mount points the dependency Before=local-fs.target is only added when nofail is not used. This seems to be a concious decision (added by Lennart in 155da457, and then survived all the refactorings by Tom and Thomas...). Do we still want this behaviour? Well, nofail means that we shouldn't bother if the device doesn't show up at boot. Now, if we add After= for it there, then we will time-out on it (though not fail) if something else pulls it in. I figure this is a question what nofail really should mean: never wait for it, never fail for it (which is the status quo), or just usually don't wait, never fail for it (which would be the change if we added After= in). I am tempted to say that the status quo is more likely what people would expect, no? 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] why does nofail imply no After= in /etc/fstab
On Thu, 16.01.14 16:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Jan 16, 2014 at 03:51:02PM +0100, Lennart Poettering wrote: On Wed, 15.01.14 20:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I was a bit surprised that for mount points the dependency Before=local-fs.target is only added when nofail is not used. This seems to be a concious decision (added by Lennart in 155da457, and then survived all the refactorings by Tom and Thomas...). Do we still want this behaviour? Well, nofail means that we shouldn't bother if the device doesn't show up at boot. Now, if we add After= for it there, then we will time-out on it (though not fail) if something else pulls it in. I figure this is a question what nofail really should mean: never wait for it, never fail for it (which is the status quo), or just usually don't wait, never fail for it (which would be the change if we added After= in). I am tempted to say that the status quo is more likely what people would expect, no? The problem is that with current boot speeds, usually don't wait means that it shows up at some upredictable time. With a bit of luck, users might be able to log in before such mount points which are declared in /etc/fstab are mounted. I think that's unexpected, because it goes againt the general rule that things declared in /etc/fstab (w/o automount or noauto) are mounted at boot. I'd argue that nofail is precisely what the admin can use to *enable* this race. If it should be avoided to allow the user to log in before the device has shown up and is hooked in the admin should not have used nofail... I'd prefer to keep things orthogonal. This feels like an optimization that it user visible. We should rather encourage people to use automounts if the don't want to wait for the mountpoint to come up. I am pretty sure people would be annoyed by this change of behaviour, simply because every boot would still delay for 90s if the device is not plugged in. I have the suspicion that people would really assume that using nofail would make their system boot-up cleanly, without delays if the file system cannot be found -- and that expection is something we'd not fulfill? 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] why does nofail imply no After= in /etc/fstab
On Jan 16, 2014, at 7:51 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 15.01.14 20:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I was a bit surprised that for mount points the dependency Before=local-fs.target is only added when nofail is not used. This seems to be a concious decision (added by Lennart in 155da457, and then survived all the refactorings by Tom and Thomas...). Do we still want this behaviour? Well, nofail means that we shouldn't bother if the device doesn't show up at boot. Now, if we add After= for it there, then we will time-out on it (though not fail) if something else pulls it in. I figure this is a question what nofail really should mean: never wait for it, never fail for it (which is the status quo), or just usually don't wait, never fail for it (which would be the change if we added After= in). I am tempted to say that the status quo is more likely what people would expect, no? It depends on how literal you want it to be. I think most people using nofail use it as a hammer to both don't wait or fail. Linguistically nofail doesn't indicate whether to wait, only to not fail. So I'd say with nofail, tolerate some wait but don't fail. If there's some delay with a device appearing, hence the wait, then it seems to me that's a different problem that probably shouldn't be masked by nofail, but maybe such problems are common (?). The alternate is an added option nowait which would also imply nofail. That would also be literal. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 6/8] add GOP mode setting and splash drawing support
Hi, On 14.01.2014 16:13, Tom Gundersen wrote: On Tue, Jan 14, 2014 at 2:15 PM, Joonas Lahtinen joonas.lahti...@linux.intel.com wrote: I've implemented very basic BMP support and commited it. The custom format was there for best possible speed to be achieved when displaying the splash, as the original use case is extremely time critical. I will look into the speed differences and see if there's still need to use the custom format. In case it is still causing your trouble, the BMP parser can certainly be optimized a bit. In particular, if you target a specific format (e.g. without alpha support etc). By our measurements, the original BGRX code only adds some 5 milliseconds to the boot time compared to no logo at all, where the BMP code adds almost 70 milliseconds. I think the most difference comes from the fact that in the BGRX file the pixel data is already in format suitable format for UEFI blit operations, and pixels are pushed to the blit operation as a big batch, just like they are loaded as one big batch. The BMP code invidually loops each pixel. Would the BGRX format be accepted aside the BMP format, for these speed reasons? Regards, Joonas Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 6/8] add GOP mode setting and splash drawing support
Hi Joonas, On Thu, Jan 16, 2014 at 4:13 PM, Joonas Lahtinen joonas.lahti...@linux.intel.com wrote: By our measurements, the original BGRX code only adds some 5 milliseconds to the boot time compared to no logo at all, where the BMP code adds almost 70 milliseconds. I think the most difference comes from the fact that in the BGRX file the pixel data is already in format suitable format for UEFI blit operations, and pixels are pushed to the blit operation as a big batch, just like they are loaded as one big batch. The BMP code invidually loops each pixel. Would the BGRX format be accepted aside the BMP format, for these speed reasons? Could we first try to optimize the BMP loader? Also, could you share your test image so I can have a look? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] why does nofail imply no After= in /etc/fstab
On Thu, Jan 16, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 16.01.14 16:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Jan 16, 2014 at 03:51:02PM +0100, Lennart Poettering wrote: On Wed, 15.01.14 20:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I was a bit surprised that for mount points the dependency Before=local-fs.target is only added when nofail is not used. This seems to be a concious decision (added by Lennart in 155da457, and then survived all the refactorings by Tom and Thomas...). Do we still want this behaviour? Well, nofail means that we shouldn't bother if the device doesn't show up at boot. Now, if we add After= for it there, then we will time-out on it (though not fail) if something else pulls it in. I figure this is a question what nofail really should mean: never wait for it, never fail for it (which is the status quo), or just usually don't wait, never fail for it (which would be the change if we added After= in). I am tempted to say that the status quo is more likely what people would expect, no? The problem is that with current boot speeds, usually don't wait means that it shows up at some upredictable time. With a bit of luck, users might be able to log in before such mount points which are declared in /etc/fstab are mounted. I think that's unexpected, because it goes againt the general rule that things declared in /etc/fstab (w/o automount or noauto) are mounted at boot. I'd argue that nofail is precisely what the admin can use to *enable* this race. If it should be avoided to allow the user to log in before the device has shown up and is hooked in the admin should not have used nofail... I'd prefer to keep things orthogonal. This feels like an optimization that it user visible. We should rather encourage people to use automounts if the don't want to wait for the mountpoint to come up. I am pretty sure people would be annoyed by this change of behaviour, simply because every boot would still delay for 90s if the device is not plugged in. I have the suspicion that people would really assume that using nofail would make their system boot-up cleanly, without delays if the file system cannot be found -- and that expection is something we'd not fulfill? man mount 8: nofail -- Do not report errors for this device if it does not exist. Right, we cannot really re-define this. It's use is established since years. Used for things like isci, which is often not available at bootup. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Mon, 13.01.14 22:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Eeeh, why? This new name suggests that this libary is for systemd functionality. But so far it is a generic. Also, we have libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library, I'd much prefer to have it separated, if I'm using it for something not-systemd related. So, this is really hard to keep seperate. The thing is that much of this is such basic functionality that the libraries require that functionality from each other. For example, it's certainly a good idea to provide sd-event hookup for all our libraries that can integrate in an event loop. WHich would suggest we'd make all those libraries depend on libsystemd-bus. But then, we'd also like to make use of the calls from libsystemd-login from sd-bus, since we provide sd_bus_creds_new_from_pid() and friends. And there you have your cyclic dep... And this is the smae for id128 and the others (We currently avoid these issues via a varity of unsatisfactory hacks: for example, we don't provide any sd-event integration, and expect consumers to do this on their own. Or, for the libsystemd-login case we actually have the real code in src/shared/cgroup-util.c and have libsystemd-login just a thin wrapper around it) There are more problems this generates, for example, we link all of src/shared/*.c into each of these libs, and then let the linker remove all functions agin that are unused by the specific libs. This sounds nice, but actually just means that a lot of functions are in memory a number of times because they exist the same way in all our libraries. This is sometimes quite ridiculous, for example for libsystemd-id128 which is kinda trivial but still pulls in a copy of its own of much of src/shared/*.c. So I am pretty sure libsystemd-id128, libsystemd-login, libsystemd-journal should just end up in a single libsystemd.so together with the event loop, the bus, the asyncns stuff and more. All this functinality requires each other, and should nto pull in its own copy of src/shared/*.c each time. There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. libsystemd-dhcp however really sounds like something that will always be consumer of services, never provider of services from this new libsystemd.so, and the set of programs making use of it will always be very small, so we can and should certainly keep it a seperate lib. I hope this makes some 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] why does nofail imply no After= in /etc/fstab
'Twas brillig, and Chris Murphy at 16/01/14 15:34 did gyre and gimble: On Jan 16, 2014, at 8:25 AM, Kay Sievers k...@vrfy.org wrote: On Thu, Jan 16, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 16.01.14 16:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Jan 16, 2014 at 03:51:02PM +0100, Lennart Poettering wrote: On Wed, 15.01.14 20:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I was a bit surprised that for mount points the dependency Before=local-fs.target is only added when nofail is not used. This seems to be a concious decision (added by Lennart in 155da457, and then survived all the refactorings by Tom and Thomas...). Do we still want this behaviour? Well, nofail means that we shouldn't bother if the device doesn't show up at boot. Now, if we add After= for it there, then we will time-out on it (though not fail) if something else pulls it in. I figure this is a question what nofail really should mean: never wait for it, never fail for it (which is the status quo), or just usually don't wait, never fail for it (which would be the change if we added After= in). I am tempted to say that the status quo is more likely what people would expect, no? The problem is that with current boot speeds, usually don't wait means that it shows up at some upredictable time. With a bit of luck, users might be able to log in before such mount points which are declared in /etc/fstab are mounted. I think that's unexpected, because it goes againt the general rule that things declared in /etc/fstab (w/o automount or noauto) are mounted at boot. I'd argue that nofail is precisely what the admin can use to *enable* this race. If it should be avoided to allow the user to log in before the device has shown up and is hooked in the admin should not have used nofail... I'd prefer to keep things orthogonal. This feels like an optimization that it user visible. We should rather encourage people to use automounts if the don't want to wait for the mountpoint to come up. I am pretty sure people would be annoyed by this change of behaviour, simply because every boot would still delay for 90s if the device is not plugged in. I have the suspicion that people would really assume that using nofail would make their system boot-up cleanly, without delays if the file system cannot be found -- and that expection is something we'd not fulfill? man mount 8: nofail -- Do not report errors for this device if it does not exist. Right, we cannot really re-define this. It's use is established since years. Used for things like isci, which is often not available at bootup. Although with faster boot times, a device in fstab not existing is probably increasingly common. What about splitting the scheduling of .mount jobs such that /sysroot happens early, and everything else listed in fstab happens much later, to give the underlying device every opportunity to appear before the attempt? Primarily because special casing things is evil. Perhaps it would be better to just use a much smaller timeout for these generated units? Perhaps combine that with some kind of automount magic and then we've done all we can? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] why does nofail imply no After= in /etc/fstab
On Jan 16, 2014, at 8:25 AM, Kay Sievers k...@vrfy.org wrote: On Thu, Jan 16, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 16.01.14 16:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Jan 16, 2014 at 03:51:02PM +0100, Lennart Poettering wrote: On Wed, 15.01.14 20:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I was a bit surprised that for mount points the dependency Before=local-fs.target is only added when nofail is not used. This seems to be a concious decision (added by Lennart in 155da457, and then survived all the refactorings by Tom and Thomas...). Do we still want this behaviour? Well, nofail means that we shouldn't bother if the device doesn't show up at boot. Now, if we add After= for it there, then we will time-out on it (though not fail) if something else pulls it in. I figure this is a question what nofail really should mean: never wait for it, never fail for it (which is the status quo), or just usually don't wait, never fail for it (which would be the change if we added After= in). I am tempted to say that the status quo is more likely what people would expect, no? The problem is that with current boot speeds, usually don't wait means that it shows up at some upredictable time. With a bit of luck, users might be able to log in before such mount points which are declared in /etc/fstab are mounted. I think that's unexpected, because it goes againt the general rule that things declared in /etc/fstab (w/o automount or noauto) are mounted at boot. I'd argue that nofail is precisely what the admin can use to *enable* this race. If it should be avoided to allow the user to log in before the device has shown up and is hooked in the admin should not have used nofail... I'd prefer to keep things orthogonal. This feels like an optimization that it user visible. We should rather encourage people to use automounts if the don't want to wait for the mountpoint to come up. I am pretty sure people would be annoyed by this change of behaviour, simply because every boot would still delay for 90s if the device is not plugged in. I have the suspicion that people would really assume that using nofail would make their system boot-up cleanly, without delays if the file system cannot be found -- and that expection is something we'd not fulfill? man mount 8: nofail -- Do not report errors for this device if it does not exist. Right, we cannot really re-define this. It's use is established since years. Used for things like isci, which is often not available at bootup. Although with faster boot times, a device in fstab not existing is probably increasingly common. What about splitting the scheduling of .mount jobs such that /sysroot happens early, and everything else listed in fstab happens much later, to give the underlying device every opportunity to appear before the attempt? Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readme: CONFIG_FHANDLE is a requirement
On Tue, 14.01.14 15:26, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: From: Umut Tezduyar Lindskog umu...@axis.com --- README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/README b/README index a1058c5..6fcab4f 100644 --- a/README +++ b/README @@ -63,7 +63,7 @@ REQUIREMENTS: Some udev rules and virtualization detection relies on it: CONFIG_DMIID -Mount and bind mount handling might require it: +Mount and bind mount handling requires it: CONFIG_FHANDLE Support for some SCSI devices serial number retrieval, to S. I don't really care too much whether we declare CONFIG_FHANLDE as mandatory or not, but the original intention was to make this an optional requirement, not a mandatory one. We need the CONFIG_FHANLDE stuff only to detect within tmpfiles (for its aging stuff) and suchlike whether we are descending into a mount point that is of the same file system as the file system it is mounted into. The usual checks with stat() on both fs and comparing st_dev won't be reliable in this case. This is only a safety check, and in many (especially embedded cases with a fixed set of software) it shouldn't matter. Now, I never ran the whole thing on a kernel lacking CONFIG_FHANDLE, which is probably why the intended optional dep thing didn't work. It should be fairly easy to fix that (probably just some checking for errno == ENOTSUP or so somewhere). If there's interest to support kernels without CONFIG_FHANDLE then I'd be happy to merge a patch that makes this work and again declares CONFIG_FHANDLE optional. I'd suspect this to be a three-line change or so, for somebody who's interested... 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] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Thu, Jan 16, 2014 at 04:41:48PM +0100, Lennart Poettering wrote: On Mon, 13.01.14 22:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Eeeh, why? This new name suggests that this libary is for systemd functionality. But so far it is a generic. Also, we have libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library, I'd much prefer to have it separated, if I'm using it for something not-systemd related. So, this is really hard to keep seperate. The thing is that much of this is such basic functionality that the libraries require that functionality from each other. For example, it's certainly a good idea to provide sd-event hookup for all our libraries that can integrate in an event loop. WHich would suggest we'd make all those libraries depend on libsystemd-bus. But then, we'd also like to make use of the calls from libsystemd-login from sd-bus, since we provide sd_bus_creds_new_from_pid() and friends. And there you have your cyclic dep... And this is the smae for id128 and the others (We currently avoid these issues via a varity of unsatisfactory hacks: for example, we don't provide any sd-event integration, and expect consumers to do this on their own. Or, for the libsystemd-login case we actually have the real code in src/shared/cgroup-util.c and have libsystemd-login just a thin wrapper around it) There are more problems this generates, for example, we link all of src/shared/*.c into each of these libs, and then let the linker remove all functions agin that are unused by the specific libs. This sounds nice, but actually just means that a lot of functions are in memory a number of times because they exist the same way in all our libraries. This is sometimes quite ridiculous, for example for libsystemd-id128 which is kinda trivial but still pulls in a copy of its own of much of src/shared/*.c. So I am pretty sure libsystemd-id128, libsystemd-login, libsystemd-journal should just end up in a single libsystemd.so together with the event loop, the bus, the asyncns stuff and more. All this functinality requires each other, and should nto pull in its own copy of src/shared/*.c each time. There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. libsystemd-dhcp however really sounds like something that will always be consumer of services, never provider of services from this new libsystemd.so, and the set of programs making use of it will always be very small, so we can and should certainly keep it a seperate lib. I hope this makes some sense... Yes, it does. Thank you for the nice summary. I am also a bit worried about so-bumps: currently we have very nice backwards compatibility, without any API removals. -daemon, -id128, -journal, -login are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to keep this way, among other reasons, because it's much bigger, and much more experimental. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Thu, Jan 16, 2014 at 5:31 PM, Michael Biebl mbi...@gmail.com wrote: 2014/1/16 Lennart Poettering lenn...@poettering.net: So I am pretty sure libsystemd-id128, libsystemd-login, libsystemd-journal should just end up in a single libsystemd.so together with the event loop, the bus, the asyncns stuff and more. All this functinality requires each other, and should nto pull in its own copy of src/shared/*.c each time. There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. libsystemd-dhcp however really sounds like something that will always be consumer of services, never provider of services from this new libsystemd.so, and the set of programs making use of it will always be very small, so we can and should certainly keep it a seperate lib. I hope this makes some sense... Would that mean you intend to break existing software which uses those libraries, especially libsystemd-daemon. Do you intend to at least keep the .pc files so a recompilation would be sufficient? The old lib should be able to stay around for older compiled tools as long as needed. Linking against the new lib should not create conflicts when the new lib provides the same symbols. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
2014/1/16 Lennart Poettering lenn...@poettering.net: So I am pretty sure libsystemd-id128, libsystemd-login, libsystemd-journal should just end up in a single libsystemd.so together with the event loop, the bus, the asyncns stuff and more. All this functinality requires each other, and should nto pull in its own copy of src/shared/*.c each time. There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. libsystemd-dhcp however really sounds like something that will always be consumer of services, never provider of services from this new libsystemd.so, and the set of programs making use of it will always be very small, so we can and should certainly keep it a seperate lib. I hope this makes some sense... Would that mean you intend to break existing software which uses those libraries, especially libsystemd-daemon. Do you intend to at least keep the .pc files so a recompilation would be sufficient? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Thu, 16.01.14 17:31, Michael Biebl (mbi...@gmail.com) wrote: 2014/1/16 Lennart Poettering lenn...@poettering.net: So I am pretty sure libsystemd-id128, libsystemd-login, libsystemd-journal should just end up in a single libsystemd.so together with the event loop, the bus, the asyncns stuff and more. All this functinality requires each other, and should nto pull in its own copy of src/shared/*.c each time. There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. libsystemd-dhcp however really sounds like something that will always be consumer of services, never provider of services from this new libsystemd.so, and the set of programs making use of it will always be very small, so we can and should certainly keep it a seperate lib. I hope this makes some sense... Would that mean you intend to break existing software which uses those libraries, especially libsystemd-daemon. Nope, certainly not, we don't want to break this. Note that all our libraries carry carefully written symbol versioning. This means you can actually load the old e.g libsystemd-login.so and the new libsystem.so into to the same process and the symbols will not clash and thus not create problems. Thus a smooth upgrade path should be possible for Debian and similar distros which cannot just recompile everything for the new library (which is what we'd do for Fedora). Do you intend to at least keep the .pc files so a recompilation would be sufficient? No. We'd drop this. 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] src/libsystemd-dhcp src/systemd
On Mon, 06.01.14 03:35, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
+lease-dns = new0(struct in_addr*, len / 4 + 1);
+if (!lease-dns)
+return -ENOMEM;
+
+for (i = 0; i len / 4; i++) {
+lease-dns[i] = new0(struct in_addr, 1);
+memcpy(lease-dns[i]-s_addr, option + 4 *
i, 4);
+}
+
+lease-dns[i + 1] = NULL;
Isn't this a bit overkill? Why not just use an array of struct in_addr
rather than an array of struct in_addr*? I mean, even if we'd ignore
the overhead of malloc() here, the code is a lot more complex, and on
64bit you use double the memory for storing the pointer to the address
than for the actual address stored... ;-)
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] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Thu, 16.01.14 17:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. libsystemd-dhcp however really sounds like something that will always be consumer of services, never provider of services from this new libsystemd.so, and the set of programs making use of it will always be very small, so we can and should certainly keep it a seperate lib. I hope this makes some sense... Yes, it does. Thank you for the nice summary. I am also a bit worried about so-bumps: currently we have very nice backwards compatibility, without any API removals. -daemon, -id128, -journal, -login are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to keep this way, among other reasons, because it's much bigger, and much more experimental. Well, it's true that we have been pretty good ad keeping compatibility in the old libraries, but I am quite confident that we can do the same for the new library. At least that's my personal goal. I'll give the new APIs a thorough review before we make it official API and I'd welcome if others did too, so that we have a good chance, we can keep compatibility. 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] 6 commits - Makefile.am src/bus-proxyd src/network TODO
On Sun, 12.01.14 06:32, Tom Gundersen (tome...@kemper.freedesktop.org) wrote: +r = mkdir_safe_label(/run/systemd/network, 0755, 0, 0); +if (r 0) +return r; + +r = fopen_temporary(/run/systemd/network/resolv.conf, f, temp_path); +if (r 0) +return r; + +fchmod(fileno(f), 0644); + +fputs(# This file is managed by systemd-networkd(8). Do not edit.\n, f); I'd propose we add a longer comment here, explaining the situation. For example, we should tell admins that the way to edit this file is to replace the symlink in /etc by a real file, and edit that, thus opting out of the automatic handling of networkd. Also, we should make clear in the comment I think, that the real file is not API other programs should ever reference, i.e. people should not assume that we simply moved /etc/resolv.conf to /run and kept all other semantics, and they can just happily read that file directly. They should not do that, they should always use the /etc/resolv.conf name and nothing else... LLennart -- 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] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On 16/01/14 15:41, Lennart Poettering wrote: There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. (Please consider reviewing https://bugs.freedesktop.org/show_bug.cgi?id=71818#c5 so dbus will stop embedding sd-daemon.[ch] :-) With distro hat on: we don't really care how many clones of a library are compiled by its home source package (for instance, dbus-daemon statically links a variant of libdbus, but that's fine, because they both live in the dbus source package). What we care about is that when there's a serious bug like a security flaw, we want to fix it as few times as possible, and have the rest of the distro pick it up - so we don't want to embed copies of libraries in our *other* source packages. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Thu, 16.01.14 18:27, Michael Biebl (mbi...@gmail.com) wrote: 2014/1/16 Lennart Poettering lenn...@poettering.net: On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote: 2014/1/16 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: I am also a bit worried about so-bumps: currently we have very nice backwards compatibility, without any API removals. -daemon, -id128, -journal, -login are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to keep this way, among other reasons, because it's much bigger, and much more experimental. I'd prefer if the libraries were kept separate, at least for the ones for which it is possible without it beeing to painful. At least libsytemd-daemon should imho be kept separate with a stable API/ABI. We already have 10+ reverse dependencies of that library in Debian and the list is constantly growing. Sure, but as mentioned, if we end up merging libsystemd-daemon.so into libsystemd.so, both would be parallel installable and would not result in symbol clashes. Thus, the transition should be smooth... (Also note that it would still be the same scope, so if you are concerned about pulling in incompatible code into non-systemd boots, there's shouldn't be a problem) Well, since you plan to drop the .pc files I wouldn't really call the transition smooth, as every package would need sourceful changes to their configure check to now use a different .pc file name. Well, it can certainly continue to use and build against the old version for a while, no? Having to touch every affected package is something I'd like to avoid especially since I don't quite see the benefit of folding libsd-daemon into libsd. Well, we currently do a lot of stuff manually in sd-daemon.c which if merged (and with the embeddability requirement dropped) we could just use functions from util.c for. (Remember that sd_notify() discussion on debian's ctte ML, where some people got irritated by the perceived complexity of the function...?) Also, the library evolves. For example, I recently added calls to simplify the WATCHDOG_USEC stuff to the lib, and sooner or later it just gets annoying to hack these new things without src/shared/*.c available... I mean, that's probably the key issue here: Hacking with src/shared/*.c and with _cleanup_ and other gcc macros defined is fun. Hacking without it is so much nastier these days... I really am put off by that nowawadays. It's probably the one big reason why I am doing such a shitty job at Avahi maintaining these days: hacking without the luxury of the systemd internal APIs and syntactic sugar is just not fun anymore... 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] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
2014/1/16 Lennart Poettering lenn...@poettering.net: On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote: 2014/1/16 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: I am also a bit worried about so-bumps: currently we have very nice backwards compatibility, without any API removals. -daemon, -id128, -journal, -login are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to keep this way, among other reasons, because it's much bigger, and much more experimental. I'd prefer if the libraries were kept separate, at least for the ones for which it is possible without it beeing to painful. At least libsytemd-daemon should imho be kept separate with a stable API/ABI. We already have 10+ reverse dependencies of that library in Debian and the list is constantly growing. Sure, but as mentioned, if we end up merging libsystemd-daemon.so into libsystemd.so, both would be parallel installable and would not result in symbol clashes. Thus, the transition should be smooth... (Also note that it would still be the same scope, so if you are concerned about pulling in incompatible code into non-systemd boots, there's shouldn't be a problem) Well, since you plan to drop the .pc files I wouldn't really call the transition smooth, as every package would need sourceful changes to their configure check to now use a different .pc file name. Having to touch every affected package is something I'd like to avoid especially since I don't quite see the benefit of folding libsd-daemon into libsd. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Thu, 16.01.14 17:19, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 16/01/14 15:41, Lennart Poettering wrote: There are some exceptions to this though. For example, I am unsure about libsystemd-daemon: it's relatively easy to maintain this in its own lib, sicne so far it actually doesn't use any of the shared code, because its' embeddable. But then agaiun, given that this library evolves too, and given that distros generally don't like embedding anyway, we should probably just merge it into libsystemd.so too, in particular since the functions it provides are really low-level stuff. (Please consider reviewing https://bugs.freedesktop.org/show_bug.cgi?id=71818#c5 so dbus will stop embedding sd-daemon.[ch] :-) Done! With distro hat on: we don't really care how many clones of a library are compiled by its home source package (for instance, dbus-daemon statically links a variant of libdbus, but that's fine, because they both live in the dbus source package). What we care about is that when there's a serious bug like a security flaw, we want to fix it as few times as possible, and have the rest of the distro pick it up - so we don't want to embed copies of libraries in our *other* source packages. Yeah, I can understand that. But then again I think sd-daemon.c so far was trivial enough to make this a non-issue... But yeah, as mentioned, I am mostly leaning towards dropping the emebeddability thing, and just telling everybody to link directly against our lib... 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] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
2014/1/16 Lennart Poettering lenn...@poettering.net: On Thu, 16.01.14 18:27, Michael Biebl (mbi...@gmail.com) wrote: 2014/1/16 Lennart Poettering lenn...@poettering.net: On Thu, 16.01.14 17:33, Michael Biebl (mbi...@gmail.com) wrote: 2014/1/16 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: I am also a bit worried about so-bumps: currently we have very nice backwards compatibility, without any API removals. -daemon, -id128, -journal, -login are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to keep this way, among other reasons, because it's much bigger, and much more experimental. I'd prefer if the libraries were kept separate, at least for the ones for which it is possible without it beeing to painful. At least libsytemd-daemon should imho be kept separate with a stable API/ABI. We already have 10+ reverse dependencies of that library in Debian and the list is constantly growing. Sure, but as mentioned, if we end up merging libsystemd-daemon.so into libsystemd.so, both would be parallel installable and would not result in symbol clashes. Thus, the transition should be smooth... (Also note that it would still be the same scope, so if you are concerned about pulling in incompatible code into non-systemd boots, there's shouldn't be a problem) Well, since you plan to drop the .pc files I wouldn't really call the transition smooth, as every package would need sourceful changes to their configure check to now use a different .pc file name. Well, it can certainly continue to use and build against the old version for a while, no? We'd have to make pre-systemd-209 and systemd-209 packages co-installable (different source package names etc.) to be able to continue to provide the old version. That is not really fun. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
On Thu, Jan 16, 2014 at 7:00 PM, Michael Biebl mbi...@gmail.com wrote: 2014/1/16 Lennart Poettering lenn...@poettering.net: Well, it can certainly continue to use and build against the old version for a while, no? We'd have to make pre-systemd-209 and systemd-209 packages co-installable (different source package names etc.) to be able to continue to provide the old version. That is not really fun. Why? The lib is packaged separately, isn't it? What does it have to do with the systemd package? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
2014/1/16 Kay Sievers k...@vrfy.org: On Thu, Jan 16, 2014 at 7:00 PM, Michael Biebl mbi...@gmail.com wrote: 2014/1/16 Lennart Poettering lenn...@poettering.net: Well, it can certainly continue to use and build against the old version for a while, no? We'd have to make pre-systemd-209 and systemd-209 packages co-installable (different source package names etc.) to be able to continue to provide the old version. That is not really fun. Why? The lib is packaged separately, isn't it? What does it have to do with the systemd package? Packaged separately in the sense that the systemd source package builds a libsystemd-daemon0 binary package (among others). In systemd v209 we could no longer build such a libsystemd-daemon0 binary package from the systemd source package. We'd have to introduce a separate source package (based on systemd pre 209) named differently then systemd if we want to be able to continue to build libsystemd-daemon0. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/libsystemd-dhcp src/systemd
On Thu, Jan 16, 2014 at 5:35 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 06.01.14 03:35, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
+lease-dns = new0(struct in_addr*, len / 4 + 1);
+if (!lease-dns)
+return -ENOMEM;
+
+for (i = 0; i len / 4; i++) {
+lease-dns[i] = new0(struct in_addr, 1);
+memcpy(lease-dns[i]-s_addr, option + 4 *
i, 4);
+}
+
+lease-dns[i + 1] = NULL;
Isn't this a bit overkill? Why not just use an array of struct in_addr
rather than an array of struct in_addr*? I mean, even if we'd ignore
the overhead of malloc() here, the code is a lot more complex, and on
64bit you use double the memory for storing the pointer to the address
than for the actual address stored... ;-)
Fair enough :-) Fixed locally, will push soon.
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 6 commits - Makefile.am src/bus-proxyd src/network TODO
On Thu, Jan 16, 2014 at 6:13 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 12.01.14 06:32, Tom Gundersen (tome...@kemper.freedesktop.org) wrote: +r = mkdir_safe_label(/run/systemd/network, 0755, 0, 0); +if (r 0) +return r; + +r = fopen_temporary(/run/systemd/network/resolv.conf, f, temp_path); +if (r 0) +return r; + +fchmod(fileno(f), 0644); + +fputs(# This file is managed by systemd-networkd(8). Do not edit.\n, f); I'd propose we add a longer comment here, explaining the situation. For example, we should tell admins that the way to edit this file is to replace the symlink in /etc by a real file, and edit that, thus opting out of the automatic handling of networkd. Also, we should make clear in the comment I think, that the real file is not API other programs should ever reference, i.e. people should not assume that we simply moved /etc/resolv.conf to /run and kept all other semantics, and they can just happily read that file directly. They should not do that, they should always use the /etc/resolv.conf name and nothing else... I extended the comment a bit, but suggestions welcome. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Merging journal logs from btrfs snapshots
Due to anti-magic, a recent update horribly broke the system's ability to do further updates. This is resolved by regression to a prior Btrfs snapshot, once updated it works fine. But that's a two week old snapshot. I don't need the broken rootfs but I want to keep the journal for those two weeks. Is this a reasonable want or need and if so how to merge the logs? Between the two snapshots there are several like named files in /var/log/journal/machine-id. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
Chris Murphy li...@colorremedies.com schrieb: Due to anti-magic, a recent update horribly broke the system's ability to do further updates. This is resolved by regression to a prior Btrfs snapshot, once updated it works fine. But that's a two week old snapshot. I don't need the broken rootfs but I want to keep the journal for those two weeks. Is this a reasonable want or need and if so how to merge the logs? Between the two snapshots there are several like named files in /var/log/journal/machine-id. I'd recommend to place /var/log/journal on a subvolume so it is not affected by snapshotting. You can do separate snapshots for it (tho I cannot imagine why you would want to do it). That way you get a snapshot protection for these files, too, and you are free to roll back the rest of the system without affecting this subvolume. HTH Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
On Jan 16, 2014, at 1:58 PM, Kai Krakow hurikha...@gmail.com wrote: Chris Murphy li...@colorremedies.com schrieb: Due to anti-magic, a recent update horribly broke the system's ability to do further updates. This is resolved by regression to a prior Btrfs snapshot, once updated it works fine. But that's a two week old snapshot. I don't need the broken rootfs but I want to keep the journal for those two weeks. Is this a reasonable want or need and if so how to merge the logs? Between the two snapshots there are several like named files in /var/log/journal/machine-id. I'd recommend to place /var/log/journal on a subvolume so it is not affected by snapshotting. You can do separate snapshots for it (tho I cannot imagine why you would want to do it). That way you get a snapshot protection for these files, too, and you are free to roll back the rest of the system without affecting this subvolume. Aha, good idea. So then I mount the subvol at /var/log/journal? Is there any risk of journald writing to rootfs /var/log/journal before the subvolume is mounted? Or is the flush to persistent storage sufficiently delayed as to not be a concern? Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_mess
'Twas brillig, and Michael Biebl at 16/01/14 18:22 did gyre and gimble: 2014/1/16 Kay Sievers k...@vrfy.org: On Thu, Jan 16, 2014 at 7:00 PM, Michael Biebl mbi...@gmail.com wrote: 2014/1/16 Lennart Poettering lenn...@poettering.net: Well, it can certainly continue to use and build against the old version for a while, no? We'd have to make pre-systemd-209 and systemd-209 packages co-installable (different source package names etc.) to be able to continue to provide the old version. That is not really fun. Why? The lib is packaged separately, isn't it? What does it have to do with the systemd package? Packaged separately in the sense that the systemd source package builds a libsystemd-daemon0 binary package (among others). In systemd v209 we could no longer build such a libsystemd-daemon0 binary package from the systemd source package. We'd have to introduce a separate source package (based on systemd pre 209) named differently then systemd if we want to be able to continue to build libsystemd-daemon0. Could we not provide a libsystemd-daemon.so.0 that is just a stub and links to libsystemd.so.X and just calls the functions therein? That way the API could still be provided with the old lib (and old .pc files too) until such times as everything is updated. I would presume the name mangling would allow for this to work OK with some clever tricks here and there... (correctly me if I'm wrong) This would surely be the nicest way to handle things during any transition phase and could be turned off with a configure switch? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
Chris Murphy li...@colorremedies.com schrieb: Due to anti-magic, a recent update horribly broke the system's ability to do further updates. This is resolved by regression to a prior Btrfs snapshot, once updated it works fine. But that's a two week old snapshot. I don't need the broken rootfs but I want to keep the journal for those two weeks. Is this a reasonable want or need and if so how to merge the logs? Between the two snapshots there are several like named files in /var/log/journal/machine-id. I'd recommend to place /var/log/journal on a subvolume so it is not affected by snapshotting. You can do separate snapshots for it (tho I cannot imagine why you would want to do it). That way you get a snapshot protection for these files, too, and you are free to roll back the rest of the system without affecting this subvolume. Aha, good idea. So then I mount the subvol at /var/log/journal? Is there any risk of journald writing to rootfs /var/log/journal before the subvolume is mounted? Or is the flush to persistent storage sufficiently delayed as to not be a concern? I guess systemd is intelligent enough to handle that case as it auto-creates dependecies for filesystem mounts. But if you want to be safe, specify your mount point with x-system.automount option is fstab. This would buffer access to the directory until it has been mounted and is ready to use. OTOH, I'm not sure if this could create a deadlock during boot as journald is one of the essential services restarted as early as possible. I'm sure an expert here can give more details. Using systemctl show systemd-journald.service and systemctl show systemd- journal-flush.service should give you an idea how systemd would handle it. I have not tried it yet but you gave me an interesting idea... ;-) Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
Am 16.01.2014 22:15 schrieb Chris Murphy li...@colorremedies.com: On Jan 16, 2014, at 1:58 PM, Kai Krakow hurikha...@gmail.com wrote: Chris Murphy li...@colorremedies.com schrieb: Due to anti-magic, a recent update horribly broke the system's ability to do further updates. This is resolved by regression to a prior Btrfs snapshot, once updated it works fine. But that's a two week old snapshot. I don't need the broken rootfs but I want to keep the journal for those two weeks. Is this a reasonable want or need and if so how to merge the logs? Between the two snapshots there are several like named files in /var/log/journal/machine-id. I'd recommend to place /var/log/journal on a subvolume so it is not affected by snapshotting. You can do separate snapshots for it (tho I cannot imagine why you would want to do it). That way you get a snapshot protection for these files, too, and you are free to roll back the rest of the system without affecting this subvolume. Aha, good idea. So then I mount the subvol at /var/log/journal? Is there any risk of journald writing to rootfs /var/log/journal before the subvolume is mounted? Or is the flush to persistent storage sufficiently delayed as to not be a concern? Chris Murphy Afair, you don't need to mount subvolumes. Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
On Jan 16, 2014, at 2:48 PM, Mirco Tischler mircotisch...@gmx.net wrote: Afair, you don't need to mount subvolumes. I do in this case in order to make sure there's an fstab in subsequent snapshots, that mounts the /var/log/journal subvolume. Otherwise, the booted snapshot will end up with a new /var/log/journal and all new journal entries which is not what I want. Chris Murphy___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
Mirco Tischler mircotisch...@gmx.net schrieb: Am 16.01.2014 22:15 schrieb Chris Murphy li...@colorremedies.com: On Jan 16, 2014, at 1:58 PM, Kai Krakow hurikha...@gmail.com wrote: Chris Murphy li...@colorremedies.com schrieb: Due to anti-magic, a recent update horribly broke the system's ability to do further updates. This is resolved by regression to a prior Btrfs snapshot, once updated it works fine. But that's a two week old snapshot. I don't need the broken rootfs but I want to keep the journal for those two weeks. Is this a reasonable want or need and if so how to merge the logs? Between the two snapshots there are several like named files in /var/log/journal/machine-id. I'd recommend to place /var/log/journal on a subvolume so it is not affected by snapshotting. You can do separate snapshots for it (tho I cannot imagine why you would want to do it). That way you get a snapshot protection for these files, too, and you are free to roll back the rest of the system without affecting this subvolume. Aha, good idea. So then I mount the subvol at /var/log/journal? Is there any risk of journald writing to rootfs /var/log/journal before the subvolume is mounted? Or is the flush to persistent storage sufficiently delayed as to not be a concern? Chris Murphy Afair, you don't need to mount subvolumes. This is only true if you place subvolumes within your rootfs namespace at exactly the position you'd normally expect the mount-point at. If you follow recommendations, you place every subvolume in the subvol=0 namespace - and then you need to mount it. Like this: / [subvol=0] rootfs [subvolume] var log ... var-log-journal [subvolume] ... home [subvolume] username ... resulting in btrfs-device[subvolid=rootfs] mounted as /, then btrfs- device[subvolid=var-log-journal] mounted as /var/log/journal vs. your idea: subvol=0 / var log journal [subvolume] ... home [subvolume] username ... resulting in btrfs-device mounted as / = no really usage of subvolumes. But that has some downsides as you cannot easily roll-back your rootfs without copying the hole stuff. Even if you roll-back somehow, you may alter the subvolume residing in a sub directory of your rootfs. I'd recommend against this scheme. Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
Chris Murphy li...@colorremedies.com schrieb: On Jan 16, 2014, at 2:48 PM, Mirco Tischler mircotisch...@gmx.net wrote: Afair, you don't need to mount subvolumes. I do in this case in order to make sure there's an fstab in subsequent snapshots, that mounts the /var/log/journal subvolume. Otherwise, the booted snapshot will end up with a new /var/log/journal and all new journal entries which is not what I want. To fix this, you may want to boot into recovery, then snapshot your current rootfs. Next, snapshot your var/log/journal into [subvol0]/var-log-journal, which makes that a subvolume, rename var/log/journal into a backup location, recreate var/log/journal as empty directory, add the fstab entry, then take a new snapshot of your rootfs. This way you migrate to the new scheme while maintaining rolling back to the old behavior. And it's easy to refix after rolling back to the old behavior by just repeating the step move journal, create empty, add fstab and it'll pickup your existing journal after booting back into normal mode. After a grace period you won't need your old rootfs snapshots any longer and everything is good. It won't be that trivial if you'd made the var-log-journal within your rootfs namespace (because after rolling back your subvolume is a subvolume of a snapshot you'd rather delete, read: it's a sub-sub-volume). Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Merging journal logs from btrfs snapshots
On Jan 16, 2014, at 3:44 PM, Kai Krakow hurikha...@gmail.com wrote: Chris Murphy li...@colorremedies.com schrieb: On Jan 16, 2014, at 2:48 PM, Mirco Tischler mircotisch...@gmx.net wrote: Afair, you don't need to mount subvolumes. I do in this case in order to make sure there's an fstab in subsequent snapshots, that mounts the /var/log/journal subvolume. Otherwise, the booted snapshot will end up with a new /var/log/journal and all new journal entries which is not what I want. To fix this, you may want to boot into recovery, then snapshot your current rootfs. Next, snapshot your var/log/journal into [subvol0]/var-log-journal, which makes that a subvolume, rename var/log/journal into a backup location, recreate var/log/journal as empty directory, add the fstab entry, then take a new snapshot of your rootfs. This way you migrate to the new scheme while maintaining rolling back to the old behavior. And it's easy to refix after rolling back to the old behavior by just repeating the step move journal, create empty, add fstab and it'll pickup your existing journal after booting back into normal mode. After a grace period you won't need your old rootfs snapshots any longer and everything is good. It won't be that trivial if you'd made the var-log-journal within your rootfs namespace (because after rolling back your subvolume is a subvolume of a snapshot you'd rather delete, read: it's a sub-sub-volume). I tend to keep the original boot, root, home subvolumes as primary. So I think it's a bit weird having FS_TREE/root/var/log/journal as a subvolume that is then mounted on top of itself most of the time - as that's the way it would be in order for the fstab of subsequent root snapshots to mount the journal subvolume. Otherwise I'd have to change the fstab for each snapshot = annoying. So I think I'd put the journal subvolume in top level 5, or maybe in some other tree for persistent subvolumes to mount. Another limitation with fstab in a snapshot is that it has the wrong entries for the snapshot, those entries are only valid for the original subvolumes. So a snapshot of root subvolume called root.snap1, contains an /etc/fstab that calls for mounting subvol=root, rather than subvol=root.snap1. Making snapshots bootable poses some logistical challenges for legacy fstab, and also how to get them displayed in grub - some of the grub aspects have been discussed for several months on grub-devel@. Also, there's an argument to be made that a legitimate snapshot should initially be read-only. Upon rollback a rw snapshot would be created from the ro snapshot. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build-sys: merge libsystemd-login into libsystemd
--- Makefile.am | 73 +-- src/libsystemd/libsystemd.sym| 87 +++-- src/login/libsystemd-login.pc.in | 2 +- src/login/libsystemd-login.sym | 94 4 files changed, 97 insertions(+), 159 deletions(-) delete mode 100644 src/login/libsystemd-login.sym diff --git a/Makefile.am b/Makefile.am index 4fce9d6..4511d24 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1795,11 +1795,6 @@ systemctl_LDADD = \ libsystemd-internal.la \ libsystemd-logs.la -if ENABLE_LOGIND -systemctl_LDADD += \ - libsystemd-login-internal.la -endif - systemctl_LDADD += \ libsystemd-journal-internal.la \ libsystemd-id128-internal.la \ @@ -2027,7 +2022,11 @@ libsystemd_la_SOURCES = \ src/libsystemd/rtnl-util.h \ src/libsystemd/rtnl-util.c \ src/libsystemd/sd-resolve.c \ - src/libsystemd/resolve-util.h + src/libsystemd/resolve-util.h \ + src/login/sd-login.c \ + src/systemd/sd-login.h \ + src/login/login-shared.c \ + src/login/login-shared.h nodist_libsystemd_la_SOURCES = \ src/libsystemd/bus-error-mapping.c @@ -3258,11 +3257,6 @@ libsystemd_journal_core_la_LIBADD = \ libsystemd-id128-internal.la \ libsystemd-shared.la -if ENABLE_LOGIND -libsystemd_journal_core_la_LIBADD += \ - libsystemd-login-internal.la -endif - if HAVE_ACL libsystemd_journal_core_la_LIBADD += \ libsystemd-acl.la @@ -3460,12 +3454,8 @@ systemd_coredump_SOURCES = \ systemd_coredump_LDADD = \ libsystemd-journal-internal.la \ libsystemd-label.la \ - libsystemd-shared.la - -if ENABLE_LOGIND -systemd_coredump_LDADD += \ - libsystemd-login-internal.la -endif + libsystemd-shared.la \ + libsystemd-internal.la rootlibexec_PROGRAMS += \ systemd-coredump @@ -4226,14 +4216,14 @@ test_login_SOURCES = \ src/login/test-login.c test_login_LDADD = \ - libsystemd-login-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la test_login_shared_SOURCES = \ src/login/test-login-shared.c test_login_shared_LDADD = \ - libsystemd-login-internal.la \ + libsystemd-internal.la \ libsystemd-shared.la test_inhibit_SOURCES = \ @@ -4259,29 +4249,6 @@ tests += \ test-login-tables \ test-login-shared -libsystemd_login_la_SOURCES = \ - src/login/libsystemd-login.sym \ - src/login/sd-login.c \ - src/systemd/sd-login.h \ - src/login/login-shared.c \ - src/login/login-shared.h - -libsystemd_login_la_CFLAGS = \ - $(AM_CFLAGS) \ - -fvisibility=hidden - -libsystemd_login_la_LDFLAGS = \ - $(AM_LDFLAGS) \ - -version-info $(LIBSYSTEMD_LOGIN_CURRENT):$(LIBSYSTEMD_LOGIN_REVISION):$(LIBSYSTEMD_LOGIN_AGE) \ - -Wl,--version-script=$(top_srcdir)/src/login/libsystemd-login.sym - -libsystemd_login_la_LIBADD = \ - libsystemd-daemon-internal.la \ - libsystemd-shared.la - -libsystemd_login_internal_la_SOURCES = \ - $(libsystemd_login_la_SOURCES) - if HAVE_PAM pam_systemd_la_SOURCES = \ src/login/pam-module.c @@ -4344,12 +4311,6 @@ dist_pkgsysconf_DATA += \ pkginclude_HEADERS += \ src/systemd/sd-login.h -lib_LTLIBRARIES += \ - libsystemd-login.la - -noinst_LTLIBRARIES += \ - libsystemd-login-internal.la - pkgconfiglib_DATA += \ src/login/libsystemd-login.pc @@ -4520,7 +4481,7 @@ login_la_LDFLAGS = \ login_la_LIBADD = \ $(PYTHON_DEVEL_LIBS) \ libsystemd-journal.la \ - libsystemd-login.la \ + libsystemd.la \ libsystemd-daemon-internal.la \ libsystemd-shared.la @@ -4980,7 +4941,8 @@ endef test-libsystemd-sym.c: \ src/libsystemd/libsystemd.sym \ src/systemd/sd-bus.h \ - src/systemd/sd-utf8.h + src/systemd/sd-utf8.h \ + src/systemd/sd-login.h $(generate-sym-test) test-libsystemd-daemon-sym.c: \ @@ -4998,11 +4960,6 @@ test-libsystemd-journal-sym.c: \ src/systemd/sd-journal.h $(generate-sym-test) -test-libsystemd-login-sym.c: \ - src/login/libsystemd-login.sym \ - src/systemd/sd-login.h - $(generate-sym-test) - test-libudev-sym.c: \ src/libudev/libudev.sym \ src/udev/udev.h @@ -5028,11 +4985,6 @@ test_libsystemd_journal_sym_SOURCES = \ test_libsystemd_journal_sym_LDADD = \ libsystemd-journal.la -test_libsystemd_login_sym_SOURCES = \ - test-libsystemd-login-sym.c -test_libsystemd_login_sym_LDADD = \ - libsystemd-login.la - test_libudev_sym_SOURCES = \ test-libudev-sym.c test_libudev_sym_LDADD = \ @@ -5051,7 +5003,6 @@ tests += \ test-libsystemd-daemon-sym \ test-libsystemd-id128-sym \ test-libsystemd-journal-sym \ - test-libsystemd-login-sym \ test-libudev-sym cppcheck: diff --git
