1

If executed manually with sudo, the script does its job.

#!/bin/bash
echo "Script executed at $(date)" >> /var/log/realtimesync.log
echo
/opt/FreeFileSync/RealTimeSync /mnt/harddrive/SWbackup/RealTimeSync/BatchRun.ffs_batch &
echo "The return value is $?" >> /var/log/realtimesync.log

if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
    echo "Script is being executed." >>/var/log/realtimesync.log
else
    echo "Script is being sourced."
fi

echo 
echo 
echo 
echo 
echo 
echo 

In order to execute the script as a root at startup I used systemd, configuring a systemd service unit.I created a systemd Service File:

sudo nano /etc/systemd/system/realtimesync.service



[Unit]

Description=realtimesync is executed and the DATA folder are synchronised between the hard drive and the external hard drive
After=network.target
[Service]

ExecStart=/mnt/harddrive/SWbackup/scripts/realtimesync.sh
User=root
Type=oneshot
RemainAfterExit=true
[Install]
WantedBy=multi-user.target

Then I reoladed and enabled the service

sudo systemctl daemon-reload
sudo systemctl enable realtimesync.service

Finally I started the service

sudo systemctl start realtimesync.service

After rebooting the script looks like to be executed but the software does not keep running. Somehow is like the process has been killed at some point. Any suggestions and how to keep it running?

EDIT: According to the messages I modified my script with the software execution not being run in background:

#!/bin/bash
echo "Script executed at $(date)" >> /var/log/realtimesync.log
echo
/opt/FreeFileSync/RealTimeSync /mnt/harddrive/SWbackup/RealTimeSync/BatchRun.ffs_batch

I also updated the Service File to change to Type=simple:

[Unit]

Description=realtimesync is executed and the DATA folder are synchronised between the hard drive and the external hard drive
After=network.target
[Service]

ExecStart=/mnt/harddrive/SWbackup/scripts/realtimesync.sh
User=root
Type=simple
[Install]
WantedBy=multi-user.target

However the software RealTimeSync is not running after reboot.

EDIT2: I updated my /etc/systemd/system/realtimesync.service

[Unit]

Description=realtimesync is executed and the DATA folder are synchronised between the hard drive and the external hard drive
After=network.target
[Service]

ExecStart=/opt/FreeFileSync/RealTimeSync /mnt/harddrive/SWbackup/RealTimeSync/BatchRun.ffs_batch
User=root
Type=simple
[Install]
WantedBy=multi-user.target

It is still nor running, but now there are logs:

× realtimesync.service - realtimesync is executed and the DATA folder are synchronised between the hard drive and the external hard drive
     Loaded: loaded (/etc/systemd/system/realtimesync.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2025-08-19 20:35:31 CEST; 53min ago
   Duration: 36ms
 Invocation: 6e10d64335bd4e68ae166bde84483dc2
    Process: 3879 ExecStart=/opt/FreeFileSync/RealTimeSync /mnt/harddrive/SWbackup/RealTimeSync/BatchRun.ffs_batch (code=exited, status=255/EXCEPTION)
   Main PID: 3879 (code=exited, status=255/EXCEPTION)
   Mem peak: 1.9M
        CPU: 15ms

Aug 19 20:35:31 debian systemd[1]: Started realtimesync.service - realtimesync is executed and the DATA folder are synchronised between the hard drive and the external hard drive.
Aug 19 20:35:31 debian RealTimeSync[3879]: Authorization required, but no authorization protocol specified
Aug 19 20:35:31 debian RealTimeSync[3879]: 20:35:31: Error: Unable to initialize GTK+, is DISPLAY set properly?
Aug 19 20:35:31 debian systemd[1]: realtimesync.service: Main process exited, code=exited, status=255/EXCEPTION
Aug 19 20:35:31 debian systemd[1]: realtimesync.service: Failed with result 'exit-code'.

There are here info about this error

Unable to initialize GTK+, is DISPLAY set properly?

Overall, I cannot run the software as a root. The problem is that the software only works if executed as a root probably because it uses data that belongs to root. It was not straightforward to change the ownership of this data. That is why I opened this question.

12
  • 1
    I'm not sure what your script does, but is oneshot really the type you need? Commented Aug 19 at 15:29
  • 1
    TBH I don't understand why this needs to be a script. Even if you want a script for some personal use, the systemd service should just be executing /opt/FreeFileSync/RealTimeSync /mnt/harddrive/SWbackup/RealTimeSync/BatchRun.ffs_batch directly as a Type=simple service. The rest of the script doesn't do anything useful for systemd services. Commented Aug 19 at 15:36
  • 1
    When you run a program in the background with &, you can't get its exit status with $? since the script doesn't wait for it to exit. Commented Aug 19 at 15:37
  • @MarcusMüller I decided to use the type "oneshot" to use "RemainAfterExit=true" in order to keep the first process active. I thought that maybe the command that runs the software is killed with the "Type=simple". I will give it a try with the "Type=simple" I will remove the "RemainAfterExit=true". Commented Aug 19 at 16:29
  • 2
    @birdman not quite what I had in mind! Instead of ExecStart=/mnt/harddrive/SWbackup/scripts/realtimesync.sh I would have just used ExecStart=/opt/FreeFileSync/RealTimeSync /mnt/harddrive/SWbackup/RealTimeSync/BatchRun.ffs_batch . That way, you get all the output of that program in your journalctl log, and can figure out what goes wrong. Your whole manual logging in that script is pretty counter-productive! Your system brings much better logging tools :) Commented Aug 19 at 17:29

1 Answer 1

3

Finally I changed the systemd running mode to the user mode. Because the system mode is launched before the user log into his session and therefore there is no praphical interface. That is why the error

Unable to initialize GTK+, is DISPLAY set properly?

  1. I moved the service file from /etc/systemd/system/Testing1.service /etc/systemd/user/ to /etc/systemd/user

  2. Reload systemd: sudo systemctl daemon-reload

  3. Finally start the service as a user:

    systemctl --user start realtimesync.service

At the beginning the software only worked if run with sudo due to permission issues of writing files in the external hard drive which was mounted as a type ntfs. After changing the mount type to ntf-3g, I was able to modify the data in the external hard drive as a standard user. It looks like if you use ntfs type in your fstab it will mount your NTFS as read only, whereas The ntfs-3g is the newer FUSE driver and will mount the partitions as read-write.

2
  • 1
    Note that there could still be race condition that the service is started before the X server / Wayland Compositor is started (or that the env vars are imported to the user manager's). With at least some setup it is better to have a systemctl start command in some startup script such as .xinitrc instead of enabling the service (i.e. pull it with some target), especially if you are not using some DE that notifies systemd that by some means (e.g. graphical-session.target). Commented Aug 20 at 7:31
  • @TomYan I guess I had actually this problem, that the service is started before the X server. I added the, in this answer [1] suggested entries, under [Unit] and [Install] and now seems to work fine. [1]: unix.stackexchange.com/questions/585054/… Commented Aug 20 at 8:02

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.