Re: [systemd-devel] mount units and symlinks
On Mon, Jun 30, 2014 at 12:41:10PM -0700, Colin Walters wrote: There's likely other people in the field though with mount points that are symlinks, and while they're clearly buggy it'd be rather unfriendly to just have them entirely break after upgrading systemd. Maybe a loud warning? One of my mount didn't work due to this change. Initially I didn't understand why and just did a mount -a to figure out if there was a problem mounting. Only much later noticed the journalctl entry. Mounting over a symlink seem to have worked without issues so bit baffled about this change. To clarify: I didn't realize I had it as a symlink, it should've been an empty directory (due to reordering data and so on). -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journald stops logging when lots of output
On Wed, Sep 11, 2013 at 08:35:49PM +0200, Lennart Poettering wrote: (Of course, journald should not exit under any such circumstances, but to find that we first need to track down why it does that currently). Though it might hide problems, shouldn't journald be configured to automatically be restarted by systemd? -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] License of systemd API
At Hackers News, someone (seemingly involved with OpenRC) claims that the systemd API is somehow licensed under the LGPL. Thus making it impossible for OpenRC to implement the same API. See https://news.ycombinator.com/item?id=6446700 for the entire comments and https://news.ycombinator.com/item?id=6448366 for the specific claim made by the user synchronise. As far as I understood, an API cannot be under any license/copyright. Just the method/code implementing it is. Anyway, to avoid any misunderstandings, could a main developer clarify if the systemd API is or is not under a copyright / license and if it is, which? Thanks. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Feature request: randomly delay scheduled jobs
Feature request: allow to randomly delay a scheduled job Why: I have various cron jobs that run every 20min on various VMs + servers. All servers are synched with NTP. What happens is that if they use some shared resource (e.g. an LDAP server), the load spikes on that LDAP server spikes every 20min. So every 20min the LDAP server is slowish and afterwards it does nothing again. Not running the jobs at the same exact time would spread the usage of that server, and likely result is that the load never spikes anymore. It would be nice if I could do the following in systemd: Run this script every 20min, but randomly delay it by up to 5min. Currently I introduce such delays either in the script itself, and sometimes before calling the script. It would be much nicer to have a syntax for this. Note that the random delay could either be changed for each execution or determined once per job/unit. I'm not sure which one is better. Benefit if only determining the random delay once, is that you still get the same 20min delay each time. On other hand, that is not really random anymore. Different possible random option: a. Every 20min: 0:00 + 1min 24sec, 0:20 + 3min 21 sec, 0:40 + 0min 48sec b. Every 20min: 0:00 + 1min 24sec, 0:20 + 1min 24 sec, 0:40 + 1min 24sec a. = random every time b. = delay is random, but then predictable delay I'm fine with either btw. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Someone working on gui for multiseat?
On Wed, Jan 23, 2013 at 10:39:46AM +, Colin Guthrie wrote: 'Twas brillig, and Stef Bon at 23/01/13 10:28 did gyre and gimble: what should the gui toolkit be? Gtk3? I prefer that over qt, which is not my favorite. And is there a location to store the project? I can of course get one at github or something like that, but maybe there is a better one? Safe to say that would be in alignment with Lennart's own general feelings! But ultimately it would be down to the author. Some might argue that using some kind of abstraction system might be beneficial here (i.e. something like libyui which can target Gtk, Qt or curses interfaces), but that would essentially mean your app will always be a kind of standalone tool - the benefit being it is cross desktop, but the drawback being it won't be super nicely integrated with any of the desktops. So perhaps it would make sense to look at implementing the GUI as a component that will eventually be part of the GNOME systemsettings? i.e. make a bold statement about where it should live. If it proves to be useful and popular, then some KDE/Qt centric folks may port it to their system settings GUI too. For gnome-control-center (3.7.x name being 'Settings' :P), best to check beforehand where it would fit and how it should interact and so on. There is an Wacom tablet thing in there. Ideally it should only be shown when needed (e.g. when it finds hardware), etc. Only something in Settings is not always enough, lately goal is providing the best experience, not just making something work. E.g. if it can be automatic, do it automatically. If it really needs something manual, maybe ask when there the need to ask arises, etc. For above and more, best to check beforehand. Assume that'll result in some API that multiple DE can use. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multiseat apart from Fedora
On Tue, Jan 08, 2013 at 06:48:18PM +0200, Damian Ivanov wrote: Requirements for multiseat to work with the plugable devices is AFAIK only running recent versions of systemd, gdm and have ConsoleKit removed. I am trying to get the plugable automatic multiseat to work on openSUSE but unfortunaley I have had no luck with it. The seat is created properly: If you have time to spare, could you also check if multiseat works with any of the Mageia 3 beta's? It should work, but I don't think anyone tested it. In case of bugs please either file a bug or mail me. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] One of my fundamental problems with systemd...
On Sat, Oct 27, 2012 at 01:01:36PM +0200, Zbigniew Jędrzejewski-Szmek wrote: Kay, Olav, I think that we're being a bit unfair towards Michael. There's an implication that his posts were offensive, but they weren't. Overly verbose, yes, repetitive, yes, agitated, etc, but not intended as rude. Michael started by reporting valid problems, with a I wasn't trying to implicate that it was offensive. Anyway, this is not about systemd, so I prefer to end it here.. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] One of my fundamental problems with systemd...
On Fri, Oct 26, 2012 at 10:16:47PM -0400, Michael H. Warfield wrote: BTW... Not to drop names (which I'm about to do) or anything and I know in a big organization not everybody knows everyone but... I prefer judging myself. And at the moment I see you using words like: - crap - POS -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] One of my fundamental problems with systemd...
sent too quickly.. On Sat, Oct 27, 2012 at 05:22:30AM +0200, Olav Vitters wrote: On Fri, Oct 26, 2012 at 10:16:47PM -0400, Michael H. Warfield wrote: BTW... Not to drop names (which I'm about to do) or anything and I know in a big organization not everybody knows everyone but... I prefer judging myself. And at the moment I see you using words like: - crap - POS - barf - fsck (though meaning fuck) It is not needed to tell what you did. Just be nice and people will show the same courtesy. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journalctl | grep -v mail.*
I'm trying to learn journalctl a bit. I'd prefer if I could do a grep -v, but in journalctl using some argument, e.g. -v. E.g. show me all the logs _except_ mail related things: $ journalctl -v -f SYSLOG_FACILITY=2 ideally (could this be implemented?): $ journalctl -v -f SYSLOG_FACILITY=mail I noticed the SYSLOG_FACILITY for postfix is given as 2, shouldn't that be 16? In /usr/include/sys/syslog.h it has 23 for LOG_MAIL, I'd expect that to be in SYSLOG_FACILITY. At the moment I'm still using rsyslog and /etc/syslog.conf allows me to redirect mail related things just fine, example: mail.=debug;mail.=info;mail.=notice -/var/log/mail/info.log Goal: something funny is going on, no clue what is causing it, but not mail messages. They should not be shown as they clutter the output. Maybe you want an entire expression thing on the command line, like find has. At the moment a -v would be more than enough for me. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl | grep -v mail.*
On Tue, Oct 23, 2012 at 11:13:32PM +0200, Lennart Poettering wrote: On Tue, 23.10.12 22:38, Olav Vitters (o...@vitters.nl) wrote: I'm trying to learn journalctl a bit. I'd prefer if I could do a grep -v, but in journalctl using some argument, e.g. -v. Negative filtering (i.e. not foo=bar, but foo!=bar) is currently not implemented. I have figured out how to implement this relatively efficiently now, but this will take some time to implement. It's on the TODO list. Cool! I noticed the SYSLOG_FACILITY for postfix is given as 2, shouldn't that be 16? In /usr/include/sys/syslog.h it has 23 for LOG_MAIL, I'd expect that to be in SYSLOG_FACILITY. At the moment I'm still using rsyslog and /etc/syslog.conf allows me to redirect mail related things just fine, example: mail.=debug;mail.=info;mail.=notice -/var/log/mail/info.log The full syslog priority field is decoded into PRIORITY= and SYSLOG_FACILITY=, so that it is easy to filter for them independently. The latter has the SYSLOG_ prefix since we consider a bit of an outdated concept. 20 numeric facilities are quite limited, and it is _SYSTEMD_UNIT= usually a much better way to filter things. We do store it however, in order not to lose any data. I know there are better ways, but for me it is way easier to reuse some existing knowledge. The priority I don't care that much about at the moment, the colours added by journalctl seems to be good enough for now. Logging the mail stuff into multiple files is the way Mageia/Mandriva set it up. Messages that are not genreated via syslog( )wil not carry SYSLOG_FACILITY= however, but they will carry the log priority, since that is generally useful functionality. Postfix should be using mail / 16 as priority, otherwise rsyslog wouldn't have filtered that into /var/log/mail/info.log. And I guess if it didn't use syslog, it shouldn't have SYSLOG_FACILITY. However, I see things like: $ journalctl -n1 -o export SYSLOG_FACILITY=2 __CURSOR=s=d58b63a971464dc0ae21bc409d611941;i=d742;b=3ae5edd0461841d69be6e46800ec3f3b;m=52ffd54860;t=4ccc0b1ec92f9;x=2526026ee985410d __REALTIME_TIMESTAMP=1351027897701113 __MONOTONIC_TIMESTAMP=356479486048 _BOOT_ID=3ae5edd0461841d69be6e46800ec3f3b _TRANSPORT=syslog PRIORITY=6 SYSLOG_FACILITY=2 SYSLOG_IDENTIFIER=postfix/qmgr SYSLOG_PID=2193 MESSAGE=1842050036E: removed _PID=2193 _UID=489 _GID=484 _COMM=qmgr _EXE=/usr/lib64/postfix/qmgr _CMDLINE=qmgr -l -t fifo -u -c _SYSTEMD_CGROUP=/system/postfix.service _SYSTEMD_UNIT=postfix.service _SOURCE_REALTIME_TIMESTAMP=1351027897700510 _MACHINE_ID=73d0b740d3400a0f495236640206 _HOSTNAME=bkor.dhs.org Here, the SYSLOG_FACILITY should have read 16, or am I mistaken? Note that I'm not yet storing things on disk. I assume/hope Mageia will do that soon. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald leaking maps?
On Thu, Oct 11, 2012 at 11:31:18PM +0100, Colin Guthrie wrote: Something is obviously not good there! journald is using something in the region of 250MB res. My journal stats: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 367 0.0 4.9 4904900 198620 ? Ss Oct03 2:10 /usr/lib/systemd/systemd-journald Also Mageia, systemd 192. The systemd on the system has been updated since (194 atm), but have not yet rebooted. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Tue, Jun 19, 2012 at 06:44:25PM +0200, Michael Olbrich wrote: This is not about the files from systemd. It's about the dependencies. Every user of a source based distro, that only wants systemd now has to first install dbus then udev, and then remove dbus again. Shouldn't the build system do this automatically? I can understand it is inconvenient and makes things slower, but if you're building from source anyway, a few build time dependencies is ok? Trying to see this in relation to jhbuild. There I hate webkit and mozilla, but those are in a different order than what is discussed here. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
On Wed, Jun 20, 2012 at 02:34:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 01:46:40PM +0200, Olav Vitters wrote: On Wed, Jun 20, 2012 at 01:32:52PM +0200, Michael Olbrich wrote: On Wed, Jun 20, 2012 at 09:38:22AM +0200, Olav Vitters wrote: Shouldn't the build system do this automatically? Why should it? The equivalent for a normal distro would be to require e.g. perl in udev for a post-install script only. And then you expect the package manager to understand this and install perl before installing udev and remove it again afterwards. Not really. There are build time dependencies and runtime dependencies. Build time stuff is only of a concern of building the software. Has no relevance to post-install scripts (talking about post-install rpm scripts, not sure if you mean the same). Yes really. This is about the end user of the distro. Which means comparing installing packages. It is only needed during the build, so don't see what you're getting at. Install when needed, remove after. [..] It sometimes happens that to apply a patch you need additional BuildRequires to e.g. regenerate 'configure' and so on. That won't result in any extra runtime dependencies. We all know this works very well with the big binary distros. This whole thread is about source distros. Which means every user has to support all build time requirements. Which means they are all part of the final system of _every_ user unless we add extra complexity to keep unwanted things out. I don't see why it should. Just install the build time dependencies automatically and remove afterwards. If the build system of a source based distribution doesn't know the difference between these, then seems the build system needs to be taught the difference. IMO, this seems to be just a difference in perception. IMO there is a difference between build time and runtime dependencies. If you think that there is no difference (or should be no difference), then every extra build time dependency causes pollution (cause the build stuff is kept on machines instead of removed after building). I don't see why there is a difference between building at a build machine or building at users machine should make any difference. On both types, you don't want to keep those build dependencies on the machine. I can see you of course need to build all the various build time dependencies, so if there a lot it'll result in wasted CPU cycles... but if you want efficiency on that it is easier to have something build everything for you. In any case, if there is no knowledge of build vs runtime dependencies, a machine will already have loads of packages purely for making stuff build. -- Regards, Olav ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
