Return to Answer

Reasons I am running Unison as a cron job rather than with -repeat (presumably as a systemd service)

I would actually suggest that systemd is a perfect fit for when you want "cron but single instance". You don't need to keep it as a long-running service - you can use systemd timers in a cron-like manner while taking advantage of systemd to manage instances.

1. Define a systemd service of Type=exec. This service will be considered active until the process exits. Use the same command line you currently use with cron.
2. Define a systemd timer to start the service previously defined. This can be set to happen either at a clock (calendar) time (OnCalendar=), or after a period (OnUnitActiveSec= would be relative to last service start time, OnUnitInactiveSec= would be relative to last service stop time). Personally, I like calendar since it's more predictable and won't drift.
3. Enable and start the timer. Don't enable the service, you don't want it running independently of the timer.
4. The timer will start the service on schedule. The service manager will ensure only one instance of the service is active. If the service is still running when the timer next fires, it will simply not do anything.

Sample unit files to run Unison as SOMEUSER with profile SOMEPROFILE (except for their .service and .timer suffixes, both unit files must have the same name):

unison.service:

[Unit]
Description=Unison SOMEUSER@SOMEPROFILE
After=network.target

[Service]
User=SOMEUSER
# Type=exec is not supported on all versions
Type=single
# may be relative to the service's root directory specified by RootDirectory=, or the special value "~"
WorkingDirectory=~
# systemd may insist on an absolute path for the executable
# Run unison with -terse to prevent cluttering the system journal
ExecStart=/usr/bin/unison -auto -batch -ui text -terse SOMEPROFILE
Restart=no

unison.timer (fires daily at 13:37; for OnCalendar syntax see man 5 systemd.time, section Calendar Events):

[Unit]
Description=Daily unison SOMEUSER@SOMEPROFILE

[Timer]
OnCalendar=*-*-* 13:37

[Install]
WantedBy=timers.target

Drop these two unit files into /etc/systemd/system/, then run:

sudo systemctl enable unison.timer
sudo systemctl start unison.timer

You can test the setup by running sudo systemctl start unison.service – this requires only the service unit, not the timer unit. This is also a way to start sync out of schedule. Unison output will be written to the system journal with unison as a tag.

Reasons I am running Unison as a cron job rather than with -repeat (presumably as a systemd service)

I would actually suggest that systemd is a perfect fit for when you want "cron but single instance". You don't need to keep it as a long-running service - you can use systemd timers in a cron-like manner while taking advantage of systemd to manage instances.

1. Define a systemd service of Type=exec. This service will be considered active until the process exits. Use the same command line you currently use with cron.
2. Define a systemd timer to start the service previously defined. This can be set to happen either at a clock (calendar) time (OnCalendar=), or after a period (OnUnitActiveSec= would be relative to last service start time, OnUnitInactiveSec= would be relative to last service stop time). Personally, I like calendar since it's more predictable and won't drift.
3. Enable and start the timer. Don't enable the service, you don't want it running independently of the timer.
4. The timer will start the service on schedule. The service manager will ensure only one instance of the service is active. If the service is still running when the timer next fires, it will simply not do anything.

Sample unit files to run Unison as SOMEUSER with profile SOMEPROFILE (except for their .service and .timer suffixes, both unit files must have the same name):

unison.service:

[Unit]
Description=Unison SOMEUSER@SOMEPROFILE
After=network.target

[Service]
User=SOMEUSER
# Type=simple may be used on older versions
Type=exec
# may be relative to the service's root directory specified by RootDirectory=, or the special value "~"
WorkingDirectory=~
# systemd may insist on an absolute path for the executable
# Run unison with -terse to prevent cluttering the system journal
ExecStart=/usr/bin/unison -auto -batch -ui text -terse SOMEPROFILE
Restart=no

unison.timer (fires daily at 13:37; for OnCalendar syntax see man 5 systemd.time, section Calendar Events):

[Unit]
Description=Daily unison SOMEUSER@SOMEPROFILE

[Timer]
OnCalendar=*-*-* 13:37

[Install]
WantedBy=timers.target

Drop these two unit files into /etc/systemd/system/, then run:

sudo systemctl enable unison.timer
sudo systemctl start unison.timer

You can test the setup by running sudo systemctl start unison.service – this requires only the service unit, not the timer unit. This is also a way to start sync out of schedule. Unison output will be written to the system journal with unison as a tag.

Reasons I am running Unison as a cron job rather than with -repeat (presumably as a systemd service)

I would actually suggest that systemd is a perfect fit for when you want "cron but single instance". You don't need to keep it as a long-running service - you can use systemd timers in a cron-like manner while taking advantage of systemd to manage instances.

1. Define a systemd service of Type=exec. This service will be considered active until the process exits. Use the same command line you currently use with cron.
2. Define a systemd timer to start the service previously defined. This can be set to happen either at a clock (calendar) time (OnCalendar=), or after a period (OnUnitActiveSec= would be relative to last service start time, OnUnitInactiveSec= would be relative to last service stop time). Personally, I like calendar since it's more predictable and won't drift.
3. Enable and start the timer. Don't enable the service, you don't want it running independently of the timer.
4. The timer will start the service on schedule. The service manager will ensure only one instance of the service is active. If the service is still running when the timer next fires, it will simply not do anything.

Sample unit files to run Unison as SOMEUSER with profile SOMEPROFILE (except for their .service and .timer suffixes, both unit files must have the same name):

unison.service:

[Unit]
Description=Unison SOMEUSER@SOMEPROFILE
After=network.target

[Service]
User=SOMEUSER
Type=exec
WorkingDirectory=/path/to/home/dir
ExecStart=/path/to/unison -auto -batch -ui text SOMEPROFILE
Restart=no

unison.timer (fires daily at 13:37; for OnCalendar syntax see man 5 systemd.time, section Calendar Events):

[Unit]
Description=Daily unison SOMEUSER@SOMEPROFILE

[Timer]
OnCalendar=*-*-* 13:37

[Install]
WantedBy=timers.target

Drop these two unit files into /etc/systemd/system/, then run:

sudo systemctl enable unison.timer
sudo systemctl start unison.timer

Reasons I am running Unison as a cron job rather than with -repeat (presumably as a systemd service)

I would actually suggest that systemd is a perfect fit for when you want "cron but single instance". You don't need to keep it as a long-running service - you can use systemd timers in a cron-like manner while taking advantage of systemd to manage instances.

1. Define a systemd service of Type=exec. This service will be considered active until the process exits. Use the same command line you currently use with cron.
2. Define a systemd timer to start the service previously defined. This can be set to happen either at a clock (calendar) time (OnCalendar=), or after a period (OnUnitActiveSec= would be relative to last service start time, OnUnitInactiveSec= would be relative to last service stop time). Personally, I like calendar since it's more predictable and won't drift.
3. Enable and start the timer. Don't enable the service, you don't want it running independently of the timer.
4. The timer will start the service on schedule. The service manager will ensure only one instance of the service is active. If the service is still running when the timer next fires, it will simply not do anything.

Sample unit files to run Unison as SOMEUSER with profile SOMEPROFILE (except for their .service and .timer suffixes, both unit files must have the same name):

unison.service:

[Unit]
Description=Unison SOMEUSER@SOMEPROFILE
After=network.target

[Service]
User=SOMEUSER
# Type=exec is not supported on all versions
Type=single
# may be relative to the service's root directory specified by RootDirectory=, or the special value "~"
WorkingDirectory=~
# systemd may insist on an absolute path for the executable
# Run unison with -terse to prevent cluttering the system journal
ExecStart=/usr/bin/unison -auto -batch -ui text -terse SOMEPROFILE
Restart=no

unison.timer (fires daily at 13:37; for OnCalendar syntax see man 5 systemd.time, section Calendar Events):

[Unit]
Description=Daily unison SOMEUSER@SOMEPROFILE

[Timer]
OnCalendar=*-*-* 13:37

[Install]
WantedBy=timers.target

Drop these two unit files into /etc/systemd/system/, then run:

sudo systemctl enable unison.timer
sudo systemctl start unison.timer

You can test the setup by running sudo systemctl start unison.service – this requires only the service unit, not the timer unit. This is also a way to start sync out of schedule. Unison output will be written to the system journal with unison as a tag.

Reasons I am running Unison as a cron job rather than with -repeat (presumably as a systemd service)

I would actually suggest that systemd is a perfect fit for when you want "cron but single instance". You don't need to keep it as a long-running service - you can use systemd timers in a cron-like manner while taking advantage of systemd to manage instances.

1. Define a systemd service of Type=exec. This service will be considered active until the process exits. Use the same command line you currently use with cron.
2. Define a systemd timer to start the service previously defined. This can be set to happen either at a clock (calendar) time (OnCalendar=), or after a period (OnUnitActiveSec= would be relative to last service start time, OnUnitInactiveSec= would be relative to last service stop time). Personally, I like calendar since it's more predictable and won't drift.
3. Enable and start the timer. Don't enable the service, you don't want it running independently of the timer.
4. The timer will start the service on schedule. The service manager will ensure only one instance of the service is active. If the service is still running when the timer next fires, it will simply not do anything.

Sample unit files to run Unison as SOMEUSER with profile SOMEPROFILE (except for their .service and .timer suffixes, both unit files must have the same name):

unison.service:

[Unit]
Description=Unison SOMEUSER@SOMEPROFILE
After=network.target

[Service]
User=SOMEUSER
Type=exec
WorkingDirectory=/path/to/home/dir
ExecStart=/path/to/unison -auto -batch -ui text SOMEPROFILE
Restart=no

unison.timer (fires daily at 13:37; for OnCalendar syntax see man 5 systemd.time, section Calendar Events):

[Unit]
Description=Daily unison SOMEUSER@SOMEPROFILE

[Timer]
OnCalendar=*-*-* 13:37

[Install]
WantedBy=timers.target

Reasons I am running Unison as a cron job rather than with -repeat (presumably as a systemd service)

I would actually suggest that systemd is a perfect fit for when you want "cron but single instance". You don't need to keep it as a long-running service - you can use systemd timers in a cron-like manner while taking advantage of systemd to manage instances.

1. Define a systemd service of Type=exec. This service will be considered active until the process exits. Use the same command line you currently use with cron.
2. Define a systemd timer to start the service previously defined. This can be set to happen either at a clock (calendar) time (OnCalendar=), or after a period (OnUnitActiveSec= would be relative to last service start time, OnUnitInactiveSec= would be relative to last service stop time). Personally, I like calendar since it's more predictable and won't drift.
3. Enable and start the timer. Don't enable the service, you don't want it running independently of the timer.
4. The timer will start the service on schedule. The service manager will ensure only one instance of the service is active. If the service is still running when the timer next fires, it will simply not do anything.

Sample unit files to run Unison as SOMEUSER with profile SOMEPROFILE (except for their .service and .timer suffixes, both unit files must have the same name):

unison.service:

[Unit]
Description=Unison SOMEUSER@SOMEPROFILE
After=network.target

[Service]
User=SOMEUSER
Type=exec
WorkingDirectory=/path/to/home/dir
ExecStart=/path/to/unison -auto -batch -ui text SOMEPROFILE
Restart=no

unison.timer (fires daily at 13:37; for OnCalendar syntax see man 5 systemd.time, section Calendar Events):

[Unit]
Description=Daily unison SOMEUSER@SOMEPROFILE

[Timer]
OnCalendar=*-*-* 13:37

[Install]
WantedBy=timers.target

Drop these two unit files into /etc/systemd/system/, then run:

sudo systemctl enable unison.timer
sudo systemctl start unison.timer