Trying to trigger scans from fujitsu ScanSnap iX500 using CLI, defining a specific scanner.
scanimage --device 'fujitsu:ScanSnap iX500:[s/n]' --resolution 300 --batch=Scan-p%d.pnm --format=pnm --mode color
The error from that: scanimage: open of device fujitsu:ScanSnap iX500:[s/n] failed: Invalid argument
The --device entry was derived from sudo scanimage -L
The following variations of --device return the same error:
fujitsu:ScanSnap iX500
fujitsu:ScanSnap
fujitsu
Removing the --device option removes the error, BUT causes the command to search for a locally-attached device, which introduces a long delay. Targeting the --device in the hopes of eliminating the delay.
From https://linux.die.net/man/1/scanimage : there is no parameter "--device" for the scanimage command.
Maybe you want to use -d or --device-name and follow the advices given in the manual:
The -d or --device-name options must be followed by a SANE device-name like 'epson:/dev/sg0' or 'hp:/dev/usbscanner0'. A (partial) list of available devices can be obtained with the --list-devices option (see below). If no device-name is specified explicitly, scanimage reads a device-name from the environment variable SANE_DEFAULT_DEVICE. If this variable is not set, scanimage will attempt to open the first available device.
The problem, it turns out, was not in the naming of the device. (The name returned by sudo scanimage -L is the correct one to use and works fine.
The issue has to do with permissions / user
Running the command under the .sh file used appropriate permissions. Running directly in command line must have used another user, even though both were executed under the same ssh session.
Solution: Choose the right login user. In my case adding sudo before the command (which was not included or necessary in the .sh file) resolved the issue.
Related
I am trying to connect to a server via SSH from my C++ application (and send a shut-down command). I have informed the server about my SSH-key (updated authorized_keys on my FreeBSD-based Freenas server).
The following console command works instantly (Manjaro Linux console):
ssh -i /home/[uname]/.ssh/amd_freenas root#freenas.local poweroff
I'm trying to use the following command from my C++ code to do exactly the same:
execl("/sbin/ssh", "ssh", "-i /home/[uname]/.ssh/amd_freenas", "root#192.168.178.48", "poweroff", (char*)NULL);
When called from my program, the console output consistently says, that my SSH-file does not exist, which is not true, since the direct console command has no issues either (picture shows comparison, upper command was from code, bottom one was in the console directly).
The error output is:
Warning: Identity file /home/al/.ssh/amd_freenas not accessible: No such file or directory.
I have tried to change permissions on the file (chmod 600), I tried to move it elsewhere and read it from there. I have no clue why this does not work. The file is my private key, so that should be correct. Can somebody help?
enter image description here
execl("/sbin/ssh", "ssh", "-i /home/[uname]/.ssh/amd_freenas", ...
Warning: Identity file /home/al/.ssh/amd_freenas not accessible
^^
ssh is interpreting the space following the -i as part of the filename. You can see that there's an extra space before the name of the key file in the error message, because ssh thinks the name has a leading space.
You should specify the parameter in one of these ways:
execl("/sbin/ssh", "ssh", "-i", "/home/[uname]/.ssh/amd_freenas", ...
or
execl("/sbin/ssh", "ssh", "-i/home/[uname]/.ssh/amd_freenas", ...
This is script content, located in /etc/init.d/myserviced:
#!/lib/init/init-d-script
DAEMON="/usr/local/bin/myprogram.py"
NAME="myserviced"
DESC="The description of my service"
When I start the service (either by calling it directly or by calling sudo service myserviced start), I can see program myprogram.py run, but it did not return to command prompt.
I guess there must be something that I misunderstood, so what is it?
The system is Debian, running on a Raspberry Pi.
After more works, I finally solved this issue. There are 2 major reasons:
init-d-script actually calls start-stop-daemon, who don't work well with scripts specified via --exec option. When killing scripts, you should only specify --name option. However, as init-d-script always fill --exec option, it cannot be used with script daemons. I have to write the sysv script by myself.
start-stop-daemon won't magically daemonize the thing you provide. So the executable provided to start-stop-daemon should be daemonized itself, but not a regular program.
I'm using AWS Codedeploy to deploy my code from GitHub to AWS EC2 instance(Windows 2008 server). Deployment fails in DownloadBundle event
Error stack in logs of AWS :
No such file or directory - C:\ProgramData/Amazon/CodeDeploy/4fbb84fd-caa5-4d1a-9894-16b25abcea76/d-QUPXMDBCF/deployment-archive-temp/My-Application-163e9d3343be82038fe2e5c58a9fcae86683d4ea/src/main/java/com/myapp/dewa/customexceptions/EventNotPublishedException.java
The problem here might be with the file path limit of windows.
UPDATE: AWS CodeDeploy Support team has confirmed that this is a limitation from their side. More than half of the file path is being used by CodeDeploy because of which limit is being exceeded
Have you replaced some strings from the file_path and/or file_name?
This error you get when the total length of the file_path is beyond 260 characters. This length includes one null character at the end for termination. Your total length is 239+1 = 240.
For reference, please see this article: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
If you check the path in the destination, you should not see the file because it was not copied but it is in your revision zip file.
In my case, the total length was 266. It may not be possible to shorten the strings of the actual file path in the revision since lots of them are created by the developer tools. Amazon is investing at their end now to see how to overcome this.
You can test and confirm by doing the following:
Run the following command in the command prompt to create the deployment archive folder:
mkdir "c:\ProgramDat0/Amazon/CodeDeploy/4fbb84fd-caa5-4d1a-9894-16b25abcea76/d-QUPXMDBCF/deployment-archive-temp"
Simply try to extract your revision zip file directly under 'deployment-archive-temp' folder.
You should received the following error for file crossing the maximum path length of 260:
'Error 0x80010135: Path too long'
Ref: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
I hope this helps.
While not a complete solution, I've experienced the same problem and we were able to remove the preceding 'ProgramData\Amazon\CodeDeploy' to save 29 characters if you can stand the mess in your root folder.
To do this we modified the conf.yml file located in c:\programdata\amazon\codedeploy\
I changed ... root_dir: 'Amazon\CodeDeploy' ... to ... root_dir: 'C:\'
If you are using Windows 2016, setting the value to 1 for the following registry entry will fix the issue with long paths.
HKLM:SYSTEM\CurrentControlSet\Control\FileSystem
Referencing iskandar's post this can be done through a powershell script if you wish to automate it in something like a startup script.
# #see https://github.com/aws/aws-codedeploy-agent/issues/46
# #see https://learn.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#paths
Write-Verbose "----> Enabling Long Path Support"
$RegistryPath = "HKLM:SYSTEM\CurrentControlSet\Control\FileSystem"
$Name = "LongPathsEnabled"
New-ItemProperty -Path $RegistryPath -Name $Name -Value 1 -PropertyType DWORD -Force | Out-Null
# You'll want to reboot to make sure; this is Windows we're working with.
Restart-Computer
You can also use the GUI method outlined in this post.
Note - either method will definitely require a restart for the setting to take affect
I am trying to start / stop CAN boards or to update their baudrate using SocketCAN from userspace. My tests are performed on PeakSystem and IXXAT USB-to-CAN V1/V2 boards.
My first attempt was to use visudo and to enable NOPASSWD to "ip link set ...", and then to call "sudo ip link set ..." in my C++ code.
Complete visudo line is:
%sudo ALL=(ALL:ALL) NOPASSWD: /bin/ip link set can[0123456789]* type can bitrate [0123456789]*, /bin/ip link set can[0123456789]* up, /bin/ip link set can[0123456789]* down
Then, I tried with Linux capabilities by adding capabilities to /bin/ip. That allows me to call "ip link set ..." from my C++ code which was even better.
Add capabilities command:
sudo setcap cap_net_raw,cap_net_admin+ep /bin/ip
But then I discovered libsocketcan which is a far better approach than calling command lines from C++. However when calling "can_set_bitrate" or "can_do_start", I have an error "RTNETLINK: Operation not permitted". But things are working fine when my program is launched as root. Other functions like can_get_state are working fine in userspace (actually, they are returning : 4 -> CAN_STATE_STOPPED).
I tried to adding capabilities to my program without any success ""sudo setcap cap_net_raw,cap_net_admin+ep ./myprogram".
How can I allow my program to use libsocketcan in userspace?
Thanks for your help!
sudo setcap cap_net_raw,cap_net_admin+ep your_executable is the solution. You may need to compile with -Wl,-rpath so your program finds its shared libraries (also see this answer)
I successfully compiled a MUD source code, and it says in the instructions to start up the server using
nohup ./startup &
although when I do this it gives me this error:
$ nohup: ignoring input and appending output to `nohup.out'
nohup: failed to run command `./startup': Permission denied
I have looked all over the internet to find the answer. A few of them said to put my cygwin directory in the root folder (I am using windows 7) and its directory is C:\cygwin
so thats not a problem.. Can anyone help me with this please??
Try chmod +x startup, maybe your startup file is not executable.
From "man nohup":
If the standard output is a terminal, all output written by the named
utility to its standard output shall be appended to the end of the
file nohup.out in the current directory. If nohup.out cannot be
created or opened for appending, the output shall be appended to the
end of the file nohup.out in the directory specified by the HOME
environment variable. If neither file can be created or opened for
appending, utility shall not be invoked. If a file is created, the
file's permission bits shall be set to S_IRUSR | S_IWUSR.
My guess is that since "sh -c" doesn't start a login shell, it is inheriting the environment of the invoking shell, including the HOME environment variable, and is trying to open it there. So I would check the permissions of both your current directory and $HOME. You can try to touch test.txt in current directory or $HOME to see if you can perform that command.
As staticx writes, check the permissions of the directory (and the user) - and the executable.
Instead of using nohup:
check if nohup is needed at all, try ./startup </dev/null >mud.out 2>mud.err &, then close the terminal window and check if it is running
or just run ./startup in a screen session and detach it (<ctrl>+<a>,<d>)