Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instead of our logging use syslog or even journal #92

Open
phracek opened this issue Mar 7, 2016 · 7 comments
Open

Instead of our logging use syslog or even journal #92

phracek opened this issue Mar 7, 2016 · 7 comments
Assignees

Comments

@phracek
Copy link
Contributor

phracek commented Mar 7, 2016

Instead of ssds logging function use syslog or even journal.

@lnykryn: Can you please journalctl command for getting logs? How can we get ssds logs from journal?

@lnykryn
Copy link

lnykryn commented Mar 7, 2016

  1. make sure that your service is wrapped by systemd unit and started through systemd
  2. use the journal API for logging http://0pointer.de/blog/projects/journal-submit.html
    (you could also use the classic syslog functions or even stdout, but the jounral api is preferred)
  3. read your logs through journalctl -u ssds.service

By the way if you have some questions about systemd integration or potential features (socket activation pops up in my mind) feel free to contact me.

@mruprich
Copy link
Collaborator

So if I understand this correctly, the journal is suitable for the server side app because it will probably start on bootup as a daemon and the logging might be useful. But is the journal really usable for client side? The client app will run only for a short time and not much logging is actually needed...

So the question is, should we use journal on server and syslog on client?

@lnykryn
Copy link

lnykryn commented Mar 21, 2016

Well there is no difference. If you use syslog api, the messages will end up in journal anyway.
$ readlink /dev/log
/run/systemd/journal/dev-log
The nice thing about journal api is that you can easily add some metadata to the message. The client will not be run under any systemd unit, so it might be useful to somehow tag it through your own variable.
I would just suggest to stick with one api (journal or syslog) and use it everywhere.

@mruprich
Copy link
Collaborator

Ok thanks. One more question if you don't mind. I'm not that much familiar with systemd usage so I was wondering about the first point where you say "make sure that your service is wrapped by systemd unit". I'm not entirely sure what that means :(

@lnykryn
Copy link

lnykryn commented Mar 21, 2016

That is only related to the server part. Basically it means, have an unit-file and start it through systemd :-)

@mruprich
Copy link
Collaborator

Ok thanks a lot :)

@msekletar
Copy link

In my opinion, it is very important to leave the trace in system log (or other well-known location) that package set on the machine changed.

When using yum admin can later consult output of yum history command. AFAICT, it is not possible to figure out what changed if one uses just plain rpm. Hence to make changes made by ssds client easily discover-able for admins you should log to system log instead of your own log file. If you decide to use journald API instead of plain syslog you will be able to use all the nice things @lnykryn talked about, though in your case just setting syslog identifier should be sufficient.

@mruprich mruprich self-assigned this Mar 31, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants