Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Chris Murphy
This is suspicious:

# df -h
...
/dev/mapper/live-rw  6.4G  5.7G  648M  91% /

And in the log:
47,19636,16754831,-;systemd-journald[905]: Fixed min_use=1.0M
max_use=648.7M max_size=81.0M min_size=512.0K keep_free=973.1M
n_max_files=100

Why is keep_free bigger than available free space? Is that the cause
of the vacuuming?

47,19867,16908013,-;systemd-journald[905]:
/var/log/journal/05d0a9c86a0e4bbcb36c5e0082b987ee/system.journal:
Allocation limit reached, rotating.
47,19868,16908029,-;systemd-journald[905]: Rotating...

And then

47,27860,22417049,-;systemd-journald[905]: Vacuuming...
47,27861,22427712,-;systemd-journald[905]: Deleted archived journal
/var/log/journal/05d0a9c86a0e4bbcb36c5e0082b987ee/system@daa6e38474b84afc8404527c7b204c24-0001-00058dff129d34ae.journal
(8.0M).
47,27862,22427724,-;systemd-journald[905]: Vacuuming done, freed 8.0M
of archived journals from
/var/log/journal/05d0a9c86a0e4bbcb36c5e0082b987ee.

That vacuuming event is the direct cause of the data loss. But does it
happen because keep_free is greater than free space, and if so then
why is keep_free greater than free space?

Slightly off topic but why are there over 18000 (that's not a typo) of
these identical lines? It seems excessive.

47,27869,22428300,-;systemd-journald[905]: Journal effective settings
seal=no compress=yes compress_threshold_bytes=512B

I've updated the bug report to include an attachment of the journal
I've captured by forwarding to kmsg.

https://bugzilla.redhat.com/show_bug.cgi?id=1715699#c17


Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Chris Murphy
On Thu, Jul 18, 2019 at 4:36 PM Greg Oliver  wrote:

> I am assuming you have ripped apart the initramfs to see exactly how RedHat 
> is invoking systemd in the live images?

I have not. No idea what I'd be looking for.

# ps aux | grep systemd

Installed system (Fedora 30):
root 1  0.0  0.1 171444 14696 ?Ss   12:05   0:09
/usr/lib/systemd/systemd --switched-root --system --deserialize 18

Live system (Rawhide):
root 1  0.8  0.4 171516 14708 ?Ss   19:57   0:07
/usr/lib/systemd/systemd --switched-root --system --deserialize 32



-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Chris Murphy
On Thu, Jul 18, 2019 at 4:02 PM Chris Murphy  wrote:
>
> On Thu, Jul 18, 2019 at 10:18 AM Dave Howorth  wrote:
> >
> > On Thu, 18 Jul 2019 09:55:51 -0600
> > Chris Murphy  wrote:
> > > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala 
> > > wrote:
> > > >
> > > > On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
> > > > > So far nothing I've tried gets me access to information that would
> > > > > give a hint why systemd-journald thinks there's no free space and
> > > > > yet it still decides to create a single 8MB system journal, which
> > > > > then almost immediately gets deleted, including all the evidence
> > > > > up to that point.
> > > >
> > > > Run journald under strace and check the results of the system calls
> > > > used to query space? (One way to run it under strace would be to
> > > > change the unit file to use "strace -D -o /run/output
> > > > systemd-journald" as the process to start.)
> > >
> > > It's a good idea but strace isn't available on Fedora live media. So I
> > > either have to learn how to create a custom live media locally (it's a
> > > really complicated process) or convince Fedora to add strace to live
> > > media...
> >
> > I'm not a fedora user, but I don't think it's that difficult to run
> > strace.
> >
> > To run it once, start your live image and type:
> >
> > # yum install strace
> >
> > You will need to reinstall it if you reboot.
> >
> > To permanently install it apparently you need to configure your USB
> > with persistent storage. I haven't looked up how to do that.
>
> I thought about that, but this is a substantial alteration from the
> original ISO in terms of the storage layout and how everything gets
> assembled. But it's worth a shot. If it is a systemd bug, then it
> should still reproduce. If it doesn't reproduce, then chances are it's
> some kind of assembly related problem.
>
> Still seems like a systemd-journald bug that neither forward to
> console nor to kmsg includes any useful systemd or dracut debugging.

I used livecd-iso-to-disk to create the persistent boot media, the
problem does reproduce. But I needed a custom initramfs that has the
modified systemd-journald.service unit file in it, as well as strace,
because this problem happens that early in the startup process. Thing
is, that custom initramfs blows up trying to assemble the persistent
overlay. Looking at the compose logs for this image, I see a rather
complex dracut command is needed:

dracut --nomdadmconf --nolvmconf --xz --add livenet dmsquash-live
convertfs pollcdrom qemu qemu-net --omit plymouth --no-hostonly
--debug --no-early-microcode --force
boot/initramfs-5.3.0-0.rc0.git4.1.fc31.x86_64.img
5.3.0-0.rc0.git4.1.fc31.x86_64

Fine. Now I can boot. Next gotcha is that /run/output is a 0 byte
length file. I don't know why. I've booted with enforcing=0 in case
selinux doesn't like strace writing to /run/ but that hasn't made a
difference.

The change I made in /usr/lib/systemd/system/systemd-journald.service is
ExecStart=/usr/bin/strace -D -o /run/output /usr/lib/systemd/systemd-journald

I've also tried booting with the original initrd which doesn't have
the systemd-journald modification, relying only on the one on
persistent storage. I still get /run/output as a 0 length file. I've
tried booting with enforcing=0 in case selinux is denying the write,
but that doesn't solve the problem.

So I'm still stuck.


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Greg Oliver
On Thu, Jul 18, 2019 at 5:02 PM Chris Murphy 
wrote:

> On Thu, Jul 18, 2019 at 10:18 AM Dave Howorth 
> wrote:
> >
> > On Thu, 18 Jul 2019 09:55:51 -0600
> > Chris Murphy  wrote:
> > > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala 
> > > wrote:
> > > >
> > > > On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
> > > > > So far nothing I've tried gets me access to information that would
> > > > > give a hint why systemd-journald thinks there's no free space and
> > > > > yet it still decides to create a single 8MB system journal, which
> > > > > then almost immediately gets deleted, including all the evidence
> > > > > up to that point.
> > > >
> > > > Run journald under strace and check the results of the system calls
> > > > used to query space? (One way to run it under strace would be to
> > > > change the unit file to use "strace -D -o /run/output
> > > > systemd-journald" as the process to start.)
> > >
> > > It's a good idea but strace isn't available on Fedora live media. So I
> > > either have to learn how to create a custom live media locally (it's a
> > > really complicated process) or convince Fedora to add strace to live
> > > media...
> >
> > I'm not a fedora user, but I don't think it's that difficult to run
> > strace.
> >
> > To run it once, start your live image and type:
> >
> > # yum install strace
> >
> > You will need to reinstall it if you reboot.
> >
> > To permanently install it apparently you need to configure your USB
> > with persistent storage. I haven't looked up how to do that.
>
> I thought about that, but this is a substantial alteration from the
> original ISO in terms of the storage layout and how everything gets
> assembled. But it's worth a shot. If it is a systemd bug, then it
> should still reproduce. If it doesn't reproduce, then chances are it's
> some kind of assembly related problem.
>
> Still seems like a systemd-journald bug that neither forward to
> console nor to kmsg includes any useful systemd or dracut debugging.
>

I'm no systemd expert by any means, and just a Fedora user because we ship
our product on RHEL, so I like to see what is coming down the pipe.
Nonetheless, I have been following this thread with interest since threads
I always follow on LKML refer to the kernel's shitty print to console
implementation that sucks so bad and well, it might cross boundaries..

Not to toss knives, but I would almost always blame RedHat before anyone
else in the community - they do have a tendency to bastardize things in
ways that suit themselves.  Please do not take that as a jab, it just is
what it is - like I said - I have just learned to accept it.

I am assuming you have ripped apart the initramfs to see exactly how RedHat
is invoking systemd in the live images?

-Greg
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Chris Murphy
On Thu, Jul 18, 2019 at 10:18 AM Dave Howorth  wrote:
>
> On Thu, 18 Jul 2019 09:55:51 -0600
> Chris Murphy  wrote:
> > On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala 
> > wrote:
> > >
> > > On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
> > > > So far nothing I've tried gets me access to information that would
> > > > give a hint why systemd-journald thinks there's no free space and
> > > > yet it still decides to create a single 8MB system journal, which
> > > > then almost immediately gets deleted, including all the evidence
> > > > up to that point.
> > >
> > > Run journald under strace and check the results of the system calls
> > > used to query space? (One way to run it under strace would be to
> > > change the unit file to use "strace -D -o /run/output
> > > systemd-journald" as the process to start.)
> >
> > It's a good idea but strace isn't available on Fedora live media. So I
> > either have to learn how to create a custom live media locally (it's a
> > really complicated process) or convince Fedora to add strace to live
> > media...
>
> I'm not a fedora user, but I don't think it's that difficult to run
> strace.
>
> To run it once, start your live image and type:
>
> # yum install strace
>
> You will need to reinstall it if you reboot.
>
> To permanently install it apparently you need to configure your USB
> with persistent storage. I haven't looked up how to do that.

I thought about that, but this is a substantial alteration from the
original ISO in terms of the storage layout and how everything gets
assembled. But it's worth a shot. If it is a systemd bug, then it
should still reproduce. If it doesn't reproduce, then chances are it's
some kind of assembly related problem.

Still seems like a systemd-journald bug that neither forward to
console nor to kmsg includes any useful systemd or dracut debugging.


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Dave Howorth
On Thu, 18 Jul 2019 09:55:51 -0600
Chris Murphy  wrote:
> On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala 
> wrote:
> >
> > On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:  
> > > So far nothing I've tried gets me access to information that would
> > > give a hint why systemd-journald thinks there's no free space and
> > > yet it still decides to create a single 8MB system journal, which
> > > then almost immediately gets deleted, including all the evidence
> > > up to that point.  
> >
> > Run journald under strace and check the results of the system calls
> > used to query space? (One way to run it under strace would be to
> > change the unit file to use "strace -D -o /run/output
> > systemd-journald" as the process to start.)  
> 
> It's a good idea but strace isn't available on Fedora live media. So I
> either have to learn how to create a custom live media locally (it's a
> really complicated process) or convince Fedora to add strace to live
> media...

I'm not a fedora user, but I don't think it's that difficult to run
strace.

To run it once, start your live image and type:

# yum install strace

You will need to reinstall it if you reboot.

To permanently install it apparently you need to configure your USB
with persistent storage. I haven't looked up how to do that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Chris Murphy
On Thu, Jul 18, 2019 at 4:50 AM Uoti Urpala  wrote:
>
> On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
> > So far nothing I've tried gets me access to information that would
> > give a hint why systemd-journald thinks there's no free space and yet
> > it still decides to create a single 8MB system journal, which then
> > almost immediately gets deleted, including all the evidence up to that
> > point.
>
> Run journald under strace and check the results of the system calls
> used to query space? (One way to run it under strace would be to change
> the unit file to use "strace -D -o /run/output systemd-journald" as the
> process to start.)

It's a good idea but strace isn't available on Fedora live media. So I
either have to learn how to create a custom live media locally (it's a
really complicated process) or convince Fedora to add strace to live
media...

-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Linux Plumbers 2019: Containers and Checkpoint/Restore micro-conference CFP

2019-07-18 Thread Christian Brauner
Hey everyone,

We're excited to announce another edition of the combined Containers and
Checkpoint/Restore micro-conference at this year's Linux Plumbers
conference in Lisbon, Portugal!

The Containers and Checkpoint/Restore micro-conference at Linux Plumbers
is the opportunity for runtime and kernel maintainers and others
involved with containers to talk about what they are up to and agree on
the next major changes to kernel- and userspace.

 The CFP is open until 2nd of August 2019!
Please send us your proposals by applying on the official Linux Plumbers
website:

https://www.linuxplumbersconf.org/event/4/abstracts/#submit-abstract

You can find more details on how to apply and suggestions for topics on
the following website:

https://discuss.linuxcontainers.org/t/containers-micro-conference-at-linux-plumbers-2019

We're very excited to hear what you have been hacking on over the last
year, what progress you made on ongoing projects, new ideas you have,
and what you think is missing and needs more work or attention in
kernel- and userspace.

Looking forward to see you all there! :)
Christian


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald deleting logs on LiveOS boots

2019-07-18 Thread Uoti Urpala
On Mon, 2019-07-15 at 14:32 -0600, Chris Murphy wrote:
> So far nothing I've tried gets me access to information that would
> give a hint why systemd-journald thinks there's no free space and yet
> it still decides to create a single 8MB system journal, which then
> almost immediately gets deleted, including all the evidence up to that
> point.

Run journald under strace and check the results of the system calls
used to query space? (One way to run it under strace would be to change
the unit file to use "strace -D -o /run/output systemd-journald" as the
process to start.)


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: sd_journal_send non-blocking call

2019-07-18 Thread Mantas Mikulėnas
On Thu, Jul 18, 2019 at 12:44 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 18.07.2019 um 10:06 in
> Nachricht
> :
> > On Thu, Jul 18, 2019 at 10:32 AM Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >
> >> >>> Vaibhav Dahiya  schrieb am 18.07.2019 um 02:53 in
> >> Nachricht
> >> <5d2fc2f0.1c69fb81.214d0.1...@mx.google.com>:
> >> > Hello,
> >> >
> >> > I am using sd_journal_send api() api call to log messages on syslog
> >> server.
> >> > I see that this uses
> >> > sendmsg(fd, &mh, MSG_NOSIGNAL) call.
> >>
> >> Aren't syslog messages UDP anyway? When would an UDP send block?
> >>
> >
> > No, program APIs use Unix sockets (/dev/log,
> /run/systemd/journal/socket).
> > You only get UDP when your local syslog daemon is configured to forward
> > elsewhere.
> >
> > That said, both are datagram sockets, I'm not sure whether sending to
> Unix
> > dgram sockets can block or not?
>
> ??? Datagram _is_ UDP
>

UDP is datagram, but datagram is not always UDP.

"UDP" specifically means the datagram transport protocol that runs over
IPv4/IPv6, nothing else. Unix sockets (AF_UNIX) have a datagram mode but
they do not use UDP (or IP). Netlink is datagram-based but it isn't
UDP-based. &c.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "Unknown lvalue '' in section 'Service'"

2019-07-18 Thread Mantas Mikulėnas
On Thu, Jul 18, 2019 at 12:49 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 18.07.2019 um 10:46 in
> Nachricht
> :
> > On Thu, Jul 18, 2019 at 11:34 AM Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> wrote:
> >
> >> Hi!
> >>
> >> I noticed that a line of "===" in "[Service]" cases the message "
> >> Unknown lvalue '' in section 'Service'".
> >> (systemd 228)
> >>
> >> Shouldn't that be "Parse error at '===' in section 'Service'"?
> >>
> >
> > Arguably it isn't a parse error – the keyfile parser successfully
> > recognizes the line as assigning the value "==" to the key "". It's
> > only later when the parsed results are interpreted that each key is
> matched
> > to an internal handler.
>
> Well, of course it's a matter of interpretation:
> You could assign "==" to a variable with an empty name, or you could
> assing "=" to a variable named "=", but to me the the parser sould
> detect
> theis kind of error (I susüect it was a mark from some merge, btw)
>
> >
> > The error message *could* be clearer if all such errors had a common
> "Parse
> > error:" prefix, I guess. (And what's the point of calling it an 'lvalue'
> > anyway?...)
>
> Well if the variable with an empty name is valid, it's an lvalue and it's
> name
> is the "unknown" value (if you like to argue that way). IMHO variable names
> consisting of empty strings are a bad concept at least...
>

Yes, and Zbigniew's PR adjusts the parser to not allow empty names.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: "Unknown lvalue '' in section 'Service'"

2019-07-18 Thread Ulrich Windl
>>> Mantas Mikulenas  schrieb am 18.07.2019 um 10:46 in
Nachricht
:
> On Thu, Jul 18, 2019 at 11:34 AM Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> wrote:
> 
>> Hi!
>>
>> I noticed that a line of "===" in "[Service]" cases the message "
>> Unknown lvalue '' in section 'Service'".
>> (systemd 228)
>>
>> Shouldn't that be "Parse error at '===' in section 'Service'"?
>>
> 
> Arguably it isn't a parse error – the keyfile parser successfully
> recognizes the line as assigning the value "==" to the key "". It's
> only later when the parsed results are interpreted that each key is matched
> to an internal handler.

Well, of course it's a matter of interpretation:
You could assign "==" to a variable with an empty name, or you could
assing "=" to a variable named "=", but to me the the parser sould detect
theis kind of error (I susüect it was a mark from some merge, btw)

> 
> The error message *could* be clearer if all such errors had a common "Parse
> error:" prefix, I guess. (And what's the point of calling it an 'lvalue'
> anyway?...)

Well if the variable with an empty name is valid, it's an lvalue and it's name
is the "unknown" value (if you like to argue that way). IMHO variable names
consisting of empty strings are a bad concept at least...

> 
> -- 
> Mantas Mikulėnas



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Antw: sd_journal_send non-blocking call

2019-07-18 Thread Ulrich Windl
>>> Mantas Mikulenas  schrieb am 18.07.2019 um 10:06 in
Nachricht
:
> On Thu, Jul 18, 2019 at 10:32 AM Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> wrote:
> 
>> >>> Vaibhav Dahiya  schrieb am 18.07.2019 um 02:53 in
>> Nachricht
>> <5d2fc2f0.1c69fb81.214d0.1...@mx.google.com>:
>> > Hello,
>> >
>> > I am using sd_journal_send api() api call to log messages on syslog
>> server.
>> > I see that this uses
>> > sendmsg(fd, &mh, MSG_NOSIGNAL) call.
>>
>> Aren't syslog messages UDP anyway? When would an UDP send block?
>>
> 
> No, program APIs use Unix sockets (/dev/log, /run/systemd/journal/socket).
> You only get UDP when your local syslog daemon is configured to forward
> elsewhere.
> 
> That said, both are datagram sockets, I'm not sure whether sending to Unix
> dgram sockets can block or not?

??? Datagram _is_ UDP

> 
> 
>>
>> > Is there a provision of passing MSG_DONTWAIT flag to this.
>> > or else have a separate api like sd_journal_send_non_blocking().
>> > I want to use this call in an application where I cant make a blocking
>> call
>> > for logging.
>> >
>> > Regards
>> >
>> > Sent from Mail for Windows 10
>>
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org 
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 
> 
> 
> 
> -- 
> Mantas Mikulėnas



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "Unknown lvalue '' in section 'Service'"

2019-07-18 Thread Zbigniew Jędrzejewski-Szmek
On Thu, Jul 18, 2019 at 11:46:59AM +0300, Mantas Mikulėnas wrote:
> On Thu, Jul 18, 2019 at 11:34 AM Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> wrote:
> 
> > Hi!
> >
> > I noticed that a line of "===" in "[Service]" cases the message "
> > Unknown lvalue '' in section 'Service'".
> > (systemd 228)
> >
> > Shouldn't that be "Parse error at '===' in section 'Service'"?
> >
> 
> Arguably it isn't a parse error – the keyfile parser successfully
> recognizes the line as assigning the value "==" to the key "". It's
> only later when the parsed results are interpreted that each key is matched
> to an internal handler.
> 
> The error message *could* be clearer if all such errors had a common "Parse
> error:" prefix, I guess. (And what's the point of calling it an 'lvalue'
> anyway?...)

https://github.com/systemd/systemd/pull/13107

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "Unknown lvalue '' in section 'Service'"

2019-07-18 Thread Mantas Mikulėnas
On Thu, Jul 18, 2019 at 11:34 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I noticed that a line of "===" in "[Service]" cases the message "
> Unknown lvalue '' in section 'Service'".
> (systemd 228)
>
> Shouldn't that be "Parse error at '===' in section 'Service'"?
>

Arguably it isn't a parse error – the keyfile parser successfully
recognizes the line as assigning the value "==" to the key "". It's
only later when the parsed results are interpreted that each key is matched
to an internal handler.

The error message *could* be clearer if all such errors had a common "Parse
error:" prefix, I guess. (And what's the point of calling it an 'lvalue'
anyway?...)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] "Unknown lvalue '' in section 'Service'"

2019-07-18 Thread Ulrich Windl
Hi!

I noticed that a line of "===" in "[Service]" cases the message " Unknown 
lvalue '' in section 'Service'".
(systemd 228)

Shouldn't that be "Parse error at '===' in section 'Service'"?

Regards,
Ulrich


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: sd_journal_send non-blocking call

2019-07-18 Thread Mantas Mikulėnas
On Thu, Jul 18, 2019 at 10:32 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Vaibhav Dahiya  schrieb am 18.07.2019 um 02:53 in
> Nachricht
> <5d2fc2f0.1c69fb81.214d0.1...@mx.google.com>:
> > Hello,
> >
> > I am using sd_journal_send api() api call to log messages on syslog
> server.
> > I see that this uses
> > sendmsg(fd, &mh, MSG_NOSIGNAL) call.
>
> Aren't syslog messages UDP anyway? When would an UDP send block?
>

No, program APIs use Unix sockets (/dev/log, /run/systemd/journal/socket).
You only get UDP when your local syslog daemon is configured to forward
elsewhere.

That said, both are datagram sockets, I'm not sure whether sending to Unix
dgram sockets can block or not?


>
> > Is there a provision of passing MSG_DONTWAIT flag to this.
> > or else have a separate api like sd_journal_send_non_blocking().
> > I want to use this call in an application where I cant make a blocking
> call
> > for logging.
> >
> > Regards
> >
> > Sent from Mail for Windows 10
>
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: sd_journal_send non-blocking call

2019-07-18 Thread Ulrich Windl
>>> Vaibhav Dahiya  schrieb am 18.07.2019 um 02:53 in 
>>> Nachricht
<5d2fc2f0.1c69fb81.214d0.1...@mx.google.com>:
> Hello,
> 
> I am using sd_journal_send api() api call to log messages on syslog server. 
> I see that this uses
> sendmsg(fd, &mh, MSG_NOSIGNAL) call. 

Aren't syslog messages UDP anyway? When would an UDP send block?

> Is there a provision of passing MSG_DONTWAIT flag to this. 
> or else have a separate api like sd_journal_send_non_blocking(). 
> I want to use this call in an application where I cant make a blocking call 
> for logging. 
> 
> Regards
> 
> Sent from Mail for Windows 10




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel