/dev/ttyACM0 File does not exist while Postfix pipe - linux

When I run script as regular user manually, everything is OK. But if an email is received and piped into Go script, I can not open serial port because file does not exist.
postfix 1239 1025 0 13:20 ? 00:00:00 pipe -n watchParadox -t unix flags=F user=watch argv=/usr/local/bin/watch -paradox
watch 1240 1239 0 13:20 ? 00:00:00 /usr/local/bin/watch -paradox
Script is running under watch user who has been added to dialout group, postfix user, just to be sure, is in dialout also.
In my script I ran ls -la command to find out which files do truly exist:
drwxr-xr-x 6 root root 380 Feb 25 13:19 .
dr-xr-xr-x. 18 root root 4096 Feb 22 17:53 ..
lrwxrwxrwx 1 root root 11 Feb 25 13:19 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Feb 25 13:19 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Feb 25 13:19 full
drwxr-xr-x 2 root root 0 Feb 25 13:19 hugepages
lrwxrwxrwx 1 root root 28 Feb 25 13:19 log -> /run/systemd/journal/dev-log
drwxrwxrwt 2 root root 40 Feb 25 13:19 mqueue
crw-rw-rw- 1 root root 1, 3 Feb 25 13:19 null
lrwxrwxrwx 1 root root 8 Feb 25 13:19 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 Feb 25 13:19 pts
crw-rw-rw- 1 root root 1, 8 Feb 25 13:19 random
drwxrwxrwt 2 root root 40 Feb 25 13:19 shm
lrwxrwxrwx 1 root root 15 Feb 25 13:19 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Feb 25 13:19 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Feb 25 13:19 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Feb 25 13:19 tty
crw-rw-rw- 1 root root 1, 9 Feb 25 13:19 urandom
I am certain following file exists but is not shown when postfix pipe is executed.
crw-rw---- 1 root dialout 166, 0 25. úno 13.19 ttyACM0
I tried chmod 777 on the file but no luck in that department. Opening file via https://github.com/tarm/serial library which uses Go function:
os.OpenFile("ttyACM0", syscall.O_RDWR|syscall.O_NOCTTY|syscall.O_NONBLOCK, 0666)
results with
ttyACM0: no such file or directory
The problem is not the path because I tried relative (using chdir) and absolute with same exact outcome.
I even disabled SELinux which is not what I want to do but in search of solution I try anything.
Code is OK because manual execution of the script passes through properly. I think there is something wrong with Linux settings.

The correct path the ttyACM0 is /dev/ttyACM0. You define a udev rules to set the file mode when it attaches.
If that is not reachable from your program, it might be the case that your program runs chrooted().

It seems like it was truly Linux problem and some underlying fabrics of it which I do not understand. I was running Fedora25 but the problem does not occur on Debian8.

Related

How to flash MB1355C and/or MB1293C from the STM32WB55 Nucleo Pack on Linux?

I would like to program the (MB1355C and/or MB1293C) devices from an STM32WB55 Nucleo Pack on my (Ubuntu 18.04.3 LTS) machine - preferably with the convenience of an eclipse based IDE that supports debugging features.
I installed
STM32CubeProgrammer (version 2.2.1)
Atolic TrueStudio (version 9.3.0)
STM32CubeIDE (version 1.1.0)
and I now have the following udev rules
chandran#chandran-OptiPlex-9020:~$ ll /etc/udev/rules.d/
total 160
drwxr-xr-x 2 root root 4096 Dec 13 14:11 ./
drwxr-xr-x 4 root root 4096 Dec 4 13:44 ../
-rw-rw-r-- 1 root root 270 Oct 14 18:10 49-stlinkv1.rules
-rw-rw-r-- 1 root root 270 Oct 14 18:10 49-stlinkv1.rules.O
-rw-rw-r-- 1 root root 464 Oct 14 18:10 49-stlinkv2-1.rules
-rw-rw-r-- 1 root root 464 Oct 14 18:10 49-stlinkv2-1.rules.O
-rw-rw-r-- 1 root root 278 Oct 14 18:10 49-stlinkv2.rules
-rw-rw-r-- 1 root root 278 Oct 14 18:10 49-stlinkv2.rules.O
-rw-r--r-- 1 root root 458 Dec 11 17:26 49-stlinkv3loader.rules
-rw-rw-r-- 1 root root 845 Oct 14 18:10 49-stlinkv3.rules
-rw-rw-r-- 1 root root 845 Oct 14 18:10 49-stlinkv3.rules.O
-rw-r--r-- 1 root root 381 Dec 6 17:10 '#61-msp430uif.rules#'
-rw-r--r-- 1 root root 381 Dec 4 15:09 61-msp430uif.rules
-rwxr-xr-x 1 root root 2145 Dec 4 15:09 70-mm-no-ti-emulators.rules*
-rw-r--r-- 1 root root 58549 Dec 4 12:29 70-snap.core.rules
-rw-r--r-- 1 root root 79 Dec 5 12:11 77-msp430-blacklist.rules
-rw-r--r-- 1 root root 0 Dec 5 12:10 77-msp430-blacklist.rules~
-rw-rw-r-- 1 root root 18450 Oct 14 17:33 99-jlink.rules
-rw-rw-r-- 1 root root 18450 Oct 14 17:33 99-jlink.rules.O
I am in the dialout group
chandran#chandran-OptiPlex-9020:~$ groups chandran
chandran : chandran adm dialout cdrom sudo dip plugdev lpadmin sambashare
I downloaded an example project called STM32100E-EVAL_USART_IrDA_Transmit and it builds successfully, but I get the following error message when I connect the evaluation board(s) and click on debug to flash the micro controller
ST-Link enumeration failed
Error in initializing ST-Link device.
Reason: (2) ST-Link DLL error.
I get the same error message when I try the above with STM32CubeIDE.
I have tried shifting JP1 as described in section 7.6 of the users manual but to no avail.
A previous question on stack overflow deals with the same error message so I got STM32CubeProgrammer to launch and tried making the changes suggested by #IsaBostan, but the development boards don't seem to be detected
How can I proceed to resolve this problem and program the boards?
Debugging ideas or suggestions are welcome, even if they haven't been tested...
It was just a question of permissions as suggested by KamilCuk
Launching TrueStudio as root and then clicking on debug solved the problem.
This is what worked on my machine:
sudo su
/opt/Atollic_TrueSTUDIO_for_STM32_x86_64_9.3.0/ide/./TrueSTUDIO
STM32CubeIDE's debugger also works when launched as follows on my machine:
sudo su
/opt/st/stm32cubeide_1.1.0/./stm32cubeide
and STM32CubeProgrammer connects to the device straight away when launched as follows:
sudo su
/usr/local/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/./STM32CubeProgrammer
My device shows up under /dev/ttyACM0 with the following permissions:
crw-rw----+ 1 root dialout 166, 0 Dec 28 11:56 ttyACM0
openocd and st-flash were not required.

What does it mean to have a directory name prefixed with two dots?

I got the below file hierarchy in my Linux system. Wondering what it means to have two dots prefixed to a directory name?
/run/mydir # ls -la
total 4
drwxrwxrwt 3 root root 140 Sep 22 13:03 .
drwxr-xr-x 3 root root 4096 Sep 30 06:26 ..
drwxr-xr-x 2 root root 100 Sep 22 13:03 ..2019_09_22
lrwxrwxrwx 1 root root 31 Sep 22 13:03 ..data -> ..2019_09_22
lrwxrwxrwx 1 root root 13 Sep 22 13:03 address -> ..data/address
lrwxrwxrwx 1 root root 16 Sep 22 13:03 name -> ..data/name
lrwxrwxrwx 1 root root 12 Sep 22 13:03 cell -> ..data/cell
/run/mydir # ls -la ../
total 8
drwxr-xr-x 3 root root 4096 Sep 30 06:26 .
drwxr-xr-x 3 root root 4096 Sep 30 06:26 ..
drwxrwxrwt 3 root root 140 Sep 22 13:03 mydir
/run/mydir #
It has no significance except that ls will not normally list the names because the first character is a dot .. To see names beginning with a dot, you need ls -a or thereabouts, as you show. It looks like a convention that someone with root privileges on your machine likes as a way to identify other directories, but that's about all.
We could guess that over time, there might eventually be other directories such as ..2019_09_29 and that ..data might be rigged to point to the directory currently being analyzed, but that's guesswork.
There are always two default directories:
single period (.) = Current Directory
Double Period (..) = Parent Directory

Can't run dmidecode on docker container

I am trying to run command dmidecode in my docker container,
docker run --device /dev/mem:/dev/mem -it jin/ubu1604
However, it claims that there is no permission
root#bd1062dfd8ab:/# dmidecode
# dmidecode 3.0
Scanning /dev/mem for entry point.
/dev/mem: Operation not permitted
root#bd1062dfd8ab:/# ls -l /dev
total 0
crw--w---- 1 root tty 136, 0 Jan 7 03:21 console
lrwxrwxrwx 1 root root 11 Jan 7 03:20 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Jan 7 03:20 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Jan 7 03:20 full
crw-r----- 1 root kmem 1, 1 Jan 7 03:20 mem
drwxrwxrwt 2 root root 40 Jan 7 03:20 mqueue
crw-rw-rw- 1 root root 1, 3 Jan 7 03:20 null
lrwxrwxrwx 1 root root 8 Jan 7 03:20 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 Jan 7 03:20 pts
crw-rw-rw- 1 root root 1, 8 Jan 7 03:20 random
drwxrwxrwt 2 root root 40 Jan 7 03:20 shm
lrwxrwxrwx 1 root root 15 Jan 7 03:20 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Jan 7 03:20 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Jan 7 03:20 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Jan 7 03:20 tty
crw-rw-rw- 1 root root 1, 9 Jan 7 03:20 urandom
crw-rw-rw- 1 root root 1, 5 Jan 7 03:20 zero
This confused me. Since I was able to run dmidecode -t system on the host (ubuntu 14.04) fine.
I even followed some advice and set the permission on dmidecode executable
setcap cap_sys_rawio+ep /usr/sbin/dmidecode
It still doesn't work.
Any ideas?
UPDATE
Based on David Maze's answer, the command should be
run --device /dev/mem:/dev/mem --cap-add SYS_RAWIO -it my/ubu1604a
Do this only when you are going to trust what runs in container. For example, if you are test installation procedure on a pristine OS.
Docker provides an isolation layer, and one of the major goals of Docker is to hide details of the host's hardware from containers. The easiest, most appropriate way to query low-level details of the host's hardware is from a root shell on the host, ignoring Docker entirely.
The actual mechanism of this is by restricting Linux capabilities. capabilities(7) documents that you need CAP_SYS_RAWIO to access /dev/mem, so in principle you can launch your container with --cap-add SYS_RAWIO. You might need other capabilities and/or device access to make this actually work, because Docker is hiding the details of what you're trying to access as a design goal.

`cd` to a folder in bash script not working: No such folder [duplicate]

This question already has answers here:
Why can't I change directories using "cd" in a script?
(33 answers)
'\r': command not found [duplicate]
(3 answers)
Closed 4 years ago.
This is my entire script. it is simply to avoid having to type it again and again
cd api
rails s -p 3001 -b 0.0.0.0
cd ..
When I am in the directory of the script and run cd api it works just fine. However when I run the script via ./start_server It does not work. Here is the output of ls -al:
mendel#DESKTOP-LIKG5E5:/mnt/c/Projects/chaverim-update$ ls -al
total 8
drwxrwxrwx 0 root root 512 Apr 13 12:32 .
drwxrwxrwx 0 root root 512 Apr 5 12:40 ..
drwxrwxrwx 0 root root 512 Apr 13 12:09 api
-rwxrwxrwx 1 root root 1237 Apr 5 12:40 boxfile.yml
drwxrwxrwx 0 root root 512 Apr 8 16:54 .bundle
drwxrwxrwx 0 root root 512 Apr 8 16:54 client
drwxrwxrwx 0 root root 512 Apr 13 12:09 .git
-rwxrwxrwx 1 root root 11 Apr 5 12:40 .gitignore
-rwxrwxrwx 1 root root 1097 Apr 5 12:40 LICENSE
drwxrwxrwx 0 root root 512 Apr 5 12:40 nginx
-rwxrwxrwx 1 root root 82 Apr 5 12:40 Procfile
-rwxrwxrwx 1 root root 67 Apr 5 12:40 README.md
-rwxrwxrwx 1 root root 188 Apr 5 12:40 run_tests
-rwxrwxrwx 1 root root 28 Apr 5 12:40 start_client
-rwxrwxrwx 1 root root 41 Apr 13 12:52 start_server
drwxrwxrwx 0 root root 512 Apr 8 16:54 vendor
As you can see there is a folder called api at the top and the start_server script is set to have execution permissions.

Searching shared libraries in Linux

please explain me why on x86_64 Scientific Linux no file under /etc/ld.so.conf.d contains the directory /usr/lib64?
The list of directories to be searched by program loader is stored in the file /etc/ld.so.conf. On my distributive, this file stores this row: include ld.so.conf.d/.conf*
And the above directory consists of:
[root#dev_host build]$ ls -la /etc/ld.so.conf.d
total 36
drwxr-xr-x. 2 root root 4096 Aug 29 23:13 .
drwxr-xr-x. 103 root root 12288 Sep 18 03:41 ..
-rw-r--r--. 1 root root 17 Mar 20 2012 atlas-x86_64.conf
-r--r--r--. 1 root root 324 May 7 23:40 kernel-2.6.32-431.17.1.el6.x86_64.conf
-r--r--r--. 1 root root 324 Nov 22 2013 kernel-2.6.32-431.el6.x86_64.conf
-rw-r--r--. 1 root root 17 Feb 12 2014 mysql-x86_64.conf
lrwxrwxrwx 1 root root 31 Aug 11 14:46 postgresql-pgdg-libs.conf -> /etc/alternatives/pgsql-ld-conf
-rw-r--r--. 1 root root 22 Sep 7 2011 qt-x86_64.conf
I examined all these files - there is no /usr/lib64. Why? Is it stored in /etc/ld.so.cache?

Resources