On 09/17/2014 09:38 AM, Risto Vaarandi wrote:
> 2014-09-16 17:58 GMT+03:00 Eric V. Smith <e...@trueblade.com
> <mailto:e...@trueblade.com>>:
>
> I run multiple copies of sec in order to independently monitor multiple
> log files. I'm moving to Fedora 20, and I'd like to run sec from systemd
> instead of using init.d shell scripts.
>
> Fedora (and all other distros I've seen) provide a sample sec.service
> file that just runs a single instance of sec.
>
> I think what I need to do is copy the supplied sec.service once for each
> instance of sec I want to run, and modify it to have the specific
> parameters I want. Then I'd never start sec.service itself, but only
> start my copied (and renamed) service files. I don't think using systemd
> "instantiated services" (aka templates) buys me anything, because I
> can't individually control the parameters to each sec instance with
> enough granularity.
>
> Anyway, I'm just asking here to see if anyone has given this any
> thought, and maybe came to a different conclusion. I've searched the
> archives, and while there's some systemd chatter, I couldn't find
> anything talking about systemd and multiple sec instances.
>
> Thanks.
> Eric.
>
>
> I have to acknowledge that I am not an expert of systemd, but when
> googling I have discovered a relevant page about the topic:
> http://zero-knowledge.org/post/92
> It follows your idea of setting up several systemd service files, and it
> appears systemd has some builtin support for this. Following the
> suggestions from the above page, I copied sec.service file to
> sec@my.service, and edited the latter by adding %I variable to relevant
> places:
>
> [Unit]
> Description=Simple Event Correlator script to filter log file entries
> After=syslog.target
>
> [Service]
> Type=forking
> PIDFile=/run/sec-%I.pid
> ExecStart=/usr/bin/sec -detach -pid=/run/sec-%I.pid
> -conf=/etc/sec/*.sec-%I -input=/var/log/messages -log=/var/log/sec-%I
> -intevents
>
> [Install]
> WantedBy=multi-user.target
>
> I also copied sec@my.service to sec@my2.service, and when issuing the
> following commands
>
> systemctl start sec@my2
> systemctl start sec@my
>
> these processes appear in the process table:
>
> root 19842 1 0 16:22 ? 00:00:00 /usr/bin/perl -w
> /usr/bin/sec -detach -pid=/run/sec-my2.pid -conf=/etc/sec/*.sec-my2
> -input=/var/log/messages -log=/var/log/sec-my2 -intevents
> root 19850 1 0 16:22 ? 00:00:00 /usr/bin/perl -w
> /usr/bin/sec -detach -pid=/run/sec-my.pid -conf=/etc/sec/*.sec-my
> -input=/var/log/messages -log=/var/log/sec-my -intevents
>
> Also, when doing systemctl start sec, a third process will be started
> with default parameters from sec.service. So it seems to me that your
> idea about having several files is supported by systemd. Also, if you
> manage to use %I for describing all instance specific command line
> options, you can have just one real file to edit, while additional sec
> instance can be set up by creating a symbolic (or hard) link to this file.
>
> However, maybe there are some experienced systemd fans in this list who
> would be able to describe one-file-no-symlinks approach for handling the
> issue...
>
> kind regards,
> risto
>
>
Thanks, risto.
My problem is that I need to parameterize the input filename, so the %I
stuff won't work for me. I need one instance to read /var/log/messages,
and another to read /var/log/secure.
So I think I'm going to create sec-1.service, sec-2.service, etc., each
with the parameters I want to use. And I'll probably disable ("mask", in
systemd-speak) the stock sec.service so it will never run.
I'm generating these sec-1.service, sec-2.service files from a
puppet-like tool, so managing them isn't a big deal for me.
It just occurs to me that another way to do this is to have an
EnvironmentFile= configuration line (which specifies a filename that
contains environment variables, like /etc/sysconfig/sec), and maybe I
could specify the input files as -input=${INPUT_FILENAME_%I}. I'll have
to play with how systemd expands %-variables and environment variables.
Then I could in fact use the %I multiple instance mode, which would save
me some hassle on starting the services. I'll report back what I find.
Eric.
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
