Jonathan Callen posted on Sat, 15 Mar 2014 02:21:38 -0400 as excerpted:
> The correct way to do this is to create the file with contents like the
> following:
>
> [Service]
> ExecStart=
> ExecStart=/usr/bin/gpm --my --options
>
> The first ExecStart= line is a special case that tells systemd to unset
> the ExecStart parameter completely so you can override it (instead of
> adding additional commands to run on startup).
Thanks. I'll try that.
(I had thought about it as I had read something to that effect, but I
only thought it applied to resetting accumulatives, and save for oneshot
types, execstart must be single-shot, thus the problem in the first
place. But if you say it works... and this /will/ be my first time using
the reset technique.)
But I'm rebooted with openrc ATM. I needed to test if the /var/tmp bind-
mount to the tmpfs on /tmp would work in openrc or not (it did), and
decided while I was at it that I needed a break from worrying about
systemd, to get some other things done, including an emerge update on top
of something I was familiar with, since I hadn't updated in over a week,
due to focusing on getting systemd working.
Meanwhile, my next big systemd-land hump to get over is deciding whether
I want to reactivate syslog-ng as my general purpose logger (with journald
set storage=volatile, as I set that temporarily while I figured things
out), or whether I want to unmerge syslog-ng and switch entirely to
journald, setting storage=persistent.
If I switch to journald I'll have to seriously investigate filtering, as
among other things I've one script that does an sudo every 10 seconds
(IIRC), and while I have sudo's logging already configured separately,
there's still an sudo-related pamd entry spit to syslog for each of
those. I have syslog-ng set to simply dump those but I noticed them in
journald when I set it to output to tty12, too -- when that script was
running the tty12 output was unusable as it was all but 100% noise from
that. I was glad I had storage=volatile set!
The other alternative, since that 10-second sudo is actually log related
too (being effectively a /var/log/messages tail to superkaramba when I'm
in X/kde), is to figure out how to do something similar using journald,
without the sudo but without giving the graphical user unlimited log-
checking privs (sudo is setup to allow that one very specific command,
not anything else, presently).
But regardless, I'll need to learn how to manage filtering in journald
anyway; this is simply the first and most pressing reason to do so, not
the only one.
And of course if I switch to journald I'll need to adjust that script
anyway... ideally by configuring journald to write an unprivileged tail
log (say 20 lines or whatever) to somewhere on tmpfs so all I'll need to
do in superkaramba is to have it output that file directly, avoiding the
script entirely.
IOW, now I have to basically repeat for journald the same process I did
for systemd in general, figure out what it would take to convert to it,
and whether I actually want to, or whether I'd prefer to keep journald
set to storage=volatile and simply forward to syslog-ng, mostly keeping
the existing (somewhat advanced for a single host) syslog-ng
configuration in place.
I'm thinking about just punting for now, activating syslog-ng pretty much
with the existing config (changed my existing syslog-ng filters as
necessary to deal with any systemd specific logging) in systemd, and
keeping journald set storage=volatile.
But that's why I'm taking a rest from systemd ATM, back on openrc, to
study journald at my leisure now that I have systemd itself more or less
setup and am thus familiar with /its/ workings, and then give my
subconscious time to weigh the syslog/journal options and come to its own
decision, before I make the conscious decision and get down and dirty in
the config, implementing it.
Meanwhile, with a bit of luck gentoo/systemd and the various upstreams
will work thru the systemd-209+ networking and dracut related issues, and
I'll have a more permanent networkd based systemd-network service config
to replace my current temporary network.service hack, by the time I get
the journald stuff worked out and hopefully switch over to systemd more
or less permanently.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
> The correct way to do this is to create the file with contents like the
> following:
>
> [Service]
> ExecStart=
> ExecStart=/usr/bin/gpm --my --options
>
> The first ExecStart= line is a special case that tells systemd to unset
> the ExecStart parameter completely so you can override it (instead of
> adding additional commands to run on startup).
Thanks. I'll try that.
(I had thought about it as I had read something to that effect, but I
only thought it applied to resetting accumulatives, and save for oneshot
types, execstart must be single-shot, thus the problem in the first
place. But if you say it works... and this /will/ be my first time using
the reset technique.)
But I'm rebooted with openrc ATM. I needed to test if the /var/tmp bind-
mount to the tmpfs on /tmp would work in openrc or not (it did), and
decided while I was at it that I needed a break from worrying about
systemd, to get some other things done, including an emerge update on top
of something I was familiar with, since I hadn't updated in over a week,
due to focusing on getting systemd working.
Meanwhile, my next big systemd-land hump to get over is deciding whether
I want to reactivate syslog-ng as my general purpose logger (with journald
set storage=volatile, as I set that temporarily while I figured things
out), or whether I want to unmerge syslog-ng and switch entirely to
journald, setting storage=persistent.
If I switch to journald I'll have to seriously investigate filtering, as
among other things I've one script that does an sudo every 10 seconds
(IIRC), and while I have sudo's logging already configured separately,
there's still an sudo-related pamd entry spit to syslog for each of
those. I have syslog-ng set to simply dump those but I noticed them in
journald when I set it to output to tty12, too -- when that script was
running the tty12 output was unusable as it was all but 100% noise from
that. I was glad I had storage=volatile set!
The other alternative, since that 10-second sudo is actually log related
too (being effectively a /var/log/messages tail to superkaramba when I'm
in X/kde), is to figure out how to do something similar using journald,
without the sudo but without giving the graphical user unlimited log-
checking privs (sudo is setup to allow that one very specific command,
not anything else, presently).
But regardless, I'll need to learn how to manage filtering in journald
anyway; this is simply the first and most pressing reason to do so, not
the only one.
And of course if I switch to journald I'll need to adjust that script
anyway... ideally by configuring journald to write an unprivileged tail
log (say 20 lines or whatever) to somewhere on tmpfs so all I'll need to
do in superkaramba is to have it output that file directly, avoiding the
script entirely.
IOW, now I have to basically repeat for journald the same process I did
for systemd in general, figure out what it would take to convert to it,
and whether I actually want to, or whether I'd prefer to keep journald
set to storage=volatile and simply forward to syslog-ng, mostly keeping
the existing (somewhat advanced for a single host) syslog-ng
configuration in place.
I'm thinking about just punting for now, activating syslog-ng pretty much
with the existing config (changed my existing syslog-ng filters as
necessary to deal with any systemd specific logging) in systemd, and
keeping journald set storage=volatile.
But that's why I'm taking a rest from systemd ATM, back on openrc, to
study journald at my leisure now that I have systemd itself more or less
setup and am thus familiar with /its/ workings, and then give my
subconscious time to weigh the syslog/journal options and come to its own
decision, before I make the conscious decision and get down and dirty in
the config, implementing it.
Meanwhile, with a bit of luck gentoo/systemd and the various upstreams
will work thru the systemd-209+ networking and dracut related issues, and
I'll have a more permanent networkd based systemd-network service config
to replace my current temporary network.service hack, by the time I get
the journald stuff worked out and hopefully switch over to systemd more
or less permanently.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman