tengel/petrified
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

update README/man for new systemd things

Browse source
This commit is contained in:
tengel 2024-03-20 09:32:36 -05:00
parent 8843922cee
commit 31237bf367
2 changed files with 37 additions and 49 deletions
Download patch file Download diff file Expand all files Collapse all files

38
README.pod
View file

@ -63,35 +63,31 @@ configuration.
user: systemctl --user --now enable petrified.timer
systemctl --user list-timers petrified.timer
A target of C<petrified.target> is pre-configured if multuple interfaces are
to be configured; per standard systemd methodology the existing service unit
is first customized either at the system or user level, then all custom units
and the timer are started/enabled.
For example at the system level if two interfaces are to be used, it might
look like:
Multiple interfaces can be configured using the standard systemd semantics
of unit overrides, which might look like this:
/etc/systemd/system/petrified-iface1.service
--------------------------------------------
.include /usr/lib/systemd/system/petrified.service
[Service]
ExecStart=
ExecStart=/usr/bin/petrified -c /etc/petrified-iface1.conf
/etc/systemd/system/petrified-iface2.service
The first C<ExecStart=> is intentional, needed to negate the existing value
first before defining a new value (systemd design for ExecStart override).
A corresponding new timer is then created to call this unit as it may be
desireable to run different interfaces on different time schedules, which
might then look like this:
/etc/systemd/system/petrified-iface1.timer
--------------------------------------------
.include /usr/lib/systemd/system/petrified.service
[Service]
ExecStart=/usr/bin/petrified -c /etc/petrified-iface2.conf
.include /usr/lib/systemd/system/petrified.timer
[Timer]
Unit=petrified-iface1.service
OnCalendar=0/8:00:00
Then both customized service units are enabled, as well as the timer unit:
systemctl --now enable petrified-iface1.service
systemctl --now enable petrified-iface2.service
systemctl --now enable petrified.timer
The per user configuration looks the same and is usually configured in the
F<~/.config/systemd/user/> space in the home directory. The provided units
for the service contain the connection to the target pre-configured.
This timer will now operate the new custom unit when it's enabled.
=over 4
@ -101,8 +97,6 @@ L<http://www.freedesktop.org/software/systemd/man/systemd.unit.html>
L<http://www.freedesktop.org/software/systemd/man/systemd.timer.html>
L<http://www.freedesktop.org/software/systemd/man/systemd.target.html>
=back
=head1 DEPENDENCIES

48
petrified.1
View file

@ -129,7 +129,7 @@
.\" ========================================================================
.\"
.IX Title "PETRIFIED 1"
.TH PETRIFIED 1 "2017-09-29" "petrified 2.0.0" "Petrified Manual"
.TH PETRIFIED 1 "2017-11-19" "petrified 2.0.0" "Petrified Manual"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
@ -191,46 +191,40 @@ configuration.
\& systemctl \-\-user list\-timers petrified.timer
.Ve
.PP
A target of \f(CW\*(C`petrified.target\*(C'\fR is pre-configured if multuple interfaces are
to be configured; per standard systemd methodology the existing service unit
is first customized either at the system or user level, then all custom units
and the timer are started/enabled.
Multiple interfaces can be configured using the standard systemd semantics
of unit overrides, which might look like this:
.PP
For example at the system level if two interfaces are to be used, it might
look like:
.PP
.Vb 5
.Vb 6
\& /etc/systemd/system/petrified\-iface1.service
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\& .include /usr/lib/systemd/system/petrified.service
\& [Service]
\& ExecStart=
\& ExecStart=/usr/bin/petrified \-c /etc/petrified\-iface1.conf
\&
\& /etc/systemd/system/petrified\-iface2.service
.Ve
.PP
The first \f(CW\*(C`ExecStart=\*(C'\fR is intentional, needed to negate the existing value
first before defining a new value (systemd design for ExecStart override).
.PP
A corresponding new timer is then created to call this unit as it may be
desireable to run different interfaces on different time schedules, which
might then look like this:
.PP
.Vb 6
\& /etc/systemd/system/petrified\-iface1.timer
\& \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
\& .include /usr/lib/systemd/system/petrified.service
\& [Service]
\& ExecStart=/usr/bin/petrified \-c /etc/petrified\-iface2.conf
\& .include /usr/lib/systemd/system/petrified.timer
\& [Timer]
\& Unit=petrified\-iface1.service
\& OnCalendar=0/8:00:00
.Ve
.PP
Then both customized service units are enabled, as well as the timer unit:
.PP
.Vb 3
\& systemctl \-\-now enable petrified\-iface1.service
\& systemctl \-\-now enable petrified\-iface2.service
\& systemctl \-\-now enable petrified.timer
.Ve
.PP
The per user configuration looks the same and is usually configured in the
\&\fI~/.config/systemd/user/\fR space in the home directory. The provided units
for the service contain the connection to the target pre-configured.
This timer will now operate the new custom unit when it's enabled.
.IP "\fBSee also:\fR" 4
.IX Item "See also:"
<http://www.freedesktop.org/software/systemd/man/systemd.unit.html>
.Sp
<http://www.freedesktop.org/software/systemd/man/systemd.timer.html>
.Sp
<http://www.freedesktop.org/software/systemd/man/systemd.target.html>
.SH "DEPENDENCIES"
.IX Header "DEPENDENCIES"
.Vb 7