2

I'm trying to learn about rsyslog. On one of my linux boxes, I think that rsyslog has been configured to run through systemd based on this output:

>systemctl status rsyslog
rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)
   Active: active (running) since Tue 2017-01-10 11:28:07 PST; 3 months 19 days ago
 Main PID: 954 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           L954 /sbin/rsyslogd -n

>ps ax | grep syslog
  954 ?        Ssl    6:22 /sbin/rsyslogd -n

On the other linux box, though, systemv (systemctl is not present) seems unaware that rsyslogd is running:

[root@box ~]# service --status-all | grep -i syslog 2>&1
[root@box ~]# ps ax | grep -i syslog
 7866 ?        Sl     1:49 /sbin/rsyslogd -n -c5 -i /var/run/syslogd.pid

Why this disparity?

On the second box, is the fact that rsyslogd is running but not "found" by service evidence that it was spawned "manually" from the command-line and not configured through one of service's init.d scripts? (Sorry if my terminology is primitive).

What I actually wanted to achieve was: on the second box, I wanted to restart rsyslog, and I expected to do so by running something like service rsyslog restart. But not finding rsyslog when I ran service --status-all led me down this detour.

Box 1 configuration:

>uname -a
Linux box1 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 20 (Heisenbug)
Release:        20
Codename:       Heisenbug

Box 2 configuration:

Linux box2 2.6.37+ #2 Tue Apr 18 03:07:09 PDT 2017 armv7l GNU/Linux
Improve this question
9
  • What are the Linux distributions and versions of box1 and box2? Commented May 2, 2017 at 4:48
  • @TopHat - Updated post with box 1 distro. On box 2, I tried all methods for finding distro that google led me to: 1) uname -r (output did not have distro info), 2) lsb_release -a (command not found), 3) cat /proc/version (output did not have distro info), 4) cat /etc/*-release (file not found), 5) cat /etc/issue (file not found), 6) dmesg (I could not find a distro name in the output). So I couldn't get distro information on box 2 I'm afraid. Commented May 2, 2017 at 17:34
  • Interesting. So I'd expect rsyslog to be a service and accessible with older systems via the service command and newer systems with the systemctl command. Box1 is doing what I'd expect. I'm not sure how to try and replicate with box2 since we don't know the distro and version. :( If box2 uses rpm you could see if you can find the package of rsyslog in use with rpm -qa | grep rsyslog. If it was built from source then it won't show up with that command and that could explain why it doesn't have a service script. Commented May 2, 2017 at 20:40
  • @TopHat box2 isn't being amenable to investigation: when I tried rpm -qa | grep rsyslog, I got rpm usage text, as though it doesn't recognize the argument. This may be of interest: that usage text says BusyBox v1.18.4 - I wonder if that reveals the Linux distro? Commented May 2, 2017 at 21:20
  • I think BusyBox is likely just a package. Does this work better? rpm -q rsyslog It may return with nothing. If it does return you could try rpm -q --info rsyslog for more information. We could also try running rpm on a more obviously installed package to try and glean OS information. Such as: rpm -q --info bash The "Vendor" would be a good item to check if it returns output Commented May 2, 2017 at 21:39

1 Answer 1

Reset to default
1

Not from the command line, but perhaps from another initialization script. In the bad old days, a command like 

 $ sudo bash -c "find / -xdev -type f -print0 -size -1M | xargs -0 grep rsyslog"

or, more likely

$ sudo bash
# find / -xdev -type f -print0 -size -1M | xargs -0 grep rsyslog

will go through all the files on the system looking for plain files that contain the desired string. The -mount option on find keeps it out of /proc, and these days grep is smart enough that it will note when the file appears to be a binary file that contains the string. -print0 and the -0 option to xargs work together and insure that files with odd characters, spaces, for example, which might otherwise confuse the parser, are properly dealt with. And "-size -1M" insures that only files that are one megabyte or smaller are looked at - files that are larger than that are not likely what you are interested - rsyslog will most likely be started from a script.

There is one other possibility, of course, and that is that the program is started remotely. I can easily imagine someone starting rsyslog from an ssh script that is tied to a particular key, that does only that thing, it might not even let you get a shell, the point of this being that you run syslogd when the machine that is supposed to receive the syslogs is there to take them.

A command like pstree can show you what is what's child, and while it is easily possible to get out from under your parent so that you are inherited by init,

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.