#1 2019-09-25 09:23:00

hebasto
Member
Registered: 2019-08-07
Posts: 15

PID management issue

From VMWare Backup - XSIBackup: pid management:

XSIBackup process types:
• cron: this type is launched from the xsibackup-cron file without any user intervention.
• remote: if backup job is launched from a different host, this type is registered in the xsibackup-pid file.

But I've got a "remote" process type instead of a "cron" one for a backup job launched from the same (local) host:

[root@esxi02:~] head /vmfs/volumes/backup/xsi-dir/var/logs/201909250905-111.log 
2019-09-25T09:05:03|  ###############################################################################
2019-09-25T09:05:03|     XSIBACKUP-PRO 11.2.10: new execution request                     
2019-09-25T09:05:03|  ###############################################################################
2019-09-25T09:05:03|  
2019-09-25T09:05:04|  NOTICE: (c) XSIBackup kills any user launched jobs, make sure you don't overlap manual jobs
---------------------------------------------------------------------------------------------------------------------------------
XSIBackup PID:           118123                                               esxi02.pci.net.ua
Wed, 25 Sep 2019 09:05:03 +0000                                    IPv4: 10.0.0.110/255.255.0.0
VMware ESXi 6.0.0 build-2809209                              (c) Rsync 3.1.0 as opt. dependency
---------------------------------------------------------------------------------------------------------------------------------
[root@esxi02:~] cat /vmfs/volumes/backup/xsi-dir/xsibackup-pid 
118123 remote

Offline

#2 2019-09-25 10:28:42

admin
Administrator
Registered: 2017-04-21
Posts: 1,370

Re: PID management issue

Can you provide the backup job itself?

Offline

#3 2019-09-25 10:31:23

hebasto
Member
Registered: 2019-08-07
Posts: 15

Re: PID management issue

[root@esxi02:~] cat /vmfs/volumes/backup/xsi-dir/jobs/111
"/vmfs/volumes/backup/xsi-dir/xsibackup" \
--description="ONCE: Mirror Abso to esxi01:DS-2" \
--backup-id="111" \
--backup-prog="onediff:l" \
--backup-point="10.0.0.51:22:/vmfs/volumes/datastore2" \
--backup-type="custom" \
--backup-vms="Abso" \
--backup-how="warm" \
--shutdown-wait="30" \
--mail-to="hebasto@fastmail.fm" \
--use-smtp="1" \
--img-list="none|none|none|none|none|none" \
--exec=yes > \
"/vmfs/volumes/backup/xsi-dir/var/logs/$(date '+%Y%m%d%H%M')-111.log" \
2>&1

Offline

#4 2019-09-25 15:49:55

admin
Administrator
Registered: 2017-04-21
Posts: 1,370

Re: PID management issue

The PID line type is handled by this piece of code at the beginning of the main xsibackup file at around line 123:

if [ -t 1 ]
then
    launched="user"
    separator="\e[90m$separator\033[0m"
    TW=$( stty size | cut -d ' ' -f 2 )
    XSIDIFFSILENT=""
    stty sane
    echo -e "\033c"
    clear
else
    if [ "${keyvalstr/--time/}" == "${keyvalstr}" -a "$( echo "$keyvalstr" | sed -e 's/--exec=yes$//g' )" == "${keyvalstr}" ]
    then
        exit 0
    fi
    if [ ! -z "${host}" ]
    then
        separator="-"
    fi
    launched="cron"
    TW=130
    XSIDIFFSILENT="--silent"
fi

if [ "$2" == "base64" ]
then
    launched="remote"
fi

This isn't nested inside any IF block, it is indeed executed everytime the main xsibackup file is invoked and sets the kind of PID written to the xsibackup.pid file.

The only way that a job may be assigned the remote property via the launched variable is when the second argument in the xsibackup call is equal to "base64", which is how XSIBackup passes commands to remote servers.

Thus the code you shared above must have been launched from a remote server.

[root@esxi02:~] head /vmfs/volumes/backup/xsi-dir/var/logs/201909250905-111.log 
2019-09-25T09:05:03|  ###############################################################################
2019-09-25T09:05:03|     XSIBACKUP-PRO 11.2.10: new execution request                     
2019-09-25T09:05:03|  ###############################################################################
2019-09-25T09:05:03|  
2019-09-25T09:05:04|  NOTICE: (c) XSIBackup kills any user launched jobs, make sure you don't overlap manual jobs
---------------------------------------------------------------------------------------------------------------------------------
XSIBackup PID:           118123                                               esxi02.pci.net.ua
Wed, 25 Sep 2019 09:05:03 +0000                                    IPv4: 10.0.0.110/255.255.0.0
VMware ESXi 6.0.0 build-2809209                              (c) Rsync 3.1.0 as opt. dependency
---------------------------------------------------------------------------------------------------------------------------------

Offline

#5 2019-09-25 19:43:10

hebasto
Member
Registered: 2019-08-07
Posts: 15

Re: PID management issue

Could the relevant code be here (at around line 390):

if [ -z $from ] && [ "$launched" == "cron" ]
then
	rsyncbusy=0
	if [ $( ps | grep xsibackup-rsync | wc -l ) -gt 0 ]
	then
	    rsyncbusy=1		
	fi
	if [ "$exec" = "yes" ]
	then
	    if [ "$rsyncbusy" -eq "1" ]
	    then
	    	writeout "ERROR: there are some ongoing rsync process/es loaded into memory. Clean them manually \ 
	    	if no backup job is running now -> \e[1mkill -9 $( ps -c | grep rsync | awk '{print $1}')\033[0m"
	    	exit 0
	    fi
	    righttime=1
	    echo "$$ remote" >> "${PWD}/xsibackup-pid"
...

?

Offline

#6 2019-09-26 19:45:00

admin
Administrator
Registered: 2017-04-21
Posts: 1,370

Re: PID management issue

Yes, that is the issue, you should not use the --exec=yes argument (we didn't see it at first glance). It is reserved for internal use of the program and it is an indicator that the command was launched remotely. You won't see it in the manual, maybe in some older post where we explained how to launch from an external cron.

Offline

#7 2019-09-26 19:47:17

hebasto
Member
Registered: 2019-08-07
Posts: 15

Re: PID management issue

Thank you for clarification.

Offline

#8 2019-09-30 09:33:54

hebasto
Member
Registered: 2019-08-07
Posts: 15

Re: PID management issue

admin wrote:

Yes, that is the issue, you should not use the --exec=yes argument (we didn't see it at first glance). It is reserved for internal use of the program and it is an indicator that the command was launched remotely. You won't see it in the manual, maybe in some older post where we explained how to launch from an external cron.

Tested on XSIBackup-PRO 11.2.10
It does not work as cron job without --exec=yes argument.

Offline

#9 2019-09-30 12:38:17

admin
Administrator
Registered: 2017-04-21
Posts: 1,370

Re: PID management issue

It does for us, please re-check.

Offline

#10 2019-09-30 12:41:14

hebasto
Member
Registered: 2019-08-07
Posts: 15

Re: PID management issue

admin wrote:

It does for us, please re-check.

Double re-checked. I cannot even provide you a job log file, as it is created, but remains empty.

Offline

#11 2019-10-01 06:06:16

hebasto
Member
Registered: 2019-08-07
Posts: 15

Re: PID management issue

Reading the code of xsibackup script (lines 382 to 475, XSIBackup-PRO 11.2.10) makes me believe that cron job will run if:
1) --exec=yes argument is provided
OR
2) --time=... argument is provided

The latter is not used with ESXi cron, IIRC; therefore,  --exec=yes argument is mandatory for ESXi cron jobs.

The bug mentioned in the OP could be fixed in line 398: s/remote/cron/

Right?

Offline

Board footer