On Mon, Feb 23, 2015 at 1:31 PM, <covici@ccs.covici.com> wrote:
>
> Marc Joliet <marcec@gmx.de> wrote:
>
> > Am Mon, 23 Feb 2015 12:10:18 -0600
> > schrieb Canek Peláez Valdés <caneko@gmail.com>:
> >
> > > On Mon, Feb 23, 2015 at 11:49 AM, <covici@ccs.covici.com> wrote:
> > > >
> > > > Canek Peláez Valdés <caneko@gmail.com> wrote:
> > > >
> > > > > On Mon, Feb 23, 2015 at 3:41 AM, <covici@ccs.covici.com> wrote:
> > > > > >
> > > > > > Marc Joliet <marcec@gmx.de> wrote:
> > > > > >
> > > > > > > Am Mon, 23 Feb 2015 00:41:50 +0100
> > > > > > > schrieb lee <lee@yagibdah.de>:
> > > > > > >
> > > > > > > > Neil Bothwick <neil@digimed.co.uk> writes:
> > > > > > > >
> > > > > > > > > On Wed, 18 Feb 2015 21:49:54 +0100, lee wrote:
> > > > > > > > >
> > > > > > > > >> > I wonder if the OP is using systemd and trying to read the
> > > > > journal
> > > > > > > > >> > files?
> > > > > > > > >>
> > > > > > > > >> Nooo, I hate systemd ...
> > > > > > > > >>
> > > > > > > > >> What good are log files you can't read?
> > > > > > > > >
> > > > > > > > > You can't read syslog-ng log files without some reading
> > > software,
> > > > > usually
> > > > > > > > > a combination of cat, grep and less. systemd does it all with
> > > > > journalctl.
> > > > > > > > >
> > > > > > > > > There are good reasons to not use systemd, this isn't one of
> > > them.
> > > > > > > >
> > > > > > > > To me it is one of the good reasons, and an important one. Plain
> > > text
> > > > > > > > can usually always be read without further ado, be it from rescue
> > > > > > > > systems you booted or with software available on different
> > > operating
> > > > > > > > systems. It can be also be processed with scripts and sent as
> > > email.
> > > > > > > > You can probably even read it on your cell phone. You can still
> > > read
> > > > > > > > log files that were created 20 years ago when they are plain text.
> > > > > > > >
> > > > > > > > Can you do all that with the binary files created by systemd? I
> > > can't
> > > > > > > > even read them on a working system.
> > > > > > >
> > > > > > > What Canek and Rich already said is good, but I'll just add this:
> > > it's
> > > > > not like
> > > > > > > you can't run a classic syslog implementation alongside the systemd
> > > > > journal.
> > > > > > > On my systems, by *default*, syslog-ng kept working as usual,
> > > getting
> > > > > the logs
> > > > > > > from the systemd journal. If you want to go further, you can even
> > > > > configure
> > > > > > > the journal to not store logs permanently, so that you *only* end up
> > > > > with
> > > > > > > plain-text logs on your system (Duncan on gentoo-amd64 went this
> > > way).
> > > > > > >
> > > > > > > So no, the format that the systemd journal uses is most decidedly
> > > *not*
> > > > > a reason
> > > > > > > against using systemd.
> > > > > > >
> > > > > > > Personally, I'm probably going to uninstall syslog-ng, because
> > > > > journalctl is
> > > > > > > *such* a nice way to read logs, so why run something whose output
> > > I'll
> > > > > never
> > > > > > > read again? I recommend reading
> > > > > > > http://0pointer.net/blog/projects/journalctl.html for examples of
> > > the
> > > > > kind of
> > > > > > > stuff you can do that would be cumbersome, if not *impossible* with
> > > > > regular
> > > > > > > syslog.
> > > > > >
> > > > > > Except that I get lots of messages about the system journal missing
> > > > > > messages when forwarding to syslog, so how can I make sure this does
> > > not
> > > > > > happening?
> > > > >
> > > > > Could you please show those messages? systemd sends *everything* to the
> > > > > journal, and then the journal (optionally) can send it too to a regular
> > > > > syslog. In that sense, it's impossible for the journal to miss any
> > > message.
> > > > >
> > > > > The only way in which the journal could miss messages is at very early
> > > boot
> > > > > stages; but with a proper initramfs (like the ones generated with
> > > dracut),
> > > > > even those get caught. You get to put an instance of systemd and the
> > > > > journal inside the initramfs, and so it's available almost from the
> > > > > beginning.
> > > > >
> > > > > And if you use gummiboot, then you can even log from the moment the UEFI
> > > > > firmware comes to life.
> > > >
> > > > So, I get lots of messages in my regular syslog-ng /var/log/messages
> > > > like the following:
> > > > Feb 23 12:47:52 ccs.covici.com systemd-journal[715]: Forwarding to
> > > > syslog missed 15 messages.
> > > >
> > > > So, I saw a post on Google to up the queue length, and I uped it to 200,
> > > > but no joy, still get the messages like the one above.
> > >
> > > Are you using the unit file provided by syslog-ng (systemd-delta doesn't
> > > mention syslog)? Also, is /etc/systemd/system/syslog.service is a link
> > > to /usr/lib/systemd/system/syslog-ng.service?
> > >
> > > I do, and I don't get any of those messages. I use the default journal
> > > configuration. According to [1], this should be fixed.
> >
> > I remember getting a small number of messages like that, too, on my laptop.
> > However, it's at the university, so I can't check now to see what types of
> > messages were missed (if any; if I understand [1] correctly, those messages are
> > most likely bogus?).
> >
> > But yeah, that's any idea, Covici: see what's in /var/log/messages, compare that
> > to the journalctl output, and check if any messages were actually missed ("diff
> > -U" might be of help here). And if/once you did that, what kinds of messages
> > were missed, if any? If those messages really are bogus, you shouldn't see any
> > differences between the two.
> >
> > > Regards.
> > >
> > > https://github.com/balabit/syslog-ng/issues/314
> >
> > Note that that fix would only be in the ~arch version of syslog-ng, the current
> > stable version (3.4.8) is a few months too old.
>
> I am up to 3.6 something, so the fix should be there. But my unit file
> is different, so that remains to check.
I would try the provided unit file. It seems that the only difference with yours is that it doesn't comment the Restart=on-failure line, and that it has StandardOutput=null.
I think the general idea is always to use upstream's unit files. They write the software, supposedly they should know better.
Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México