Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On 11/20/2012 12:41 AM, Lennart Poettering wrote: On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: >Isn't there a way to shut off systemV init scripts altogether, it just so >happens that we hit one on my machine. But in the field a customer could have >an init script and then setup containers and systemd will attempt to start it. > I want a way to say don't run SysV Init scripts altogether. Hmm, there is currently no option for that. A semi-dirty trick might be to over-bind-mount /etc/rc.d with something empty? Or he can just simply apply and test the diff for iscsi in [1] and walk around the office and ask all those RH maintainers that maintain iscsi what the freaking hold up is. JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=714688 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] journal over the network
On Tuesday 20 Nov 2012 01:21:54 Lennart Poettering wrote: > My intention was to speak only HTTP for all of this, so that we can > nicely work through firewalls. Wait, I thought one of the guiding principles of systemd was to do things The Right Way, and not use ugly workarounds for other people's brokenness. If admins want to send network traffic over a port, and their firewall is preventing them, surely the problem is in the firewall, and the firewall should be fixed? Making everything HTTP-friendly to get around broken firewall policies is an ugly workaround which just helps perpetuate the problem. Not to mention the fact that HTTP is a horrible protocol for almost anything except serving up web pages. It's effectively implements a basic request/response datagram protocol (albeit with arbitrarily large "packets"), which can only be initiated from one side, but with the overhead of HTTP headers and the creation of a TCP connection. Just my ¤0.02 Adam ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] journal over the network
On 11/20/2012 09:02 AM, Adam Spragg wrote: On Tuesday 20 Nov 2012 01:21:54 Lennart Poettering wrote: My intention was to speak only HTTP for all of this, so that we can nicely work through firewalls. Wait, I thought one of the guiding principles of systemd was to do things The Right Way, and not use ugly workarounds for other people's brokenness. If admins want to send network traffic over a port, and their firewall is preventing them, surely the problem is in the firewall, and the firewall should be fixed? Making everything HTTP-friendly to get around broken firewall policies is an ugly workaround which just helps perpetuate the problem. Agreed + you dont want to use ssh to do this ether Not to mention the fact that HTTP is a horrible protocol for almost anything except serving up web pages. It's effectively implements a basic request/response datagram protocol (albeit with arbitrarily large "packets"), which can only be initiated from one side, but with the overhead of HTTP headers and the creation of a TCP connection. Agreed I somehow always imagined remote systemd and systemd journal integration being handle in similar manner as func [1] and certmaster[2] are doing. 1. https://fedorahosted.org/func/ 2. https://fedorahosted.org/certmaster/ JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] journal over the network
Am 20.11.2012 02:26, schrieb Lennart Poettering: > On Mon, 19.11.12 11:14, Thomas Bächler (tho...@archlinux.org) wrote: > >> Am 19.11.2012 01:21, schrieb Zbigniew Jędrzejewski-Szmek: >>> They are parsed and stored >>> into a journal file. The journal file is /var/log/journal/external-*.journal >>> by default, but this can be overridden by commandline options (--output). >> >> What about /var/log/$MACHINE_ID/, isn't it the right place for these? > > I doubt we can do that. The machine ID isn't really something people > might want to specify on the command line. But if it isn't specified on > the command line we'd have to get this data from the remote host, but > that host we only trust enough to pull out its data, but we cannot allow > it to choose the file path where we store things in, because that it > could use to overwrite data from other hosts (including our local one) > by simply pretending that some specific machine ID was his, which > actually isn't. That's a very long sentence - I still think I get your point. My thoughts on this: 1) If we can configure to allow a specific host to log only to certain machine IDs, we can easily filter the incoming messages. 2) There should be a solution for the trust issue. The remote host could authenticate in some way, or even sign the messages. I don't want messages from any untrusted source in my logs, no matter in what path. IMO, in any scenario where you want to store remote log messages, you want to make sure that they're coming from the right place and have not been tampered with. It is reasonable to expect the admin to perform some configuration here. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] journal over the network
On Tue, Nov 20, 2012 at 10:02:39AM +, "Jóhann B. Guðmundsson" wrote: > On 11/20/2012 09:02 AM, Adam Spragg wrote: > >On Tuesday 20 Nov 2012 01:21:54 Lennart Poettering wrote: > >>My intention was to speak only HTTP for all of this, so that we can > >>nicely work through firewalls. > >Wait, I thought one of the guiding principles of systemd was to do things The > >Right Way, and not use ugly workarounds for other people's brokenness. > > > >If admins want to send network traffic over a port, and their firewall is > >preventing them, surely the problem is in the firewall, and the firewall > >should be fixed? Making everything HTTP-friendly to get around broken > >firewall > >policies is an ugly workaround which just helps perpetuate the problem. > > Agreed + you dont want to use ssh to do this ether I think that firewalls are just one of the reasons... I think that we want to have SSL-encrypted communciations by default, and then the specific protocol used above that is invisible to the firewall anyway. Having multiple "transports" isn't really a problem -- it is mostly a matter of hooking into some library. HTTP is already spoken by systemd-journal-gatewayd, and SSH is useful because everybody already has it set up. > >Not to mention the fact that HTTP is a horrible protocol for almost anything > >except serving up web pages. It's effectively implements a basic > >request/response datagram protocol (albeit with arbitrarily large "packets"), > >which can only be initiated from one side, but with the overhead of HTTP > >headers and the creation of a TCP connection. If encryption is used, TCP connection overhead is negligible. And we only want mostly one-way communication anyway. > I somehow always imagined remote systemd and systemd journal > integration being handle in similar manner as func [1] and > certmaster[2] are doing. > > 1. https://fedorahosted.org/func/ > 2. https://fedorahosted.org/certmaster/ Certmaster looks great: maybe it can be used to solve the problem of certificate distribution. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2012 07:41 PM, Lennart Poettering wrote: > On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: > >> Isn't there a way to shut off systemV init scripts altogether, it just >> so happens that we hit one on my machine. But in the field a customer >> could have an init script and then setup containers and systemd will >> attempt to start it. I want a way to say don't run SysV Init scripts >> altogether. > > Hmm, there is currently no option for that. > > A semi-dirty trick might be to over-bind-mount /etc/rc.d with something > empty? > > Lennart > What run levels would get executed? I would prefer to mount over the empty run levels and allow an admin to be able to turn on a SysV init script. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCrizMACgkQrlYvE4MpobPk8ACcDymNxFWTj3MqBhma2Z1GwfzB /VYAoKkWpC4JoFnbyYcvFNiKJXTB0LP5 =MiLv -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to see full lines with journalctl?
Zbigniew Jędrzejewski-Szmek in.waw.pl> writes: > > journalctl will output full lines when running under a pager, > and also when not outputting to a tty. Do you need something > different? On my machine, running simply "journalctl" starts the pager (less) and the lines do not get shortened with the ellipsis but they are still not wrapped properly if they are longer than the terminal width. I can only see the rest by scrolling horizontally with the arrow keys (which is awful). Running "journalctl --no-pager | less" makes them wrap properly, however. I second the suggestion of getting rid of the whole line-cutting/shortening black magic by default and reserve it for a flag. The non-wrapping behaviour should never happen and I suspect it's a bug since I can't even find anything like it in less' manpage. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to see full lines with journalctl?
On Tue, Nov 20, 2012 at 02:04:02PM +, Gregory Leon wrote: > Zbigniew Jędrzejewski-Szmek in.waw.pl> writes: > > > > journalctl will output full lines when running under a pager, > > and also when not outputting to a tty. Do you need something > > different? > > On my machine, running simply "journalctl" starts the pager (less) and the > lines do not get shortened with the ellipsis but they are still not wrapped > properly if they are longer than the terminal width. I can only see the rest > by scrolling horizontally with the arrow keys (which is awful). Running > "journalctl --no-pager | less" makes them wrap properly, however. Of course they are not wrapped "properly", since the point is not to wrap them at all. I don't see anything awful about using arrow keys to move left and right and up and down. This makes it easy to quickly review lots of messages, some of which are long, some of which are short, while making it easy to read the whole message. > I second the suggestion of getting rid of the whole line-cutting/shortening > black magic by default and reserve it for a flag. The non-wrapping behaviour > should never happen and I suspect it's a bug since I can't even find > anything like it in less' manpage. Try 'man git diff'. Different behaviours are good at different times and for different people... This one (paging by default) is used quite sucessfully in some modern tools. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On 11/20/2012 01:52 PM, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2012 07:41 PM, Lennart Poettering wrote: On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: Isn't there a way to shut off systemV init scripts altogether, it just so happens that we hit one on my machine. But in the field a customer could have an init script and then setup containers and systemd will attempt to start it. I want a way to say don't run SysV Init scripts altogether. Hmm, there is currently no option for that. A semi-dirty trick might be to over-bind-mount /etc/rc.d with something empty? Lennart What run levels would get executed? I would prefer to mount over the empty run levels and allow an admin to be able to turn on a SysV init script. It's just nonsense to add any switch and doing so only slows down migration of sysv init scripts to native systemd files. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Tue, Nov 20, 2012 at 08:52:51AM -0500, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/19/2012 07:41 PM, Lennart Poettering wrote: > > On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: > > > >> Isn't there a way to shut off systemV init scripts altogether, it just > >> so happens that we hit one on my machine. But in the field a customer > >> could have an init script and then setup containers and systemd will > >> attempt to start it. I want a way to say don't run SysV Init scripts > >> altogether. > > > > Hmm, there is currently no option for that. > > > > A semi-dirty trick might be to over-bind-mount /etc/rc.d with something > > empty? > > > > Lennart > > > What run levels would get executed? I would prefer to mount over the empty > run levels and allow an admin to be able to turn on a SysV init script. I'm not convinced we need to support that explicitly. If an admin wants to support execution of some ad-hoc script they can easily make a system unit that uses the various ExecXXX directives to invoke their arbitrary shell scripts. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2012 09:36 AM, Daniel P. Berrange wrote: > On Tue, Nov 20, 2012 at 08:52:51AM -0500, Daniel J Walsh wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 11/19/2012 07:41 PM, Lennart Poettering wrote: >>> On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: >>> Isn't there a way to shut off systemV init scripts altogether, it just so happens that we hit one on my machine. But in the field a customer could have an init script and then setup containers and systemd will attempt to start it. I want a way to say don't run SysV Init scripts altogether. >>> >>> Hmm, there is currently no option for that. >>> >>> A semi-dirty trick might be to over-bind-mount /etc/rc.d with something >>> empty? >>> >>> Lennart >>> >> What run levels would get executed? I would prefer to mount over the >> empty run levels and allow an admin to be able to turn on a SysV init >> script. > > I'm not convinced we need to support that explicitly. If an admin wants to > support execution of some ad-hoc script they can easily make a system unit > that uses the various ExecXXX directives to invoke their arbitrary shell > scripts. > > Daniel > I was thinking more that if they wanted to execute chkconfig within the container, the right thing would happen, which I get by mounting empty dirs over /etc/rc.d/rc.[0-6]d Similar to us allowing the admin to execute systemctl enable foobar.service within the container. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCrmL8ACgkQrlYvE4MpobMCUQCgwsbUmhD+EWbjyKb82rXtlz4J 75AAnArmyLK7Juc8Z1HuZ49SImMz+WJa =LyFa -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd in LXC container
On Tue, 20.11.12 15:23, Alexander Vladimirov (alexander.idkfa.vladimi...@gmail.com) wrote: > > > I was able to fix it using simple patch (http://pastie.org/5380592) > > which > > > makes systemd ignore root mount when running in container. > > > > Hmm, the code in mount_points_list_umount() in umount.c already exlcudes > > / and /usr from all unmounting? > > > Yes, it does, but those filesystems are counted as failed then, and systemd > reports that it cannot unmount all filesystems. > I was guessing if it could be the reason why journal gets corrupted and it > turns out it's not. > It still seems a bit useful, since it prevents systemd from printing > cryptic warnings about failed unmounts without actual filesystem name. > > > > > > The second issue is journald reporting journal corruption on every > > > container boot, regardless of clean shutdown. This also happens when I > > > bind-mount hosts journal directory into container. > > > > Hmm, this is interesting. Do you see any messages about journal shutting > > down in the journal? > > > That's what container's journal look like after shutdown: > http://pastie.org/private/njgmtyxdglrpx3qxspufog, > there's no warnings or errors on console during or after shutdown. Could you file two fdo bugs about issues? This both looks like stuff to fix properly. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Tue, Nov 20, 2012 at 09:50:39AM -0500, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/20/2012 09:36 AM, Daniel P. Berrange wrote: > > On Tue, Nov 20, 2012 at 08:52:51AM -0500, Daniel J Walsh wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> > >> On 11/19/2012 07:41 PM, Lennart Poettering wrote: > >>> On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: > >>> > Isn't there a way to shut off systemV init scripts altogether, it > just so happens that we hit one on my machine. But in the field a > customer could have an init script and then setup containers and > systemd will attempt to start it. I want a way to say don't run SysV > Init scripts altogether. > >>> > >>> Hmm, there is currently no option for that. > >>> > >>> A semi-dirty trick might be to over-bind-mount /etc/rc.d with something > >>> empty? > >>> > >>> Lennart > >>> > >> What run levels would get executed? I would prefer to mount over the > >> empty run levels and allow an admin to be able to turn on a SysV init > >> script. > > > > I'm not convinced we need to support that explicitly. If an admin wants to > > support execution of some ad-hoc script they can easily make a system unit > > that uses the various ExecXXX directives to invoke their arbitrary shell > > scripts. > > > > Daniel > > > > > I was thinking more that if they wanted to execute > > chkconfig within the container, the right thing would happen, which I get by > mounting empty dirs over /etc/rc.d/rc.[0-6]d > > Similar to us allowing the admin to execute > > systemctl enable foobar.service > > within the container. IMHO supporting legacy commands like chkconfig is a non-goal for libvirt-sandbox. It is brand new functionality designed around closely integrating with systemd, and I don't think we should pollute it with code for legacy / dieing init systems. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Tue, 20.11.12 08:52, Daniel J Walsh (dwa...@redhat.com) wrote: > > Hmm, there is currently no option for that. > > > > A semi-dirty trick might be to over-bind-mount /etc/rc.d with something > > empty? > > > > Lennart > > > What run levels would get executed? I would prefer to mount over the empty > run levels and allow an admin to be able to turn on a SysV init script. Well, if you boot into multi-user then all sysv scripts enabled in runlevel 2+3+4 are pulled in. If you boot into graphical, then all services from 5 will be pulled in too. Let me get this right: you want to disable all sysv scripts in the container, but then allow the admin to reenable a few of his own choice? If so, it might be possible to replace /etc/rc.d by something empty (but persistent, if changed), and then mount /etc/rc.d/init.d into it from the host system. That way the host's scripts are avaulable but the enable/disable status is separate from the host? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2012 09:53 AM, Daniel P. Berrange wrote: > On Tue, Nov 20, 2012 at 09:50:39AM -0500, Daniel J Walsh wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 11/20/2012 09:36 AM, Daniel P. Berrange wrote: >>> On Tue, Nov 20, 2012 at 08:52:51AM -0500, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2012 07:41 PM, Lennart Poettering wrote: > On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@redhat.com) wrote: > >> Isn't there a way to shut off systemV init scripts altogether, >> it just so happens that we hit one on my machine. But in the >> field a customer could have an init script and then setup >> containers and systemd will attempt to start it. I want a way to >> say don't run SysV Init scripts altogether. > > Hmm, there is currently no option for that. > > A semi-dirty trick might be to over-bind-mount /etc/rc.d with > something empty? > > Lennart > What run levels would get executed? I would prefer to mount over the empty run levels and allow an admin to be able to turn on a SysV init script. >>> >>> I'm not convinced we need to support that explicitly. If an admin wants >>> to support execution of some ad-hoc script they can easily make a >>> system unit that uses the various ExecXXX directives to invoke their >>> arbitrary shell scripts. >>> >>> Daniel >>> >> >> >> I was thinking more that if they wanted to execute >> >> chkconfig within the container, the right thing would happen, which I get >> by mounting empty dirs over /etc/rc.d/rc.[0-6]d >> >> Similar to us allowing the admin to execute >> >> systemctl enable foobar.service >> >> within the container. > > IMHO supporting legacy commands like chkconfig is a non-goal for > libvirt-sandbox. It is brand new functionality designed around closely > integrating with systemd, and I don't think we should pollute it with code > for legacy / dieing init systems. > > Daniel > Ok your the boss. Bind mounting over /etc/rc.d -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCrnLgACgkQrlYvE4MpobPZEwCfSf4wdPx4rokbdyOBkVyXJ8Xm HEwAn0GaE+V4ayHb3Xo2UuNHvCv+ZFCU =6f4A -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] journal over the network
On Tue, Nov 20, 2012 at 03:35:30AM +0100, Zbigniew Jędrzejewski-Szmek wrote: > I guess that writing a man-page is in order... So, to make things concrete, I've put together a wish-list manpage, which describe some things which are there and quite a few things which are not there yet. If this is accepted, then I'll start to fix the code to follow the docs. I'm pushing this to git://in.waw.pl/git/systemd branch remote. Zbyszek --- SYSTEMD-JOURNAL-RE(8) systemd-journal-remote SYSTEMD-JOURNAL-RE(8) NAME systemd-journal-remote, systemd-journal-remote.service, systemd- journal-remote.socket - Stream journal messages over the network SYNOPSIS systemd-journal-remote [OPTIONS...] [-o/--output=DIR|FILE] [SOURCES...] systemd-journal-remote.service systemd-journal-remote.socket DESCRIPTION systemd-journal-remote is a command to receive journal events and store them to the journal. Input streams must be in the Journal Export Format[1], i.e. like the output from journalctl --output=export. SOURCES Sources can be either "active" (systemd-journal-remote requests and pulls the data), or "passive" (systemd-journal-remote waits for a connection and than receives events pushed by the other side). systemd-journal-remote can read more than one event stream at a time. They will be interleaved in the output file. In case of "active" connections, each "source" is one stream, and in case of "passive" connections each connection can result in a separate stream. Sockets can be configured in "accept" mode (i.e. only one connection), or "listen" mode (i.e. multiple connections, each resulting in a stream). When there are no more connections, and no more can be created (there are no listening sockets), then systemd-journal-remote will exit. Active sources can be specified in the following ways: When - is given as an argument, events will be read from standard input. When an URL is given systemd-journal-remote will retrieve messages over HTTP or HTTPS. The URL should refer to the root of a remote systemd-journal-gatewayd(8) instance (e.g. http://some.host:19531/). If the URL starts with ssh:// an ssh(1) connection will be opened and journalctl(1) will be launched on the remote host (e.g. ssh://u...@some.host). Messages will be sent over the encrypted connection and stored locally. If a file path is given, journal events will be read from local disk. If the path refers to an exisiting file, just this file will be read. If the path refers to an exisiting directory, journal files underneath this directory will be read (like with journalctl --directory=). Passive sources can be specified in the following ways: --listen=ADDRESS ADDRESS must be an address suitable for ListenStream= (c.f. systemd.socket(5)). A stream of journal events in expected. --listen-http=ADDRESS ADDRESS must be an address suitable for ListenStream= (c.f. systemd.socket(5)). An HTTP POST request is expected to /events. --listen-https=ADDRESS ADDRESS must be an address suitable for ListenStream= (c.f. systemd.socket(5)). An HTTPS POST request is expected to /events. $LISTEN_FDS When systemd-journal-remote is started as a service (systemd-journal-remote.service unit) sockets configured in systemd-journal-remote.socket will be passed using $LISTEN_FDS. By default, open sockets passed through socket activation behave like those opened with --listen= described above. If --listen-http=- or --listen-https=- is used, HTTP and HTTPS connections will be expected like with the options --listen-http= and --listen-https= above. Integer refers to the n-th socket of $LISTEN_FDS, and must be in the range 0 .. $LISTEN_FDS-1. SINKS The location of the output journal can be specified with -o or --output=. --output=FILE Will write to this journal. The filename must end with .journal. The file will be created if it does not exist. When necessary (journal file full, or corrupted) the file will be renamed following normal journald rules and a new journal file will be created in it's stead. --output=DIR Will create journal files underneath directory DIR. The directory must exist. When necessary (journal files full, or corrupted) journal files will be renamed following normal journald rules. Names of files underneath DIR will be generated using the rules
Re: [systemd-devel] How to see full lines with journalctl?
On Tue, Nov 20, 2012 at 03:52:46PM +0100, Gregory Leon wrote: > On Tue, Nov 20, 2012 at 3:16 PM, Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > Of course they are not wrapped "properly", since the point is not to wrap > > them at all. I don't see anything awful about using arrow keys to move > > left and right and up and down. This makes it easy to quickly review > > lots of messages, some of which are long, some of which are short, > > while making it easy to read the whole message. > > > > I can understand that some people might find this useful but it is rather > unfortunate that if you need raw, complete, unwrapped output, you have to > use two flags of which one is long (i.e. "--no-pager -a"). Hm, wrapping should be disabled when using a pipe. At least that's what I see locally. Also, I'm not sure about -a/-all, since it will give you unprintable characters... This is not what you want, usually. > Furthermore, if > you would like to page this, it becomes "journalctl --no-pager -a | less", Here 'LESS=-R journalctl' does the trick. > which is rather cumbersome. This is a rather important use-case since it is > necessary if you would like to pipe the complete output to any other > command. I'm not the one to blindly complain about journalctl "not > following the Unix way", but this seems rather important. > For what it's worth, I was quite surprised with the shortening and it was > not at all intuitive how to stop it when I've first encountered it, > particularly because it only appears *after* you disable the default pager. Actually, it only appear is you use --no-pager. I guess that some examples in the manpage could be useful. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ConditionBatteryPower
I totally agree, that targets in current state is not enough to support
such thing. I try to write here my motivation about using
the targets anyway, sorry for my English and long text.
When I first tried systemd, I thought about the .target units, as the
states in which the system resides. This is quite natural in the context
of use of the system, which controls the entire life cycle of
services. When I boot the system, I expect the default behavior and
functionality (default.target). When I shutdown it, I expect opposite
functionality. When I have bluetooth device or network up, I expect the
extension functionality, mixed up with the current one. That's how about
regular user like me meets systemd at first time.
My first understanding of the misunderstanding of the situation came
during the creation of my first target unit. I wanted to start some
services, when my NFC reader attached to the laptop. So i write
something like
.. ENV{SYSTEMD_WANTS}="nfc.target"
When I remove device, nfc.target stays active. Then I found, that
targets were more like startup barriers, but not states. That was
strange. How on earth shutdown.target when? Then I found
DefaultDependencies, StopWhenUnneeded and other workarounds to achive
some functionality of state system on barrier-targeted system.
I understand fundamental difference between barriers and states, but
don't have an idea why they should be used. Anyway, my feelings about
targets behavior is my very own, and not a point of discussion.
As laptop user, I want to have my system was flexible. What does it mean
for me? I want to get different behavior in different environments and
conditions. For example, I want to have (and successfully have with
systemd base user session) such functionality:
+ My network shares (depends on place or VPN connection) automatically
mounted and pulse default sink changes, when I arrived to work/home, and
unmounts/changes when I leave that place
+ When I have arrived, my mpop client begins to checking for new mail
from local mail server (depends on place)
+ My trusted VPN ups, when I'm not at home/work
+ Development services (like ADB) ups when I have device connected to my
laptop, and stopped when not
+ Depends on place,power situation and network connection level
different browsers should be started by default:
+ firefox, when I'm at home/work or in place, where I have a chance to
get stable AC power
+ opera, when I'm at train, with awful GPRS without AC
and so on
Most of these features could be successfully completed with systemd
push/conflicts model. I use StopWhenUnneeded= to clean services with
targets and Conflicts to clean targets. There are some problems with
this approach.
- Services with StopWhenUnneeded= couldn't be started as
orphans. So, if I want to get service up in some conditions, I should
find some target, that wants it, and start it. And that starts
something, that I'm not actually need for..
> - the current target units are currently mostly of the type where
> loading things matters, but unloading them is not really that
> important. This is different where AC is a state that people care
> about in both cases.
So:
- Bottom-Top configuration. To get behavior of state system, I must
change every single component of that system.
I.e. add StopWhenUnneeded= to every unit.
That is not very big problem to clean something with raised unit with current
functionality - Conflicts= will do the job. The problem is - how
to restore previous state. So, I stop using powersaving.target as
grouping tool, and start using is like a negative Tag (in
Conflicts=). To do so I write some patches (
http://lists.freedesktop.org/archives/systemd-devel/2012-November/007307.html
http://lists.freedesktop.org/archives/systemd-devel/2012-November/007304.html
).
How it works for me now:
1. powersaving tartget drop the units, that conflicted with it, and push them
to restore list
2. When powersaving.target stops, units from list started again
I think that is bad approach. This is hacks and workarounds, not the
solution. I think, more straight ways to solve this should be found.
So, why I think, that additional conditions in units are not among them?
- Grouping. It will be impossible with current implementation of core
things to have a group of units, that should stop, in case of
powersaving state achived. (If I place condition to target, than it
stops, but other units will be alive)
- Hardcoded special case. Why I think this is not ok?
Because the problem of power management can be extrapolated to other cases,
that takes into account the state of the host. I.e. networking
substate, user defined logical substates etc (ones from my use-cases,
for example).
> if you have a broken EC, I think a good solution would be to copy the
> unit with the ConditionBatteryPower= you don't like to /etc and comment
> the condition there? No?
- Weak configuration capabilities. As notebook user, I prep
Re: [systemd-devel] [RFC/PATCH] journal over the network
On Tue, 20.11.12 03:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > My intention was to speak only HTTP for all of this, so that we can > > nicely work through firewalls. > Yeah, probably that's more useful than raw stream for normal purposes, > since it allows for authentication and whatnot. Yeah, and not just that. I also want to beef up the server side so that it optionally can run as CGI and as fastCGI, so that people can integrate that into their existing web servers, if they wish. But yeah, using HTTP solves many many issues, such as auth, encryption, firewall/proxy support, and so on. On top of this the semantics of log syncing fit really nicely into the GET/POST model of HTTP. > > I think it would make sense to drop things into > > /var/log/journal//*.journal by default. The hostname would > > have to be determined from the URL the user specified on the command > > line. Ideally we'd use the machine ID here, but since the machine ID is > > hardly something the user should specify on the command line (and we > > cannot just take the machine ID supplied form the other side, because we > > probably should not trust that and hence allow it to tell us to > > overwrite another hosts' data), the hostname is the next best > > thing. Currently libsystemd-journald will ignore directories that are > > not machine IDs when browsing, but we could easily drop that limitation. > So it seems that this mapping (url/source/whatever -> .journal path) > will require some thought. > > I'd imagine, that people will want to use this most often as a syslogd > replacement, i.e. launch systemd-journal-remote on a central host, and > then let all other hosts stream messages live. In this case we know > only two things: _MACHINE_ID specified remotely, and the remote > IP:PORT and thus hostname. Actually, I thought that since all those > things are "unreliable" (IP only to some extent, but still), they > wouldn't be used to determine the output file, and all output would go > into one .journal. So, my thinking here is that hostnames generally suck for identifying machines since they are not unique, can change and sometimes are not set at all. However, that is only true in the general case. In the specific case where admins want to set up an infrastructure for centralizing logs they first set up a network, and as part of that I am pretty sure they came up with a sane naming/addressing scheme first, that makes the name unique in their local setup, makes the names fixed and ensures the name is always there. Or to put this in other words: to be able to sync logs from another hosts you first need to think about how you can contact that other host, and hence had to introduce a naming scheme first, and we should be able to just build on that. > I remember that samba does (did?) something like what you suggest, and > kept separate logs based on the information under control of the > connecting host. On a host connected to the internet this would lead > to hundreds of log files. > > In addition, .journal files have a fairly big overhead: ~180kB for a > an "empty" file. This overhead might be unwanted if there are many > sources. > > Maybe there's no one answer, and choices will have to be provided. I think it definitely makes sense to allow admins to name the local destination dir as they want. I am mostly just interested in finding a good default, and I'd vote extracting the "basename" of the URL used to access the remote journal for that. > > > Push mode is not implemented... (but it would be a separate program > > > anyway). > > > > My intention was actually to keep this in the same tool. So that we'd > > have for input and output: > > > > A) HTTP GET > > B) HTTP POST > > C) SSH PULL (would invoke "journalctl -o export" via ssh) > > D) SSH PUSH (would invoke systemd-journald-remote via ssh) > > E) A directory for direct read access (which would allows us to merge > > multiplefile into one with this tool) > > F) A directory for direct write access (which is of course the > > default) > > Also useful: > B1) socket listen() without HTTP Where would I want to use that instead of B? > B2) HTTPS POST (I'm assuming that POST means to listen) HTTPS for me is just a special case of HTTP. When I meant HTTP above I meant HTTP with and without TLS, and with and without authentication. > E1) a specific file for read access > F1) a specific file for write access That's something we have to think about anyway: i.e. whether we should allow accessing a separate journal file via libsystemd-journal? Currently we only allow accessing dirs. The reason for that is more or less that accessing files probably doesn't do what people assume it would do, since files are subject to rotation and referencing a file hence quickly becomes a dangling reference... > B1, F, F1 are implemented; A is implemented but ugly (curl). > E and E1 would require pulling in journalctl functionality. > > > We should always require that either E
Re: [systemd-devel] Heavy IO -- need help on how to debug
On Sat, 10.11.12 11:13, Pedro Francisco (pedrogfranci...@gmail.com) wrote: > Yesterday my system was slow and I checked iotop: systemd-journal was > using 99% IO (but not CPU). I haven't restarted the machine, but kill > systemd-journal didn't help, the process would respawn -- as expected > -- and resume the heavy IO). usually this simply indicates that something is sending journald lots of messages. Have you tried stracing journald, to see what it is doing? If you see a lot of recvmsg() this might be the indication that something is spamming journald.. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Verbose output option when starting daemons manually
On Thu, 08.11.12 18:23, William Giokas (1007...@gmail.com) wrote: > All, Heya, > I have been using systemd for a few months now, and I must say, it is a > great init system. I myself am no coder, else I would attempt to write > something to do just this. One not-dealbreaking thing that I do find > lacking is a verbose option for `systemctl start `, essentially > running `journalctl -f -u ` (and possibly for multiple dependent > units as well). For most services, I feel like this would be a line or > two of output just saying "It worked!" or "It broke!" but for services > like netcfg@, or services that start dependencies, it could be useful to > see what's getting started and how it's getting started. Again, feel free > to ignore me, I don't know how feasible or practical this would be, but > it seems like it would be useful. > > Again, sorry that I cannot put something together myself to at least > show you. I have added to the TODO list that we should have a mode where systemctl start/stop/... show in a single line what they did. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroup: look up user session units from cgroups as well.
On Thu, 15.11.12 17:46, Mirco Tischler (mt...@gmx.de) wrote: > 2012/11/15 Zbigniew Jędrzejewski-Szmek > > > On Tue, Nov 06, 2012 at 01:07:26AM +0100, Mirco Tischler wrote: > > > This allows the journal code to set the _SYSTEMD_UNIT tag for messages > > generated > > > by systemd --user session units. > > Hi, > > this would open the door to spoofed messages. Previously Lennart > > suggested [1] using _SYSTEMD_USER_UNIT=. > > > > Zbyszek > > > > [1] > > http://lists.freedesktop.org/archives/systemd-devel/2012-August/006103.html > > Hi, > > thanks for your comment. > My idea was to add filtering after the _SYSTEMD_SESSION field to systemctl > status. The reason why I didn't implement this yet is because I wasn't sure > about the best way to make known wether we are in session or system mode > where we'd need it. But if _SYSTEMD_USER_UNIT is preferred, I'll try to > implement a patch. I think _SYSTEMD_USER_UNIT= would be the much nicer solution as it avoids any misunderstands by default. Otherwise the patch looked quite OK from a rough glance. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journal API demo application: "tallow" - a fail2ban replacement
On Sun, 11.11.12 17:24, David Strauss (da...@davidstrauss.net) wrote: > > Units "subscribed" to specific message IDs has two negative effects: > (1) massive proliferation of units, since each one can supposedly only > handle one UUID and (2) unit names that are useless from a human > perspective. > > It would be much cleaner to offer "message activation" though a unit > with an arbitrary name and a journalctl-style filter for incoming > messages. > > I'd also consider a socket-based approach for event "subscriptions" as > long as it's efficient to stat() the non-existence of the appropriate > Message ID socket, since the common case would be no listener. If a > socket unit is the only supported way to listen, even the stat() would > be unnecessary, as systemd would know all active sockets to begin > with. There could be a standard naming convention for such sockets, > like /var/run/journal/msgid/. This would allow message > "activation" of a listener and human-friendly unit names. It would > also allow listening to happen in both "accept" and non-"accept" > socket modes. Even a shell script could easily receive and handle > certain events. Having message ID based activation is definitely something we want to add, i.e. by adding a new unit type ".msgid" or so which can be used to trigger services, much the same way as ".timer" or ".socket" trigger anothe runit on time or on socket. It's not trivial to do though, since there are a couple of corrner cases where we need to get good behaviour. Biggest question right now is: if a .msgid unit is activated, should it look at the history of journal messages, or not? It probably should, if we start a .msgid unit at boot at least look at everything that happened in early-boot/kernel so far. But then again, maybe it shouldn't, i.e. if we start a .msgid late during runtime, it probably shouldn't "replay" all the journal that has been accumulated in the last 4 weeks. So, this is a bit contradictory. Maybe we can make this configurable in the .msgid unit file, or so but I am a bit unsure how this should best work... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl --follow broken
On Thu, 01.11.12 13:03, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > Hi, > > today I noticed that journalctl --follow seems to print out much more > than 10 lines. Actually, aftern printing 10 lines correctly, it jump > to some point in the past: > > Logs begin at Sat, 13 Oct 2012 06:13:18 +. > Nov 01 11:09:26 fedora-15 sshd[29669]: pam_unix(sshd:session): session > clos...ek > Nov 01 11:09:26 fedora-15 systemd-logind[455]: Removed session 101. > Nov 01 11:09:28 fedora-15 python3[29709]: Allowing runtime journal files to > > ESC[1;39m- Reboot -ESC[0m > Oct 28 12:08:26 fedora-15 systemd[1]: SELinux Got Sender :1.312 > Oct 28 12:08:26 fedora-15 systemd[1]: GetConnectionSELinuxSecurityContext > u...8) > ESC[1;39m- Reboot -ESC[0m > Nov 01 11:09:28 fedora-15 systemd-journal-gatewayd[11055]: Failed to send > dat... > Nov 01 11:09:51 fedora-15 python3[29729]: Allowing runtime journal files to > > ESC[1;39m- Reboot -ESC[0m > Oct 28 12:08:26 fedora-15 systemd[1]: SELinux access check > scon=unconfined_...ic > > Apparently sd_journal_next() makes the jump when at EOF. > > I'm too lazy to look into sd_journal_next(), but git bisect points to: > > Author: Lennart Poettering > Date: Fri Sep 21 20:52:23 2012 +0200 > > journal: completely rework the mmap cache as I too dumb to actually > understand it > > Zbyszek Hmm, can you use "-o verbose" instead, and check if there really is a time jump/seqno jump? (The seqno is the i= bit of the cursor string...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH] journal over the network
On Tue, Nov 20, 2012 at 06:31:36PM +0100, Lennart Poettering wrote: > On Tue, 20.11.12 03:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > My intention was to speak only HTTP for all of this, so that we can > > > nicely work through firewalls. > > Yeah, probably that's more useful than raw stream for normal purposes, > > since it allows for authentication and whatnot. > > Yeah, and not just that. I also want to beef up the server side so that > it optionally can run as CGI and as fastCGI, so that people can > integrate that into their existing web servers, if they wish. > > But yeah, using HTTP solves many many issues, such as auth, encryption, > firewall/proxy support, and so on. On top of this the semantics of log > syncing fit really nicely into the GET/POST model of HTTP. > > > > I think it would make sense to drop things into > > > /var/log/journal//*.journal by default. The hostname would > > > have to be determined from the URL the user specified on the command > > > line. Ideally we'd use the machine ID here, but since the machine ID is > > > hardly something the user should specify on the command line (and we > > > cannot just take the machine ID supplied form the other side, because we > > > probably should not trust that and hence allow it to tell us to > > > overwrite another hosts' data), the hostname is the next best > > > thing. Currently libsystemd-journald will ignore directories that are > > > not machine IDs when browsing, but we could easily drop that limitation. > > So it seems that this mapping (url/source/whatever -> .journal path) > > will require some thought. > > > > I'd imagine, that people will want to use this most often as a syslogd > > replacement, i.e. launch systemd-journal-remote on a central host, and > > then let all other hosts stream messages live. In this case we know > > only two things: _MACHINE_ID specified remotely, and the remote > > IP:PORT and thus hostname. Actually, I thought that since all those > > things are "unreliable" (IP only to some extent, but still), they > > wouldn't be used to determine the output file, and all output would go > > into one .journal. > > So, my thinking here is that hostnames generally suck for identifying > machines since they are not unique, can change and sometimes are not set > at all. However, that is only true in the general case. In the specific > case where admins want to set up an infrastructure for centralizing logs > they first set up a network, and as part of that I am pretty sure they > came up with a sane naming/addressing scheme first, that makes the name > unique in their local setup, makes the names fixed and ensures the name > is always there. Or to put this in other words: to be able to sync logs > from another hosts you first need to think about how you can contact > that other host, and hence had to introduce a naming scheme first, and > we should be able to just build on that. Exactly. I was thinking about --trust-hostname=no|cert|always as described in the other mail. > > I remember that samba does (did?) something like what you suggest, and > > kept separate logs based on the information under control of the > > connecting host. On a host connected to the internet this would lead > > to hundreds of log files. > > > > In addition, .journal files have a fairly big overhead: ~180kB for a > > an "empty" file. This overhead might be unwanted if there are many > > sources. > > > > Maybe there's no one answer, and choices will have to be provided. > > I think it definitely makes sense to allow admins to name the local > destination dir as they want. I am mostly just interested in finding a > good default, and I'd vote extracting the "basename" of the URL used to > access the remote journal for that. > > > > > Push mode is not implemented... (but it would be a separate program > > > > anyway). > > > > > > My intention was actually to keep this in the same tool. So that we'd > > > have for input and output: > > > > > > A) HTTP GET > > > B) HTTP POST > > > C) SSH PULL (would invoke "journalctl -o export" via ssh) > > > D) SSH PUSH (would invoke systemd-journald-remote via ssh) > > > E) A directory for direct read access (which would allows us to merge > > > multiplefile into one with this tool) > > > F) A directory for direct write access (which is of course the > > > default) > > > > Also useful: > > B1) socket listen() without HTTP > > Where would I want to use that instead of B? It's much easier to write a non-HTTP client. And it's a natural extension of allowing it locally, through a pipe. > > B2) HTTPS POST (I'm assuming that POST means to listen) > > HTTPS for me is just a special case of HTTP. When I meant HTTP above I > meant HTTP with and without TLS, and with and without authentication. Yeah, but usually one listens for the one or the other. Ugrades from HTTP to HTTPS don't work well. > > E1) a specific file for read access > > F1) a specific file for write access > > Th
Re: [systemd-devel] [PATCH 3/6] [RFE] Add OnStop rule
On Sat, 03.11.12 21:52, Oleksii Shevchuk (alx...@gmail.com) wrote: > Add deps to run when unit successfuly stopped Hmm, what is the use case? I am a bit concerned about this change, as this turns systemd unit files into a turing complete language. With two unit files which have OnStop= on each other you can implement a loop. That sounds very dangerous to me. Can you elaborate on the usecase for this? Maybe we can find a different solution? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/6] Add trivial templated args to [Install] WantedBy and RequiredBy fields
On Sat, 03.11.12 21:52, Oleksii Shevchuk (alx...@gmail.com) wrote:
I think this makes sense.
> +#include "specifier.h"
>
> typedef struct {
> char *name;
> @@ -51,6 +52,30 @@ typedef struct {
> Hashmap *have_installed;
> } InstallContext;
>
> +char *name_printf(char * prefix, char * instance, char* format) {
We don't need to export this, do we?
> +
> +/*
> + * This will use the passed string as format string and
> + * replace the following specifiers, if any:
> + *
> + * %p: the unit prefix (foo)
> + * %i: the instance(bar)
> + */
> +
> +char empty_prefix[] = "%p";
> +char empty_instance[] = "%i";
> +
> +const Specifier table[] = {
> +{ 'p', specifier_string, prefix ? : empty_prefix},
> +{ 'i', specifier_string, instance ? : empty_instance},
> +{ 0, NULL, NULL }
> +};
Hmm, specifier_string() already handles NULL strings, and returns the
empty string for them. Isn't that good enough for this case? Is
returning the unreplaced %p, resp. %i really nicer in that case?
> +
> +assert(format);
> +
> +return specifier_printf(format, table, NULL);
> +}
> +
> static int lookup_paths_init_from_scope(LookupPaths *paths, UnitFileScope
> scope) {
> assert(paths);
> assert(scope >= 0);
> @@ -1271,13 +1296,21 @@ static int install_info_symlink_wants(
>
> STRV_FOREACH(s, i->wanted_by) {
> char *path;
> +char *instance = NULL;
> +char *prefix = NULL;
> +char *dst = NULL;
> +
> +unit_name_to_instance(i->name, &instance);
We always need to check for OOM for calls like this.
Otherwise looks quite OK...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl wish: Follow in less
On Mon, 29.10.12 09:18, Colin Guthrie (gm...@colin.guthr.ie) wrote:
> Hi,
>
> Just a quick note of a wish while I remember. As you've tried very hard
> to make "journalctl" without any arguments act mostly like "less
> /var/log/messages", one thing I sometimes used to do but no longer can
> is scroll to the end of the output (shift+g [or just G if you prefer!])
> and then enter follow mode via shift+f [aka F]. Less then displays
> "Waiting for data... (interrupt to abort)".
>
> Obviously when lessing a file this works fine, but when used in
> conjunction with journalctl, it does not.
>
> Would it be possible to enable some automatic "all output+follow" mode
> (as opposed to the "last 10 lines+follow" mode that -f enables) and
> enable this mode by default when the automatic paging is used? When
> going to the end of the file you'll still only see what it there when
> you hit G, but you should then be able to enable follow mode inside the
> pager without any quirks.
>
> As a side note, when you try and exit less' follow mode, you normally
> press ctrl+c ("interrupt to abort"). When used with journalctl+pager
> this just exists immediately. This would also need to be fixed to make
> it behave in the same way.
Added this to the TODO list. Not sure we can really make this work, but
we need to invistigate this at least.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dbus-common: Add helper method to handle no-reply messages
On Tue, 30.10.12 15:38, Colin Walters (walt...@verbum.org) wrote: > [Tested in latest gnome-ostree; if accepted, I'll look at a followup > patch which fixes the other dbus_connection_send(reply, ...) calls > besides logind] Looks cool! Merged! Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/6] Add OnStopRestoreConflicts rule.
On Sat, 03.11.12 21:52, Oleksii Shevchuk (alx...@gmail.com) wrote: > If checked, the unit with this rule should start all > conflicted units, that were successfuly stopped on starting What precisely is the usecase for this one? Doesn't this patch do more than you suggest it would do? What i mean: if A and B conflict, and neither is running, and you then start B and stop it again with this new option set, wouldnt that start A even if it wasn't running before? Is that desirable? I really wonder if we can find a nicer way to solve this. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cryptsetup: disk unlocking order
On Sun, 28.10.12 15:33, Martin Blumenstingl (martin.blumensti...@googlemail.com) wrote: > Hi, > > I switched to systemd yesterday as I was curious if/how it would work > out for me. > There is one really annoying thing so far: > > I have 3 hard disks listed in /etc/crypttab. > I have to enter a password for each one at boot time. > Three disks means three passwords (strong, 15+ characters). > > It turns out that the order in which I'm asked for the passwords at startup > is completely random. > At first I was asked in an alphabetical order (/mnt/a, /mnt/b, /mnt/c). > On the next reboot it used the order in which the disks are listed in > /etc/crypttab. > The reboot after that had a completely different order. > > Is there any fix for this behavior? > I'm using systemd 195 on Arch Linux. If Plymouth is used plymouth can do the necessary caching. That said it is actually my intention to use the kernel keyring for this, so that this wokrs independently of Plymouth and requires no further userspace infrastructure. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journalctl --follow broken
On Tue, Nov 20, 2012 at 06:49:19PM +0100, Lennart Poettering wrote: > On Thu, 01.11.12 13:03, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > Hi, > > > > today I noticed that journalctl --follow seems to print out much more > > than 10 lines. Actually, aftern printing 10 lines correctly, it jump > > to some point in the past: > > > > Logs begin at Sat, 13 Oct 2012 06:13:18 +. > > Nov 01 11:09:26 fedora-15 sshd[29669]: pam_unix(sshd:session): session > > clos...ek > > Nov 01 11:09:26 fedora-15 systemd-logind[455]: Removed session 101. > > Nov 01 11:09:28 fedora-15 python3[29709]: Allowing runtime journal files to > > > > ESC[1;39m- Reboot -ESC[0m > > Oct 28 12:08:26 fedora-15 systemd[1]: SELinux Got Sender :1.312 > > Oct 28 12:08:26 fedora-15 systemd[1]: GetConnectionSELinuxSecurityContext > > u...8) > > ESC[1;39m- Reboot -ESC[0m > > Nov 01 11:09:28 fedora-15 systemd-journal-gatewayd[11055]: Failed to send > > dat... > > Nov 01 11:09:51 fedora-15 python3[29729]: Allowing runtime journal files to > > > > ESC[1;39m- Reboot -ESC[0m > > Oct 28 12:08:26 fedora-15 systemd[1]: SELinux access check > > scon=unconfined_...ic > > > > Apparently sd_journal_next() makes the jump when at EOF. > > > > I'm too lazy to look into sd_journal_next(), but git bisect points to: > > > > Author: Lennart Poettering > > Date: Fri Sep 21 20:52:23 2012 +0200 > > > > journal: completely rework the mmap cache as I too dumb to actually > > understand it > > > > Zbyszek > > Hmm, can you use "-o verbose" instead, and check if there really is a > time jump/seqno jump? (The seqno is the i= bit of the cursor string...) I can't seem to reproduce it anymore. Probably depends on a specific set of logs, which I didn't think to copy. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What does it take to make test-engine working again?
On Wed, 31.10.12 08:43, Holger Freyther (hol...@freyther.de) wrote: > Hi, > > I made a small change and wanted to add test coverage for the bug > I was fixing. The only test that is loading units appears to be > test-engine. Sadly this test is not executed as part of make check > and executing it by hand results in an assertion when starting the > first job. > > Is there a preferred way to test loading of units? Does the test work > for someone? That specific test is really old, and hasn't been used in a long time. I guess we should either remove it or make it work again. (Happy to take patches...) We usually use the functional tests with qemu/LXC instead, i.e. the stuff in test/TEST-0*/, which builds an entire OS and tries to boot that up. More unit tests for parsing unit files would be very desirable though! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving the journal during bootup
On Wed, 24.10.12 15:45, Cliff Brake (cliff.br...@gmail.com) wrote: > Hello, > > We have an embedded system where we boot from an initramfs, but partway > through the boot, we would like to move the journal to NAND flash if its > available. > > I tried modifying the systemd-journald.service to Requires my > nand-mount.mount unit, and that seems to work on bootup, but there is some > type of deadlock on shutdown. > > Any thoughts on how you would approach this problem? Ideally, we could > switching the journal location after it is started. 2nd best would be to > delay the journal starting until the storage medium was available. The journal already supports moving the log data from /run to /var after /var ha sbeen mounted. Maybe you can piggyback on that, and just make sure that /var/log/journal resides on the right kind of storage? Then you should get all this for free? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journalctl and sshd disconnects
On Fri, 26.10.12 11:11, Jake Rooney (tehe...@gmail.com) wrote: > Hi, > > Couple of questions... > > At the moment (195) journalctl _SYSTEMD_UNIT=sshd.service prints out > most sshd logs, but skips user disconnections/logouts. These seem to > be logged under the UID of the user that logged out and are stored in > a separate journal. Why is this? This is because sshd gets moved into the per-session cgroup, and that's what we are looking for. The disconnect message is that generated from UID 0 or the actual user? If it is run as UID of the user we really shouldn't trust the code, and hence splitting things off in the per-user journal sounds like the right thing to do? > journalctl _COMM=sshd matches all logs, including disconnects, but > _EXE=/usr/sbin/sshd skips disconnections. There seems to be some > inconsistency here, so I was wondering what's the "best" way to filter > for all sshd info, rather than having to resort to dumping the journal > and grep'ing. This part really sounds as if it is simply an instance of a common race that we still need to fix in the kernel: the journal will receive UID/GID/PID credentials of the sender of a message along with the message, and then uses that to lookup _EXE, _COMM and other fields. Now, if by the time where the message has been received and we begin to lookup up those extra fields the client side already exited we cannot gather that information. This is someting to fix in the kernel: we'd really like an interface that can send along _EXE, _COMM and suchlike right-away, so that we have it without having to actually gather it explicitly, so that the race is gone. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/6] Add OnStopRestoreConflicts rule.
> What precisely is the usecase for this one? http://lists.freedesktop.org/archives/systemd-devel/2012-November/007479.html I use it to restore previous state after going to alternate state, like powersaving. > Doesn't this patch do more than you suggest it would do? What i mean: if > A and B conflict, and neither is running, and you then start B and stop > it again with this new option set, wouldnt that start A even if it > wasn't running before? Is that desirable? It wouldn't start A in that case. Separate list in current unit fills with marked as Conflicted ones only when other Conflicted ones actually stopped (% > I really wonder if we can find a nicer way to solve this. I hope // Wbr, Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Handling sysctl entries that depend on module presence?
On Tue, Nov 20, 2012 at 2:06 AM, Lennart Poettering wrote: > On Mon, 19.11.12 08:13, Mantas Mikulėnas (graw...@gmail.com) wrote: > >> On Mon, Nov 19, 2012 at 8:01 AM, Mantas Mikulėnas wrote: >> > Anything that is written to /sys/module/*/parameters goes to >> > modprobe.d(5) -- again, to be applied when the module is inserted, not >> > at some fixed point: >> > >> > https://github.com/vodik/powersave/blob/master/modprobe.d/powersave.conf >> > >> > Use sysctl.conf(5) for settings under /proc/sys: >> > >> > https://github.com/vodik/powersave/blob/master/sysctl.d/powersave.conf >> >> This reminded me that systemd-sysctl doesn't properly handle >> sysctl.conf entries that depend on the presence of modules loaded by >> modules-load.d... >> >> In particular, I was having problems with: >> >> net.ipv4.tcp_allowed_congestion_control = cubic reno lp >> >> This setting is required to allow non-root programs (the Transmission >> BitTorrent daemon in particular) to use the "lowest priority" >> congestion control algorithm. >> >> However, if the "tcp_lp" module is not yet loaded, the write to >> /proc/sys is simply refused with EINVAL (if I remember correctly). >> >> And if the module is loaded later (or not loaded manually), without >> the sysctl setting being updated, Transmission receives EPERM when it >> calls setsockopt(TCP_CONGESTION). >> >> This doesn't affect TCPCongestion= in systemd socket units, since root >> is allowed to set any algorithm, and the module is simply loaded on >> demand when systemd asks for it... >> >> How can this be fixed? > > Hmm, whenever a module is loaded this also generates udev events, maybe > for this specific case we should add a udev rule that tries to write the > sysctl again after the module was successfully loaded? There would probably be too many modules even for this sysctl :/ Now that I think of it, it would be nicer if setting the sysctl autoloaded the modules... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/6] [RFE] Add OnStop rule
> Hmm, what is the use case? As for OnFailure=, but opposite. Usefull for doing dangerous jobs in mode like emergency, but not interactive. Like core configuration files/software updates. Pushing OnStop=default.target to that unit I create way home, and JobSecTimeout+OnFailure=emergency.target way to fixing. Personaly I use it to quick soft reload userspace after update >_< > With two unit files which have OnStop= on each other you can implement > a loop. Yeah, that's cool // Wbr, Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/6] Add trivial templated args to [Install] WantedBy and RequiredBy fields
>> +char *name_printf(char * prefix, char * instance, char* format) {
> We don't need to export this, do we?
Don't know. We don't need this function to be exported, but I have no
idea about the policy of using/definition of such functions in systemd.
> Hmm, specifier_string() already handles NULL strings, and returns the
> empty string for them. Isn't that good enough for this case? Is
> returning the unreplaced %p, resp. %i really nicer in that case?
The idea was: if template parameters pushed to non-templated unit, then
Ivalid argument error will be raised by unit_name_is_valid function. In
other case -- unit not found. IMO the second one is irrelevant.
> unit_name_to_instance(i->name, &instance);
> We always need to check for OOM for calls like this.
Yes, this should be fixed. How about this one?
diff --git a/src/shared/install.c b/src/shared/install.c
index a9d75f3..83ea06a 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -36,6 +36,7 @@
#include "install.h"
#include "conf-parser.h"
#include "conf-files.h"
+#include "specifier.h"
typedef struct {
char *name;
@@ -51,6 +52,30 @@ typedef struct {
Hashmap *have_installed;
} InstallContext;
+static char *name_printf(char * prefix, char * instance, char* format) {
+
+/*
+ * This will use the passed string as format string and
+ * replace the following specifiers, if any:
+ *
+ * %p: the unit prefix (foo)
+ * %i: the instance(bar)
+ */
+
+char empty_prefix[] = "%p";
+char empty_instance[] = "%i";
+
+const Specifier table[] = {
+{ 'p', specifier_string, prefix ? : empty_prefix},
+{ 'i', specifier_string, instance ? : empty_instance},
+{ 0, NULL, NULL }
+};
+
+assert(format);
+
+return specifier_printf(format, table, NULL);
+}
+
static int lookup_paths_init_from_scope(LookupPaths *paths, UnitFileScope
scope) {
assert(paths);
assert(scope >= 0);
@@ -1271,13 +1296,24 @@ static int install_info_symlink_wants(
STRV_FOREACH(s, i->wanted_by) {
char *path;
+char *instance = NULL;
+char *prefix = NULL;
+char *dst = NULL;
-if (!unit_name_is_valid(*s, true)) {
+r = unit_name_to_instance(i->name, &instance);
+if (r != 0)
+break;
+
+prefix = unit_name_to_prefix(i->name);
+
+dst = name_printf(prefix, instance, *s);
+
+if (!unit_name_is_valid(dst, true)) {
r = -EINVAL;
continue;
}
-if (asprintf(&path, "%s/%s.wants/%s", config_path, *s,
i->name) < 0)
+if (asprintf(&path, "%s/%s.wants/%s", config_path, dst,
i->name) < 0)
return -ENOMEM;
q = create_symlink(i->path, path, force, changes, n_changes);
@@ -1305,13 +1341,24 @@ static int install_info_symlink_requires(
STRV_FOREACH(s, i->required_by) {
char *path;
+char *instance = NULL;
+char *prefix = NULL;
+char *dst = NULL;
+
+r = unit_name_to_instance(i->name, &instance);
+if (r != 0)
+break;
+
+prefix = unit_name_to_prefix(i->name);
+
+dst = name_printf(prefix, instance, *s);
-if (!unit_name_is_valid(*s, true)) {
+if (!unit_name_is_valid(dst, true)) {
r = -EINVAL;
continue;
}
-if (asprintf(&path, "%s/%s.requires/%s", config_path, *s,
i->name) < 0)
+if (asprintf(&path, "%s/%s.requires/%s", config_path, dst,
i->name) < 0)
return -ENOMEM;
q = create_symlink(i->path, path, force, changes, n_changes);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Starting systemd service in udev rule viaENV{SYSTEMD_WANTS} - help needed
On 11/20/12 3:55 PM, Lennart Poettering wrote: SYSTEMD_WANTS=ext-usb-backup@.myth.backup\x20connected.service This looks alright, doesn't it? Are you saying that this service is not pulled in even though this field showed up on the device? I found where issue is. When developing udev rule I tested it via: udevadm trigger --sysname-match=sdc1 --action=add This seems to correctly launch actions within udev but NOT in systemd. When I physically connect USB device things started to move: -udev SYSTEMD_WANTS seems to be propagated to systemd -systemd launches unit -it looks like params are passed in a way I don't understand Namely: udev has: SYSTEMD_WANTS=ext-usb-backup@.myth.backup\x20connected.service So if unit has something like this: ExecStartPre=/bin/sh -c "/usr/bin/perl /usr/local/bin/osd_notify.pl %I connected backup" osd_notify.pl should have parameters like: ".myth.backup connected backup" but in reality it has: "sys/devices/pci:00/:00:09.0/:04:00.0/usb3/3-1/3-1:1.0/host12/target12:0:0/12:0:0:0/block/sdc/sdc1 connected backup" Do I missed something here ? <>___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd lingering users, user sessions and pusleaudio+mpd (was: Re: New release - mpd has stopped working with same user)
'Twas brillig, and Arun Raghavan at 20/11/12 03:07 did gyre and gimble:
>> > P.S. - using systemd's logind, if that makes a difference.
> Bluewind from the Arch side was speaking to me on IRC several hours ago,
> and let me summarise our findings.
>
> 1. mpd is spawned as your "main" user, with XDG_RUNTIME_DIR unset. As a
> result, we use the fallback runtime dir (which is ~/.pulse if it exists,
> or ~/.config/pulse on a new install).
>
> 2. Your "main" user logs in, XDG_RUNTIME_DIR is set to /run/..., and
> PulseAudio clients try to look for or spawn a server based on that.
>
> The two possible solutions are for mpd to get the same XDG_RUNTIME_DIR,
> or your user session's PULSE_RUNTIME_PATH be set to the same as what mpd
> uses.
>
> Now the semantics of XDG_RUNTIME_DIR dictate that it be completely wiped
> out when the user logs out. I am given to understand that the mpd daemon
> does not get a session proper, so your user logging out could cause
> breakage with the first solution (even though it is more correct, in
> some sense, imo).
>
> That's as far as we got. Perhaps someone with a better understanding of
> the the session stuff can see if mpd can be spawned with its own session
> (which I hope will keep the XDG_RUNTIME_DIR around).
If you're using systemd, then the correct way to get a user session when
not really logged in is with "session lingering". Just calling "loginctl
enable-linger $USER" would work. This should ensure that the runtime dir
is created when user sessions become available
(systemd-user-sessions.service).
Of course, this doesn't actually set the XDG_RUNTIME_DIR for mpd.service
(or whatever your mpd service unit is called).
I'm not sure what the "correct" (aka long term plans) for this are. I'd
guess that it will only really come into it's own when systemd user
sessions are also used in which case I guess a user session daemon
(user@$USER.service) will be automatically started and set to a specific
target ("linger.target"??) when lingering is enabled for a given user.
If that's the case a "regular" user unit, mpd.service, can be
WantedBy=linger.target (rather than graphical.target or whatever). This
is not to be confused with the system mpd.service of course.
Anyway, I've CC'ed the systemd list on this one to get more of a view on
how session lingering is going to work long term.
In the short term, you should hack your *system* mpd.service to have a line:
Environment=XDG_RUNTIME_DIR=/run/user/500
Where 500 is the uid of your user (the path should also be shown as
RuntimePath in "loginctl show-user $USER").
I do feel the correct solution is full lingering support however and the
above is a hack at best.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journalctl and sshd disconnects
Hi Lennart, Thanks for the reply. I can't understand the user-generated sshd log being put into it's own journal out of distrust, isn't that just paranoia? I don't see the practicality of it. Either way, it's still getting logged. Does it matter that it's not in the main journal? Can you elaborate on this please? As for the _EXE and _COMM 'race' issue you mentioned; are you really sure that's a kernel problem..? I'm not clear enough (or qualified enough) on the internals to speculate, but it sounds more like a mishandling on systemd's behalf... Also: I'd really like to see regular expression capability built into journalctl :) Cheers, Jake On 20 November 2012 18:40, Lennart Poettering wrote: > On Fri, 26.10.12 11:11, Jake Rooney (tehe...@gmail.com) wrote: > >> Hi, >> >> Couple of questions... >> >> At the moment (195) journalctl _SYSTEMD_UNIT=sshd.service prints out >> most sshd logs, but skips user disconnections/logouts. These seem to >> be logged under the UID of the user that logged out and are stored in >> a separate journal. Why is this? > > This is because sshd gets moved into the per-session cgroup, and that's > what we are looking for. > > The disconnect message is that generated from UID 0 or the actual user? > If it is run as UID of the user we really shouldn't trust the code, and > hence splitting things off in the per-user journal sounds like the right > thing to do? > >> journalctl _COMM=sshd matches all logs, including disconnects, but >> _EXE=/usr/sbin/sshd skips disconnections. There seems to be some >> inconsistency here, so I was wondering what's the "best" way to filter >> for all sshd info, rather than having to resort to dumping the journal >> and grep'ing. > > This part really sounds as if it is simply an instance of a common race > that we still need to fix in the kernel: the journal will receive > UID/GID/PID credentials of the sender of a message along with the > message, and then uses that to lookup _EXE, _COMM and other fields. Now, > if by the time where the message has been received and we begin to > lookup up those extra fields the client side already exited we cannot > gather that information. > > This is someting to fix in the kernel: we'd really like an interface > that can send along _EXE, _COMM and suchlike right-away, so that we have > it without having to actually gather it explicitly, so that the race is > gone. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd v196
Heya, This is a feature release: http://www.freedesktop.org/software/systemd/systemd-196.tar.xz CHANGES WITH 196: * udev gained support for loading additional device properties from an indexed database that is keyed by vendor/product IDs and similar device identifiers. For the beginning this "hwdb" is populated with data from the well-known PCI and USB database, but also includes PNP, ACPI and OID data. In the longer run this indexed database shall grow into becoming the one central database for non-essential userspace device metadata. Previously, data from the PCI/USB database was only attached to select devices, since the lookup was a relatively expensive operation due to O(n) time complexity (with n being the number of entries in the database). Since this is now O(1), we decided to add in this data for all devices where this is available, by default. Note that the indexed database needs to be rebuilt when new data files are installed. To achieve this you need to update your packaging scripts to invoke "udevadm hwdb --update" after installation of hwdb data files. For RPM-based distributions we introduced the new %udev_hwdb_update macro for this purpose. * The Journal gained support for the "Message Catalog", an indexed database to link up additional information with journal entries. For further details please check: http://www.freedesktop.org/wiki/Software/systemd/catalog The indexed message catalog database also needs to be rebuilt after installation of message catalog files. Use "journalctl --update-catalog" for this. For RPM-based distributions we introduced the %journal_catalog_update macro for this purpose. * The Python Journal bindings gained support for the standard Python logging framework. * The Journal API gained new functions for checking whether the underlying file system of a journal file is capable of properly reporting file change notifications, or whether applications that want to reflect journal changes "live" need to recheck journal files continously in appropriate time intervals. * It is now possible to set the "age" field for tmpfiles entries to 0, indicating that files matching this entry shall always be removed when the directories are cleaned up. * coredumpctl gained a new "gdb" verb which invokes gdb right-away on the selected coredump. * There's now support for "hybrid sleep" on kernels that support this, in addition to "suspend" and "hibernate". Use "systemctl hybrid-sleep" to make use of this. * logind's HandleSuspendKey= setting (and related settings) now gained support for a new "lock" setting to simply request the screen lock on all local sessions, instead of actually executing a suspend or hibernation. * systemd will now mount the EFI variables file system by default. * Socket units now gained support for configuration of the SMACK security label. * timedatectl will now output the time of the last and next daylight saving change. * We dropped support for various legacy and distro-specific concepts, such as insserv, early-boot SysV services (i.e. those for non-standard runlevels such as 'b' or 'S') or ArchLinux /etc/rc.conf support. We recommend the distributions who still need support this to either continue to maintain the necessary patches downstream, or find a different solution. (Talk to us if you have questions!) * Various systemd components will now bypass PolicyKit checks for root and otherwise handle properly if PolicyKit is not found to be around. This should fix most issues for PolicyKit-less systems. Quite frankly this should have been this way since day one. It is absolutely our intention to make systemd work fine on PolicyKit-less systems, and we consider it a bug if something doesn't work as it should if PolicyKit is not around. * For embedded systems it is now possible to build udev and systemd without blkid and/or kmod support. * "systemctl switch-root" is now capable of switching root more than once. I.e. in addition to transitions from the initrd to the host OS it is now possible to transition to further OS images from the host. This is useful to implement offline updating tools. * Various other additions have been made to the RPM macros shipped with systemd. Use %udev_rules_update() after i
