0

The below command works fine of remote AiX server when run on the server.

ls -ltr /tmp/*.pid  | grep "$(date '+%b %e')"

Output:

-rwx-rwx-rw-- ........ Oct 1 /tmp/new.pid

echo $?
0

I wish to run the above command using ssh but it fails. See output below:

ssh user@10.0.0.9 -C 'ls -ltr /tmp/*.pid  | grep "$(date "'"+%b %e"'")"'

echo $?
1

Note: The command gets from "$(date '+%b %e')" to grep "$(date "'"+%b %e"'")" by ansible automation.

-name: Chek is pid file was modified today
 raw: "ls -ltr /tmp/{{ another_folder }}/*.pid  | grep \"$(date '+%b %e')\""
 register: pidfiledet

Can you please suggest how can I address this issue and get the command to run remotely as well ?

Update: I ran the commands suggested by users in the answer and comment sections however, the ssh fails. Below is the failing ssh output in debug mode for the answers that were suggested.

$ ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s -o 'IdentityFile="/app/mysshkeys/id_rsa"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="tbaadm"' -o ConnectTimeout=10 -o StrictHostKeyChecking=no -o ControlPath=/home/targetuser/.ansible/cp/f623d39604 -tt 10.9.9.12 'ls -ltr /tmp/prjfolder/bin/*.pid | grep "$(date +%b\ %e)"'
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,gss-gex-sha1-,gss-group14-sha1-]
debug1: auto-mux: Trying existing master
debug2: fd 3 setting O_NONBLOCK
debug2: mux_client_hello_exchange: master version 4
debug3: mux_client_forwards: request forwardings: 0 local, 0 remote
debug3: mux_client_request_session: entering
debug3: mux_client_request_alive: entering
debug3: mux_client_request_alive: done pid = 73756
debug3: mux_client_request_session: session request sent
debug1: mux_client_request_session: master session id: 2
debug3: mux_client_read_packet: read header failed: Broken pipe
debug2: Received exit status from master 1
Shared connection to 10.9.9.12 closed.

Note, the command passed using ssh above works fine when executed locally on the target host!!

12
  • 1
    What does "it fails" actually mean? What did you expect? What happened? What didn't happen? Why do you think this is incorrect behaviour? Note that the status doesn't necessarily mean the command has failed; it could mean that the grep didn't match – roaima Oct 1 '20 at 16:59
  • 1
    Experience suggests that this is one of those questions where lots of people are going to go all around the houses trying to get the questioner to explain, and it will eventually transpire that the file had been deleted, or that it was now the 2nd of October in the questioner's timezone, or some such. – JdeBP Oct 1 '20 at 17:20
  • 2
    "translated ... by ansible automation" would be a key part of the question that is not in the question. – kbulgrien Oct 1 '20 at 17:30
  • 1
    Does it help if you remove quoting mess by the date command argument along the lines of ls -ltr /tmp/*.pid | grep "$(date +%b\ %e)"? – kbulgrien Oct 1 '20 at 18:22
  • 1
    grep returns no output and the exit status 1 after it matches nothing. Review ssh user@10.0.0.9 -C 'ls -ltr /tmp/*.pid' and ssh user@10.0.0.9 -C 'date "+%b %e"'. Are they what you expect? If not, check if this applies: Time Zone is getting different over ssh command & normal ssh. In one timezone the timestamp may still be "today", in another it may be "yesterday". Parsing ls is bad idea in general. Parsing ls to match mtime is not the right thing. – Kamil Maciorowski Oct 1 '20 at 19:09
1

Unfortunately, I am not familiar with ansible, but since it appears that ansible is in the mix, and the problem is that another process translates the command in a way that breaks quoting, perhaps eliminating the quoting in that part of the command may help.

It may be worth trying a base command something like this:

ls -ltr /tmp/*.pid  | grep "$(date +%b\ %e)"

The question remains as to whether the translator might break that too.

0

You haven't explained what you mean by "it fails" so I can only guess

  1. Rather than packaging up the entire pipeline to run remotely, you could run the necessary part remotely and the remainder locally

     ssh user@10.0.0.9 -C 'ls -ltr /tmp/*.pid' | grep "$(date '+%b %e')"
    

    The biggest advantage of this (in my opinion, of course) is that is keeps quoting simple and straightforward. You have to balance that against the amount of data traversing the network pipe and possible differences in timezone (in the instance of date)

If you know the timezone of the source machine you can instruct date to use it even when running locally, forr example

    ssh user@10.0.0.9 -C 'ls -ltr /tmp/*.pid' | grep "$(TZ=Europe/Paris date '+%b %e')"
  1. Bear in mind that your exit status code could simply mean that grep failed to match anything. I don't know if in your case that in itself is an error, but it's normal behaviour for ssh to return its command's final exit status

     ssh remoteHost true; echo SS=$?
     SS=0
     ssh remoteHost false; echo SS=$?
     SS=1
    
4
  • 1
    This is BAD. The local and the remote user can be in different time zones. Besides, it's not answering the question. – user414777 Oct 1 '20 at 17:08
  • Timezone difference is actually the reason ... This does not answer my query ... agree with @user414777. ssh command is successful but the way i'm checking for success and failure is by echo $? – Ashar Oct 1 '20 at 17:22
  • @user414777 good catch. I always use UTC and simply forgot others don't. Answer amended – roaima Oct 1 '20 at 21:31
  • @Ashar I don't understand what you mean. All my examples return status through $? – roaima Oct 1 '20 at 21:32
0

I don't know about Ansible, but here is the working ssh command:

ssh user@10.0.0.9 'touch /tmp/test.pid; ls -ld /tmp/*.pid | grep -- "$(date "+%b %d")"'

Note: even if you have GNU!binutils installed on your AIX-server, commands executed via ssh use a minimal PATH that doesn't include /opt/freeware/bin or /usr/local/bin, so use full-path if you want to use GNU!ls:

ssh user@10.0.0.9 'touch /tmp/test.pid; /usr/local/bin/ls -ld /tmp/*.pid | grep -- "$(date "+%b %e")"'

Edit: Regarding date %-sequences: AIX!ls is compatible with %d, GNU!ls with %e.

2
  • 1
    Now try %e as in the question. Enjoy counting the number of spaces. Then enjoy adding Ansible, locale-specific date formats in ls, and non-login non-interactive shells into the mix. (-: – JdeBP Oct 2 '20 at 7:00
  • @JdeBP Very true, an actual solution should be based on standardized locale, standardized timezone, and using find utility. (Edited the answer to press the difference between %d and %e) Regarding Ansible: I don't know it, but heard that it worth learning it, as expert Ansible-users can solve the problems that are caused by using Ansible. – Lorinczy Zsigmond Oct 2 '20 at 7:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.