Re: [systemd-devel] Can't make local user.conf work
On Mon, Mar 7, 2016 at 7:31 AM, G D'Arezzo wrote: > On 29 February 2016 at 19:05, Kok, Auke-jan H > wrote: >> On Sun, Feb 28, 2016 at 8:26 PM, G D'Arezzo 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'Arezzo 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 ___ 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'Arezzo wrote: > 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 Townsend wrote: > 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 Townsend wrote: > 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 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ðmundsson wrote: > 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] What I think is really wrong with systemd
On Wed, Sep 16, 2015 at 8:38 AM, Reindl Harald wrote: > Am 16.09.2015 um 17:13 schrieb Ahmed S. Darwish: >> >> Not to mention that the same rolling-release model was adopted by >> the kernel long time ago for similar reasons and much more ;-) > > that is *not* true and won't become true by repeat it > > https://www.kernel.org/ > > mainline: 4.2 2015-08-30 > stable: 4.1.7 2015-09-13 > longterm: 3.18.21 2015-08-31 > > only systemd upstream has from the core component a "that is the new version > with no major/minor" attitude and the kernel is the very last project to > compare given "longterm: 2.6.32.67 2015-06-03" nonsense. Only one of those three mentioned is actually "the linux kernel". The other two are independently running forks that "the linux kernel" maintainer does not maintain. So, he's actually entirely correct to paraphrase that the linux kernel community is using a rolling release model. The fact that individuals make "respins" that follow a non-rolling release model does not diminish the truth of that in any way possible. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://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 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] [HEADS-UP] Intent to remove readahead from systemd
On Thu, Aug 14, 2014 at 10:16 AM, Lennart Poettering 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 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] [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 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.
> +large graphs. The time elapsed since boot
> +might also include any time that the
> system
> +was suspended.
>
>
>
> 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
Re: [systemd-devel] PATCH: fix systemd-bootchart svg background
On Mon, Jun 16, 2014 at 9:52 AM, Frederic Crozat 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 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 wrote: > On Sun, Dec 1, 2013 at 8:25 PM, Hristo Venev 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@.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" 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 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/ 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 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 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 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 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/ 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 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/ 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 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 1:09 PM, Lennart Poettering 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 >> 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] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Mon, Oct 28, 2013 at 8:58 AM, Lennart Poettering 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 3:44 AM, WaLyong Cho 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] Can apps ship their own copy of libudev?
On Thu, Oct 24, 2013 at 6:39 AM, Kay Sievers wrote: > On Thu, Oct 24, 2013 at 3:15 PM, Laszlo Papp wrote: >> On Thu, Oct 24, 2013 at 2:09 PM, Kay Sievers 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] [systemd-commits] src/bootchart
On Tue, Oct 15, 2013 at 6:44 AM, Zbigniew Jędrzejewski-Szmek wrote: > src/bootchart/store.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > New commits: > commit 306e6650221d88b29831bcdcef94447afb65df5c > Author: Igor Zhbanov > Date: Tue Oct 15 14:35:13 2013 +0400 > > Fix for SIGSEGV in systemd-bootchart on short-living processes > > The function svg_ps_bars() dereferencess NULL pointer in the line > endtime = ps->last->sampledata->sampletime; > because of partially initialized ps_struct (ps->last == NULL). > > If some process terminates between scaning /proc directory in the > log_sample() > function and reading additional information from /proc/PID/... files, > the files couldn't be read, the loop will be continued and partially > initialized structure returned. ahhh neat, thanks, that must have been a hard one to spot! 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 4:21 PM, Michael Demeter wrote: >> That's not the point, the point is is if *belongs* into the systemd >> repo, not if it's *enabled* by default or not. From what I see, it's >> nothing really we should ship upstream. > > If Smack is enabled in systemd it starts very early and all of the special > devices need to be labeled properly for correct operation the question isn't whether this should be udev rules or not, since that's obvious - there is no other way to set these permissions than through udev rules. the discussion is whether these should ship with the upstream systemd project, or are vendor specific and should be maintained downstream. As I explained in my other e-mail, these rules (I'm not saying they are the right ones, I'm really not that much of a udev rule expert here!) are irregardless of any policy and are useful to anyone who enables Smack, so there's a strong preference, and benefit from having these rules here, and not in a downstream project. >> Also, it should not repeat the primary permissions settings from the >> default rules, that is just not right. > > This was done at Auke's request since the rule is adding the SECLABEL > for debugability to have the original rule present was desirable. That's just me not knowing udev well, so let's remove the permissions if they just duplicate things. 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 wrote:
> On Mon, Oct 14, 2013 at 11:58 PM, Michael Demeter
> 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
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
> ---
> 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 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 2/2] Run with a custom SMACK domain (label).
On Tue, Oct 8, 2013 at 3:29 PM, Schaufler, Casey 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] [PATCH 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.
On Wed, Oct 9, 2013 at 9:18 AM, Kay Sievers wrote: > On Wed, Oct 2, 2013 at 8:12 PM, Auke Kok 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] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
On Mon, Oct 7, 2013 at 7:53 PM, Andrey Borzenkov wrote: > В Mon, 7 Oct 2013 12:58:16 -0700 > "Kok, Auke-jan H" пишет: > >> >> 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 wrote: > On Mon, Oct 07, 2013 at 10:03:22PM +0300, Toms Seisums wrote: >> On 7 October 2013 20:33, Kok, Auke-jan H wrote: >> > On Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums >> > 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 Mon, Oct 7, 2013 at 1:27 AM, Toms Seisums 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? 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 Sun, Oct 6, 2013 at 8:02 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Oct 02, 2013 at 11:12:09AM -0700, Auke Kok wrote: >> Allows the systemd --system process to change its current >> SMACK label to a predefined custom label (usually "system") >> at boot time. >> >> This is needed to have a few system-generated folders and >> sockets automatically be created with the right SMACK >> label. Without that, processes either cannot communicate with >> systemd or systemd fails to perform some actions. >> --- > 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! 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 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 2/2] Run with a custom SMACK domain (label).
On Tue, Oct 1, 2013 at 4:42 PM, Lennart Poettering
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 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.
On Tue, Oct 1, 2013 at 4:40 PM, Lennart Poettering 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] Small tool to spawn programs in graphical sessions from non-graphical ones
On Sat, Aug 31, 2013 at 2:09 AM, Manuel Amador (Rudd-O) wrote: > Based on systemd's related sibling loginctl, I managed to accomplish the > holy grail of the 90's: get Amarok to play music on my desktop sessiom from > a crontab (motivated by the missus' desire to have an alarm in the home > theater that requires her to walk downstairs, to adapt to her polyphasic > sleep): > > https://github.com/Rudd-O/run-in-gui > > Pull requests to, well, there. Flames to my personal email. I'm sure it's > buggy as fuck since it's been working only for the last half an hour or so, > but we pulled it off together in the space of 2 hours. Not criticizing your approach here, but, I think one could implement systemd --user sessions and timer units to dbus-send "play" messages to amarok. Together with creating a service for amarok that would keep it running, one could do this in 2-3 units. Glad we have achieved your 90's holy grail though :^) Auke ___ 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, Sep 30, 2013 at 7:17 PM, Lennart Poettering wrote: > units/u...@.service.in |1 + > 1 file changed, 1 insertion(+) > > New commits: > commit e6dca814412f17db05910acedf76d36d3b7f1355 > Author: Evan Callicoat > Date: Mon Sep 23 21:01:04 2013 -0500 > > units: Add SHELL environment variable > > With the advent of systemd --user sessions, it's become very interesting > to spawn X as a user unit, as well as accompanying processes that may have > previously been in a .xinitrc/.xsession, or even just to replace a collection > of XDG/GDM/KDM/etc session files with independent systemd --user units. The > simplest case here would be to login on a tty, with the traditional > /usr/sbin/login "login manager". > > However, systemd --user (spawned by user@.service) is at the top level of > the slice for the user, and does not inherit any environment variables from > the login process. Given the number of common applications which rely on > SHELL being set in the environment, it seems like the cleanest way to provide > this variable is to set it to %s in the user@.service. > > Ideally in the long-term, applications which rely on SHELL being set > should be fixed to just grab it from getpwnam() or similar, but until that > becomes more common, I propose this simple change to make user sessions a > little bit nicer out of the box. sadly, that's going to take a very long time. so, +1 from me on this change. Thanks, 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 wrote:
> On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
> wrote:
>> On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena
>> 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 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 > 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 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 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
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
> 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] Create a new logind session from a systemd --user unit
On Mon, Aug 5, 2013 at 12:55 PM, Colin Walters wrote: > On Sun, 2013-08-04 at 10:46 -0400, Colin Walters wrote: > >> https://people.gnome.org/~walters/user-session-patches > > Now updated with various bugfixes. PolicyKit works, the lock screen > works, etc. just chiming in here... it's like you knew it was my birthday this week! :^) > Or maybe we should spawn user@.service from inside the first session, > and treat that as primary; add a new state like "user-linger" that > occurs if the user logs in twice, then closes the first one. > > It would feel a lot less architecturally weird too if we changed getty > and ssh logins to behave the same way as gdm - i.e. we have > loginshell@.service, and keep around a dummy process. > > So...dunno, it does feel hacky in some ways. > > On the other hand, I'm *really* looking forward to being able to just > ssh/VT login into a machine and be able to run e.g. "gdbus monitor" and > "gsettings". so, most of the patches look very reasonable to me, and I don't see anything wrong. I wondered, just like Simon, if multi-user is still working as well Other than that, please keep up the good work, this is something I've been looking forward to seeing for over a year now. 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 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 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
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
>> ---
>> 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 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] systemd[725]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
On Thu, Jul 4, 2013 at 6:30 PM, Kay Sievers wrote: > On Fri, Jul 5, 2013 at 2:35 AM, Cristian Rodríguez > wrote: >> Since systemd 205, Im getting this scary warning >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting >> user-1000.slice. >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Created slice >> user-1000.slice. >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting User >> Manager for 1000... >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting Session 1 >> of user crrodriguez. >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd-logind[423]: New >> session 1 of user crrodriguez. >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd-logind[423]: Linked >> /tmp/.X11-unix/X0 to /run/user/1000/X11-display. >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Started Session 1 >> of user crrodriguez. >> >> Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[725]: Failed at step >> PAM spawning /usr/lib/systemd/systemd: Operation not permitted > > We are just not there, systemd --user is not started at the moment, > the cgroup sub-tree for the user's session is not accessible for the > systemd --user process running under the user's uid. > > Nothing really to worry about, the message should be ignored for now, > we will get there soon ... does the old method of manually starting user@.service at least still work? I haven't had any time to track the latest release yet... 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 3:07 PM, Kay Sievers wrote: > On Fri, Jun 21, 2013 at 11:47 PM, Kok, Auke-jan H > 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] [HEADSUP] cgroup changes
On Fri, Jun 21, 2013 at 2:17 PM, Lennart Poettering 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 1:10 PM, Lennart Poettering 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 10:36 AM, Lennart Poettering 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] We are working on trying to scale up to > 1000 containers.
On Thu, Jun 20, 2013 at 12:23 PM, Lennart Poettering 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] [PATCH] Delay dbus connection for user session
On Tue, Jun 4, 2013 at 10:31 AM, Lennart Poettering
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] [PATCH] Describe handling of an AF_UNIX socket
On Wed, Jun 19, 2013 at 5:59 AM, Łukasz Stelmach wrote: > Describe how to handle an AF_UNIX socket, with Accept set to false, > received from systemd, upon exit. > > Signed-off-by: Łukasz Stelmach > --- > 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] Masking socket activated services is broken
On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl 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] how to end a socket activated daemon
On Tue, Jun 18, 2013 at 3:04 AM, Łukasz Stelmach 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 wrote:
> Hi Elena,
>
> On Thu, Jun 6, 2013 at 7:10 PM, Lennart Poettering
> 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, 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] Running "systemd --user" and creating a new session
On Fri, Jun 7, 2013 at 3:18 AM, Иван Шаповалов wrote: > Hi all, > > Recently I've attempted to switch my user session to "systemd --user". The > configuration is pretty simple - no multiseat, nothing special. > I start the user session with provided "user@.service" with some > modifications: > > --- /usr/lib/systemd/system/user@.service 2013-05-30 16:55:28.0 > +0400 > +++ /etc/systemd/system/user@.service 2013-06-07 03:46:27.158435556 +0400 > @@ -13,11 +13,14 @@ > User=%I > PAMName=systemd-shared > # in order to allow MEM_CG features to work, add "memory:/" here > -ControlGroup=%R/user/%U.user/shared cpu:/ > +# note to myself: cpu:/ has been removed due to running a -ck kernel > +ControlGroup=%R/user/%U.user/shared > ControlGroupModify=yes > Type=notify > ExecStart=-/usr/lib/systemd/systemd --user > +Environment=XDG_RUNTIME_DIR=/run/user/%U > > Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket > +Environment=SHELL=%s > > [Install] > Alias=user@%i.service > -- > > This modified unit works (almost) as expected, however, everything that is > started under that systemd instance does _not_ get its own session. > For example, $XDG_SESSION_ID is empty and there are no new records > in output of 'loginctl list-sessions'. > > So, a question: is this the desired behavior, and, if yes, how can I create > a session manually? This is one of the missing parts - loginctl needs modifications to make enable-linger working, and that's not implemented. Ultimately, the admin should not directly start a user@.service instance manually. 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 wrote: > On Wed, May 15, 2013 at 5:09 PM, Kok, Auke-jan H > wrote: >> On Wed, May 15, 2013 at 3:20 AM, Thomas H.P. Andersen >> 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, 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 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
> ---
> 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 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
> ---
> 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 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 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] Debugging systemd shutdown problem on openSuSE 12.3
On Mon, May 13, 2013 at 6:28 AM, Rainer Krienke wrote: > I i trouble on a openSuSE 12.3 system that is using autofs to mount > users home directories and other shares. The system basically works fine. > > When I try to shut down or reboot the system sometimes this works, but > most of the time the system terminates kdm and other processes (eg ssh > access no longer works then) but it won't reboot or turn power off in > case of shutdown. > > I added > systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M > systemd.sysv_console=1 > to the kernel command line and created a debug.sh file > > #!/bin/sh > mount -o remount,rw / > dmesg > /shutdown-log.txt > mount -o remount,ro / > > in /usr/lib/systemd/system-shutdown. Once I found a /shutdown-log.txt > log file but it did not contain any real hint for me why rebooting seems > to hang. > > The problem is that I do not see what is hanging. How can I get better > debugging results from systemd to find out more? Is it possible to > redirect all steps systemd makes when rebooting to a virtual tty? What > else could I do to get more information of what happens during > reboot/shutdown? I guess what we need is a similar mechanism that is used to display messages when we're starting up and waiting for tasks, and have this appear at shutdown for tasks taking a long time to shut down. 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 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] [PATCH] condition, man: Add support for ConditionSecurity=smack
On Wed, May 8, 2013 at 8:20 PM, Zbigniew Jędrzejewski-Szmek 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 >> 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] [PATCH] condition, man: Add support for ConditionSecurity=smack
On Tue, May 7, 2013 at 5:29 AM, Karol Lewandowski 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. 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 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:42 AM, Lennart Poettering wrote: > On Fri, 03.05.13 09:30, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: > >> >> 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). > > Yes, that's what it does, it reallocates with exponentially increasing > sizes. > > The benefit is random access and a you need two pointers less per entry, > which is quite something on 64bit... right, but we don't need random access - all the access is linear, the extra pointer... doesn't seem like such a gain if we're allocating hundreds of unused members in the arrays that are going to be unused. 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 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 >> 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] Dynamically allocate bootchart logs
On Wed, Apr 24, 2013 at 4:26 PM, 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. > > This patch also fixes parsing of /proc//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] Add help option to bootchart man page
On Fri, Apr 26, 2013 at 9:36 AM, Nathaniel Chen 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 5:20 PM, Zbigniew Jędrzejewski-Szmek 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] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 3:26 PM, Reindl Harald 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] Question about the cross session dependence
On Sun, Apr 21, 2013 at 6:49 PM, Li, Min A 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] How to run *ctl command using systemd-nspawn
On Tue, Apr 16, 2013 at 12:11 AM, Koen Kooi 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 /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] Fwd: [systemd-commits] Makefile.am src/bootchart - Make bootcharts go to the journal
On Tue, Apr 16, 2013 at 1:47 AM, Colin Guthrie 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
[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 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 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 Mon, Apr 15, 2013 at 10:59 AM, Reindl Harald 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
Re: [systemd-devel] systemd-readahead and often used applications
On Sun, Apr 14, 2013 at 2:15 PM, Reindl Harald 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 Sun, Apr 14, 2013 at 1:01 PM, Reindl Harald wrote: > > Am 14.04.2013 21:18, schrieb Kok: >> On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald >> 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 Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald 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 -> stops after 2 minutes
On Sun, Apr 14, 2013 at 10:18 AM, Reindl Harald 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 9:13 AM, Reindl Harald wrote: > > Am 14.04.2013 06:42, schrieb Kok: >> On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald >> 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 and often used applications
On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald wrote: > > > Am 13.04.2013 23:08, schrieb Kok: >> On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald >> 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] systemd-readahead and often used applications
On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald 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] Socket is dying, how to automatically restart it?
On Wed, Apr 10, 2013 at 1:12 PM, David Strauss 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] Socket is dying, how to automatically restart it?
On Wed, Apr 10, 2013 at 11:10 AM, Koen Kooi wrote: > > Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas het > volgende geschreven: > >> On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi >> 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] dbus user services using the session bus
On Wed, Apr 3, 2013 at 1:28 PM, Tom Gundersen wrote: > On Wed, Apr 3, 2013 at 9:43 PM, Kok, Auke-jan H > wrote: >> On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco 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] dbus user services using the session bus
On Wed, Apr 3, 2013 at 12:30 PM, Matthew Monaco 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 6:22 AM, Will Stephenson 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] [PATCH] [RFCv4] Add Listen* to dbus properties
On Tue, Apr 2, 2013 at 6:29 AM, Zbigniew Jędrzejewski-Szmek 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
