Gary Roach:
I found some script for rsync to write rsyincd.socket
andrsyncd.service and put them in /lib/systemd/system directory.
That was wrong. Locally made, non-packaged, unit files belong in
/etc/systemd/system/ . /lib/systemd/ is the province of
package-controlled stuff, which your hand-created file is not. You can
move the unit files now, and tell systemd to find them in their new
locations with
> systemctl daemon-reload
Gary Roach:
No mentionwas made of the soft link that had to be put in the
proper/etc/systemd/system subdirectory.
And rightly so. There are standard systemd commands for enabling and
disabling units. Hand-creating the symbolic links is not the first
resort. You should have run
> systemctl preset rsync.socket
and very likely then
> systemctl is-enabled rsync.socket && systemctl start rsync.socket
These are the commands to learn, not the manual creation of symbolic links.
Have a systemd unit for BackupPC, which should go in
/etc/systemd/system/backuppc.service and which you
start/stop/preset/disable with the conventional systemd commands
(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Managing_Services_with_systemd.html).
> [Unit]
> Description=BackupPC server, a high-performance enterprise-grade
system for backing up PCs
> After=network.target
>
> [Service]
> Type=simple
> User=backuppc
> # Ubuntu/Debian convention, discouraged by systemd developers:
> EnvironmentFile=-/etc/default/backuppc
> ExecStart=/usr/share/backuppc/bin/BackupPC
>
> [Install]
> WantedBy=multi-user.target
Bonus technical details that (as you say) might go over your head right now:
Note that this is different to Jóhann B. Guðmundsson's service unit that
he did for Fedora. The -d option to BackupPC that he had back in 2012
is wrong for systemd use. Like so many softwares in the real world
BackupPC does not _actually_ speak the systemd forking readiness
protocol with its "daemonization" mechanism. It isn't ready at the
point that it forks and exits. Like with so many softwares in the real
world, the right thing to do is to turn the bogus "daemonization" off
entirely, as one already gets what it is trying to achieve for free
under upstart, systemd, runit, nosh, perp, and other systems.
Other problems that you'll hit one day, which systemd, runit, nosh et
al. do for free and which BackupPC has hand-rolled mechanisms to do
quite badly, are the logging and the server sockets. BackupPC logs
straight to a file. It's not auto-rotated or size capped at all; it is
not available right from the "systemctl status" command; and ad hoc
shenanighans are required to rotate it. Again, the right thing to do in
this post-1997 service management world would be to just turn this
mechanism off, and rely upon the capturing of standard output/error into
a log that systemd, nosh, runit, perp et al. already do. You might like
to lobby the BackupPC developers for a simple code change to add a
"--log-to-stdout" option, or some such, that simply disables the bad
hand-rolled mechanism entirely and duplicates LOG from standard output.
BackupPC also does not have the capability for inheriting its listening
socket(s), which would allow one to have a backuppc.socket unit for
configuring its socket(s) and enabling early socket opening. This,
however, is a slightly more complex code change.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55658053.9040...@ntlworld.com
