Re: [systemd-devel] [Debate] Transition from professional to popular?
Am 11.05.2017 um 21:50 schrieb e...@a6.25u.com: On 05/11/17 21:40, Lennart Poettering wrote: On Thu, 11.05.17 21:24, e...@a6.25u.com (e...@a6.25u.com) wrote: Operating systems (that might use the Linux kernel) are being streamlined from being professional into being popular. systemd is a small factor in that development. But what is really achieved by this? Scaring away a professional audience with black boxes, in-transparency or feature creeping in favor of gaining the interest of e.g. a gamer audience? Does it really matter to gamers what operating system they use? Or does it matter to the people who streamline (ruin) operating systems (that might use the Linux kernel) for that audience? Just food for thought. Personally, I can always chroot and cheat my way out of the path that leads to the streamlined garbage. But operating systems (that might use the Linux kernel) lose their professional advantages they had over the alternatives only to become popular. So we end up having popular but redundant operating systems for the price of professionality? And professionals have to turn to LFS? This is a technical mailing list. Please keep it that way. If you want to discuss philosophical issues, please find a different forum, there are plenty of those. Thank you, I should have known that before I posted it. you should have saied *anything* related just install https://devuan.org/ as long it exists Now you will have to manually remove my post from the archive. Sorry for that. problem is that you did not have to say anyhtign in your post >>> Operating systems (that might use the Linux kernel) are being >>> streamlined from being professional into being popular if you make your decisions by "popular" you are screwed from the very begin and if you think sysvinit-scripts are less blackboxes go ahead and explain 10 of them from line to line without any doubt ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Debate] Transition from professional to popular?
On 05/11/17 21:40, Lennart Poettering wrote: On Thu, 11.05.17 21:24, e...@a6.25u.com (e...@a6.25u.com) wrote: Operating systems (that might use the Linux kernel) are being streamlined from being professional into being popular. systemd is a small factor in that development. But what is really achieved by this? Scaring away a professional audience with black boxes, in-transparency or feature creeping in favor of gaining the interest of e.g. a gamer audience? Does it really matter to gamers what operating system they use? Or does it matter to the people who streamline (ruin) operating systems (that might use the Linux kernel) for that audience? Just food for thought. Personally, I can always chroot and cheat my way out of the path that leads to the streamlined garbage. But operating systems (that might use the Linux kernel) lose their professional advantages they had over the alternatives only to become popular. So we end up having popular but redundant operating systems for the price of professionality? And professionals have to turn to LFS? This is a technical mailing list. Please keep it that way. If you want to discuss philosophical issues, please find a different forum, there are plenty of those. Thank you, Lennart I should have known that before I posted it. Now you will have to manually remove my post from the archive. Sorry for that. Dirk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [Debate] Transition from professional to popular?
Operating systems (that might use the Linux kernel) are being streamlined from being professional into being popular. systemd is a small factor in that development. But what is really achieved by this? Scaring away a professional audience with black boxes, in-transparency or feature creeping in favor of gaining the interest of e.g. a gamer audience? Does it really matter to gamers what operating system they use? Or does it matter to the people who streamline (ruin) operating systems (that might use the Linux kernel) for that audience? Just food for thought. Personally, I can always chroot and cheat my way out of the path that leads to the streamlined garbage. But operating systems (that might use the Linux kernel) lose their professional advantages they had over the alternatives only to become popular. So we end up having popular but redundant operating systems for the price of professionality? And professionals have to turn to LFS? Dirk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Debate] Transition from professional to popular?
On Thu, 11.05.17 21:24, e...@a6.25u.com (e...@a6.25u.com) wrote: > Operating systems (that might use the Linux kernel) are being streamlined > from being professional into being popular. > > systemd is a small factor in that development. > > But what is really achieved by this? > > Scaring away a professional audience with black boxes, in-transparency or > feature creeping in favor of gaining the interest of e.g. a gamer audience? > > Does it really matter to gamers what operating system they use? Or does it > matter to the people who streamline (ruin) operating systems (that might use > the Linux kernel) for that audience? > > Just food for thought. > > Personally, I can always chroot and cheat my way out of the path that leads > to the streamlined garbage. > > But operating systems (that might use the Linux kernel) lose their > professional advantages they had over the alternatives only to become popular. > > So we end up having popular but redundant operating systems for the price of > professionality? And professionals have to turn to LFS? This is a technical mailing list. Please keep it that way. If you want to discuss philosophical issues, please find a different forum, there are plenty of those. Thank you, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start user-service only with UID greater than 1000
On Wed, 10.05.17 08:39, Jakob Schürz (wertsto...@nurfuerspam.de) wrote: > Am 2017-05-09 um 18:19 schrieb Mantas Mikulėnas: > > That might be nice... but, how come your services register a logind > > session in the first place? That doesn't happen unless something > > deliberately calls pam_systemd – and the service startup process > > generally doesn't involve calling PAM in the first place. So something > > doesn't add up. (Are you using su?) > > Good point! > The User-Session for Debian-exim maybe really come from a su in a > script... I rewrote this script, now the User-Session for Debian-gdm > seems not to be startet again. util-linux' "setpriv" is the correct to use for acquiring system user privileges without setting up a full login session. > But gdm... it starts this service, in case of starting a user-session > for systemd. > This seems to be another Problem, understanding the following answers > from the others in this thread... This is actually intended behaviour: gdm sessions are supposed to be similar to normal sessions as possible. BTW there's currently a PR being discussed that would permit you to do per-user discrimination via a condition: https://github.com/systemd/systemd/pull/5926 It's not merged yet though, and in its current version only permits explicit user or group checks, not full ranges. (that said, extending things like that definitely would make sense) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Retaining boot messages on (near-)stateless systems
On Thu, 11.05.17 09:17, John Florian (j...@doubledog.org) wrote: > I maintain a derivative of Fedora Live (built using lorax) that gets > deployed on hundreds of systems, far more than my team has the man- > power to keep a watchful eye. Occasionally we are notified of a > problematic node and often it would be helpful to see the full journal > for say, the first 15 minutes of run-time in which the node transforms > itself from a generic appliance to a specific role. Unfortunately, in > many cases we are notified too late and journald has tail-trimmed the > logs we desire most. > > Reviewing journald.conf(5) I don't see options to achieve what I want > directly so my thought is to create a service and timer with > OnBootSec=15m to duplicate the journal over to persistent storage, > which would then require non-standard techniques for viewing but at > least the availability would be guaranteed. Yeah, we have no explicit support for anything like that. There have been requests to add some per-log-priority roation scheme, where youl could say "keep EMERGENCY logs for a months, but DEBUG logs only for a day" or so, but this hasn't been implemented yet. > > Is there a better way to achieve this? If not, what's the best way to > duplicate the journal data? Simply cp -a /var/log/journal/ ... or use > journalctl to dump or export it somehow? copying the journal file as-is is probably the simplest and most robust option. > I'll also add that I also wish to retain higher priority messages for a > longer period, though for the first ~15m I want everything, DEBUG > included. That leads me to think about a 2nd logger (journald, > ideally) which had messages forwarded to it, but with different > retention characteristics. You can always use rsyslog/syslog-ng in conjunction with journald, to implement something like that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 11 MB cost of DefaultMemoryAccounting=yes
On Thu, 11.05.17 10:26, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > Even though this is not a systemd problem, I believe systemd mailing > list is a good place to discuss. > > Our kernel has CONFIG_MEMCG enabled. As soon as we set > DefaultMemoryAccounting=yes, our system wide memory usage increased 11 > MB. The increase is mostly on kmalloc-* slab memory with the peak on > kmalloc-32. > > I initially thought the increase is due to systemd creating > system.slice under /sys/fs/cgroup/memory but I think I am wrong. I > have run "systemd-run -p MemoryLimit=10M /bin/sleep 5" command while > DefaultMemoryAccounting=no and there was no significant memory usage. > > I am quite puzzled about where this extra cost is coming from. Does > anybody have any idea? cgroup memory accounting comes at a cost, both in performance and memory usage. In older kernels it is so steep that many distros disabled it altogether. On current kernels it shouldn't be awful anymore, but like everything is not free... I'd recommend talking to the memcg/cgroup community about this in more detail. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 11 MB cost of DefaultMemoryAccounting=yes
Am Thu, 11 May 2017 10:26:33 +0200 schrieb Umut Tezduyar Lindskog : > Hello, > > Even though this is not a systemd problem, I believe systemd mailing > list is a good place to discuss. > > Our kernel has CONFIG_MEMCG enabled. As soon as we set > DefaultMemoryAccounting=yes, our system wide memory usage increased 11 > MB. The increase is mostly on kmalloc-* slab memory with the peak on > kmalloc-32. > > I initially thought the increase is due to systemd creating > system.slice under /sys/fs/cgroup/memory but I think I am wrong. I > have run "systemd-run -p MemoryLimit=10M /bin/sleep 5" command while > DefaultMemoryAccounting=no and there was no significant memory usage. > > I am quite puzzled about where this extra cost is coming from. Does > anybody have any idea? I think this is documented in the kernel as far as I know: Memory accounting needs some extra memory. For swap accounting, it is even more. If you look at the kernel documentation: Does this explain your issue? -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Retaining boot messages on (near-)stateless systems
I maintain a derivative of Fedora Live (built using lorax) that gets deployed on hundreds of systems, far more than my team has the man- power to keep a watchful eye. Occasionally we are notified of a problematic node and often it would be helpful to see the full journal for say, the first 15 minutes of run-time in which the node transforms itself from a generic appliance to a specific role. Unfortunately, in many cases we are notified too late and journald has tail-trimmed the logs we desire most. Reviewing journald.conf(5) I don't see options to achieve what I want directly so my thought is to create a service and timer with OnBootSec=15m to duplicate the journal over to persistent storage, which would then require non-standard techniques for viewing but at least the availability would be guaranteed. Is there a better way to achieve this? If not, what's the best way to duplicate the journal data? Simply cp -a /var/log/journal/ ... or use journalctl to dump or export it somehow? I'll also add that I also wish to retain higher priority messages for a longer period, though for the first ~15m I want everything, DEBUG included. That leads me to think about a 2nd logger (journald, ideally) which had messages forwarded to it, but with different retention characteristics.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] 11 MB cost of DefaultMemoryAccounting=yes
Hello, Even though this is not a systemd problem, I believe systemd mailing list is a good place to discuss. Our kernel has CONFIG_MEMCG enabled. As soon as we set DefaultMemoryAccounting=yes, our system wide memory usage increased 11 MB. The increase is mostly on kmalloc-* slab memory with the peak on kmalloc-32. I initially thought the increase is due to systemd creating system.slice under /sys/fs/cgroup/memory but I think I am wrong. I have run "systemd-run -p MemoryLimit=10M /bin/sleep 5" command while DefaultMemoryAccounting=no and there was no significant memory usage. I am quite puzzled about where this extra cost is coming from. Does anybody have any idea? Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
