Migrating Xi-Batch from a Tarball Installation to a Package

Xi-BatchXi-Batchinstallationmigrationpackagingremovalxb-cjlistxb-cvlistxb-ciconvxb-btuconvxb-checklic

You have Xi-Batch installed from a tarball and you want the native RPM or Debian package on the same machine. This article gives the order and the commands. Choosing a Distribution Format covers what a removal takes with it, and Migrating Xi-Batch to Another System explains what the export carries; read the removal section of the first before you start.

The licence remains valid. It is bound to the machine, and the machine is not changing, so the same licence file works in the new installation.

The systemd unit is the one thing the package will not replace

Both package formats keep a unit file that is already there. The RPM prints Not changing existing systemd file; the Debian package prints postinst: keeping existing /lib/systemd/system/xibatch.service. The reason is sound - an administrator who has edited the unit does not want it overwritten - and it has a consequence for this migration.

A tarball installation made before 1.9.2 wrote a thinner unit than the package ships: ExecStart and Type=forking, and none of Restart=on-failure, RestartSec=5, StartLimitIntervalSec=30, StartLimitBurst=5 or ExecStop=btquit -y. The package has carried all of those since 1.8.0. A scheduler running under the thinner unit stays down after an abort until somebody notices.

The tarball installer and the Debian package write the unit to /lib/systemd/system/xibatch.service and the RPM to /usr/lib/systemd/system/xibatch.service. Where /lib is a symlink to /usr/lib, which it is on the Linux distributions these packages are built for, those are one file - so the package finds the tarball's unit and keeps it.

From 1.9.2 the tarball installer writes the same unit as the package, so a tarball installation made with 1.9.2 or later carries the full unit already.

Drop-ins under /etc/systemd/system/xibatch.service.d/ are left alone by every route - the tarball installer, both packages, and removal. A drop-in you rely on survives the migration and still applies afterwards.

Two further facts about the unit under a package follow from the same code. Removal deletes the unit file, on upgrade as well as on removal, and the install writes it again - so an edit made directly to the unit file is lost at the next package upgrade. Put changes in a drop-in instead.

What to do

Step 1: establish what you have, and where

rpm -qa | grep xibatch
dpkg -l | grep xibatch
cat /etc/xi/batchconfig

Where neither package query names the product, the installation is from a tarball. Read the spool, user-programs and internal-programs directories out of /etc/xi/batchconfig and use those values in the commands below: a blend installs into different directories, and the paths in this article are the default ones.

Step 2: stop the scheduler

btquit -y
ps -ef | grep btsched

An export taken from a running scheduler can be several minutes behind it.

Step 3: export the jobs, variables, interpreters and users

BACKUP_DIR=/var/tmp/batchsave
mkdir -p "$BACKUP_DIR/Scripts"
ls /var/spool/xi/batch/btsched_[jv]file*

xb-cjlist  -D /var/spool/xi/batch btsched_jfile.xbjl6 "$BACKUP_DIR/joblist.sh" "$BACKUP_DIR/Scripts"
xb-cvlist  -D /var/spool/xi/batch btsched_vfile.xbvl6 "$BACKUP_DIR/varlist.sh"
xb-ciconv  -D /var/spool/xi/batch cifile   "$BACKUP_DIR/cilist.sh"
xb-btuconv -D /var/spool/xi/batch btufile6 "$BACKUP_DIR/userlist.sh"

cp /etc/xi/batchconfig /etc/xi/batch-hosts "$BACKUP_DIR/"

Check the job and variable file names with the ls above before typing them; the format generation forms part of the name. Holiday calendars are exported separately with bthols - see Configuring the Xi-Batch Holiday Calendar.

Step 4: copy the licence file somewhere the removal cannot reach

cp /usr/libexec/xi/.xibatch.lic /root/xibatch.lic.saved
xb-checklic

This is the step that is missed. The removal takes the licence with it, and a licence file cannot be reconstructed on the machine - a replacement needs codes from the customer portal. Record what xb-checklic reports now, so you can compare it afterwards.

Step 5: remove the tarball installation by its own route

Run the tarball's DEINSTALL.sh, as described in Removing Xi-Batch from a System. It stops the scheduler, disables the service and removes the unit file.

Step 6: confirm no unit file is left

ls -l /lib/systemd/system/xibatch.service /usr/lib/systemd/system/xibatch.service
ls -l /etc/systemd/system/xibatch.service.d/ 2>/dev/null

Both paths are listed because the formats disagree about which to write. Where a unit file remains, remove it before installing the package, or the package keeps it and you end up running the thinner unit under a packaged installation. Leave any drop-in directory in place.

Step 7: install the package

sudo rpm -ivh xibatch-<variant>-1.9.2+<buildref>-x86_64-linux-rockylinux9.rpm

Or for a Debian system:

sudo dpkg -i xibatch-<variant>-1.9.2+<buildref>-x86_64-linux-debian13.deb

The install writes the configuration, sets the service user and permissions, writes a trial licence because no licence file is present at that moment, writes the unit, and enables and starts the service.

Step 8: put your own licence back over the trial

btquit -y
sudo cp /root/xibatch.lic.saved /usr/libexec/xi/.xibatch.lic
xb-checklic

Confirm the licence and the end date are the ones you recorded in step 4. Where xb-checklic reports the licence invalid, the machine's identity has changed and you need new codes from the customer portal.

Step 9: restore in the correct order

Two of these scripts need the scheduler stopped and two need it running.

sh "$BACKUP_DIR/userlist.sh"     # users; edits the user file directly
sh "$BACKUP_DIR/cilist.sh"       # interpreters; before the scheduler starts

systemctl start xibatch

sh "$BACKUP_DIR/varlist.sh"      # variables; the scheduler must be running
sh "$BACKUP_DIR/joblist.sh"      # jobs; variables must already be there

Restore the interpreters before starting the scheduler. The scheduler loads the job file immediately after the interpreter list, and a saved job naming an interpreter that is missing at that moment is reset to the first entry.

Step 10: verify

systemctl cat xibatch
systemctl status xibatch
btjlist
btvlist
xb-checklic

systemctl cat shows the unit the machine ended up with, together with any drop-in. Confirm it carries Restart=on-failure, RestartSec=5 and ExecStop; their absence means the old unit survived step 6. Then confirm the job and variable counts match what you exported, and that user permissions are as they were.

Related articles

All articles · Release notes · Contact support