A ordem do log de um script em execução antes do desligamento?

Question

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

Configuração para 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

O script pode carregar o arquivo em meus vps antes do desligamento.

O mais estranho é o log do serviço de upload.

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...

Por que não é como seguir a ordem?

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.

diferem apenas nas últimas duas linhas, por quê?
Que resultado nesse tipo de informação de log?

Faça como diz George Udosen: Tente isto no arquivo de serviço [Unit] Requer = network-online.target After = network.target network-online.target.

Nãoadiantanada.

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

    

Answer 1

Com base nas informações disponíveis atualmente, presumo que você tenha uma CPU multi-core ou pelo menos multi-thread e que o despacho e o desacoplamento de problemas estejam permitindo a execução fora de ordem, causando anomalia fora de ordem no log saída. Eu usaria numactl para iniciar seu script. Aqui está um exemplo:

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

ou neste caso específico

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

Isso executará seu processo no primeiro core / cpu atribuído ao seu chipset (índice 0), conforme listado em /proc/cpuinfo Isso forçará o script a executar no máximo um thread simultaneamente, mas isso não significa que todo o processo será composto de apenas um thread. Se o programa for escrito para gerar um novo thread, ele será executado, mas será executado no mesmo core / cpu / thread que o restante do processo.

EDITAR: Observe que ao restringir seu processamento a um único encadeamento / núcleo / CPU isso pode resultar em um processamento mais lento da tarefa em questão.

Fontes:

link

man numactl

link

link