Udev-Rule with "PROGRAM" statement is nor executed anymore after update to ubuntu 22.04.1 - udev

I'm running a udev rule on my 3D printing server to automatically create easily identifyable symlinks to some attached microcontroller boards, which worked perfectly fine on ubuntu 20.04.
The rule triggers on the usb vendor and product ids and runs a python script via the PROGRAM directive. The script connects to the Microcontroller boards and reads it's init sequence to get the board's 'name'. It then outputs a string like "aaaaaaa b cccccc" and only the first block (containing the name) is used in the udev rule.
However, it seems like the whole PROGRAM directive is not executed at all anymore, since I updated my system to ubuntu 22.04.1.
My udev rule currently looks like this (While debugging. Regularly it just contained lines 1 and 3. I added #2 for testing purposes because the hook in line 1 works and that script is executed):
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", RUN="/bin/su me -c \"/opt/me/deviceReg.py -d %k -a %E{ACTION}\""
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}!="AI046A0Q", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QXPRV7", SYMLINK+="tty_MainSwitch", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QOIMJ6", SYMLINK+="tty_Cooler", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9PTMHGV", SYMLINK+="tty_CurrentTransformer", GROUP="dialout", OWNER="me", GOTO="script_end"
The python scripts write to some logfiles which clearly indicate that only lines 1 and 4, 5 or 6 are executed.
Is there anything in line 3 that isn't supported anymore in the latest udev version? As I said, line 3 worked perfectly before I updated the system.
The last 3 lines are my current workaround. They work fine but that's not what I want to achive with this whole naming system at all.
The python script in lines 2 & 3 runs perfectly fine, either if called as standard user or as root. It would also deliver valid output if the '-s ' input data is not matching the uc board, is missing or is random garbage.
Does anyone have an idea why the script omits any line with a PROGRAM statement?

Ok, I was able to solve the issue.
I set udev's log level to debug too see what's actually happening when the device is handled. The script actually IS invoked but immediately failed during importing needed modules: The pyserial module could not be found.
The module is installed though, but obviously in a way it could not be imported.
However, I checked the python script again and changed the first line from #!/usr/bin/env python3 to #!/usr/bin/python3 and now it works again.
So my problem actually wasn't related to udev at all, it was just my python script.

Related

Chrome debugging port not open after 10 seconds

I am using following code: It works good on local system and one unix server, but fails on another server. Any idea what I might need to do
> library(chromote)
> set_default_chromote_object(
Chromote$new(browser = Chrome$new(args = "--no-sandbox"))
and I am getting following error:
Chrome debugging port not open after 10 seconds.
Two things you can check:
On the server in question, start chrome and go to chrome://version/ . Search the Command Line: section and make sure --enable-logging is in there.
Strat R on the server in question, and do:
library(chromote)
debug(chromote:::launch_chrome)
Now run that R-code in as normal and when it stops and waits for input, hit n and then enter and repeat hitting enter until you get to the lines you link to on github. After line 87 when output gets defined, type output on the terinal and hit enter. Inspect the output and make sure that it actually conatins the lines DevTools listening on ws:// . If it does not, see if there are other ways that logging text identifies the port it listens to. If so, I would git clone that package, go in and change the way it discovers the port number and modify the package that runs for that server.
Running Chrome without X server
There are two viable options here:
vnc
X.org dummy driver
Here is the VNC recipe:
1: VNC
a. sudo dnf install tigervnc-server (for centos 8), sudo yum install tigervnc-server (for centos 7)
b. vncserver :1 (or some other suitable number)
c. DISPLAY=:1 R # and run R code to launch chrome etc.
Now you can connect from your client and see that chrome runs as it should:
vncviewer centos.ip.address:1
2: X.org dummy
I have never done this myself, but in theory it should be straight forward if you read docs and follow a tutorial.

Systrace - error truncating /sys/kernel/debug/tracing/set_ftrace_filter: No such device (19) unable to start

I am currently working on a project which aims to find out what the system is doing behind a series of user interaction on the android UI. For example, if user click send button in Facebook Messenger, the measured response time for such action is 1.2 seconds. My goal is to figure out what the 1.2 seconds consist of. My friend suggested that I should take a look into 'Systrace'.
However, when I tried systrace on my HTC one M8, I have encountered some problems:
First, error opening /sys/kernel/debug/tracing/options/overwrite - no such file or directory. I solved this problem by building up the support of the kernel following http://opensourceforu.com/2010/11/kernel-tracing-with-ftrace-part-1/ and mount -t debugfs none /sys/kernel/debug. Then I could find the tracing directory. Besides, I set ro.debuggable=1 in file default.prop within Ramdisk and burn the boot.img into my phone.
Now I encounter another problem: when I run - python systrace.py --time=10 -o mynewtrace.html sched gfx view wm, the following error(19) pop up: error truncating /sys/kernel/debug/tracing/set_ftrace_filter: No such device (19). I don't know if the way my building up kernel support for systrace is incorrect or anything is missing.
Could anyone helps me out with this problem, please?
I think I have worked out the solution. My environment is Ubuntu 16.04 + HTC one M8. I will write the steps as followed:
open terminal and enter: $adb shell
(1) $su (2) $mount -t debugfs none /sys/kernel/debug. Now you should be able to see many directories under /sys/kernel/debug/. (You may cd into /sys/kernel/debug to confirm this)
New a new terminal and enter: dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/sdcard/boot.img to generate the boot.img kernel image from your device.
Use AndroidImageKitchen to unpack the boot.img and find the default.prop within Ramdisk folder. Then change ro.debuggable=0 to ro.debuggable=1. Repack the boot.img and flash boot it to your device.
Once the device boot, under terminal, enter: adb root and message like: restarting adbd as root may pop up. Disconnect the USB and connect again.
cd to the systrace folder, e.g. ~/androidSDK/platform-tools/systrace and use:
python systrace.py --time=10 -o mynewtrace.html sched gfx view wm
Now you may able to generate your own systrace files.

Configuring Nexus 3 (3.0m7) to run as a Linux Service

Can anyone help me translate the instructions for setting this up as a Linux Service (at http://books.sonatype.com/nexus-book/3.0/reference/install.html#service-linux) into English?
After following them as best I could, I get the following when starting the service:
su: user / does not exist
Here are the parts of the instructions which were unclear:
In the bin/nexus script remove the line below.
INSTALL4J_JAVA_PREFIX="su - $run_as_user -c"
The line in the file is actually
INSTALL4J_JAVA_PREFIX=""
but ok, I can remove that. However, the next instruction is:
Replace the entire link with this line:
exec su - $run_as_user "$prg_dir/$progname" $#
What is meant by "the entire link"? The thing I removed above? That was the first line in the file - therefore the three variables above have not yet been set.... and is probably the reason the script currently fails.
I'll get the book fixed, it shouldn't have this in it anymore.
Download the 3.0 release, this was just a bug in 3.0m7, and it has been fixed. You don't need to make these changes.
https://support.sonatype.com/hc/en-us/articles/217965118
The only things you need to do is edit $NEXUS_HOME/bin/nexus.rc, uncomment the run_as_user line, and set the value for it appropriately. Then just symlink $NEXUS_HOME/bin/nexus to /etc/init.d/nexus, and after that run chkconfig or update-rc.d depending on your Linux version.

Phabricator Making Assumptions About Environment

I am attempting to get Phabricator running on Solaris over apache. The website is working, but all of the cli scripts are not. For example, phd.
The first problem, is that it is not passing arguments to the underling manage-daemons.php script that it invokes. Looking at the phd file, this does not surprise me:
$> cat phd
../scripts/daemon/manage_daemons.php
Now, given my default shell is bash, this isn't going to pass-through my arguments. To do this, I have modified the script:
#! /bin/bash
../scripts/daemon/manage_daemons.php $*
This will now pass-through the arguments, but it's now failing to find transative scripts it requires via relative path:
./phd start
Preparing to launch daemons.
NOTE: Logs will appear in '/var/tmp/phd/log/daemons.log'.
Launching daemon "PhabricatorRepositoryPullLocalDaemon".
[2014-05-09 19:29:59] EXCEPTION: (CommandException) Command failed with error #127!
COMMAND
exec ./phd-daemon 'PhabricatorRepositoryPullLocalDaemon' --daemonize --log='/var/tmp/phd/log/daemons.log' --phd='/var/tmp/phd/pid'
STDOUT
(empty)
STDERR
./phd-daemon: line 1: launch_daemon.php: not found
at [/XXX/XXX/libphutil/src/future/exec/ExecFuture.php:398]
#0 ExecFuture::resolvex() called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementWorkflow.php:167]
#1 PhabricatorDaemonManagementWorkflow::launchDaemon(PhabricatorRepositoryPullLocalDaemon, Array , false) called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementWorkflow.php:246]
#2 PhabricatorDaemonManagementWorkflow::executeStartCommand() called at [/XXX/XXX/phabricator/src/applications/daemon/management/PhabricatorDaemonManagementStartWorkflow.php:18]
#3 PhabricatorDaemonManagementStartWorkflow::execute(Object PhutilArgumentParser) called at [/XXX/XXX/libphutil/src/parser/argument/PhutilArgumentParser.php:396]
#4 PhutilArgumentParser::parseWorkflowsFull(Array of size 9 starting with: { 0 => Object PhabricatorDaemonManagementListWorkflow }) called at [/XXX/XXX/libphutil/src/parser/argument/PhutilArgumentParser.php:292]
#5 PhutilArgumentParser::parseWorkflows(Array of size 9 starting with: { 0 => Object PhabricatorDaemonManagementListWorkflow }) called at [/XXX/XXX/phabricator/scripts/daemon/manage_daemons.php:30]
Note I have obscured my paths with XXX as they give away sensitive information.
Now, obviously I shouldn't be modifying these scripts. This is an indication that some prerequisite is not set up properly.
It's clear to me that Phabricator is making some (bold) assumption about my setup. But I'm not quite sure what...?
These are supposed to be symlinks. For example, if you look at "phd" in the repository on GitHub, you can see that the file type is "symbolic link":
https://github.com/facebook/phabricator/blob/master/bin/phd
Something in your environment is incorrectly turning the symlinks into normal files. I'm not aware of any Git configuration which can cause this, although it's possible there is something. One situation where I've seen this happen is when a working copy was cloned, then copied using something like rsync without appropriate flags to preserve symlinks.

phpagi script randomly stops

For some reason phpagi script randomly stop's in the middle. This only happens once every 20-50 calls. I was able to notice several such 'fails' realtime in asterisk CLI. No error's were displayed. Script sent several verbose messages until just stopped.
Script is used for billing, it has several while's and sql queries. max execution time set to 30seconds.
I didn't find any errors in the /var/log/messages or /var/log/asterisk/messages
Asterisk 1.6.2.24
PHP 5.1.6 (cli) (built: Jun 27 2012 12:21:13)
[context-x]
exten => 1,1,Dial(SIP/XXXXXX)
exten => h,1,AGI(script.php)
Any ideas why it could just stop for random calls?
Thanks.
UPDATE:
I've just noticed that when the problem occurs AGI returns 4:
-- <SIP/xxxxxx-00000185>AGI Script script.php completed, returning 4
What's wrong?
From what I'm hearing from your symptoms, it doesn't sound like it's specifically an Asterisk issue, but, could be an issue with your script. Here's a number of tips regarding how I would go about debugging an application without any knowledge of what's happening behind the scenes of the AGI script itself...
Firstly, AGI Script script.php completed, returning 4 means that your script is exiting without a clean exit status code. returning 0 is what you'd like to see. You can see the last exit status code at your bash prompt by running a script and then checking the status code with the $? variable. Like so:
[user#host ~]$ ./script.php
[user#host ~]$ echo $?
0
That's what Asterisk is telling you what happened to your script. Anything non-zero is "something's wrong here". Generally, you can customize these to your liking, so specifically 4, I'm not sure.
One thing you'll want to do is turn on agi debugging like so:
host*CLI> agi set debug on
Then run your script, and see if you can find that your php script is spitting out any errors.
Another recommendation that I would have is to make sure your php is logging to your syslog so that you can find errors in /var/log/messages. You can do this by setting in your /etc/php.ini this line:
error_log = syslog
Lastly, to try to replicate the error, I would suggest using a development box, and originate a bunch of calls for yourself, and build a script to create a bunch of "call files".
Here's a call file to get you started:
Channel: LOCAL/100#mycontext
MaxRetries: 2
RetryTime: 60
WaitTime: 30
Application: Wait
Data: 30
When you've created a file, move it to /var/spool/asterisk/outgoing (Moving is important, you want the pointer move, because asterisk may pick up the file too soon if you're writing to it in that directory first).
You can also originate a call on an extension from the CLI:
host*CLI> channel originate LOCAL/100#mycontext application Wait 5
You may also want to use other options in the call file, such as CallerID: John Doe <8005551212> in order to feed interesting data to your AGI application while you create tests to replicate the issue.

Resources