Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAIL: 38: can not parse arg #1 #907

Open
fradaxx opened this issue Dec 28, 2015 · 23 comments
Open

FAIL: 38: can not parse arg #1 #907

fradaxx opened this issue Dec 28, 2015 · 23 comments

Comments

@fradaxx
Copy link

fradaxx commented Dec 28, 2015

Hi,

I re-submit this already known issue because it seems that it is recurrent and, unfortunately, none of the already proposed solutions work, at least in my case.

I downloaded the Telegram-cli sources and successfully built them on my UDOO-quad (an Ubuntu 12.04-based SBC, www.udoo.org); if I try to send a message "manually", putting the "msg" command on the Telegram prompt it works properly. Also it receives messages from remote and all other commands seem to work correctly.

If I try to automate the message send process using this bash script:

!/bin/bash

to=$1
msg=$2
tgpath=/home/ubuntu/tg
cd ${tgpath}
(echo "msg $to $msg"; echo "safe_quit") | bin/telegram-cli -W -v -k server.pub

it returns always the "FAIL: 38: can not parse arg #1" error; this is a transcript of what I obtain when I call the shell script containing the previous commands:

Telegram-cli version 1.3.3, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type show_license'. This is free software, and you are welcome to redistribute it under certain conditions; typeshow_license' for details.
Telegram-cli uses libtgl version 2.0.3
Telegram-cli includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)
Telegram-cli uses libpython version 2.7.3
I: config dir=[/home/ubuntu/.telegram-cli]
*** adjusting CLOCK_MONOTONIC delta to 0.242843
*** adjusting CLOCK_MONOTONIC delta to 0.249272
*** adjusting CLOCK_MONOTONIC delta to 0.559830
*** adjusting CLOCK_MONOTONIC delta to 0.556163
*** adjusting CLOCK_MONOTONIC delta to 0.256063

msg Name_Surname Prova
FAIL: 38: can not parse arg #1
safe_quit

All done. Exit
halt

Please note that I added the -v switch to increase the level of verbosity in the hope to have some more info about the cause of the error; it seems that the problem is related to the contact list load process (-W switch), that seems to be asynchronous and too slow, nonetheless in my case it is made of only 2 contacts.

I also tried to add a "sleep" of several seconds before the first echo command on the last line, to give more time to the contact list addresses to load:

(sleep 5s; echo "msg $to $msg"; echo "safe_quit") | bin/telegram-cli -W -v -k server.pub

but the result doesn't change.

I observed that if I add the "contact_list" command in front of the echo commands, followed by the sleep bash command, the list of contacts always appear only AFTER the issue of the "safe_quit" command, and this makes me suspect that the contact list load process is very slow and asynchronous (also that started automatically thanks to the -W switch) and it doesn't last before the issue of the msg command.

I also tried to use the -e switch in the telegram-cli call (as suggested in another similar issue) but the behaviour doens't change at all.

This problem greatly limits the possibility of use of telegram-cli on my case, because I need to use my SBC as a home automation gateway, using telegram as a input/output message layer.

Please, can I ask if there is there any hint/official script to definitely solve this issue?

Thanks in advance for the answer.

Francesco - Italy

@beMoD
Copy link

beMoD commented Dec 28, 2015

Hi fradaxx,

(sleep 1; echo "contact_list"; sleep 1; echo "msg hi_ho hi hi ho") | bin/telegram-cli -W -v -k server.pub works for me. The trick seems to be the first sleep 1. I do not understand why though.

As you found in the other issue the -e switch works for me too and I think that should be the preferred way. On my box if I run a bin/telegram-cli -W server.pub -e "msg hi_ho hi hi ho" the process waits for about 3 seconds (loading the contact list i think) and then issues the msg command successfully. Is this different on your box? Especially the waiting of the process is interesting to know.

Would running telegram-cli in daemon mode be an option for you?

HTH,
beMoD

@fradaxx
Copy link
Author

fradaxx commented Dec 28, 2015

Hi BeMoD,

thanks for your answer! I just tried your first solution and, incredibly, it works also in my case!!

The second solution doesn't work for me; I implemented it using the following bash script (I'm not sure about its correctness due to my limited experience with Linux...)

#!/bin/bash
to=$1
msg=$2
tgpath=/home/ubuntu/tg
cd ${tgpath}
cmd="bin/telegram-cli -W -k server.pub -e ""msg $to $msg"""
eval $cmd

I observe the pause of about 3 secs but the message is not sent at all.

And finally: yes, using Telegram-cli in daemon mode would be an optimum solution for me but... now I don't know how to do it!

I know that Telegram-cli has the -d switch to daemonize it but I don't know exactly how to use it.
Can I ask you for some hints to give me a start? I will make some tries and I will post my results ASAP!

Thank you again for your answer!

Regards.

Francesco

@beMoD
Copy link

beMoD commented Dec 28, 2015

Hi Francesco,

good to hear that the sleep works for you too.

But regarding your script, there are some problems.
First: Your bash script looks like you have some experience with basic, and your problem are the quotation marks, respectively the escaping of the quotation marks.

This one will work:

#!/bin/bash
to=$1
msg=$2
tgpath=/home/ubuntu/tg
cd ${tgpath}
cmd="bin/telegram-cli -W -k server.pub -e \"msg $to $msg\""
eval $cmd

Second: There is no need to use eval. You can just use the line

bin/telegram-cli -W -k server.pub -e "msg $to $msg" instead of

cmd="bin/telegram-cli -W -k server.pub -e \"msg $to $msg\""
eval $cmd

inside your script.

Now the daemon thing:
I posted an init script in #373 which you can use. Copy it to /etc/init.d/telegram-cli file(or choose another name) and alter the variables in the upper section of the script to fit your needs/config. Especially look at the -b parameter in the DAEMON_ARGS variable, as my telegram-cli acts as a bot and not as a regular user. Just delete the -b, if you want your telegram-cli to be a regular user.
You can then try to start your telegram-cli with /etc/init.d/telegram-cli start. The normal console output is redirected to the log file. Look into it to see if everything works.
If everything works you can then communicate with the daemon using netcat command: echo "msg hi_ho hi hi ho" | nc -q 1 localhost $TGPORT

The final step would be to configure ubuntu to autostart and stop the daemon on system boot and halt. To do this run sudo update-rc.d telegram-cli defaults.

HTH,
beMoD

@fradaxx
Copy link
Author

fradaxx commented Dec 28, 2015

Hi beMoD,

thanks again for your hits! I just tried the first solution (the one with the -e option) and, of course, now it works well!

Now I am trying the daemon way; I already created the script, made it executable and run it as service. It starts but, for now, it refuses the connection when I issue the command

echo "msg hi_ho hi hi ho" | nc -q 1 localhost $TGPORT

However it is only matter of time; I will discover soon what's wrong in my case!

Francesco

@beMoD
Copy link

beMoD commented Dec 28, 2015

You notice you have to replace $TGPORT with the port configured in the init script right?

@fradaxx
Copy link
Author

fradaxx commented Dec 28, 2015

Oh yes, of course I done this substitution, but it doesn't work anyway...

@beMoD
Copy link

beMoD commented Dec 28, 2015

What does the logfile show?

@fradaxx
Copy link
Author

fradaxx commented Dec 28, 2015

If I set USERNAME/GROUPNAME with the regular user/group (ubuntu/ubuntu), the log file is not created at all, I guess for permissions problems.

If I set them as root/root the logfile is created and when I issue the command "echo....", the following lines are added to it:

Telegram-cli version 1.3.3, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type show_license'. This is free software, and you are welcome to redistribute it under certain conditions; typeshow_license' for details.
Telegram-cli uses libtgl version 2.0.3
Telegram-cli includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)
Telegram-cli uses libpython version 2.7.3
I: config dir=[/root/.telegram-cli]
*** lua: cannot open /usr/local/lib/tg-handler.lua: No such file or directory

So the problem is with the script tg-handler.lua which is not found; I don't know where it is in my system (I'm trying to find it). I built telegram in /home/ubuntu/tg

@beMoD
Copy link

beMoD commented Dec 28, 2015

Yes, its a permission issue, as only root can write to /var/log by default. You can create the logfile once manually and chown it to the correct user.

tg-handler.lua is a script I wrote myself. It handles incoming messages. You can just remove -s $ReceiveLua from the startscript if you do not need handling of incoming messages.

@fradaxx
Copy link
Author

fradaxx commented Dec 28, 2015

I removed the "-s $ReceiveLua" portion, saved and restarted the service; it "seems" to work only for the first time, but indeed the message is not sent/received and, from the second command issue on, it returns the "FAIL: 38:" error...

I think that I need to do many experiments with my specific case.

However, for now, it is sufficient to have the first method working; I will continue to make tries by myself on the daemon (I cannot continue to take advantage of your kindness...).

Thanks again for all your help!

@beMoD
Copy link

beMoD commented Dec 28, 2015

I'd be glad to help and it should not be a big deal to get your setup running in daemon mode so let me know if you need any further assistance. But if you want to try on your own im fine with that too :-)

@fradaxx
Copy link
Author

fradaxx commented Dec 29, 2015

beMoD, thank you again for your kindness!
I will try on my own and, in case of necessity, I will ask you for some more help!

Francesco

@fradaxx
Copy link
Author

fradaxx commented Jan 4, 2016

Hi beMoD,

sorry to disturb you again but... I am unable to solve the daemon problems by myself as I hoped... so I am in need of your help again!

This is the script I use:

telegram-cli.txt

This is what if is added in the log file everytime I reboot my system and/or I restart the telegram-cli service:

Telegram-cli version 1.3.3, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type show_license'. This is free software, and you are welcome to redistribute it under certain conditions; typeshow_license' for details.
Telegram-cli uses libtgl version 2.0.3
Telegram-cli includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.openssl.org/)
Telegram-cli uses libpython version 2.7.3
I: config dir=[/root/.telegram-cli]
*** public key '/home/ubuntu/tg/server.pub' loaded successfully
*** public key '/etc/telegram-cli/server.pub' loaded successfully
*** Couldn't open public key file: tg-server.pub
*** Can not load key tg-server.pub
*** DC1 '' update: 149.154.175.50:443
*** DC2 '' update: 149.154.167.51:443
*** DC3 '' update: 149.154.175.100:443
*** DC4 '' update: 149.154.167.91:443
*** DC5 '' update: 149.154.171.5:443

When telegram-cli receives an incoming message, these lines are added to the log file:

[warn] Epoll ADD(1) on fd 0 failed. Old events were 0; read change was 1 (add); write change was 0 (none): Operation not permitted
*** outbound rpc connection from dc #2 becomed ready
*** outbound rpc connection from dc #4 becomed ready
*** outbound rpc connection from dc #1 becomed ready
*** outbound rpc connection from dc #3 becomed ready
*** outbound rpc connection from dc #5 becomed ready
*** adjusting CLOCK_MONOTONIC delta to 1.906167
*** DC1 '' update: 2001:0b28:f23d:f001:0000:0000:0000:000a:443
*** DC2 '' update: 2001:067c:04e8:f002:0000:0000:0000:000a:443
*** DC3 '' update: 2001:0b28:f23d:f003:0000:0000:0000:000a:443
*** DC4 '' update: 2001:067c:04e8:f004:0000:0000:0000:000a:443
*** DC4 '' update: 149.154.165.120:443
*** DC5 '' update: 91.108.56.165:443

Script receive_handler.lua should do only a echo of the received messages but it doesn't:

receive_handler.lua.txt

If I issue the command

echo "msg contact_name Hello World" | nc -q 1 localhost 1234

I always obtain:

ANSWER 31
FAIL: 38: can not parse arg #1

on the prompt, and these lines are added to the log file:

*** Accepting incoming connection
*** Read from incoming connection
*** Closing incoming connection

Please, can you help me to find where the problem is?

@beMoD
Copy link

beMoD commented Jan 4, 2016

There is no real error message in the log besides the FAIL 38. A short google search for the warn message implies that it can be ignored, though im not completly sure.

For FAIL 38: Try echo "contact_list" | nc -q 1 localhost 1234 and see if the contact you are trying to write to really exists.

@fradaxx
Copy link
Author

fradaxx commented Jan 4, 2016

Hi beMoD!

Thanks for your answer!

here are the results of my experiments following your hints:

If I issue the command

echo "contact_list" | nc -q 1 localhost 1234

Nothing appears on the prompt but these lines are added to log file:

*** Accepting incoming connection
*** Read from incoming connection
*** Closing incoming connection
*** error for query #6236002098176824320: #401 AUTH_KEY_UNREGISTERED

If I try to add (or re-add, because I am sure it already exists) the contact with a command like

echo "add_contact +39xxxxxxxxx name surname" | nc -q 1 localhost 1234

these lines are added to log file:

*** Accepting incoming connection
*** Read from incoming connection
*** Closing incoming connection
*** error for query #6236002135690152960: #401 AUTH_KEY_UNREGISTERED

It seems to be some authentication problem, but I am unable to identify it

Francesco

@beMoD
Copy link

beMoD commented Jan 4, 2016

Hey,

yes, seems you are not registered with telegram service. Stop the daemon. Then please remove /root/.telegram-cli and start telegram-cli without the startscript and without the -d option as root:
/home/ubuntu/tg/bin/telegram-cli -W -U root -G root -k /home/ubuntu/tg/server.pub -s /home/ubuntu/tg/receive_handler.lua -vvvRC

Then enter your phone number to authorize yourself again using the normal command prompt. After that contact_list should show you your contacts. Then you can safe_quit the client and start the daemon again. Then echo "contact_list" | nc -q 1 localhost 1234 should show you your contact list and sending messages should work.

But please note: I would really really really not suggest to run telegram-cli as root. For testing purposes you can do this, but I would not advise running any services as root when user rights are sufficient. There could be bugs in it which could allow a remote user to get root access to your machine. The better way would be to create a special user that is only used to run telegram-cli.

@fradaxx
Copy link
Author

fradaxx commented Jan 7, 2016

Hi beMoD,

in my opinion the problem is not related to the registration with the Telegram service because I can use Telegram-cli from command line.

I removed the autostart script from /etc/init.d and made some other tries on my own launching this bash script at startup using crontab (telegramd is a dedicated user I created to securely use Telegram-cli, as you suggested):

#!/bin/bash

TGPATH=/home/ubuntu/tg
cd $TGPATH
bin/telegram-cli -W -k server.pub -d -U telegramd -G telegramd -L $TGPATH/telegram-cli.log -s $TGPATH/receive_handler.lua -vvvRC -P 1234

The line added to my crontab config file is:

@reboot nohup sh /home/ubuntu/run_telegram &

(run_telegram is the script name I saved in /home/ubuntu)

With this script I have Telegram-cli permanently online and thanks to receive_handler.lua it echoes every text message I send using my other Telegram account on smartphone/tablet/PC.

However it doesn't execute any command that I send to it using the command

echo | nc -q 1 localhost 1234

At every command the following lines are added to the log file:

*** Accepting incoming connection
*** Read from incoming connection
*** Closing incoming connection

but nothing else happens; if I request the contact list it is not printed out, if I try to send a message with

echo "msg Name_Surname This is a try message" | nc -q 1 localhost 1234

it is apparently sent because I read this in the logfile:

*** Accepting incoming connection
*** Read from incoming connection
*** Closing incoming connection
[11:41] Name Surname <<< This is a try message

but nothing is received on the remote Telegram account (activated on my smartphone, tablet and PC), nonetheless Name Surname is correctly listed in the contact list of Telegram-cli)

Do you see any problem/error in the command I use to launch Telegram-cli; is there some more detailed log level I can activate to see in more detail what happens when I send a command using netcat?

Thanks in advance for any hint!

@beMoD
Copy link

beMoD commented Jan 7, 2016

Hi,

your setup is a bit mixed up I think. The sending message problem is not related to that, but let me explain why your setup is mixed up.

You say you created a crontab entry and I believe you created it as user "ubuntu". The crontab of the user ubuntu is run by the user ubuntu so the telegram process is only running with user rights. Now you have specified the -U and -G options on the commandline, but the process is not able to switch the context to the user telegramd, because it is only running with user rights. So telegram-cli is still running as user ubuntu (you can see by issuing ps -eaf | grep tele, its the first column) and thats why it is working, because you authed with the telegram service as user ubuntu from the command line.

When using the init script, which is run by root, the process is able to switch the context to the user telegramd (again look at the process using ps -eaf | grep tele), but the user telegramd has NEVER authed with the telegram service, so running telegram-cli from the init script does not work for you.

The solution would be, as described in my last message: su to the user telegramd (root in my last message) run the client in command line mode and auth it. Then the init script will work and telegram-cli is running in the correct user context.
Keep in mind though, that the user telegramd needs access to the telegram files (which it currently does not have, because the files reside in the home directory of the user ubuntu) and that telegramd needs a home directory to store the telegram-cli config.

Regarding your sending problem I currently have no idea what could be the problem because the log states, that everything is working.

*** Accepting incoming connection
*** Read from incoming connection
*** Closing incoming connection

This part shows, that a connection to the port (using the nc command) is opened, then it reads your "echo" and then closes the connection again.

[11:41] Name Surname <<< This is a try message
This part is the actual message sending. You can add more v to the the telegram-cli arguments, that will give more debug, but I dont know whether that will help.

@fredkard
Copy link

I had this problem too, solved by send command dialog_list first, then follow by msg

my script is going like this
#! /bin/sh
(sleep 1;echo "dialog_list";sleep 2;echo "msg fredykardian This is test"; sleep 2;echo "safe_quit";)|/home/udo/tg/bin/telegram-cli

@dufferzafar
Copy link

Was facing this issue as well. And as said by @fredkard adding a dialog_list before a msg worked.

I think the issue is that tg doesn't store the user id somewhere?

@rebroad
Copy link

rebroad commented Apr 28, 2021

Hi fradaxx,

(sleep 1; echo "contact_list"; sleep 1; echo "msg hi_ho hi hi ho") | bin/telegram-cli -W -v -k server.pub works for me. The trick seems to be the first sleep 1. I do not understand why though.

As you found in the other issue the -e switch works for me too and I think that should be the preferred way. On my box if I run a bin/telegram-cli -W server.pub -e "msg hi_ho hi hi ho" the process waits for about 3 seconds (loading the contact list i think) and then issues the msg command successfully. Is this different on your box? Especially the waiting of the process is interesting to know.

Would running telegram-cli in daemon mode be an option for you?

HTH,
beMoD

this works... seems odd that I have to run the contacts_list command before the msg command will work though.

@beMoD
Copy link

beMoD commented Apr 28, 2021

Hi fradaxx,
(sleep 1; echo "contact_list"; sleep 1; echo "msg hi_ho hi hi ho") | bin/telegram-cli -W -v -k server.pub works for me. The trick seems to be the first sleep 1. I do not understand why though.
As you found in the other issue the -e switch works for me too and I think that should be the preferred way. On my box if I run a bin/telegram-cli -W server.pub -e "msg hi_ho hi hi ho" the process waits for about 3 seconds (loading the contact list i think) and then issues the msg command successfully. Is this different on your box? Especially the waiting of the process is interesting to know.
Would running telegram-cli in daemon mode be an option for you?
HTH,
beMoD

this works... seems odd that I have to run the contacts_list command before the msg command will work though.

Big oof. Someone is still using this? The repository has not been updated for years and I stopped using it because of evil memory holes I encountered that killed my Pi every few days :-/

@rebroad
Copy link

rebroad commented Apr 29, 2021

this works... seems odd that I have to run the contacts_list command before the msg command will work though.

Big oof. Someone is still using this? The repository has not been updated for years and I stopped using it because of evil memory holes I encountered that killed my Pi every few days :-/

I suspect you'll only encounter memory issues if you run it in daemon mode (or constantly)... whereas running it like I'm talking about (i.e. just to send one message) is probably memory safe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants