Re: [systemd-devel] Linux Journal API/client lib
On Mon, Dec 5, 2011 at 1:40 AM, Kay Sievers wrote: > On Sat, Dec 3, 2011 at 20:41, Rainer Gerhards wrote: >> I have digested our discussion now. Two questions came up: >> >> The first one is a bit direct and blunt, my apologies for that. But I >> want to make sure I put effort into the right place. Do you see any >> benefit in an interface like I described (reading and writing the >> journal from the syslogd)? Or do you think this is a needless effort? > > Oh sure, I think it can be very useful. We might need to find out how > to identify such a stream of data in the journal, or if we should make > it possible log things for a different machine-id. Your example like > the SOHO router which pushes out syslog data could possibly get a > machine-id assigned from the syslogd config that processes the data. > We need to find out the details ... > > Syslog will not go away in many setups, the network log from other > hosts which speak syslog, real boxes or the specialized hardware like > a SOHO router, will speak the current syslog for a very long time in > the future. And we don't want to speak real syslog with the journal; > that's all stuff that should be done with syslog, and possibly if it > can act as a bridge to the journal index, it sounds like a very nice > option to have. This sounds reasonable to me as well. IMHO a bit problem in this process is how to keep trusted things trusted. But I understand that you currently have more important core things to do than tackle that beast or interop. I would be happy to provide feedback once you look at this issue. >> The second one is on /dev/log: is what is provided to the syslogd just >> like "the real thing"? I am specifically concerned if SCM_CREDENTIALS >> will properly identify the log emitter. > > We expect we are able to fake all the properties. If not we will need > to make that possible, we didn't look into the details as of now, but > the plan surely is to make /dev/log behave like it is without the > journald interception. Yes, that would be very important, especially as the rate-limiting in rsyslog heavily depends on SCM_CREDENTIALS (as do some other things, but rate-limiting is the most important one IMHO). Thanks again, Rainer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecStartPost= behavior on failure
On 11/15/2011 01:40 PM, Honza Horak wrote: I'm thinking of what is the desired behavior if the command ExecStartPost=somecommand fails. If I understand it correctly, all other ExecStartPost= commands execution is stopped, but the main process continues to work (and the service is still active). From my POV this should happen when ExecStartPost= starts with '-'. But when '-' is not used, the service as well as the main process should be ended by systemd. I agree and I have fixed this in git. http://cgit.freedesktop.org/systemd/commit/?id=2096e009a790073a934f5cd07d17024d3b199d0b Thanks for pointing it out. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] WorkingDirectory for user units
Am Samstag, den 03.12.2011, 16:52 +0200 schrieb Ran Benita: > On Sat, Dec 03, 2011 at 02:32:19PM +0100, Thomas Meyer wrote: > > 1.) Is there an option to set the WorkingDirectory automatically to the > > users home? The environment variable "HOME" seems to get set for the > > process. Or is there an option to set the WorkingDirectory based on the > > user? default working directory seems to be "/". > > I don't think there's a way to do it. I looked into either > - making the home directory the default working directory (for user's >systemd) > - adding a %~ format specifier > - or maybe both? > A patch shouldn't be too hard, which do you think is best? I think the home directory of the user should be the default working directory for user units (convention over configuration). OTOH a %~ (home directory) or %u (already taken? - user name) format specifier would be more flexible. regards, thomas signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Status multiseat?
Hi, I'm informing the status of multiseat. I've read here: http://fedoraproject.org/wiki/Features/ckremoval that there is worked on automatic detection of multiseat. Some notes: . automatic is only possible for local seats . maximum local seats is the minimum of terminals and keyboards (=N) . part of N is "X" seat, where a mouse (or any other pointing device) is available and maybe required is a framebuffer with some capabilities. . manual configuration overrides automatic detection. I've got two terminals in dual monitor (onescreen over two terminals) setup. . remote seat detection is never automatic, but happens on the fly when someone logs in. Is analysis ok? Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Allow 'list-unit-files' to run with --root.
On Tue, 22 Nov 2011 15:45:34 -0500 Bill Nottingham wrote: > To do so, move the check for the bus to the bus-using portion of > list_unit_files(), and ensure that get_config_path doesn't abort when > checking the runtime path with --root. > --- > src/install.c |5 ++--- > src/systemctl.c |5 +++-- > 2 files changed, 5 insertions(+), 5 deletions(-) Applied, thanks. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
