Mageia forum

I would like to save back copies of the Korganizer calendar file - std.ics for a running week . I've written a script to do this:

Code: Select all

#!/bin/bash
#
NOW=$(date +%a);
   cp /home/(user)/.kde4/share/apps/korganizer/std.ics /home/(user)/CalendarBackup/std_$NOW.ics
exit 0

It works fine in the terminal. I copied it to /etc/init.d; owner is root and it is executable. I then symlinked it to rc0.d and rc6.d using K75 as the prefix (K75calendar_backup.sh). Apparently something more is needed.

Any suggestions would be appreciated.

I have a similar task but I am using systemd for it. If you want to use systemd you may try the following:

1. put your backup script "calendar_backup.sh" in /usr/bin/

2. create a new service "calendar_backup.service" with the following content in /etc/systemd/system:

Code: Select all

[Unit]
Description=calendar backup service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/bin/calendar_backup.sh

[Install]
WantedBy=multi-user.target


3. enable your new service:

Code: Select all

systemctl enable calendar_backup.service


4. reboot your system

Alternatively you may try the following service script:

Code: Select all

[Unit]
Description=calendar backup service
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/bin/calendar_backup.sh

[Install]
WantedBy=reboot.target halt.target poweroff.target


magfan wrote:I have a similar task but I am using systemd for it. If you want to use systemd you may try the following:

1. put your backup script "calendar_backup.sh" in /usr/bin/

From a system administration standpoint I would suggest that it would be better to use /usr/local/bin for custom scripts and whatnot.
The first benefit is you can backup /usr/local/, do a clean install and restore /usr/local/ and you are good to go.
Mixing custom code in /usr/bin will make clean installs plus your changes/additions laborious and you would be wasting backup space/time. with the other possible 3,000+ files. Then there is the chance that a new package has the same name as you script and the next update of that package would wipe out your script.

If you were to look the results of "echo $PATH", you might notice that /usr/local/bin is before /usr/bin. The nice feature about that is whatever you place there super creeds the same file in /usr/bin.

I appreciate everyone's help. I copied the code from both 'systemd' suggestions and followed the directions meticulously. Unfortunately I was unable to get them to work.

I'll probably end up using anacron; messier, but it works.

elviejito wrote:Unfortunately I was unable to get them to work.

So there was no output at all when you run the script, or queried the status via

Code: Select all

systemctl status name_of_service

and there was also not any error message at all?

@bittwister: Thank you for your advice. I have changed my scripts accordingly.

@elviejito: Does your script really run? In my bash I have to adjust "(user)":

Code: Select all

#!/bin/bash
#
NOW=$(date +%a);
   cp /home/$USER/.kde4/share/apps/korganizer/std.ics /home/$USER/CalendarBackup/std_$NOW.ics
exit 0

But be aware that this script does make a backup only for the user who called the script - most likely root. If you want a backup for another user you may try the following change (user = magfan):

Code: Select all

#!/bin/bash
#
NOW=$(date +%a);
   su -c "cp /home/$USER/.kde4/share/apps/korganizer/std.ics /home/$USER/CalendarBackup/std_$NOW.ics" magfan
exit 0

Or, another alternative:

Code: Select all

#!/bin/bash
#
su -c "/usr/local/bin/calendar_backup.sh" magfan
exit 0

Sorry for taking so long to respond.

I have tried both suggested service scripts:
(1)

Code: Select all

[Unit]
Description=calendar backup service
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/local/bin/calendar_backup.sh

[Install]
WantedBy=reboot.target halt.target poweroff.target

(2)

Code: Select all

[Unit]
Description=calendar backup service
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/local/bin/calendar_backup.sh

[Install]
WantedBy=multi-user.target

Here's what displays when running "systemctl status calendar_backup.service" on either:

Code: Select all

[root@localhost jd5]# systemctl status calendar_backup.service
● calendar_backup.service - calendar backup service
   Loaded: loaded (/etc/systemd/system/calendar_backup.service; enabled)
   Active: inactive (dead)

The backup script is owned by root and has permissions 751 and is located in usr/local/bin. No backup copy made.

Any suggestions?

I would suggest you run the script as ExecStart rather than ExecStop.

I am certainly not an expert on systemd, and I really don't know what ExecStop is about. But I do know that the scripts I run on shutdown run fine when I have them in ExecStart.

Loaded: loaded (/etc/systemd/system/calendar_backup.service; enabled)
Active: inactive (dead)

OK, this means that the script is loaded but not doing something right now. That is how it should look like because the service must be loaded to run the backup script just before shutdown. But did you change your backup script? To make a backup for a user named "username" it should look like:

Code: Select all

#!/bin/bash
#
NOW=$(date +%a);
   su -c "cp /home/$USER/.kde4/share/apps/korganizer/std.ics /home/$USER/CalendarBackup/std_$NOW.ics" username
exit 0


The copy command in your script must be executed as a different user than root. If you do not change the user (su -c "..." username) root will try to make a backup of "/home/root/.kde4/share/apps/korganizer/std.ics".

Kudos to jiml8!!!

That worked!

I switched the string after the "=" between ExecStart and ExecStop in the service script.

Thanks.

jiml8 wrote:I am certainly not an expert on systemd, and I really don't know what ExecStop is about.

Just for completeness sake, from the man page:

man systemd.service wrote: ExecStop=
Commands to execute to stop the service started via ExecStart=. This argument takes multiple command lines, following the same scheme as described for ExecStart= above. Use of
this setting is optional. After the commands configured in this option are run, all processes remaining for a service are terminated according to the KillMode= setting (see
systemd.kill(5)). If this option is not specified, the process is terminated immediately when service stop is requested. Specifier and environment variable substitution is
supported (including $MAINPID, see above).

Those would be the commands run when doing systemctl stop foo.service

@elviejito: Which of the two service scripts do you use?

On my system I have two special service scripts. The first one is used to perform preparation tasks while booting (starting with multi-user.target):

Code: Select all

[Unit]
Description=prepare development environment

[Service]
Type=oneshot
ExecStart=/usr/local/bin/prepare_develop.sh

[Install]
WantedBy=multi-user.target


The second one performs clean up tasks right before shutdown:

Code: Select all

[Unit]
Description=clean up development environment
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/clean_develop.sh

[Install]
WantedBy=reboot.target halt.target poweroff.target


Instead of this second service I had used a slightly varied version of the first script (stopping with multi-user.target):

Code: Select all

[Unit]
Description=clean up development environment

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/usr/local/bin/clean_develop.sh

[Install]
WantedBy=multi-user.target


So, if you use a script with "WantedBy=multi-user.target" and put you backup script in "ExecStart" then your backup will be made while booting your system and not during shutdown. For simple backup purposes the difference is maybe not important. But for time consuming full system backups I would definitely choose another target or execution time.

Here is a service I constructed to unmount an iscsi share (and a couple NFS shares, and any fuser filesystems) before shutdown. Supposedly, systemd would handle this for me, but it doesn't work, so I do it explicitly.

Note that this runs before shutdown.target and is wanted by exit.target. I think that exit.target runs ahead of reboot.target, halt.target, or poweroff.target.

Code: Select all

[Unit]
Description = Unmount jssnas iscsi share
Before = shutdown.target
DefaultDependencies = yes

[Service]
ExecStart = /usr/local/bin/unmountNAS

[Install]
WantedBy = exit.target


@jiml8: Thank you for that hint. I will use "exit.target" for some tasks. Except for backups which should not be done every time I reboot my system...

jiml8 wrote:Here is a service I constructed to unmount an iscsi share (and a couple NFS shares, and any fuser filesystems) before shutdown. Supposedly, systemd would handle this for me, but it doesn't work

Just for curiosity, they are mounted with the option _netdev ?

doktor5000 wrote:Just for curiosity, they are mounted with the option _netdev ?

The iscsi share is. The NFS shares are not, but then being NFS they are automatically remote. The fuser mounts are not; this is just a convenient place to unmount those.

Could be that more recent systemd fixes the problem I had with iscsi not being unmounted (and therefore sometimes causing problems on the NAS), but I don't care; I know this service works.