Gfilui

cat /home/upload.sh 
/usr/bin/scp -P 22 /home/material.gz root@remote_ip:/home
date >> /var/log/upload.log

Setting for upload.service

cat /etc/systemd/system/upload.service
[Unit]
Description=upload files into my vps 
Before=shutdown.target reboot.target
Requires=network-online.target
After=network.target 

[Service]
ExecStart=/bin/true
ExecStop=/bin/bash /home/upload.sh 

[Install]
WantedBy=multi-user.target

The script can upload file into my vps before shutdown.

The strange thing is the upload service's log.

journal -u upload 
Apr 23 12:54:50 localhost systemd[1]: Stopping upload files into my vps...
Apr 23 12:55:13 localhost systemd[1]: Stopped upload files into my vps.
Apr 23 12:55:19 localhost systemd[1]: Started upload files into my vps.
Apr 23 12:55:19 localhost systemd[1]: Starting upload files into my vps...

Why it is not such as following order?

Apr 23 12:54:50 localhost systemd[1]: Stopping upload files into my vps...
Apr 23 12:55:13 localhost systemd[1]: Stopped upload files into my vps.
Apr 23 12:55:19 localhost systemd[1]: Starting upload files into my vps...
Apr 23 12:55:19 localhost systemd[1]: Started upload files into my vps.

Only differ in the last two lines,why?

Which result in this kind of log info?

Do as George Udosen say:Try this in the service file [Unit] Requires=network-online.target After=network.target network-online.target.

It is no use at all.

lshw -C cpu
 *-cpu 
 product: Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz
 vendor: Intel Corp.
 vendor_id: GenuineIntel
 physical id: 1
 bus info: cpu@0
 width: 64 bits
 capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb pln pts dtherm hwp hwp_noitfy hwp_act_window hwp_epp invpcid_single tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx xsaveopt xsavec xgetbv1 xsaves

Based on the information currently available I'm assuming that you have a multi-core or at least multi-threaded CPU and that dispatch and issue decoupling is allowing out-of-order execution, causing this out of order anomaly in log output. I would use numactl to launch your script. Here's an example:

numactl --physcpubind=0 /path/to/your/script

or in this specific case

numactl --physcpubind=0 /home/upload.sh

This will run your process on the first core/cpu assigned to your chipset (index 0) as listed in /proc/cpuinfo This will force the script to run at most one thread concurrently, but it does not mean that the entire process will be composed of only one thread. if the program is written to spawn a new thread, it will do so, but it will execute on the same core/cpu/thread as the rest of the process.

EDIT: Note that by restricting your processing to a single thread/core/cpu this may result in slower processing of the task at hand.

Sources:

https://superuser.com/questions/692138/how-to-force-a-process-to-run-on-a-single-thread-only-with-numactl

man numactl

https://en.wikipedia.org/wiki/Out-of-order_execution

https://en.wikipedia.org/wiki/Multithreading_(computer_architecture)