Re: [systemd-devel] Can't make local user.conf work
On Mon, Mar 7, 2016 at 7:31 AM, G D'Arezzo <gdarre...@gmail.com> wrote: > On 29 February 2016 at 19:05, Kok, Auke-jan H <auke-jan.h@intel.com> > wrote: >> On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzo <gdarre...@gmail.com> wrote: >>> "You probably want to use [Service] instead." >>> >>> Thanks for the suggestion, Auke. Unfortunately, Service and >>> DefaultEnvironment don't go together: >>> >>> [/home/temp/.config/systemd/user/test.service.d/user.conf:2] Unknown >>> lvalue 'DefaultEnvironment' in section 'Service' >> >> I just reread the man page for that. DefaultEnvironment is valid only >> for user.conf, not any conf.d* file associated with a specific unit >> (obviously, since those are not variants of "user.conf", but instead >> are variants of unit files). >> >> The [Manager] section is only valid in: >> >>/etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf, >> /run/systemd/user.conf.d/*.conf, >>/usr/lib/systemd/user.conf.d/*.conf >> >> The manual page systemd-user.conf(5) does not mention at all being >> able to use ~/.config/systemd/. This seems like a shortcoming to me, >> though. >> >> Auke > > > Is this a feature which never happened or should it work? I'm fairly sure it just never happened. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't make local user.conf work
On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzowrote: > "You probably want to use [Service] instead." > > Thanks for the suggestion, Auke. Unfortunately, Service and > DefaultEnvironment don't go together: > > [/home/temp/.config/systemd/user/test.service.d/user.conf:2] Unknown > lvalue 'DefaultEnvironment' in section 'Service' I just reread the man page for that. DefaultEnvironment is valid only for user.conf, not any conf.d* file associated with a specific unit (obviously, since those are not variants of "user.conf", but instead are variants of unit files). The [Manager] section is only valid in: /etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf, /run/systemd/user.conf.d/*.conf, /usr/lib/systemd/user.conf.d/*.conf The manual page systemd-user.conf(5) does not mention at all being able to use ~/.config/systemd/. This seems like a shortcoming to me, though. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can't make local user.conf work
On Thu, Feb 25, 2016 at 7:06 PM, Guido D'Arezzowrote: > Hello, I’m trying to run user systemd services with DefaultEnvironment set > in a user.conf under $HOME/.config/systemd/ but it isn't being read. > The only .conf files I have seen being read are /etc/systemd/user.conf and > /etc/systemd/user.conf.d/*.conf > > It should work, according to this page (under Environment Variables): > https://wiki.archlinux.org/index.php/Systemd/User > > and these words (though I can't find many other references to its use): > > "You can use DefaultEnvironment in user.conf, and place that either in > /etc/systemd/user.conf, or in ~/.config/systemd/user.conf." > > > https://lists.freedesktop.org/archives/systemd-devel/2014-March/017514.html > > > This doesn't mention user.conf but does it mean any .conf files in or under > there should be read? no, this path contains config files with a special format only, and arbitrary files in here are not read. Consider this the user equivalent of /etc/systemd/ > "Additionally, --user also adds the home-directory of the user as > source: ~/.config/systemd/user/" > > > https://lists.freedesktop.org/archives/systemd-devel/2014-August/022745.html > > but the suggestion later on > > "to create a file in: > ~/.config/systemd/user/your_service.conf.d/your_drop_in_file.conf" > > and in man systemd.unit > > Along with a unit file foo.service, a directory >foo.service.d/ may exist. All files with the suffix ".conf" >from this directory will be parsed after the file itself is >parsed. This is useful to alter or add configuration settings >to a unit, without having to modify their unit files. Make >sure that the file that is included has the appropriate >section headers before any directive. > > fails with systemctl complaining about the .conf file heading: > Unknown section 'Manager' You probably want to use [Service] instead. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bootchart speeding up boot time
On Mon, Feb 22, 2016 at 11:51 AM, Martin Townsendwrote: > Hi, > > Thanks for your reply. I wouldn't really call this system stripped down, it > has an nginx webserver, DHCP server, postgresql-server, sftp server, a few > mono (C#) daemons running, loads quite a few kernel modules during boot, > dbus, sshd, avahi, and a bunch of other stuff I can't quite remember. I > would imagine glibc will be a tiny portion of what gets loaded during boot. > I have another arm system which has a similar boot time with systemd, it's > only a single cortex A9 core, it's running a newer 4.1 kernel with a new > version of systemd as it's built with the Jethro version of Yocto so > probably a newer version of glibc and this doesn't speed up when using > bootchart and in fact slows down slightly (which is what I would expect). > So my current thinking is that it's either be down to the fact that it's a > dual core and only one core is being used during boot unless a fork/execl > occurs? Or it's down to the newer kernel/systemd/glibc or some other > component. > > Is there anyway of seeing what the CPU usage for each core is for systemd on > boot without using bootchart then I can rule in/out the first idea. Not that I know of, but, to work around the issue of dynamic linking, one can link systemd-bootchartd statically. It'll become larger, but you can then clearly ascern that the impact of glibc bits being loaded are properly recorded by bootchart. And, it's fairly trivial link it statically. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bootchart speeding up boot time
On Fri, Feb 19, 2016 at 7:15 AM, Martin Townsendwrote: > Hi, > > I'm new to systemd and have just enabled it for my Xilinx based dual core > cortex A-9 platform. The linux system is built using Yocto (Fido branch) > which is using version 219 of systemd. > > The main reason for moving over to systemd was to see if we could improve > boot times and the good news was that by just moving over to systemd we > halved the boot time. So I read that I could analyse the boot times in > detail using bootchart so I set init=//bootchart in my kernel command > line and was really suprised to see my boot time halved again. Thinking > some weird caching must have occurred on the first boot I reverted back to > normal systemd boot and boot time jumped back to normal (around 17/18 > seconds), putting bootchart back in again reduced it to ~9/10 seconds. > > So I created my own init using bootchart as a template that just slept for > 20 seconds using nanosleep and this also had the same effect of speeding up > the boot time. > > So the only difference I can see is that the kernel is not starting > /sbin/init -> /lib/systemd/systemd directly but via another program that is > performing a fork and then in the parent an execl to run > /lib/systemd/systemd. What I would really like to understand is why it runs > faster when started this way? systemd-bootchart is a dynamically linked binary. In order for it to run, it needs to dynamically link and load much of glibc into memory. If your system is really stripped down, then the portion of data that's loaded from disk that is coming from glibc is relatively large, as compared to the rest of the system. In an absolute minimal system, I expect it to be well over 75% of the total data loaded from disk. It seems in your system, glibc is about 50% of the stuff that needs to be paged in from disk, hence, by starting systemd-bootchart before systemd, you've "removed" 50% of the total data to be loaded from the vision of bootchart, since, bootchart cannot start logging data until it's loaded all those glibc bits. Ultimately, your system isn't likely booting faster, you're just forcing it to load glibc before systemd starts. systemd-analyze may actually be a much better way of looking at the problem: it reports CLOCK_MONOTONIC timestamps for the various parts involved, including, possibly, firmware, kernel time, etc.. In conjunction with bootchart, this should give a full picture. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Moving systemd-bootchart to a standalone repository
On Wed, Feb 17, 2016 at 4:49 PM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > On Wed, Feb 17, 2016 at 09:17:51AM -0800, Kok, Auke-jan H wrote: >> Splitting it out increases that potential and will allow >> systemd-bootchart to evolve out of cycle again, and look a bit over >> the fence. I've reviewed most of the changes to it, and noticed a bit >> of a drop of risky commits, and those are the ones that are going to >> be needed for this project to make it a useful tool in the future. >> >> So, I think this is a great move, one that certainly will motivate me >> to engage more deeply again :) > Hi Auke, > > what kind of big changes would you have in mind? > Just the fact of being in one repo with systemd should not have > much effect on changes to bootchart which is mostly standalone... I have been asked on several occasions to make bootchart more palatable for other OS's, including ChromeOS and even Android. This has previously been shelved entirely, and I don't know if it's currently even feasible, but at least logistically it should be a lot easier to attempt. The rest of the things I was looking at were items that being in-tree did not affect, like new ways of grouping the process bars, better IO visualization, etc. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Moving systemd-bootchart to a standalone repository
On Wed, Feb 17, 2016 at 9:03 AM, Jóhann B. Guðmundssonwrote: > On 02/17/2016 04:51 PM, Daniel Mack wrote: >> [I've put all people in Cc who have had more than one commit related to >> systemd-bootchart in the past] >> >> As part of our spring cleaning, we've been thinking about giving >> systemd-bootchart a new home, in a new repository of its own. I've been >> working on this and put the result here: > > What's the reason for splitting it out into it's own repository as what's > the criteria you used to determine that which may or may not be applicable > to other bits of systemd?+ When this code was merged into systemd originally it was by itself already a fairly useful tool, and the potential to benefit systemd as a project was enormous. That potential has subsided in the last two years significantly as the community pushing systemd has (I think) learned to be critical about additions to the code and the impact. As such the beneficial component of synergy has faded a bit, and it may actually hinder other projects from adopting systemd-bootchart. Splitting it out increases that potential and will allow systemd-bootchart to evolve out of cycle again, and look a bit over the fence. I've reviewed most of the changes to it, and noticed a bit of a drop of risky commits, and those are the ones that are going to be needed for this project to make it a useful tool in the future. So, I think this is a great move, one that certainly will motivate me to engage more deeply again :) Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Improve boot-time of systemd-based device, revisited
On Mon, Jun 15, 2015 at 5:44 AM, Harald Hoyer harald.ho...@gmail.com wrote: On 14.06.2015 15:17, cee1 wrote: BTW, systemd-bootchart has a option to chart entropy, how is the entropy involved in boot up procedure? Well, if daemons need bytes from /dev/random (think sshd key generation), I guess they will have to wait for enough entropy, and so does the boot process in the end. I added the option since we discovered that the entropy pool can take a very long time to fill, and while this generally doesn't affect startup (sshd etc. are usually started on demand) it may be problematic for services like kerberos, an SSL enabled web server. It's largely irrelevant for the basic OS components, though. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] bootchart: don't parse /proc/uptime, use CLOCK_BOOTTIME
thumbs up from me, thanks for sending this. Auke On Thu, Jul 31, 2014 at 1:15 AM, Karel Zak k...@redhat.com wrote: * systemd-bootchart always parses /proc/uptime, although the information is unnecessary when --rel specified * use /proc/uptime is overkill, since Linux 2.6.39 we have clock_gettime(CLOCK_BOOTTIME, ...). The backend on kernel side is get_monotonic_boottime() in both cases. * main() uses if (graph_start = 0.0) to detect that /proc is available. This is fragile solution as graph_start is always smaller than zero on all systems after suspend/resume (e.g. laptops), because in this case the system uptime includes suspend time and uptime is always greater number than monotonic time. For example right now difference between uptime and monotonic time is 37 hours on my laptop. Note that main() calls log_uptime() (to parse /proc/uptime) for each sample when it believes that /proc is not available. So on my laptop systemd-boochars spends all live with /proc/uptime parsing + nanosleep(), try strace /usr/lib/systemd/systemd-bootchart to see the never ending loop. This patch uses access(/proc/vmstat, F_OK) to detect procfs. --- man/systemd-bootchart.xml | 4 +++- src/bootchart/bootchart.c | 11 +++ src/bootchart/store.c | 29 - 3 files changed, 22 insertions(+), 22 deletions(-) diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml index e19bbc1..150ca48 100644 --- a/man/systemd-bootchart.xml +++ b/man/systemd-bootchart.xml @@ -131,7 +131,9 @@ not graph the time elapsed since boot and before systemd-bootchart was started, as it may result in extremely -large graphs. /para/listitem +large graphs. The time elapsed since boot +might also include any time that the system +was suspended./para/listitem /varlistentry /variablelist /refsect1 diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c index cbfc28d..909ef46 100644 --- a/src/bootchart/bootchart.c +++ b/src/bootchart/bootchart.c @@ -310,6 +310,7 @@ int main(int argc, char *argv[]) { time_t t = 0; int r; struct rlimit rlim; +bool has_procfs = false; parse_conf(); @@ -349,6 +350,8 @@ int main(int argc, char *argv[]) { log_uptime(); +has_procfs = access(/proc/vmstat, F_OK) == 0; + LIST_HEAD_INIT(head); /* main program loop */ @@ -385,11 +388,11 @@ int main(int argc, char *argv[]) { parse_env_file(/usr/lib/os-release, NEWLINE, PRETTY_NAME, build, NULL); } -/* wait for /proc to become available, discarding samples */ -if (graph_start = 0.0) -log_uptime(); -else +if (has_procfs) log_sample(samples, sampledata); +else +/* wait for /proc to become available, discarding samples */ +has_procfs = access(/proc/vmstat, F_OK) == 0; sample_stop = gettime_ns(); diff --git a/src/bootchart/store.c b/src/bootchart/store.c index e071983..cedcba8 100644 --- a/src/bootchart/store.c +++ b/src/bootchart/store.c @@ -57,27 +57,22 @@ double gettime_ns(void) { return (n.tv_sec + (n.tv_nsec / 10.0)); } -void log_uptime(void) { -_cleanup_fclose_ FILE *f = NULL; -char str[32]; -double uptime; - -f = fopen(/proc/uptime, re); - -if (!f) -return; -if (!fscanf(f, %s %*s, str)) -return; - -uptime = strtod(str, NULL); +static double gettime_up(void) { +struct timespec n; -log_start = gettime_ns(); +clock_gettime(CLOCK_BOOTTIME, n); +return (n.tv_sec + (n.tv_nsec / 10.0)); +} -/* start graph at kernel boot time */ +void log_uptime(void) { if (arg_relative) -graph_start = log_start; -else +graph_start = log_start = gettime_ns(); +else { +double uptime = gettime_up(); + +log_start = gettime_ns(); graph_start = log_start - uptime; +} } static char *bufgetline(char *buf) { -- 1.9.3 ___ 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
Re: [systemd-devel] [PATCH 2/2] bootchart: ask for --rel when failed to initialize graph start time
thanks! Auke On Sat, Aug 2, 2014 at 10:17 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Jul 31, 2014 at 10:15:40AM +0200, Karel Zak wrote: This patch uses access(/proc/vmstat, F_OK) to detect procfs. We always read system uptime before log start time. So the uptime should be always smaller number, except it includes system suspend time. It seems better to ask for --rel and exit() than try to be smart and try to recovery from this situation or generate huge messy graphs. Applied both. Zbyszek ___ 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] [HEADS-UP] Intent to remove readahead from systemd
On Thu, Aug 14, 2014 at 10:16 AM, Lennart Poettering lenn...@poettering.net wrote: Heya, Since its early days systemd contained the systemd-readahead tool, whose job was to improve boot times by reading files in their order on disk, before they would actually be needed by applications. In times of SSD the benefit of systemd-readahead is much less convincing, in many case it actually slows things down. The fact is now that nobody really cares about systemd-readahead much anymore. Nobody in the systemd team still works on a laptop with rotating media, hence nobody tries to optimize it in any way. And it probably needs a lot of looking after and love to still be useful as general purpose systems, instead of just slowing them down... So, I think with the release after the upcoming one we should just remove it from the systemd package and just throw it on the pile of historic cruft. So, yeah, here's the advance warning that this will be happening... (Well, unless somebody from the community who cares and wants to invest the necessary time in it steps up and gives it the love it really needs. If nobody does until that release, I will delete the component from systemd). I fully understand that not everybody uses SSDs yet, and also that theoretically doign systemd-readahead on SSD could be beneficial still (since RAM is still orders of magnitude faster than SSDs), but it's really not about that, it's about maintainership and giving the tool the love it needs. heh, ouch X_X I can understand your sentiment, though. I've identified plenty of cases where readahead just isn't working out well at all, and the constant tweaking has left it ... quite a bit messy. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix systemd-bootchart svg background
On Mon, Jun 16, 2014 at 9:52 AM, Frederic Crozat fcro...@suse.com wrote: Hi all, attached is a fix for SVG generated by systemd-bootchart, similar to a fix already done in systemd-analyze. yeah, that's a nice change. Looks good to me. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 2/2] bootchart: add cgroup option
On Wed, Apr 23, 2014 at 1:13 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 28.03.14 17:07, WaLyong Cho (walyong@samsung.com) wrote: Sounds useful. Agreed - this looks highly useful. Would be nice maybe to see an example output file somehere, but otherwise thumbs up (though, please refactor as per Lennart's comments). Thanks WaLyong, Kyungmin! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd session mode
On Sun, Dec 1, 2013 at 12:33 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Dec 1, 2013 at 8:25 PM, Hristo Venev hri...@venev.name wrote: I've implemented session mode for systemd. I am currently using it and it works pretty okay. I just had to generate D-Bus user services for D-Bus activation to work. A new variable, XDG_SESSION_DIR, has been added. It defaults to /run/session/$XDG_SESSION_ID and is to be used for session-specific files as it is `rm -rf`-ed on logout. There, in ./systemd/private, the systemd socket is stored. Also, my implementation of session units stores the D-Bus socket in ./dbus/session_bus_socket. There is intentionally only support for systemd --user, no plan to support any sort of systemd session instance. The one instance for the user will be shared by all sessions of the same user. right, my personal thoughts on this were to have session@seat.service units that take care of spawing a graphical UX to the user on that seat. I see little reason to create yet another instance of systemd --user as the one existing process should be able to handle everything for a single user already. Not sure what to do with this patch series, I fear it will risk running into problems when you have multiple seats and other things like that, but I haven't looked into details of the patches too much... Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Nov 12, 2013 6:16 AM, Karel Zak k...@redhat.com wrote: On Fri, Nov 01, 2013 at 09:19:27AM -0700, Kok, Auke-jan H wrote: On Fri, Nov 1, 2013 at 12:57 AM, Karel Zak k...@redhat.com wrote: On Thu, Oct 31, 2013 at 01:20:18PM -0700, Kok, Auke-jan H wrote: BTW, for SELinux we remove selinux specific mount options in userspace (in mount(8)) if the kernel does not support selinux. It help us to make command line or fstab setting independent on the current kernel features. Maybe we can use the same for SMACK, is there any way how to determine that the system uses SMACK? (/proc/something or so...). -- for selinux we check for /sys/fs/selinux or /selinux. Ohh yes that would be so nice. You've got your choice for detecting smack, but I like stat(/sys/fs/smackfs) == 0 the best so far. You can parse /proc/filesystems for smackfs too, but that's obviously more complex. This method works with 3.9 and above, as that's when we made sysfs hold the mount point for smackfs. I assume we're talking about this code here: https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181 Yes, the se_rem code (with SELinux is it tricky, because old kernels don't support selinux options remount, options duplication is problem etc.. I guess that for SMACK it will be less complex :-). Do you have somewhere list of the smack mount options? I'll prepare the patch. Yes, the authoritative documentation is the code: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smack.h#n143 OK, implemented: https://github.com/karelzak/util-linux/commit/b8095d25bae0588dfce8a62169f6db5496cf45c5 You have to compile util-linux with --with-smack. It's trivial change, so I can backport it to the next stable release v2.24.1 (at the end of this year). OK? Awesome - looks good (with the typo fix) and we'll get this tested. Thanks again! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Wed, Nov 6, 2013 at 1:32 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 06/11/13 02:08 did gyre and gimble: alright, I'll comment, but it took me 5 minutes to clear the coffee off my monitor... Looking at the feature list, why are you not contributing to connman instead? AFAIK, Tom has had plenty discussions with Marcel and Daniel on the connman side. I actually made sure Tom met Daniel in Edinburgh a couple weeks ago for this reason! I guess I'm at fault for not attending those conferences ... So I don't think you need to worry too much about conman vs. systemd-networkd rather think of it as a rather collaborative effort in general. Quite where all the code and shared bits live in the end I don't know but I think this process is going about things in the right way to come to a good end-solution. Sorry if my post seemed out of line - I'm happy to see the thread here with comments from everyone that answer my concern and questions, and knowing that this was well coordinated now makes me quite positive about this effort. Marcel and me have certainly struggled with the problem that happens when you attempt to bring connman into a more server-like environment, so, I'm very pleased to see that there is a significant effort to bring an appropriate solution in this space that actually involves connman as well. Thanks! Auke PS Marcel - Now we just need to figure out what to do with that JavaScript engine for pacrunner and get it working ;^) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
On Tue, Nov 5, 2013 at 4:33 PM, Tom Gundersen t...@jklm.no wrote: This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured, mostly as a proof of concept. I expect to expand on this as soon as we are agreed on the basic design. Comments, testing and contributions greatly appreciated! alright, I'll comment, but it took me 5 minutes to clear the coffee off my monitor... Looking at the feature list, why are you not contributing to connman instead? It seems you're going to be duplicating a ton of code And connman does what your goal is, meaning you can pre-provision static configurations without any of the more involved dependencies. It has a DBus interface for status, configuration etc I'm frankly shocked a bit, not sure what to say. Maybe this is a great thing, but, without a doubt someone will want to convert this code long term into connman / NM, and at that point we have 3 standards, not 2. Best to try and stick to 2 standards and fix the one that has the best long-term prospective value. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Linux kernel API
On Mon, Nov 4, 2013 at 2:10 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Nov 04, 2013 at 10:54:26PM +0100, ScotXW wrote: Hi, On 11/02/2013 12:15 AM, Greg KH wrote: On Sat, Nov 02, 2013 at 12:05:23AM +0100, ScotXW wrote: On 11/01/2013 06:51 PM, Greg KH wrote: On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote: systemd is written exclusively for the Linux kernel because this offers advantages over the POSIX API. To illustrate the difference between Linux kernel API and POSIX API I created a diagram, see [1]. Linux doesn't implement all of the POSIX api in the kernel, other portions of it are in other userspace pieces. Would you please name a couple beside the libc? Why, this is your research, not mine :) This is //not// a recherche, I was looking for some fast answer from the off the top of ones head. Besides the scheme, there is now an article [1]. I still fail to understand how _any_ of this pertains to this mailing list... Thanks Greg. Scot, I find your messages not appropriate for this list. Please remember that the list is named systemd-devel for a reason. Your requests are clearly not in the interest, or promote the development of systemd (if they are, you failed terribly at making a case that that is the case... and please do not attempt to do so further). So please don't post this kind of stuff to this list. There are far better places to post these requests. Sorry, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Fri, Nov 1, 2013 at 12:57 AM, Karel Zak k...@redhat.com wrote: On Thu, Oct 31, 2013 at 01:20:18PM -0700, Kok, Auke-jan H wrote: BTW, for SELinux we remove selinux specific mount options in userspace (in mount(8)) if the kernel does not support selinux. It help us to make command line or fstab setting independent on the current kernel features. Maybe we can use the same for SMACK, is there any way how to determine that the system uses SMACK? (/proc/something or so...). -- for selinux we check for /sys/fs/selinux or /selinux. Ohh yes that would be so nice. You've got your choice for detecting smack, but I like stat(/sys/fs/smackfs) == 0 the best so far. You can parse /proc/filesystems for smackfs too, but that's obviously more complex. This method works with 3.9 and above, as that's when we made sysfs hold the mount point for smackfs. I assume we're talking about this code here: https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181 Yes, the se_rem code (with SELinux is it tricky, because old kernels don't support selinux options remount, options duplication is problem etc.. I guess that for SMACK it will be less complex :-). Do you have somewhere list of the smack mount options? I'll prepare the patch. Yes, the authoritative documentation is the code: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smack.h#n143 /* * Mount options */ #define SMK_FSDEFAULT smackfsdef= #define SMK_FSFLOOR smackfsfloor= #define SMK_FSHAT smackfshat= #define SMK_FSROOT smackfsroot= #define SMK_FSTRANS smackfstransmute= BTW, the options should be also documented in mount.8 man page :-) nod Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Thu, Oct 31, 2013 at 12:00 PM, Karel Zak k...@redhat.com wrote: On Tue, Oct 29, 2013 at 01:27:07PM +0100, Lennart Poettering wrote: On Tue, 29.10.13 16:02, WaLyong Cho (walyong@samsung.com) wrote: Hmm, here's an idea: there has been a long standig feature request to add a configurable boolean to mount unit files that controls /bin/mount's -s switch. Let's say we call it SloppyOptions=yes/no, or so. Then, we could set this for this unit file and apply the rest of the patch and things should work, and where they don't we can easily reassign to the kernel to respect the -s flag properly. Doing a patch that allows -s to be controlled should be fairly easy, would be happy to merge a patch for that! ahhh I hadn't even seen -s in /bin/mount yet, so I can see this helping out a lot. I'd be okay with a solution like that, it would certainly simplify things a lot, but we need to be careful not to overload mount options with all sorts of nonstandard options - it will make problems harder to debug and for some of these security enabled systems we will most likely want to actually _not_ use -s. After all, we want to make sure we're actually booting with properly setup Smack options e.g. a typo in 'nodev,nosuid,nexec' could be disastrous. (typo deliberate). Auke I am not sure we can use the -s option. First I tried that in my fedora machine. # mount -t tmpfs -s -o mode=1777,strictatime,smackfsroot=* tmpfs /test BTW, for SELinux we remove selinux specific mount options in userspace (in mount(8)) if the kernel does not support selinux. It help us to make command line or fstab setting independent on the current kernel features. Maybe we can use the same for SMACK, is there any way how to determine that the system uses SMACK? (/proc/something or so...). -- for selinux we check for /sys/fs/selinux or /selinux. Ohh yes that would be so nice. You've got your choice for detecting smack, but I like stat(/sys/fs/smackfs) == 0 the best so far. You can parse /proc/filesystems for smackfs too, but that's obviously more complex. This method works with 3.9 and above, as that's when we made sysfs hold the mount point for smackfs. I assume we're talking about this code here: https://github.com/karelzak/util-linux/blob/master/libmount/src/context_mount.c#L181 ? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Tue, Oct 29, 2013 at 12:02 AM, WaLyong Cho walyong@samsung.com wrote: How about add specific options for smack? According to http://schaufler-ca.com/description_from_the_linux_source_tree Smack supports some mount options: smackfsdef=label: specifies the label to give files that lack the Smack label extended attribute. smackfsroot=label: specifies the label to assign the root of the file system if it lacks the Smack extended attribute. smackfshat=label: specifies a label that must have read access to all labels set on the filesystem. Not yet enforced. smackfsfloor=label: specifies a label to which all labels set on the filesystem must have read access. Not yet enforced. If we support 'SmackFsRoot=label' option and append the 'smackfsroot' option after checking the smack by test_security(smack), then I think we can solve most problems.(with Auke's worry) Adding config options for optional mount options that aren't even standard sorry, that just sounds like a terrible idea. Let's see why the -s option in mount isn't working. For Tizen, I'd rather see a ConditionSecurity=!smack / ConditionSecurity=smack pair of complementary unit files since that is a method that should aready work and even cover the case where you boot with security=none or even a kernel with smack disabled. Again a solution I would not recommend carrying upstream but it solves the problem for Tizen well and would be a 20-line patch or so. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Mon, Oct 28, 2013 at 3:44 AM, WaLyong Cho walyong@samsung.com wrote: At the same reason of /run and /dev/shm, when systemd is running with SMACK, countless tasks are failed by missed privilege. To avoid, /tmp is assigned '*' label. We discussed this problem earlier in our office last week as we're looking in to the same issues here, but the solution in this patch is very problematic: +m4_ifdef(`HAVE_SMACK', +`Options=mode=1777,strictatime,smackfsroot=*', +`Options=mode=1777,strictatime') The issue is here - the way you pass these options into tmp.mount make it so that everyone who has compiled systemd with Smack enabled cause them to attempt to mount tmpfs with these smack option. This is a problem since: 1) mount fails if the option smackfsroot=* is not known, and because 2) if the kernel was not booted with Smack, the option is not known/invalid and most importantly: 3) everyone who compiles systemd with xattr support will have Smack enabled too, even if they did not pass --enable-smack to configure. In short, you'd break everyone's tmp.mount with this patch. Patches like this need to stay out of the upstream tree, until we figure out how to automatically retry without these Smack specific options, or some other more elegant solution that doesn't break everyone else. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Mon, Oct 28, 2013 at 8:58 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 28.10.13 19:44, WaLyong Cho (walyong@samsung.com) wrote: At the same reason of /run and /dev/shm, when systemd is running with SMACK, countless tasks are failed by missed privilege. To avoid, /tmp is assigned '*' label. Won't this break if people compile systemd with SMACK enabled but run a kernel that has it disabled? We had a similar problem for the other mounts like /run, where we found a somewhat nice solution, but I am not sure how we can make the same work here... Our posts intersected, badly. Yes, as I said in my mail, this sadly does a bad job for those folks running with smack enabled in systemd but with it disabled in the kernel. For Tizen, we're thinking of just keeping this patch out of tree (and it will just be a one-liner). We could do a ConditionSecurity=Smack, or something like that (ottomh) but we'd get duplicate tmp mounts, which is bad due to the way we name mount units. ick. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Mon, Oct 28, 2013 at 1:09 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 28.10.13 12:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Mon, Oct 28, 2013 at 8:58 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 28.10.13 19:44, WaLyong Cho (walyong@samsung.com) wrote: At the same reason of /run and /dev/shm, when systemd is running with SMACK, countless tasks are failed by missed privilege. To avoid, /tmp is assigned '*' label. Won't this break if people compile systemd with SMACK enabled but run a kernel that has it disabled? We had a similar problem for the other mounts like /run, where we found a somewhat nice solution, but I am not sure how we can make the same work here... Our posts intersected, badly. Yes, as I said in my mail, this sadly does a bad job for those folks running with smack enabled in systemd but with it disabled in the kernel. For Tizen, we're thinking of just keeping this patch out of tree (and it will just be a one-liner). We could do a ConditionSecurity=Smack, or something like that (ottomh) but we'd get duplicate tmp mounts, which is bad due to the way we name mount units. ick. Hmm, here's an idea: there has been a long standig feature request to add a configurable boolean to mount unit files that controls /bin/mount's -s switch. Let's say we call it SloppyOptions=yes/no, or so. Then, we could set this for this unit file and apply the rest of the patch and things should work, and where they don't we can easily reassign to the kernel to respect the -s flag properly. Doing a patch that allows -s to be controlled should be fairly easy, would be happy to merge a patch for that! ahhh I hadn't even seen -s in /bin/mount yet, so I can see this helping out a lot. I'd be okay with a solution like that, it would certainly simplify things a lot, but we need to be careful not to overload mount options with all sorts of nonstandard options - it will make problems harder to debug and for some of these security enabled systems we will most likely want to actually _not_ use -s. After all, we want to make sure we're actually booting with properly setup Smack options e.g. a typo in 'nodev,nosuid,nexec' could be disastrous. (typo deliberate). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can apps ship their own copy of libudev?
On Thu, Oct 24, 2013 at 6:39 AM, Kay Sievers k...@vrfy.org wrote: On Thu, Oct 24, 2013 at 3:15 PM, Laszlo Papp lp...@kde.org wrote: On Thu, Oct 24, 2013 at 2:09 PM, Kay Sievers k...@vrfy.org wrote: No, you cannot really ship your own libudev, it is coupled with the daemon. They speak a non-trivial wire protocol and write udev database files which are a private implementation only; they changed in the past, and might change at any time again. Libudev and udevd can only be used in the same version. Do you provide some compatibility for a reasonable time to accommodate the existing users to switch onto the changed wired protocol? No, the daemon and the lib need to be updated at the same time, there is no promise about compat in any direction, they just belong together. Failing that, what would you suggest for the Qt developers? Is there an alternative solution to keep udev in the loop without building two separate packages, or distribution dependent packages? Libudev0 and libudev1 are almost API compatible, only a few pointless functions are no longer provided by the new library. There should be no problem at compilation time, both versions should work fine. Things built by distributions should not notice anything, but for binary compatibility across different versions of libraries, I have no sensible idea, sorry. One of the places I encountered this problem is Steam - it links against libudev0 while most non-pleistocene distributions are well into libudev1... Symlinking them allows me to waste time playing games :^) I can't recompile Steam, sadly. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Smack enabled systems need /dev special devices correctly labeled
On Mon, Oct 14, 2013 at 3:54 PM, Kay Sievers k...@vrfy.org wrote: On Mon, Oct 14, 2013 at 11:58 PM, Michael Demeter michael.deme...@intel.com wrote: +KERNEL==tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*, +GROUP=dialout, SECLABEL{smack}=* The SECLABEL{} instruction in a separate line? What is that supposed to do? Have you tested any of this? looks like the patch got munged in the process here (wrapped). Also, I'm not convinced that this belongs into the upstream repo. This seems like a very specific policy, similar to the selinux policy, which does not necessarily belong into systemd. Where is the policy defined for the apps and other stuff, isn't that the better place? We had a discussion about this in the office here, because I was hesitant about merging this upstream at first as well. However, the rules above (or, at least what they intend to do) are useful irregardless of whether you actually have created a Smack policy or not. Creating a Smack policy can be complex or simple, but there are a few basic things that should be tweaked even without any existing policy in place, hence, it makes sense to merge this upstream. After all, no matter the policy, these rules here are going to be needed. In short, setting '*' here as label is useful for all implementations of Smack, policy present or not. This basically boils down to the built-in set of rules that Smack has in the kernel - without these rules basic operation will stop working once you create a Smack policy. We want to make it easy for Smack users to create their Smack policy without having to hunt down all sorts of really low level Smack effects, and this is part of that. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Smack enabled systems need /dev special devices correctly labeled
On Fri, Oct 11, 2013 at 4:47 PM, Michael Demeter michael.deme...@intel.com wrote: - Add AC_DEFINE for HAVE_SMACK to configure.ac - Add Check for smack in Makefile.am to include smack default rules - Add smack default rules to label /dev/xxx correctly for access Change-Id: Iab07eb632b487b9ac4567cd08d0da6879709d44f Signed-off-by: Michael Demeter michael.deme...@intel.com --- Makefile.am | 5 + configure.ac | 1 + rules/55-udev-smack-default.rules | 18 ++ 3 files changed, 24 insertions(+) create mode 100644 rules/55-udev-smack-default.rules diff --git a/Makefile.am b/Makefile.am index e8be76b..bd397c4 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1943,6 +1943,11 @@ dist_udevrules_DATA += \ rules/80-net-name-slot.rules \ rules/95-udev-late.rules +if HAVE_SMACK +dist_udevrules_DATA += \ + rules/55-udev-smack-default.rules +endif + dist_udevhwdb_DATA = \ hwdb/20-pci-vendor-model.hwdb \ hwdb/20-pci-classes.hwdb \ diff --git a/configure.ac b/configure.ac index 091fe20..facd931 100644 --- a/configure.ac +++ b/configure.ac @@ -472,6 +472,7 @@ AS_HELP_STRING([--with-smack-run-label=STRING], if test x${have_smack} = xyes ; then AC_DEFINE(HAVE_SMACK, 1, [Define if SMACK is available]) +AM_CONDITIONAL([HAVE_SMACK], [true]) fi # -- diff --git a/rules/55-udev-smack-default.rules b/rules/55-udev-smack-default.rules new file mode 100644 index 000..6df90bb --- /dev/null +++ b/rules/55-udev-smack-default.rules @@ -0,0 +1,18 @@ +# do not edit this file, it will be overwritten on update + +KERNEL==null,SMACK=* +KERNEL==zero,SMACK=* +KERNEL==console,SMACK=* +KERNEL==kmsg,SMACK=* +KERNEL==video0,SMACK=* +KERNEL==card0,SMACK=* shouldn't these be card* and video* ? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] core: require $XDG_RUNTIME_DIR to be set for user instances
On Wed, Oct 9, 2013 at 4:57 AM, Mantas Mikulėnas graw...@gmail.com wrote: It seems that some places use /run otherwise, which isn't going to work. --- src/core/main.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/core/main.c b/src/core/main.c index fe291f8..36543c6 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -1404,6 +1404,12 @@ int main(int argc, char *argv[]) { goto finish; } +if (arg_running_as == SYSTEMD_USER +!getenv(XDG_RUNTIME_DIR)) { +log_error(Trying to run as user instance, but \$XDG_RUNTIME_DIR is not set.); +goto finish; +} + This is good, hopefully it will help folks debug user session usage better. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.
On Wed, Oct 9, 2013 at 9:18 AM, Kay Sievers k...@vrfy.org wrote: On Wed, Oct 2, 2013 at 8:12 PM, Auke Kok auke-jan.h@intel.com wrote: These 2 mounts are allowed to fail, which will happen if the system is not running a SMACK enabled kernel or security=none is passed to the kernel. The kernel throws errors for this at the console: tmpfs: Bad mount option smackfsroot Please conditionalize the mount calls with is_smack_enabled() or something similar. thanks for the note - I realize that smack support will be enabled for almost all builds since people have xattr support almost anywhere and that is the prereq. Churning on a patch as we speak... Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).
On Tue, Oct 8, 2013 at 3:29 PM, Schaufler, Casey casey.schauf...@intel.com wrote: -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, October 08, 2013 3:17 PM To: Kok, Auke-jan H Cc: Zbigniew Jędrzejewski-Szmek; Schaufler, Casey; systemd-devel Subject: Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label). On Mon, 07.10.13 10:30, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: Hi, the patches look OK. I dont' have a system with smack support at hand, but I tested them on Fedora, and didn't notice any adverse effects. I you've tested them with smack, then they should be applied, imo. Thanks, I just applied them myself - I just wanted to give folks a bit of time to read and test - so thanks for doing so! Hmm, the patches as they are merged now try to mount the SMACK version of /run and /dev/shm also in containers. Will this work? So long as the cgroup filesystem propagates the xattrs to and from the real filesystem it won't be a problem. If the cgroup filesystem is not doing that there will be a problem. So far (at least for SELinux) we tried to turn off all security layers in containers, since the policies are not virtualized. I don't know what you mean by virtualized in this context. Due to that it sounds more appropriate not to mount these SMACK versions in a container. More specifically, I'd like to remove the MNT_IN_CONTAINER flags from the lines you just added? That does sound like the safest approach. I would be fine with that. Does that make sense to you? yes, that makes sense. I'll include this in the patch that makes the smack-specific mounts not throw errors since that touches these lines as well. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
On Mon, Oct 7, 2013 at 7:53 PM, Andrey Borzenkov arvidj...@gmail.com wrote: В Mon, 7 Oct 2013 12:58:16 -0700 Kok, Auke-jan H auke-jan.h@intel.com пишет: Doing a `ln -sf /usr/lib/systemd/user/dbus.socket /etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or something like that maybe helps, but you're running into the basic problem that there's just not enough there for systemd --user to do anything useful (no default target defined, no dependencies installed to sane defaults, etc.). If there nothing to run as user session, why systemd starts user session? You probably misunderstand the problem. Stock systemd will start user@0.service when session for root opens (and I assume user@$UID.service for each other user). This service sometimes does not stop on shutdown causing timeout. If this service is not needed, it should not be started, right? So it is not we who are running in basic problem - it is systemd which is running into basic problem :) I can't speak for others, but I have not yet reproduced the issue at shutdown with just an empty user@0.service running. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
On Mon, Oct 7, 2013 at 12:08 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Oct 07, 2013 at 10:03:22PM +0300, Toms Seisums wrote: On 7 October 2013 20:33, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums toms.seis...@gmail.com wrote: I got two systems having the exact same problem with similar symptoms. Both systems are upgraded to latest Arch Linux, and just recieved Linux Kernel 3.11.4 upgrades also. One is running on Linode, one is a local machine. Apparently, the fix provided by Auke does not resolve the problem. Tom Gundersens' one, though, does it. Two problems still remain, though: 1. The dbus notice message upon logging in (Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory). Why are you starting a session dbus for user root? I'm not, it's started automatically. Might be an issue in Arch Linux. I think that we (as in upstream) start user@0.service whenever a root session is opened by cron or whatever. ahh yes, I see that here now too. So, the reason that dbus.socket/dbus.service isn't setup or anything is that there is no properly setup default.target that requires or sets up dbus.socket for user sessions. Doing a `ln -sf /usr/lib/systemd/user/dbus.socket /etc/systemd/user/default.target.wants/dbus.socket` (quick hack) or something like that maybe helps, but you're running into the basic problem that there's just not enough there for systemd --user to do anything useful (no default target defined, no dependencies installed to sane defaults, etc.). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
On Fri, Oct 4, 2013 at 9:37 AM, Toms Seisums toms.seis...@gmail.com wrote: [object Object] Look at Gmail failing flat on its face... lol Aside from that, can you perhaps try this patch: --- systemd-user-sessions.service 2013-10-02 15:37:14.181330287 -0700 +++ systemd-user-sessions.service 2013-10-04 11:53:37.02867 -0700 @@ -8,7 +8,7 @@ [Unit] Description=Permit User Sessions Documentation=man:systemd-user-sessions.service(8) -After=remote-fs.target +After=remote-fs.target dbus.service [Service] Type=oneshot some colleagues of mine identified that tasks in the user session that attempt to contact the system bus during shutdown may hang doing so. We can prevent this hang by making user sessions shut down entirely first before dbus is destroyed. It may or may not help. You can also insert After=dbus.service in to user@.service, but I feel this is a better spot. Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.
On Tue, Oct 1, 2013 at 4:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 01.10.13 16:11, Auke Kok (auke-jan.h@intel.com) wrote: Once system itself is running in a security domain for SMACK, it will fail to start countless tasks due to missing privileges for mounted and created directory structures. For /run and shm specifically, we grant all tasks access. Hmm, I am not convinced this patch is really desirable. So far we tried to make sure that a systemd that is compiled with selinux/smack/ima support works on kernels that lack it and vice versa. However, if I am not mistaken this patch will break this, as you set MNT_FATAL for the mounts but unconditionally add smackfsroot=* to the mount options -- which if I am not mistaken will cause the mount to fail on kernels that lack SMACK, right? thanks for replying - I was struggling to figure out if we really want to do that or not. Something that might work is simply dropping the MNT_FATAL from the HAVE_SMACK lines. That way, it will be attempted to mount things with the specified parameters, and if that fails it will be retried immediately with the following line that lacks the smackfsdef= param? The mounting code is smart enough to detect if /run is mounted and will not actually try to mount things twice if something is found to be mounted there already... I like that, that's totally reasonable. Will respin. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).
On Tue, Oct 1, 2013 at 4:42 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 01.10.13 16:11, Auke Kok (auke-jan.h@intel.com) wrote: index 1434dea..d7b8dce 100644 --- a/src/core/smack-setup.c +++ b/src/core/smack-setup.c @@ -36,6 +36,7 @@ #include macro.h #include smack-setup.h #include util.h +#include fileio.h #include log.h #include label.h @@ -138,6 +139,12 @@ int smack_setup(void) { return 0; } +#ifdef SMACK_RUN_LABEL +if (write_string_file(/proc/self/attr/current, SMACK_RUN_LABEL)) +log_warning(Failed to set SMACK label \%s\ on self: %s, +SMACK_RUN_LABEL, strerror(abs(r))); +#endif Looks got in principle, but error handling is borked. You need to assign r first before you print it. Also, write_string_file returns negative errno, so you should just strerror(-r) instead of strerror(abs(r)). derp prize. Apologies. Will fix. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers k...@vrfy.org wrote: On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena elena.reshet...@intel.com wrote: For example, I can set a couple of smack-related xattrs in one go like XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*. Doesn't make sense from smack point of view (only smack64 is really meaningful on device nodes), but proves that functionality works. right, but we could be setting other non-SMACK xattrs now all in one go - for example, SELINUX ones (security.selinux). Yeah, *looks* powerful, but also scary. :) And selinux is not managed by visible strings exposed to tools, it's all hidden in a library, and the database returns the stuff to apply. There should never be the need to set any string from selinux with a tool carrying static strings. This looks OK to me, can you take another look at it? I still can't wrap my head around the issue that we can use udev rules now to *add* things which will never get removed again. If we add a rule that set one of these attributes, and remove the rule again, the applied xattr will never be cleared. It all sounds not right to me, and I don't think we should go ahead with anything like this before we have sorted out the responsibilities and ownership of data we attach to device nodes. We do not do that for anything else, things just don't pile up, they are reset, cleared when the config goes away and an event is triggered. We probably need some concept of ownership, based on xattr names or namespaces, soemthing that makes it clear who's responsible to reset/clear the attributes when the config changes. Not sure, maybe we can just reset all xattrs with an add event, and declare add as a form of reset to a prisitine state. The other issue is, that as nice as generic support for xattrs sounds, it might in the end not be what we should offer to random users. I really can't decide at this moment, I have to think it through. well, for Tizen at least, we need this functionality. Too many nodes appear in /dev/ that should only be accessible by certain services alone, and this is exactly what SMACK adds. A good example is that SMACK allows us to grant only camera (/dev/video/*) privileges to approved camera applications, instead of having every application for a user in a session have full access to the camera. We get the best of both access control methods. I realize that unsetting/removal is a concern, but I don't think it should preclude merging code that is better at setting/adding :^) The only alternative I see is to create another udev event listener and have that process set smack labels. That would just duplicate a lot of udev code... And it still doesn't solve the removal of rules - that would be something only a e.g. %post script could consistently do. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] configure.ac Makefile.am src/login units/u...@.service.in
On Wed, Sep 11, 2013 at 12:39 PM, Zbigniew Jędrzejewski-Szmek zbys...@kemper.freedesktop.org wrote: Makefile.am|5 + configure.ac |7 +++ src/login/pam-module.c |4 ++-- src/login/systemd-user |8 units/u...@.service.in |2 +- 5 files changed, 23 insertions(+), 3 deletions(-) New commits: commit 5c390a4ae0d383b2003074ed011d47876c7e630c Author: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Date: Wed Sep 11 14:31:14 2013 -0400 Add pam configuration to allow user sessions to work out of the box systemd-logind will start user@.service. user@.service unit uses PAM with service name 'systemd-user' to perform account and session managment tasks. Previously, the name was 'systemd-shared', it is now changed to 'systemd-user'. Most PAM installations use one common setup for different callers. Based on a quick poll, distributions fall into two camps: those that have system-auth (Redhat, Fedora, CentOS, Arch, Gentoo, Mageia, Mandriva), and those that have common-auth (Debian, Ubuntu, OpenSUSE). Distributions that have system-auth have just one configuration file that contains auth, password, account, and session blocks, and distributions that have common-auth also have common-session, common-password, and common-account. It is thus impossible to use one configuration file which would work for everybody. systemd-user now refers to system-auth, because it seems that the approach with one file is more popular and also easier, so let's follow that. +1 Thanks for doing this - it'll be good for folks implementing user sessions to have a consistent approach. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Convert Inittab-Entry to systemd
On Tue, Aug 27, 2013 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Also I don't think this will properly handle session registration will it? There is nothing here that registers the session - no pam configs to include pam_systemd etc. nope I think you would need some kind of PAMName= attribute here to also handle that (man systemd.exec(5)). Obviously the /etc/pam.d/ stuff would need to be configured accordingly with appropriate permissions (I presume) to allow autologin but also ensure the pam_systemd stuff is configured properly. Never tried this kind of autologin but I don't think I'm talking too much nonsense :D PAMName=login should just work here. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to wait for a group of devices?
On Mon, Aug 19, 2013 at 10:37 AM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Aug 19, 2013 at 05:35:35PM +0200, Manuel Reimer wrote: On 08/19/2013 04:53 PM, Greg KH wrote: The second one wants to access DVB devices. These could be connected via PCI, PCI express or USB. So here I need Wait until all possible, currently connected, DVB devices are initialized and drivers are loaded. Same here, there is no way to ever do this (PCI devices can be hotplugged at anytime, just like USB). Instead, just do something based on _when_ you see a specific type of USB device, that way everything will work properly, no need to wait for anything. I'm not the developer of that daemon. I just want to run it reliably on a distribution, using systemd. What happens to that daemon if a new device is plugged into the system while it is already running? It has to handle that properly today, so there's no need in waiting around for some unknown amount of time for any reason. If it doesn't handle it properly, go poke upstream to get that fixed, as that's a major bug. I've encountered the problem in e.g. mythtv - if your DVB adapter takes a long time to initialize (40 seconds for my hauppauge cards, for instance, due to some weird FW loading problem), then your system will just boot and run mythbackend, which won't see any DVB tuners, and none of your scheduled recordings will record. This isn't something that can be fixed outside of MythTV. maybe it's been already fixed upstream, but in 0.25.1 this was still a bug. libudev should provide the methods needed to implement a proper fix. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena elena.reshet...@intel.com wrote: -Original Message- From: Kay Sievers [mailto:k...@vrfy.org] Sent: Tuesday, July 16, 2013 10:12 PM To: Reshetova, Elena Cc: Lennart Poettering; systemd-devel@lists.freedesktop.org; Ware, Ryan R; Schaufler, Casey; walyong@samsung.com Subject: Re: [systemd-devel] Patch for Smack labelling support in udev On Tue, Jul 9, 2013 at 4:34 PM, Reshetova, Elena elena.reshet...@intel.com wrote: -static int node_permissions_apply(struct udev_device *dev, bool apply, mode_t mode, uid_t uid, gid_t gid) +static int node_permissions_apply(struct udev_device *dev, bool +apply, mode_t mode, + uid_t uid, gid_t gid, struct +udev_list xattr_list) Guess we better pass the udev_list as a const pointer here. Ups, sorry, missed this one, of course it won't even work this way (I haven't tried to run it yet ... It looks like it could work, but please test it and make sure it does the right thing before we go ahead from here. OK, so now I have tested it and with one minor fix (passing a list entry and not the whole list in udev-node) it works just fine. I am able to setup one or more xattrs on device node using the syntax XATTR{attr_name}=value For example, I can set a couple of smack-related xattrs in one go like XATTR{security.SMACK64}=*, XATTR{security.SMACK64EXEC}=*. Doesn't make sense from smack point of view (only smack64 is really meaningful on device nodes), but proves that functionality works. right, but we could be setting other non-SMACK xattrs now all in one go - for example, SELINUX ones (security.selinux). I am attaching the patch. Kay, This looks OK to me, can you take another look at it? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wanna construct server-client model with systemd option.
On Mon, Jul 29, 2013 at 5:48 PM, Tony Seo tonys...@gmail.com wrote: I have aimed to construct server-client model. In order to build that mode, I supposed that there was X_server and A_client. I tried to do several time to operate that model properly, but I have failed to do that operation. In my view, I need to edit my service option which have been used for execution , but I'm not accustomed to using service option and confused a few option related with execution like Type=and Execstart=. All of the options involving startup types and dependencies are explained in the manual pages. You can view them online here: http://www.freedesktop.org/software/systemd/man/systemd.service.html If you need more help, or are troubleshooting, please post your unit files here and a description of what you intend for these to do, and we can look at solving your problems. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does systemd have points to spend many times to complete its process?
On Thu, Jul 25, 2013 at 4:58 AM, Tony Seo tonys...@gmail.com wrote: Hello I'm Tony Seo. I've analyzed a plot resulted in systemd-analyze plot. As you can see an attached image file, I got this image from my systemd. While I have analyzed it, I have several questions. 1. what is -.mount ? when I first saw -.mout, I was confused how to configure it. 2. I doubt that there are critical points which make systemd more delayed for several reasons. I have tried to test my systemd for optimization in perspective of time consume. So, I changed the order of unit dependency and sequence among units. But I found that I may not reduce the time to activate getty.target, multi-user.target and graphical.target. And I doubt that there are critical points or span of stage to make the systemd more delayed. I want to know whether I'm wrong or not. what do you think about it? If you know some tip to improve a systemd in optimize perspective, could you give some tips to make my systemd more fast? systemd is not the problem. the picture you posted shows that some service is delaying sysinit.target or basic.target. Most likely the player.service is implemented incorrectly. You may have entered the wrong Type in the service file. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
On Wed, Jul 10, 2013 at 5:48 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 06.07.13 01:16, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote: When creating the cgroup hierarchy for a user slice, chown this slice to the user uid. Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com --- src/shared/cgroup-label.c | 8 1 file changed, 8 insertions(+) diff --git a/src/shared/cgroup-label.c b/src/shared/cgroup-label.c index 574a7be..1891c9a 100644 --- a/src/shared/cgroup-label.c +++ b/src/shared/cgroup-label.c @@ -41,6 +41,7 @@ int cg_create(const char *controller, const char *path) { _cleanup_free_ char *fs = NULL; +uid_t uid = (uid_t) -1; int r; r = cg_get_path_and_check(controller, path, NULL, fs); @@ -59,6 +60,13 @@ int cg_create(const char *controller, const char *path) { return -errno; } +r = cg_path_get_owner_uid(path, uid); +if (r 0 r != -ENOENT) +return r; + +if (uid != (uid_t) -1) +chown(fs, uid, (gid_t) -1); + systemd in git will now grant access to the cgroup subtree in user@.service to the specific user. That should solve the issue. (Note that this means systemd --user will only work when run from user@.service, as access to the cgroup tree is *not* granted for normal sessions directly.) can you elaborate what normal sessions are? Are we talking about `PAMName=systemd-shared` being the part that distinguishes them? Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd[725]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
On Sat, Jul 6, 2013 at 1:40 AM, Marc-Antoine Perennou marc-anto...@perennou.com wrote: The patch I mailed a few hours ago about chowning cgroups solved this issue here. but it's not a permanent solution - only a workaround. I believe from the release notes that systemd --user shouldn't maintain the cgroups itself anymore directly and instead delegate to systemd-run(?). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] cgroup changes
On Fri, Jun 21, 2013 at 10:36 AM, Lennart Poettering lenn...@poettering.net wrote: Heya, On monday I posted this mail: http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html Here's an update and a bit on the bigger picture: Thanks for doing this - I am really looking forward to seeing this all take shape, and I hope to be able to leverage this in the future :^) All the points below are great, and problems that I've encountered in the past have all hinted towards this being the right way forward. #2 below has my interest - when you have some ideas about how the API will look I'd like to review it and match against our use cases... Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] cgroup changes
On Fri, Jun 21, 2013 at 1:10 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 21.06.13 12:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: http://lists.freedesktop.org/archives/systemd-devel/2013-June/011388.html Here's an update and a bit on the bigger picture: Thanks for doing this - I am really looking forward to seeing this all take shape, and I hope to be able to leverage this in the future :^) All the points below are great, and problems that I've encountered in the past have all hinted towards this being the right way forward. #2 below has my interest - when you have some ideas about how the API will look I'd like to review it and match against our use cases... Point #2 is precisely about not having APIs for this... ;-) So, in the future, when you have some service, and that service wants to alter some cgroup resource limits for itself (let's say: set its own cpu shares value to 1500), this is what should happen: the service should use a call like sd_pid_get_unit() to get its own unit name, and then use dbus to invoke SetCPUShares(1500) for that service. systemd will then do the rest. (*) Lennart (*) to make this even simpler we have been thinking of defining a new virtual bus object path /org/freedesktop/systemd1/self/ or so which will always points to the callers own unit. This would be similar to /proc/self/ which also points to its own PID dir for each process... With that in place you could then set any resource setting you want with a single bus method call. This is fine for applications that manage themselves, but I'm seeing more interest in use cases where we want external influence on cgroup hierarchies, for instance: - foreground/background priorities - a window manager marks background applications and puts them in the freezer, changes oom_score_adj so that old apps can get automatically cleaned up in case memory availability is low. - detecting runaway apps and taking cpu slices away from them. - thermally constraining classes of applications Those would be tasks that an external process would do by manipulating properties of cgroups, not something each task would do on it's own. Do you suggest these manipulations should be implemented without high level systemd API's and the controller just manipulates the cgroups directly? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] cgroup changes
On Fri, Jun 21, 2013 at 2:17 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 21.06.13 14:10, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: So, in the future, when you have some service, and that service wants to alter some cgroup resource limits for itself (let's say: set its own cpu shares value to 1500), this is what should happen: the service should use a call like sd_pid_get_unit() to get its own unit name, and then use dbus to invoke SetCPUShares(1500) for that service. systemd will then do the rest. (*) Lennart (*) to make this even simpler we have been thinking of defining a new virtual bus object path /org/freedesktop/systemd1/self/ or so which will always points to the callers own unit. This would be similar to /proc/self/ which also points to its own PID dir for each process... With that in place you could then set any resource setting you want with a single bus method call. This is fine for applications that manage themselves, but I'm seeing more interest in use cases where we want external influence on cgroup hierarchies, for instance: - foreground/background priorities - a window manager marks background applications and puts them in the freezer, changes oom_score_adj so that old apps can get automatically cleaned up in case memory availability is low. - detecting runaway apps and taking cpu slices away from them. - thermally constraining classes of applications Those would be tasks that an external process would do by manipulating properties of cgroups, not something each task would do on it's own. Do you suggest these manipulations should be implemented without high level systemd API's and the controller just manipulates the cgroups directly? All changes to cgroup attributes must go through systemd. If the WM wants to freeze or adjust OOM he needs to issue systemd bus calls for that. The run-away stuff I can't follow? the kernel will distribute CPU evenly among running apps if all want it, so not seeing why there's more monitoring needed. The thermal stuff is probably best done in-kernel i guess... Too dangerous/subject-to-latency for userspace, no? Only userspace can distinguish between e.g. a foreground and background application (WM) and decide that CPU consumption of certain apps in the background is excessive, and throttle it down further, which is somewhat similar to using freezer to just SIGSTOP them entirely basically. Thermal throttling from userspace allows you to distinguish between never make my SETI turn the fan on and throttle the entire system when I reach high fan speeds. You can't do that in the kernel. [1] Arguably this could be done in-task and not by an external controller, but you're still trusting the task to do the right thing, which may not be something you want to do. Auke [1] Note that the new Intel P-state driver by Dirk Brandewie changes how things work with nice(). The old behaviour was abused by folks running bitcoin miners at nice values which caused ondemand to do something irrational: nice-only tasks would keep the CPU in lowest frequencies, which is terrible from a power perspective - now every daemon running at nice value takes much longer to complete its task, burning more power then when it had raced-to-idle. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] cgroup changes
On Fri, Jun 21, 2013 at 3:07 PM, Kay Sievers k...@vrfy.org wrote: On Fri, Jun 21, 2013 at 11:47 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: Only userspace can distinguish between e.g. a foreground and background application (WM) and decide that CPU consumption of certain apps in the background is excessive, and throttle it down further, This would probably be some bus call to the systemd --user instance managing the services in the session, if that's what you mean? for instance, yes. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] We are working on trying to scale up to 1000 containers.
On Thu, Jun 20, 2013 at 12:23 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 18.06.13 09:11, Daniel J Walsh (dwa...@redhat.com) wrote: One concern we have is what will happen to systemd if we start 1000 services at boot. systemctl start httpd_sandbox.target For example. Is there anything we can do to throttle the start of so many unit files. Or would systemd do something itself. So, we have rate limits on some things. We maintain per-service ratelimits, and a ratelimit in the main even loop. However, that's really just a last resort thing. Basically, if the event loop spins more often than 50.000 times per second we will just totally block execution for 1s. So things get awfully slow when we do too much stuff so that we don't consumer 100% CPU forever, and that's all. I have no experience with running this many services on a machine. I am sure we can add various bits here and there to make sure things scale nicely for this. But for that I'd really like some performance data first, i.e. what actually really happens with the current code. I'd be very interested to see at least a bootchart and systemd-analyze plot of this... please post them to share! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking socket activated services is broken
On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl mbi...@gmail.com wrote: Hi, I've run systemctl mask rsyslog.service, but the service can still be started via systemctl start rsyslog.service or by generating a log message. Looks like a bug to me. Why would it be? Masking just removes the unit from the dependency tree of a target - I kinda prefer being able to mask and manually start a unit. The alternative, which is what you suggest, is that the administrator is prohibited from starting a unit - sounds much worse to me. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Describe handling of an AF_UNIX socket
On Wed, Jun 19, 2013 at 5:59 AM, Łukasz Stelmach l.stelm...@samsung.com wrote: Describe how to handle an AF_UNIX socket, with Accept set to false, received from systemd, upon exit. Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com --- man/systemd.socket.xml | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) Applied, thanks! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Delay dbus connection for user session
On Tue, Jun 4, 2013 at 10:31 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 29.05.13 08:59, Yang Chengwei (chengwei.y...@intel.com) wrote: diff --git a/src/core/manager.c b/src/core/manager.c index 0508628..467b5ba 100644 --- a/src/core/manager.c +++ b/src/core/manager.c @@ -503,7 +503,7 @@ int manager_new(SystemdRunningAs running_as, Manager **_m) { goto fail; /* Try to connect to the busses, if possible. */ -r = bus_init(m, running_as != SYSTEMD_SYSTEM); +r = bus_init(m, running_as != SYSTEMD_SYSTEM running_as != SYSTEMD_USER); if (r 0) goto fail; So, I've looked at this code again as I've spotted this problem over a year ago, and I'm wondering if this entire section should just be removed, since running_as only has 2 values (_SYSTEM and _USER) anyway... Would there be any objection to just dropping these 4 lines entirely? Lennart, Kay? I don't see how we'd have a 3rd manager type here. Yes, just in that case. If all of you agreed, I'd like submit a V2 to drop these lines. Hmm, this would break my usual testing routine, where i run user systemd against a bus daemon that is already running... I have no doubt that dropping the check entirely is the right way to go eventually, but maybe we can find a better way so that this continues to work for me until GNOME has switched over to systemd as service manager. I'm kinda dumb for not thinking this over, but, if you already have a dbus-daemon running, you have DBUS_SESSION_BUS_ADDRESS set. So, the whole idea of connection to a session bus if DBUS_SESSION_BUS_ADDRESS is unset makes no sense whatsoever. Lennart, would you agree that we could just do something like: if (getenv(DBUS_SESSION_BUS_ADDRESS)) // attempt to init dbus early else // debug message printing out that an attempt to connect to an existing session bus was not done I think that solves your use case, and will remove the whole dbus init attempt for folks running under a user session where this is not needed. Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to end a socket activated daemon
On Tue, Jun 18, 2013 at 3:04 AM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2013-06-17 pon 20:51, when Lennart Poettering wrote: On Fri, 14.06.13 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Jun 14, 2013 at 10:03:00AM +0200, Łukasz Stelmach wrote: We are converting some daemons to socket activation. Most of them open unix sockets and manage incoming connections in a main-loop, so the easiest way to convert it is to create Accept=false socket with systemd. Now, it is quite well described how to start such daemon, however, there is little about shutting it down. Should the daemon close(2) the received sockets? Should it unlink(2) them from a filesystem? close() yes, unlink() no. Strictly speaking you don't even have to do that. The kernel will clean up left-over fds when your process exits, hence you don't have to close it explicitly. But you certainly should not unlink() the socket in the fs, because then the socket will not be accessible anymore. Maybe I've asked the wrong question. I should rather have asked: Can I close? Can I unlink? Because that's what the code does now and we wanted to know which parts are common for standalone and systemd-socket-activated paths. The way I think about it is that if you are socket activated, you have a .socket unit and a .service unit. The .socket unit controls the socket. The .service unit does NOT control the socket. Therefore, the .service daemon should NOT unlink the socket. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Mon, Jun 17, 2013 at 9:37 PM, Kyungmin Park kmp...@infradead.org wrote: Hi Elena, On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 08.05.13 11:16, Reshetova, Elena (elena.reshet...@intel.com) wrote: Hi, This is the patch for review for enabling smack labelling for device nodes. The functionality and reasoning is inside. I will be happy to answer any questions. So, this needs some HAVE_SMACK ifdeffery at least. That said, I wonder if we should instead make this a generic XATTR{foobar}=waldo thing. Kay? Any update for this? if we use SMACK for udev, it requires it. Lennart's suggestion seems more than reasonable - it would make it generic enough to do: XATTR{security.SMACK64}=label which I think is all we need here. Elena, do you need help respinning this? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Tuning A/V at Boot
On Sat, Jun 8, 2013 at 5:43 PM, systemdki...@yopmail.com wrote: Where in boot sequence tune A/V latency? Is sound.target relevant? anything device specific should be triggered from a udev rule, so that you're not running this service while the device isn't actually available yet to userspace... systemd already installs a 99-systemd.rules file that has: SUBSYSTEM==sound, KERNEL==card*, TAG+=systemd, ENV{SYSTEMD_WANTS}+=sound.target So linking your service file into sound.target.wants should work. (but, I haven't tested this particular case or taget myself). you probably want to do: # mkdir /etc/systemd/system/sound.target.wants # ln -sf /path/to/your.service /etc/systemd/system/sound.target.wants/your.service Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] analyze: show generators on plot
On Sun, Jun 2, 2013 at 2:40 AM, Thomas H.P. Andersen pho...@gmail.com wrote: On Wed, May 15, 2013 at 5:09 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Wed, May 15, 2013 at 3:20 AM, Thomas H.P. Andersen pho...@gmail.com wrote: For completeness here is also a screenshot of how the generators are shown in the plot. (The plot was generated on an old computer with a HDD) very nice! Do you think this is something we want to commit? Absolutely - do you want to commit it yourself? If not, I'll be happy to do so. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Automatic Reboot Protocol [SOLVED]
On Thu, May 30, 2013 at 9:34 PM, systemdki...@yopmail.com wrote: Simple at did the trick from nightjanitor.sh echo systemctl start reboot.target | at now + 3 min If a more purist systemd method exists, I'd love to see it. You can likely create a timer unit, and start that once... Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Delay dbus connection for user session
On Tue, May 28, 2013 at 3:00 AM, Chengwei Yang chengwei.y...@intel.com wrote: Currently, if we have a user session, when systemd user session start, just like the situation for it as PID 1, dbus-daemon isn't ready at that moment, so it always failed with below error. Feb 06 16:50:10 localhost.localdomain systemd[417]: Failed to open private bus connection: Failed to connect to socket /run/user/app/dbus/user_bus_socket: No such file or directory Signed-off-by: Chengwei Yang chengwei.y...@intel.com --- src/core/manager.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/manager.c b/src/core/manager.c index 0508628..467b5ba 100644 --- a/src/core/manager.c +++ b/src/core/manager.c @@ -503,7 +503,7 @@ int manager_new(SystemdRunningAs running_as, Manager **_m) { goto fail; /* Try to connect to the busses, if possible. */ -r = bus_init(m, running_as != SYSTEMD_SYSTEM); +r = bus_init(m, running_as != SYSTEMD_SYSTEM running_as != SYSTEMD_USER); if (r 0) goto fail; So, I've looked at this code again as I've spotted this problem over a year ago, and I'm wondering if this entire section should just be removed, since running_as only has 2 values (_SYSTEM and _USER) anyway... Would there be any objection to just dropping these 4 lines entirely? Lennart, Kay? I don't see how we'd have a 3rd manager type here. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [Fix] Do not handle SIGKILL since we can not
On Mon, May 20, 2013 at 12:22 AM, Chengwei Yang chengwei.y...@intel.com wrote: This is a minor fix because it's not a major issue, this fix just avoid to get EINVAL error from sigaction(2). There are two signals can not handled at user space, SIGKILL and SIGSTOP even we're PID 1, trying to handle these two signals will get EINVAL error. There are two kinds of systemd instance, running as system manager or user session manager, apparently, the latter is a general user space process which can not handle SIGKILL. The special pid 1 also can not do that refer to kernel/signal.c:do_sigaction(). However, pid 1 is unkillable because the kernel did attach SIGNAL_UNKILLABLE to it at system boot up, refer to init/main.c:start_kernel() -- rest_init() -- kernel_thread() -- kernel_init() -- init_post() current-signal-flags |= SIGNAL_UNKILLABLE Signed-off-by: Chengwei Yang chengwei.y...@intel.com --- src/core/main.c |1 - src/shared/def.h |2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/core/main.c b/src/core/main.c index 7fc06be..8059f6a 100644 --- a/src/core/main.c +++ b/src/core/main.c @@ -1408,7 +1408,6 @@ int main(int argc, char *argv[]) { /* Reset all signal handlers. */ assert_se(reset_all_signal_handlers() == 0); -/* If we are init, we can block sigkill. Yay. */ ignore_signals(SIGNALS_IGNORE, -1); if (parse_config_file() 0) diff --git a/src/shared/def.h b/src/shared/def.h index 5ba170f..5abb544 100644 --- a/src/shared/def.h +++ b/src/shared/def.h @@ -32,4 +32,4 @@ #define SYSTEMD_CGROUP_CONTROLLER name=systemd #define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT -#define SIGNALS_IGNORE SIGKILL,SIGPIPE +#define SIGNALS_IGNORE SIGPIPE Ok, looks fine to me. Was there an error printed by user sessions? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make it possible to disable smack separately from xattr support
On Thu, May 16, 2013 at 1:40 AM, Karol Lewandowski k.lewando...@samsung.com wrote: Additionally, compile out rule loading if feature is disabled. --- configure.ac | 26 ++ src/core/smack-setup.c | 10 ++ src/core/socket.c |4 ++-- 3 files changed, 38 insertions(+), 2 deletions(-) Thanks, applied! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] analyze: show generators on plot
On Wed, May 15, 2013 at 3:20 AM, Thomas H.P. Andersen pho...@gmail.com wrote: For completeness here is also a screenshot of how the generators are shown in the plot. (The plot was generated on an old computer with a HDD) very nice! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition, man: Add support for ConditionSecurity=smack
On Wed, May 8, 2013 at 8:20 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, May 08, 2013 at 11:42:34AM -0700, Kok, Auke-jan H wrote: On Tue, May 7, 2013 at 5:29 AM, Karol Lewandowski k.lewando...@samsung.com wrote: On 05/07/2013 01:32 PM, Lennart Poettering wrote: On Tue, 07.05.13 13:21, Karol Lewandowski (k.lewando...@samsung.com) wrote: Heya, Hmm, does that directory always exist? Or only if AppArmor is actually runtime enabled? /sys/fs/smackfs is only registered when smack lsm is actually enabled: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smackfs.c?id=e93072374112db9dc86635934ee761249be28370#n2179 I.e. this check should ideally only return true if SMACK is not only built into the kernel, but actually really enabled during runtime. That's what the SELinux check does and what the most useful semantics are. Ok, I see that libselinux will consider selinux to be disabled also when policy is not loaded: http://userspace.selinuxproject.org/trac/browser/libselinux/src/enabled.c#L12 I guess we could do something similar (inspect /proc/self/attr/current) but honestly, I don't think it's really needed. Rafał, could you correct me if I'm wrong? smack is different as in that it can function without any loaded policies, so looking at policies isn't the right thing for smack. So likely looking at the presence of smackfs is exactly the same as looking at the preference of /proc/self/attr/current, except the latter is more complex, so less desirable imho. Applied, with a commit message based on this explanation. FYI, I just added similar code for IMA allowing ConditionSecurity=ima. I will take the AR to ask our Intel security folks if we don't need to do more - as in verify that IMA actually has a policy loaded, but the policy interface for IMA is write-only, so there is no way to find out if a policy was previously written. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 204
On Thu, May 9, 2013 at 8:56 AM, Lennart Poettering lenn...@poettering.net wrote: CHANGES WITH 204: * ConditionSecurity= gained support for detecting SMACK. Since this condition already supports SELinux and AppArmor we only miss IMA for this. Patches welcome! I just merged a minimal patch to support this (in a similar way that apparmor is done). Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
On Mon, May 6, 2013 at 2:44 PM, Kai Krakow hurikha...@gmail.com wrote: Hey list, I've built a server with systemd and it really worked out well. Fast booting (that means shorter maintenance times) and most important: Reliable service teardown and auto-restarts of crashed services. And yeah, I love the journal. I'm logging everything there. But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! So I enabled a session service for one user (actually, that's me): # sudo systemctl enable user@kakra.service But I cannot start it, and the user can neither. Starting it states in the journal: # sudo systemctl start user@kakra.service May 06 23:35:00 vweb002.jugendinfo.de systemd[1]: Starting User Manager for root... -- Subject: Unit user@kakra.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@kakra.service has begun starting up. May 06 23:35:00 vweb002.jugendinfo.de systemd[4438]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted -- Subject: Process /usr/lib/systemd/systemd could not be executed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/641257651c1b4ec9a8624d7a40a9e1e7 -- -- The process /usr/lib/systemd/systemd could not be executed and failed. -- -- The error number returned while executing this process is 1. May 06 23:35:00 vweb002.xx.de systemd[1]: Started User Manager for root. -- Subject: Unit user@kakra.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@kakra.service has finished starting up. -- -- The start-up result is done. Why does it say Starting user manager for root (and not my username) and why does it fail with pam? If I start systemd --user , then I can enable and run the user services defined in .config/systemd. The server is running Gentoo with systemd-201. Here's the systemd unit: kakra@vweb002 ~ $ cat /etc/systemd/system/user\@kakra.service # 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. [Unit] Description=User Manager for %u After=systemd-user-sessions.service [Service] User=%I PAMName=systemd-shared ^^ this line is the cause of your problems, as the /etc/pam.d/systemd-shared file does not exist. # in order to allow MEM_CG features to work, add memory:/ here ControlGroup=%R/user/%u/shared cpu:/ ControlGroupModify=yes Type=notify ExecStart=-/usr/lib/systemd/systemd --user Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket [Install] Alias=user@%i.service # as user: # systemctl start user@kakra.service Failed to issue method call: Access denied kakra@vweb002 ~ $ cat /etc/pam.d/system-auth authrequiredpam_env.so authrequiredpam_unix.so try_first_pass likeauth nullok authoptionalpam_permit.so account requiredpam_unix.so account optionalpam_permit.so passwordrequiredpam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 passwordrequiredpam_unix.so try_first_pass use_authtok nullok sha512 shadow passwordoptionalpam_permit.so session requiredpam_limits.so session requiredpam_env.so session requiredpam_unix.so session optionalpam_permit.so session optionalpam_loginuid.so session optionalpam_systemd.so You can copy /etc/pam.d/login to /etc/pam.d/systemd-shared, and then things should somewhat work. Additionally, you may want to copy the dbus user session service files from github.com/sofar/user-session-units to get user based dbus services working. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Dynamically allocate bootchart logs
On Fri, May 3, 2013 at 9:14 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 25.04.13 22:47, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Wed, Apr 24, 2013 at 5:20 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Apr 24, 2013 at 04:26:12PM -0700, Nathaniel Chen wrote: Instead of storing bootchart sample data in arrays, this patch moves storage to linked lists so that there is no more limit on samples. How does this approach compare to greedy_realloc? One of the problems with the static arrays is that it was inherently allocating way too much memory to begin with. Most tasks live much less time than (samples * interval), the rest of the array space is just wasted. The linked list approach drives down this memory requirement and makes navigating all the data much more straightforward. I also much prefer head pointers instead of having index numbers around. Still sounds like greedy_realloc() is what you want here. Storing sample data in a dynamically increasing array sounds much more natural than a linked list. I admit I hadn't heard of greedy_realloc() unti Zbigniew mentioned it, and I still fail to see why it would be so much better other than you can access members by index. You're still doing an allocation each time you extend the array (unless you're doing tricks and preallocate). The arrays are also sparse: most likely ps[0]...ps[N] will never be used since at the start (0) only very few processes exist - can greedy_realloc() handle large unallocated parts at the start of the array? That doesn't seem likely. Unless we re-index them where 0 means first sample found, but that means all sorts of extra math determining where each sample lines up in time... The lists are cross-linked, so even if one way we're making them an array again, we'd be walking them as a linked list in the other way for efficiency... Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add help option to bootchart man page
On Fri, Apr 26, 2013 at 9:36 AM, Nathaniel Chen nathaniel.c...@intel.com wrote: Bootchart has a help option. For the sake of consistency, this patch adds it to the man page. Also, the TODO is updated. Bootcharts were added to the journal in commit c4d58b0. applied, thanks. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Dynamically allocate bootchart logs
On Wed, Apr 24, 2013 at 4:26 PM, Nathaniel Chen nathaniel.c...@intel.com wrote: Instead of storing bootchart sample data in arrays, this patch moves storage to linked lists so that there is no more limit on samples. This patch also fixes parsing of /proc/pid/smaps in kernels 3.7. --- src/bootchart/bootchart.c | 48 -- src/bootchart/bootchart.h | 23 ++- src/bootchart/store.c | 96 --- src/bootchart/store.h | 3 +- src/bootchart/svg.c | 410 +++--- 5 files changed, 437 insertions(+), 143 deletions(-) mode change 100644 = 100755 src/bootchart/store.c Applied! I added an extra commit cleaning up MAXSAMPLES and 2 structs from bootchart.h. :^) Thanks for being around for 4 months on your internship - it was fun working with you! Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Dynamically allocate bootchart logs
On Wed, Apr 24, 2013 at 5:20 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Apr 24, 2013 at 04:26:12PM -0700, Nathaniel Chen wrote: Instead of storing bootchart sample data in arrays, this patch moves storage to linked lists so that there is no more limit on samples. How does this approach compare to greedy_realloc? One of the problems with the static arrays is that it was inherently allocating way too much memory to begin with. Most tasks live much less time than (samples * interval), the rest of the array space is just wasted. The linked list approach drives down this memory requirement and makes navigating all the data much more straightforward. I also much prefer head pointers instead of having index numbers around. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about the cross session dependence
On Sun, Apr 21, 2013 at 6:49 PM, Li, Min A min.a...@intel.com wrote: Hi systemd experts, I have a question about the dependence of user and system session. At system session, there is a service which need to be started after X(user session). At first I added “After=xorg.target” at this service, but It is said that the dependence of cross session is not work. Is that true? The user session instance does not know anything about the state of system services. So yes. If Yes, what’s the solution for this kind of issue? If you start your xorg through systemd --system, you will have to find an alternative way to tell the systemd --user how to determine that the service is ready. You can make a hack with a path unit, or write a user session service that uses IPC to communicate with the system session in some way. Nobody has looked at that, afaik. This is why user-session-units starts the X server from within the systemd --user environment - it removes that problem entirely. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 3:26 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem It's ok if you don't understand the proposal, but there's no reason to post random uninformed criticism, now you're creating a rumor that something like this, if implemented, would break all user management. You don't know this. It doesn't exist yet. Maybe it will be 100% backward compatible. Why wouldn't it be? Maybe it won't even go anywhere because people who do understand the topic can assess it's viability. Can you please just wait and see if this goes anywhere concrete first? Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [systemd-commits] Makefile.am src/bootchart - Make bootcharts go to the journal
On Tue, Apr 16, 2013 at 1:47 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Kok, Auke-jan H at 16/04/13 00:33 did gyre and gimble: FYI - this is a first pass to putting the bootcharts into the journal, exactly as coredump does. Ultimately, I will probably make bootcharts not go to disk other than the journal by default. A single one-liner can be used to get the latest bootchart automatically: $ journalctl -b MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518 --field=BOOTCHART bootchart.svg Just out of curiosity, what is the rational behind doing this? I think it's really cool that we can store arbitrary things in the journal, but I have concerns about storing potentially large stuff in there. The bootchart is likely not that big, but especially with coredumps (which has patches now thankfully) a small period of dump frenzy can fill up your logs and cause rotation. This could be exploited at some point in the future by an attacker to cover their tracks making you think some software had just gone haywire when reviewing your (rotated) journals. Was there anything particularly wrong or problematic previously with writing out to a file? Other than a log of previous boots, what advantage does it have to keep them in the journal? I'm mostly playing devils advocate here. I do kinda like the fact it's in there personally, but then I like shiny things. There's a few reasons why in this case I think it's good: - bootchart is optional - the value of comparing bootcharts to previous bootcharts is extremely high (single bootcharts are of less value unless you can compare them) - it compresses well (it's not compressed right now, but it should be easy to enable compression) and so it doesn't use that much space. My 100 bootcharts compressed from 75M to 5.9M with xz. - you can only reboot that often. Even on my developer system that I reboot often I still only had 100 bootcharts between june 2012 and today (and that system generates a bootchart on every boot by default) There's also the fact that the journal will rotate things away. If you don't log persistently, your bootcharts also won't be retained, etc. Ultimately, we don't want to put more files in /var/log or /run/log at all, and the journal seems the best place to put things like this. And that goes for a lot more things too. Auke PS: I would love to see a generic retreive attachment function to journalctl - something where we can pre-define attachment types that are known in an array (coredumps, bootcharts, the likes) and do something like `journalctl extract --type=all|bootchart|coredump `. It seems silly that we have coredumpctl implement this generically but only for coredumps, and should just live in journalctl. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to run *ctl command using systemd-nspawn
On Tue, Apr 16, 2013 at 12:11 AM, Koen Kooi k...@dominion.thruhere.net wrote: Hi, To help with flashing the onboard eMMC of a 10 boards I'm using systemd-nspawn to run package postinstall scripts that generate UUIDs and some other things and it's working great for that! Every board now has a unique value in /etc/machine-id instead it being empty and systemd randomizing it on startup. What doesn't work however is something like this: systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone Europe/Paris or this: systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname BeagleBoneBlack I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the name into /etc/hostname, but I'd like to use the *ctl commands because they work and have error handling built-in. it looks like I would need -b to get the *ctl commands to work, but -b doesn't support running single commands and exiting. My goal is to be able to drop in a rootfs tarball and change timezone and hostname settings in a config file for the flasher script and avoid generating N different tarballs. For use in the office lab I use something like [1] to generate the hostnames based on board revision and serial number. So, is there a way to *ctl command using systemd-nspawn in a rootfs that wasn't specially prepared (e.g. helper units/targets) for that? crazy thought, but, for completeness, there should probably be equivalent handling of init=/path/to/alternative/init in systemd-nspawn also the man page shows what you want should just work: SYNOPSIS systemd-nspawn [OPTIONS...] [COMMAND] [ARGS...] but I guess there's some issues there. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Sun, Apr 14, 2013 at 2:15 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 14.04.2013 23:06, schrieb Kok: [Unit] Description=Adaptive readahead daemon [Service] ExecStart=/usr/sbin/preload -f 1 -l Restart=always RestartSec=1 Nice=19 IOSchedulingClass=3 [Install] WantedBy=multi-user.target thanks, i will give it a try why not Type=forking? in my expierience a service works with simple/forking and only one of them while i must say my low-level understanding may not be enouh to realize what to use. The daemon doesn't need to do extra work to fork, and systemd won't need to do all the work associated with tracking a forked process - it's a lot less work, thus more efficient, and actually more robust. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Mon, Apr 15, 2013 at 10:59 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2013 19:53, schrieb Kok: thanks, i will give it a try why not Type=forking? in my expierience a service works with simple/forking and only one of them while i must say my low-level understanding may not be enouh to realize what to use. The daemon doesn't need to do extra work to fork, and systemd won't need to do all the work associated with tracking a forked process - it's a lot less work, thus more efficient, and actually more robust hi does this mean in recent systemd-versions it is no longer needed to use Type=forking at all while it was a must for some servcies in early versions? no, which is why I added the '-f' flag to the preload startup in the service unit that I posted (it keeps preload running in the foreground). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: [systemd-commits] Makefile.am src/bootchart - Make bootcharts go to the journal
FYI - this is a first pass to putting the bootcharts into the journal, exactly as coredump does. Ultimately, I will probably make bootcharts not go to disk other than the journal by default. A single one-liner can be used to get the latest bootchart automatically: $ journalctl -b MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518 --field=BOOTCHART bootchart.svg Auke -- Forwarded message -- From: Auke-Jan Kok a...@kemper.freedesktop.org Date: Mon, Apr 15, 2013 at 4:29 PM Subject: [systemd-commits] Makefile.am src/bootchart To: systemd-comm...@lists.freedesktop.org Makefile.am |3 +- src/bootchart/bootchart.c | 53 ++ 2 files changed, 55 insertions(+), 1 deletion(-) New commits: commit c4d58b0b6d238b955ece39a9dd9d3ca84b3408f3 Author: Auke Kok auke-jan.h@intel.com Date: Mon Apr 15 16:23:42 2013 -0700 bootchart: put the bootchart into the journal. This bit of code is mostly stolen from coredump.c. We construct a simple journal message and append the bootchart file in the journal automatically. You can extract the latest bootchart from the current boot with something like: $ journalctl -b MESSAGE_ID=9f26aa562cf440c2b16c773d0479b518 --field=BOOTCHART which prints it to stdout. None of the other logic is touched. The journal entry is created even if bootchart was run manually, which is probably wrong. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Sun, Apr 14, 2013 at 9:13 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 14.04.2013 06:42, schrieb Kok: On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net wrote: - extend the collector to run much longer which scre to change in teh config? You can modify systemd-readahead-done.timer, basically change: OnActiveSec=10s to whatever value you like thanks, i give it a try with 3600 seconds what should cover also a long coffee and mostly powner on with WOL and sync work-data while drive to the office take care that the new readahead file only gets written at the end of the 3600s, it's not updated continuously. is there any way to get informations what is collected and where are the informations stored? $ man systemd-readahead you can run $ /usr/lib/systemd/systemd-readahead analyze to see what's in the readahead file. a reason i would love to define specific applications which should always get preloaded on boot independent what is collected at runtime what about starting the machine remove vis WOL and never login because some data sync and shutdown 2 hours later - will the desktop get lost from the readahead-collection - questions over questions... feel free to contribute code or algorithm's to improve, I'll be more than welcome to take concrete contributions as I've been trying to improve on readahead for several years now. There is certainly room for improvement, but the devil is in the details. Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead - stops after 2 minutes
On Sun, Apr 14, 2013 at 10:18 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 14.04.2013 18:13, schrieb Reindl Harald: Am 14.04.2013 06:42, schrieb Kok: You can modify systemd-readahead-done.timer, basically change: OnActiveSec=10s to whatever value you like thanks, i give it a try with 3600 seconds what should cover also a long coffee and mostly powner on with WOL and sync work-data while drive to the office seems like i covered a bug the collector stops after exactly 2 minutes src/readahead/readahead.c has: usec_t arg_timeout = 2*USEC_PER_MINUTE; so, it's by design to stop after 2 minutes. That's for a good reason, I'm not sure if changing it makes much sense - most people will never want to use non-standard values, and 2 minutes helps everyone (it could help some non-standard cases more, but it doesn't hurt anyone). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 14.04.2013 20:49, schrieb Kok: a reason i would love to define specific applications which should always get preloaded on boot independent what is collected at runtime what about starting the machine remove vis WOL and never login because some data sync and shutdown 2 hours later - will the desktop get lost from the readahead-collection - questions over questions... feel free to contribute code or algorithm's to improve, I'll be more than welcome to take concrete contributions as I've been trying to improve on readahead for several years now. There is certainly room for improvement, but the devil is in the details if i only could C/C++ additionally to PHP/SQL and had time to work that out by 3 fulltime-jobs for one man :-( playing around with /usr/lib/systemd/systemd-readahead collect it looks like it re-creates /.readahead from scratch, meaning you lose also anything covered from the boot-run what about a dbus-triggered instance like cups and other services are fired up after login which creates a /.readahead-usersession proceeded at boot the same way as /.readahead it does more damage to do excessive readahead at boot for services that don't need to start until way, way after boot. The whole idea is to only read things you are going to need, and not more. Otherwise you could just read everything you can possibly read from disk into memory. seems like i covered a bug the collector stops after exactly 2 minutes src/readahead/readahead.c has: usec_t arg_timeout = 2*USEC_PER_MINUTE; so, it's by design to stop after 2 minutes. That's for a good reason, I'm not sure if changing it makes much sense - most people will never want to use non-standard values, and 2 minutes helps everyone (it could help some non-standard cases more, but it doesn't hurt anyone) well, but that makes systemd-readahead-done.timer useless as also extend how long the collector should run most people won't ever need to have it run more than 10 seconds until after the system is done booting, so it has good value. Longer isn't better (see my earlier argument, which holds especially true for rotating media). Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Sun, Apr 14, 2013 at 1:01 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 14.04.2013 21:18, schrieb Kok: On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald h.rei...@thelounge.net wrote: what about a dbus-triggered instance like cups and other services are fired up after login which creates a /.readahead-usersession proceeded at boot the same way as /.readahead it does more damage to do excessive readahead at boot for services that don't need to start until way, way after boot. The whole idea is to only read things you are going to need, and not more. Otherwise you could just read everything you can possibly read from disk into memory oh, now i realized that systemd-readahead covers any file-type surely it would be bad preloading anything including data please have a look at http://koji.fedoraproject.org/koji/buildinfo?buildID=393183 this is covering only libraries but seems to be in a bad maintaining-state because still no systemd-unit and all of te last updates where auto mass-rebuilds i wrote a systemd-unit for my machine which starts after kdm.service https://bugzilla.redhat.com/show_bug.cgi?id=951956 that unit file should just go into the project upstream, I'd also suggest removing the kdm dependency, running with -f, making log output go to stdout and removing the Type=forking, so it becomes: [Unit] Description=Adaptive readahead daemon [Service] ExecStart=/usr/sbin/preload -f 1 -l Restart=always RestartSec=1 Nice=19 IOSchedulingClass=3 [Install] WantedBy=multi-user.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote: Hi as far as i understand systemd-readahead is catching what is loaded directly due boot and 10 seconds after, well that's fine but is there a possibility to feed it with additional applications? example of the real life here: * the machine get powered on in the morning * due this sitting in the kitchen with a coffee * after that login in KDE, plasma and kopete are started * finally Thunderbird and Firefox are started * mostly Eclipse is the next * the machine has 16 GB RAM it would make pretty much sense that Thunderbird, Firefox and so on are pre-loaded or at least their libraries after the login-manager appears to use the time between boot and login A lot of things are possible and would help this: - change your system to auto-logon your account and start the applications for you. This is possible without any coding. - do per-user readahead, so that when a user logs in readahead-collect runs again but with a different pack, stored in the users home folder. Most of this should be possible with little work, but you'd have to write some xdg autostart files and possibly patch the readahead - extend the collector to run much longer - manually create a pack and disable the collector one of the problems is that it's hard to create something that generally works well for all situations, and autologon+lock desktop benefits from simplicity since readahead catches almost all of it. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-readahead and often used applications
On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.04.2013 23:08, schrieb Kok: On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote: it would make pretty much sense that Thunderbird, Firefox and so on are pre-loaded or at least their libraries after the login-manager appears to use the time between boot and login A lot of things are possible and would help this: - change your system to auto-logon your account and start the applications for you. This is possible without any coding. well, that's a no-go - do per-user readahead, so that when a user logs in readahead-collect runs again but with a different pack, stored in the users home folder. Most of this should be possible with little work, but you'd have to write some xdg autostart files and possibly patch the readahead - extend the collector to run much longer which scre to change in teh config? You can modify systemd-readahead-done.timer, basically change: OnActiveSec=10s to whatever value you like. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
On Wed, Apr 10, 2013 at 11:10 AM, Koen Kooi k...@dominion.thruhere.net wrote: Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas graw...@gmail.com het volgende geschreven: On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi k...@dominion.thruhere.net wrote: Hi, I have a bit of a heisenbug where dropbear.socket will just die and needs a systemctl restart dropbear.socket. I can't tell why it's dying, just that it does within 3 days of uptime. After restarting it it seems to be rock solid again for at least some weeks. The real way to fix this is to find out why it dies, After death, does `systemctl status dropbear.socket` show any error messages in the status line? No, only that it's dead, so systemd knows that it's has failed somehow dead isn't necessarily the same as failed... and I wonder if you can use ExecStartPost= here to kick it - it's valid for [Socket] sections. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket is dying, how to automatically restart it?
On Wed, Apr 10, 2013 at 1:12 PM, David Strauss da...@davidstrauss.net wrote: Are you sure it's not the corresponding service that really failed? actually, that's a good point, but if the socket unit is dead, I assume that systemd no longer is bind()ed to the ports... Koen, can you verify that that is the case? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus user services using the session bus
On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson wstephen...@kde.org wrote: I'm joining the flock of desktop people investigating using systemd to start a desktop session. So far I've checked out user-session-units and have created some more granular unit files that will do a native systemd start rather than u-s-u's wrapper around the upstream start script. As Tom asked, I'm interested in these changes as well - do you have your code posted somewhere? Also, you're saying there's a start script somewhere, can you tell me what you mean by that? I don't understand what you refer to by wrapper, either. Technically user-session-units doesn't wrap anything, it just provides straight unit files. One of them is derivative of user@.service from systemd, sure. I'm stuck now, because I want to start a service with Type=dbus that puts a service on the session bus, however, I can't see a way to specify the bus in the unit file. you can insert variables into the user session by `systemctl --user set-environment DBUS_S`. This is the only way to globally assign a dbus address to the session, but you'll have to do it before any significant service runs in the first place, which includes before dbus starts. I don't want to use dbus activation here to start the service as that invokes the chicken-egg problem that the service in question (kdeinit) job is to start all the processes that will be calling it via dbus later. Long term I would like to do away with this and perform this task via systemd too, but Type=dbus on the session bus seems like a valid use case that should work. I see there's a way to get the dbus session bus address into systemd because of the patch to fix this in user-session-units; would the right approach be to add a BusInstance= field to service and use the provided session bus address when watching for Type=dbus services that depend on user/dbus.service? all of this stuff seems to work just fine with user-session-units - of course the login/DM integration is wholly missing right now, but could you start with user-session-units and make modifications to get where you want? Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus user services using the session bus
On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco m...@0x01b.net wrote: Here are my user session units. I have a few dbus activated examples https://github.com/mmonaco/systemd-user-session I have one target for an i3 session and another for an openbox/cairo-dock session. I can freely switch between them without losing my active windows. I'll be testing gnome-3.8 soon so I'll be adding something that uses gnome-session. Would you be willing to contribute some of these (the dbus activation units for instance) back to user-session-units? There are quite a few folks using work based on user-session-units (a few distro's package it) and getting these in a central repository would help a lot of folks. Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus user services using the session bus
On Wed, Apr 3, 2013 at 1:28 PM, Tom Gundersen t...@jklm.no wrote: On Wed, Apr 3, 2013 at 9:43 PM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco m...@0x01b.net wrote: Here are my user session units. I have a few dbus activated examples https://github.com/mmonaco/systemd-user-session I have one target for an i3 session and another for an openbox/cairo-dock session. I can freely switch between them without losing my active windows. I'll be testing gnome-3.8 soon so I'll be adding something that uses gnome-session. Would you be willing to contribute some of these (the dbus activation units for instance) back to user-session-units? There are quite a few folks using work based on user-session-units (a few distro's package it) and getting these in a central repository would help a lot of folks. Auke, On a somewhat related note, any thoughts on merging user-session@.service back into user@.service upstream? Is there anything holding this back, except for lack of reviews? two things I'd like to solve before they are basically identical: 1) setting DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR and friends, if needed. We should probably have the xorg.service use `systemctl --user set-environment DISPLAY ...` or use another method to feeding the user session the proper DISPLAY (for e.g. gdm users, through loginctl). 2) figure out what to put in /etc/pam.d/systemd-shared. This file is currently not shipped at all by systemd but user@.service refers to it, and without at least including pam_systemd.so things are going to not work. Should we make this include pam_env.so? any others? nothing is holding it back, really, just time and creativity to come to good solutions. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv4] Add Listen* to dbus properties
On Tue, Apr 2, 2013 at 6:29 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Apr 02, 2013 at 08:26:17AM +0200, Tomasz Torcz wrote: On Tue, Apr 02, 2013 at 05:54:32AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 01, 2013 at 11:09:45PM +0300, Oleksii Shevchuk wrote: sockets.socket - Test Loaded: loaded (/home/alxchk/.config/systemd/user/sockets.socket; static) Active: inactive (dead) Listen: Stream: /tmp/stream1 Stream: @stream4 Pushed, but format changed to: listen1.socket - descr descr Loaded: loaded (/run/systemd/system/listen1.socket; static) Active: failed (Result: resources) ListenStream: /tmp/stream1 ListenDatagram: /tmp/stream2 I must say I liked per-type grouping better. It *looked* better, but the ordering of sockets is important: it determines the order of fd's for the .service. For some applications it might not matter, but for simple ones it might, so it's better to preserve this information. If ordering is important, the output should reflect the ordering. The only way I can see that you could accomplish that unambiguously is by numbering them. Sorting them will just leave people puzzled as to what the order is. So, consider adding some form of numbering to the list of listen addresses. Perhaps something like: 0: ListenStream: /tmp/stream1 1: ListenDatagram: /tmp/stream2 Cheers, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Optimizing systemd binaries for small deployments
On Wed, Mar 27, 2013 at 3:49 AM, Tino Breddin tbred...@tpip.net wrote: We are in the process of creating a very small image for devices with a maximum of 4MB flash. Compared to a SysV variant which clocks in at ~1MB using Systemd we are currently getting images sizes of ~10MB. At first glance the systemd binaries seem quite large. Before diving into lots of optimization I wanted to ask whether anybody has pointers we should follow or even experience using systemd for bare minimum images. Out of curiosity, but where does the consumed space actually sink into? Could you post perhaps the equivalend of something like du or list the top 20 largest items? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A newbie question regarding ordering cycles
On Thu, Mar 28, 2013 at 7:07 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Belal, Awais at 28/03/13 12:22 did gyre and gimble: Hi Guys, Just a newbie question as I am not much familiar with systemd yet. While setting up a system I have systemd-195 running but some of the services are not launched properly. I get the following: *systemd[1]: Found ordering cycle on basic.target/start* *systemd[1]: Walked on cycle path to sockets.target/start* *systemd[1]: Walked on cycle path to dbus.socket/start* *systemd[1]: Walked on cycle path to sysinit.target/start* *systemd[1]: Walked on cycle path to run-postinsts.service/start* *systemd[1]: Walked on cycle path to basic.target/start* *systemd[1]: Breaking ordering cycle by deleting job dbus.socket/start* *systemd[1]: Deleting job ofono.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job dbus.service/start as dependency of job dbus.socket/start* *systemd[1]: Deleting job connman.service/start as dependency of job dbus.socket/start* Systemd is running in SysV compatibility mode. The odd thing here for me is once the system finishes booting I can see that dbus.service is up (through systemctl) but ofono and connman are never started although I can start them manually through systemctl. 1. How can such problems be disected and is there a way for knowing the dependency graph? 2. The ordering cycle was broken at dbus.socket/start, why aren't the other services tried out after that? BR, Awais As Frederic already said in his reply, I've found the most common case for ordering cycles is the lack of LSB headers in legacy sysvinit scripts. When there are no LSB headers systemd has to use the number in the symlink (the S??fooo bit) to determine the ordering. These orders frequently cause cycles. Another improvement to the cycle breaking logic could be to somehow boot out non-native units first (ideally non-LSB, followed by LSB, followed by native if sysvinit compatibility is compiled in). It's perhaps not overly clean to implement tho'. The cleanest solution is of course just to migrate away from sysvinit in any shape or form :) BTW, both ofono and connman projects are systemd-enabled and will install service files (check the configure flags) that should work properly with systemd. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition: add option ConditionArchitecture
On Wed, Mar 27, 2013 at 12:22 AM, Tollef Fog Heen tfh...@err.no wrote: ]] Cristian Rodríguez El 26/03/13 15:17, Bill Nottingham escribió: Lukas Nykryn (lnyk...@redhat.com) said: --- TODO | 2 -- man/systemd.unit.xml.in | 8 src/core/condition.c | 16 src/core/condition.h | 1 + src/core/load-fragment-gperf.gperf.m4 | 1 + 5 files changed, 26 insertions(+), 2 deletions(-) Not that this seems wrong, but what is the usage case for this that can't be solved via package (de)installation? The patch looks fine to me, what it solves ? well.. there may be generic image deployments , who contain the same packages but one of them is only really useful in arch s390 or ppc.. etc.. I think it should be kernel architecture if so, since you might very well have multiple userland architectures enabled and working at the same time. (So it should be ConditionKernelArchitecture to make it clear.) or should it? on x86_64 one could have a kernel architecture supporting both x86_64 and i586, and running `setarch i586` does not change the kernel... Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] man/os-release: Add BUILD_ID field
On Mon, Mar 25, 2013 at 2:07 PM, William Douglas william.doug...@intel.com wrote: BUILD_ID is a fairly generic field used to identify the system image that was used to install the distribution. Signed-off-by: William Douglas william.doug...@intel.com --- man/os-release.xml | 22 ++ 1 file changed, 22 insertions(+) merged, thanks. I did remove the signed-off-by, which isn't needed. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
On Wed, Mar 27, 2013 at 10:50 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Wed, Mar 27, 2013 at 4:55 AM, Kay Sievers k...@vrfy.org wrote: On Sun, Mar 24, 2013 at 3:38 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: I don't see anything in udev code setting IOPRIO... perhaps elevating the few calls doing bklid and mount might be helpful? Maybe that really makes a difference, we should definitely try that. The blkid calls are really limited to a few bytes here and there, and will never loop for a long time, so that should be fine. Do you have a box, where you could you give it a quick try to bump the prio for the libblkid calls: ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...) in: src/udev/udev-builtin-blkid.c ? I left my non-ssd dev box in the office, so it'll be monday - but I'll absolutely give it a good test run. Could you still give that a simple try with current git and the chunking in place, so that we have some idea if the blkid calls would benefit from a higher priority? Even if we decide against doing that in the end, it would be nice to know ... I'm pretty sure it'll make a big dent, and I started looking at it already... So, I just spent an hour or so playing around with some stuff, and here are my thoughts: First off, it seems making the blkid parts run at RT,0 prio (highest possible) does absolutely nothing, which suggests that Lennart was right that almost all parts are already cached. However, while looking at the bootcharts I'm noticing `fsck` and `systemd-fsck` is taking considerable time to complete: before: - all fsck's done around 5.5sec total (measured after kernel done booting) - systemd-fsck's take ~ 2.4 secs - fsck children run for 2.2-2.8 seconds I then added RT,0 prio to systemd-fsck just before it forks it's children: after: - all fsck's done around 3.5secs total - systemd-fsck's take ~0.8 secs - fsck children run for 0.4-0.7 secs All in all that's a big gain, and it immediately exposes that `lvm` also is crazy slow (this is a vanilla fc18 install). So, I'd be interested in making this the default. Maybe not RT,0 which is a bit of a whammer, but certainly BE,0 or even RT,5 or something like that. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
On Mon, Mar 25, 2013 at 9:53 AM, Frederic Crozat fcro...@suse.com wrote: Le vendredi 22 mars 2013 à 15:22 -0700, Auke Kok a écrit For a comparison of how before/after bootcharts look (ext4 on a mobile 5400rpm 250GB drive) please look at: http://foo-projects.org/~sofar/blocked-tests/ There are bootcharts in the before and after folders where you should be able to see that many low-level services finish 5-7 seconds earlier with the patch applied (after). I've checked on my test netbook system and I can confirm your findings (with ext4 as fs), gain is around 3s, compared to the old readahead in systemd which was sometime slowing boot by 3s, compared to no readahead. I'd say commit it :) I pushed this right after v199, so folks with ext4 on a spinning drive have some extra time to compare the results. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] Makefile.am src/readahead
On Tue, Mar 26, 2013 at 10:38 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.03.13 10:33, Auke-Jan Kok (a...@kemper.freedesktop.org) wrote: Heyhey, wait. +clock_gettime(CLOCK_MONOTONIC, starttime); Could you please turn this into an usec_t? We generally use usec_t for everything, it's much simpler to use. We won't use the floating point stuff then either. usec_t is actually a uint64_t so you can do normal calculations with it, without involving floats or antyhing. usec_t starttime; starttime = now(CLOCK_MONOTONIC); ahh yes, that'll be nice to get the float out of there! Will fix asap - thanks! Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 199
On Tue, Mar 26, 2013 at 10:32 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.03.13 10:06, Shawn (shawnland...@gmail.com) wrote: you could get a backtrace in gdb Yes, please provide a backtrace for this! that's a helluva hard thing to do with systemd-coredump somehow not working on my box. I ended up redirecting coredumps to a file manually and got: #0 0xb77c4424 in __kernel_vsyscall () (gdb) bt full #0 0xb77c4424 in __kernel_vsyscall () No symbol table info available. #1 0xb75a03af in raise () from /usr/lib/libc.so.6 No symbol table info available. #2 0xb75a1c75 in abort () from /usr/lib/libc.so.6 No symbol table info available. #3 0x080b3d4b in log_assert (text=optimized out, file=0x80c6023 src/test/test-unit-name.c, line=131, func=0x80e1858 test_unit_printf, format=0x8110360 Assertion '%s' failed at %s:%u, function %s(). Aborting.) at src/shared/log.c:714 buffer = Assertion 'r == 0' failed at src/test/test-unit-name.c:131, function test_unit_printf(). Aborting., '\000' repeats 1949 times #4 0x080b4455 in log_assert_failed (text=0x80c61e3 r == 0, file=0x80c6023 src/test/test-unit-name.c, line=131, func=0x80e1858 test_unit_printf) at src/shared/log.c:719 No locals. #5 0x08050699 in test_unit_printf () at src/test/test-unit-name.c:131 m = optimized out mid = 0x8135008 7a3e74c61421e7d582e9c25e0016 root = 0xb76dcca8 u = optimized out u2 = optimized out r = optimized out bid = 0x8135030 1ab28824da47480c85252d8ce90b5d1e host = 0x8135058 hannah root_uid = optimized out #6 main (argc=1, argv=0xbfdce064) at src/test/test-unit-name.c:196 No locals. Reading symbols from /home/sofar/git/systemd/.libs/lt-test-unit-name...done. warning: core file may not match specified executable file. [New LWP 20476] Core was generated by `/home/sofar/git/systemd/.libs/lt-test-sched-prio'. Program terminated with signal 6, Aborted. #0 0xb777e424 in __kernel_vsyscall () (gdb) bt full #0 0xb777e424 in __kernel_vsyscall () No symbol table info available. #1 0xb755a3af in ?? () No symbol table info available. #2 0xb7694ff4 in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) Reading symbols from /home/sofar/git/systemd/.libs/lt-test-unit-name...done. warning: core file may not match specified executable file. [New LWP 20532] Core was generated by `./test-bus-marshal'. Program terminated with signal 6, Aborted. #0 0xb76fa424 in __kernel_vsyscall () (gdb) bt full #0 0xb76fa424 in __kernel_vsyscall () No symbol table info available. #1 0xb72383af in ?? () No symbol table info available. #2 0xb7372ff4 in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/u...@.service.in
On Mon, Mar 25, 2013 at 9:54 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 22.03.13 21:46, Auke-Jan Kok (a...@kemper.freedesktop.org) wrote: units/u...@.service.in | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) New commits: commit 3abcb6acedb588ca17f6374c1836f8a58396e520 Author: Auke Kok auke-jan.h@intel.com Date: Fri Mar 22 21:43:31 2013 -0700 Update user session unit template. While most folks will be using the derivative from user-session-units, I'm updating this one to reflect some of the fixes and things to note about user sessions: - cgroup should be set with %u - username instead of %I - set dbus path with %U explicitly too - hint to folks that wish to use MEM_CG features in user sessions - allow unit to be enabled for instances with systemctl enable Hmm, with the old %I wouldn't it suffice to instantiate the unit via user@USERNAME.service rather than user@UID.service? I mean, I am not against this patch, just noticing this... Right, it will just work regardless now, so, less chance for problems. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemd-analyze: refactor for more data collection
On Sun, Mar 24, 2013 at 11:23 AM, Umut Tezduyar u...@tezduyar.com wrote: --- src/analyze/systemd-analyze.c | 119 +++-- 1 files changed, 66 insertions(+), 53 deletions(-) diff --git a/src/analyze/systemd-analyze.c b/src/analyze/systemd-analyze.c index 01bf55e..3dcde30 100644 --- a/src/analyze/systemd-analyze.c +++ b/src/analyze/systemd-analyze.c @@ -70,7 +70,7 @@ struct boot_times { usec_t userspace_time; usec_t finish_time; }; -struct unit_times { +struct unit_stat { char *name; usec_t ixt; usec_t iet; hey, almost half of this patch is about just renaming this struct... is there a reason to do this at all? it seems like the old name is actually better at describing the content. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemd-analyze: --type cpuacct option for blame
On Sun, Mar 24, 2013 at 11:23 AM, Umut Tezduyar u...@tezduyar.com wrote: systemd-analyze blame --type cpuacct displays cpu time usage information of the cgroup. The information displayed is cpuacct.usage. ControlGroup=cpuacct:/foo/bar for a service would work. ControlGroupPersistent=yes for a oneshot service keeps cpuacct around so blame can retrieve it. DefaultControllers=cpuacct on system.conf can be set to have cpuacct same as systemd cgroup. --- src/analyze/systemd-analyze.c | 131 + 1 files changed, 119 insertions(+), 12 deletions(-) So, I'm not against this patch per se, but, I'm wondering if it's not better to display this data in systemd-cgtop. After all, systemd-analyze is a one-time snapshot and suffers from data loss when services are restarted, etc. Having a method to show cpuacct totals in systemd-cgtop seems much more useful. You could modify the code to show totals instead of percentages, etc. Have you thought about doing that? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers k...@vrfy.org wrote: On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 23.03.13 23:42, Tom Gundersen (t...@jklm.no) wrote: On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering lenn...@poettering.net wrote: Then, I generally believe better than trying to be smart when reading things we should much rather try to place things properly on disk. We already defrag things based on the read order for btrfs, we should do the same for ext4. The API for that unfortunately awful, but e4rat has shown that this does work. Basically, this is what you do: Isn't the problem that reads by blkid and friends are not being caught by readahead-collect, and hence end up blocking until readahead-replay has finished? In that case reordering won't help (I think). Hmm, if root file system is mounted the file system's superblock should be cached in memory, I'd expect, so blkid shouldn't have to block... I guess it's more about ~30-40 tiny seek()/read() on the main block device, spread all over the place mainly the first 200 and the last few kilobyte of the disk, what blkid need to do. None of of that shares the cache with the mounted filesystem blocks, and I don't think any of that data is in any other cache at that time. I don't see anything in udev code setting IOPRIO... perhaps elevating the few calls doing bklid and mount might be helpful? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
On Sat, Mar 23, 2013 at 4:37 PM, Kay Sievers k...@vrfy.org wrote: On Sun, Mar 24, 2013 at 12:02 AM, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Sat, Mar 23, 2013 at 3:54 PM, Kay Sievers k...@vrfy.org wrote: On Sat, Mar 23, 2013 at 11:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 23.03.13 23:42, Tom Gundersen (t...@jklm.no) wrote: On Sat, Mar 23, 2013 at 2:16 AM, Lennart Poettering lenn...@poettering.net wrote: Then, I generally believe better than trying to be smart when reading things we should much rather try to place things properly on disk. We already defrag things based on the read order for btrfs, we should do the same for ext4. The API for that unfortunately awful, but e4rat has shown that this does work. Basically, this is what you do: Isn't the problem that reads by blkid and friends are not being caught by readahead-collect, and hence end up blocking until readahead-replay has finished? In that case reordering won't help (I think). Hmm, if root file system is mounted the file system's superblock should be cached in memory, I'd expect, so blkid shouldn't have to block... I guess it's more about ~30-40 tiny seek()/read() on the main block device, spread all over the place mainly the first 200 and the last few kilobyte of the disk, what blkid need to do. None of of that shares the cache with the mounted filesystem blocks, and I don't think any of that data is in any other cache at that time. I don't see anything in udev code setting IOPRIO... perhaps elevating the few calls doing bklid and mount might be helpful? Maybe that really makes a difference, we should definitely try that. The blkid calls are really limited to a few bytes here and there, and will never loop for a long time, so that should be fine. Do you have a box, where you could you give it a quick try to bump the prio for the libblkid calls: ioprio_set(IOPRIO_WHO_PROCESS, getpid(), ...) in: src/udev/udev-builtin-blkid.c ? I left my non-ssd dev box in the office, so it'll be monday - but I'll absolutely give it a good test run. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel