I have a printer problem when I want to print a document, the printer queue says "backend failed" and then pause.
My computer is mac os x, version is sierra 10.12.6, and printer is Canon IR ADV4235 using smb protocol to access.
I have tried the following ways:
download the latest driver from Canon website, and reinstall the driver
remove the old printer
add new printer
but still the same problem.
So, I want to find the specific error, and I searched /var/log with keyword "backend" but no related result.
Could anyone provide some help?
Thanks in advance.
UPDATE:
Using the command cupsctl --debug-logging，I got more messages. The following error messages seem to be helpful.
D [31/Jul/2017:13:47:44 +0800] [Job 25] PID 55276 (/usr/libexec/cups/backend/smb) crashed on signal 4.
...
D [31/Jul/2017:13:47:46 +0800] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Printing jobs and dirty files"
D [31/Jul/2017:13:47:46 +0800] [Job 25] PID 55275 (/Library/Printers/Canon/CUPS_Printer/Bins/capdftopdl) stopped with status 1.
I [31/Jul/2017:13:47:46 +0800] [Job 25] Backend returned status -4 (crashed)
D [31/Jul/2017:13:47:46 +0800] Discarding unused job-state-changed event...
I [31/Jul/2017:13:47:46 +0800] [Job 25] Printer stopped due to backend errors; please consult the error_log file for details.
But, I tried to run /usr/libexec/cups/backend/smb, it was ok. I don't know if other parameters will cause it crashed.
Could anybody give me a hint?
The log file you want is /var/log/cups/error_log, but by default it doesn't contain much info. You can increase the logging a great deal by turning on debug logging with cupsctl --debug-logging (and turn it off with cupsctl --no-debug-logging). In macOS 10.12 this takes effect immediately, but in some older versions you needed to restart the cups daemon with sudo launchctl stop org.cups.cupsd.
Related
Starting 2020-12-09, VSCode's Rust Analyzer extension no longer loads for me. On launch, it prints out this error message:
Cannot activate rust-analyzer: bootstrap error. See the logs in "OUTPUT > Rust Analyzer Client" (should open automatically). To enable verbose logs use { "rust-analyzer.trace.extension": true }
Enabling extension tracing produces the following diagnostic just before failing:
INFO [12/10/2020, 10:03:22 AM]: Using server binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: Checking availability of a binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe --version: {
status: 3221225506,
signal: null,
output: [ null, '', '' ],
pid: 1648,
stdout: '',
stderr: ''
}
where <user> is the name of the user account I use to log into the system1.
The status value reported in the error diagnostic (3221225506) translates to 0xC0000022 (STATUS_ACCESS_DENIED). Navigating to the binary from within VSCode's integrated terminal and trying to execute rust-analyzer-windows.exe --version doesn't produce any output, which seems to reinstate that running this executable from VSCode is somehow blocked.
It appears that something changed with respect to access rights executing the server binary from within VSCode. In between Rust Analyzer working and Rust Analyzer no longer working I didn't update Rust, nor rustup, nor VSCode, nor any extensions.
I did install 2020-12 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB4592438), though, and the time Rust Analyzer started failing coincides with the time the update got installed. That could literally just be a coincidence.
What additional steps can I take to get to the root cause of the issue, and how do I get Rust Analyzer working again?
Version information:
Rust Analyzer (stable): v0.2.408
Windows 10 Pro: Version 10.0.19042 Build 19042
VSCode: 1.51.1 (user setup)
1 This is also the user account VSCode runs under, including all of its spawned processes. Navigating to the path from a command prompt running under this account reveals that rust-analyzer-windows.exe is present, and executing rust-analyzer-windows.exe --version prints a version identifier, as expected.
Unfortunately, I didn't quite get to investigate the root cause of this.
A system reboot that was forced upon me appears to have restored World Peace.
Clearing proxy config works for me.
I'm not sure this covered all situation, but it might be related to the network.
I noticed every time I launch a Playground in Xcode (version 9.3) a daemon starts in the background and uses more that 100% of my CPU!
I deleted Xcode's cache and its DerivedData folder but no change.
Does anyone know how to resolve this problem?
diagnosticd is a daemon you need to stop/kill with launchctl. The daemon you most likely need to stop has 'SimDevice' in its name. To get the exact name do:
/bin/launchctl list | grep SimDevice
Then with the appropriate name(s) (there could be more than 1) do:
/bin/launchctl stop 'name'
In my case 'name' was: com.apple.CoreSimulator.SimDevice.380EFF06-B636-49CD-851E-5DB4890641AE
If you use Playground a lot and you usually have more than 1 simulator eating your CPU run this script instead:
/bin/launchctl list | grep SimDevice | awk '{print $3}' | xargs -I %s /bin/launchctl stop %s
Oh, and dont forget to file a bug report with apple here: https://bugreport.apple.com/web/
Btw, its kinda fun to see playground/diagnosticd struggle with your code; if you create a bug or some other elaborate syntax, cpu goes up. If you clear it, cpu goes down (just a bit). Almost hilarious how Apple implemented this...
As a temporary workaround, I run this script after starting up a playground to kill the rogue diagnosticd and homed processes:
#!/bin/bash
kill $(ps -ef | grep Xcode.app | egrep "diagnosticd|homed" | awk '{ print $2 }')
Edit: This seems to be a problem with iOS playgrounds only, so another (less drastic) workaround is to use a macOS playgrounds for those cases where no UIKit components are needed.
2nd Edit: This bug appears to be fixed in Xcode 9.3.1 (available via MAS or direct download from developer.apple.com)
3rd Edit: 9.3.1 doesn't fully fix this, despite what the Release Notes say. According to the comments in my bug report, this is only be fully fixed in 9.4.
Get Xcode 9.4 Beta. It resolved my issue.
killing homed is not good solution and playground is not acting correctly anyway.
Had same issue and there was no way around it. People filed bugs as far back as April 8th.
Best solution is to download Xcode 9.4 Beta from Apple Developer Page.
This worked for me and CPU usage is low and Xcode doesn't crash on playgrounds anymore.
I also had the same issue with Xcode v 11.2.1(11B53)
It seems the issue happened after updating Mac OS and Xcode.
I found out that diagnosticd has something to do with Xcode simulators.
So I tried to Erase All Content and Settings... in Simulator menu.
Please refer to above picture.
After erasing all content and settings the issue was resolved. :D
This is a known bug, attributed by Apple to “over-enthusiastic logging by the MediaRemote subsystem”. There is no official workaround at this time.
See https://forums.developer.apple.com/message/305885
Same problem here, the only temporary solution I found was to kill 'homed', which was flooding the system with errors like
MediaRemote reply error: <error: 0x11162ed20> { count = 1, transaction: 0, voucher = 0x0, contents =
"XPCErrorDescription" => <string: 0x11162efc8> { length = 18, contents = "Connection invalid" }
}
I suppose diagnosticd, designed to report errors automatically, simply went in overdrive mode.
That's all I have for now...
I'm working on processing SNMP traps from CISCO devices by check_mk 1.2.8p20 version. The configuration is in progress and I've have already untranslated traps in Event Console.
Here (http://mathias-kettner.com/cms_ec.html) is simple instruction how to do it but it doesn't work. I followed instruction contained in 7.3 and 7.4 chapter and still nothing. I have around 2500 MIB files from tools.cisco dot com/ITDIT/MIBS/MainServlet
In directory /omd/sites/mySite/local/share/check_mk/compiled_mibs are all of my mibs complied by check_mk, but I had a problem with uploading:
Failed to compile your module: no module "ADSL-LINE-MIB" in symbolTable at MIB ADSL-DMT-LINE-MIB
and
You are missing the needed pysmi python module (cannot import name defaultMibPackageds).
I've solved it by clue founded in this page:
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=becad1bc22064ed7287aeec5b086e2d4edf6c010
A few days ago when I turned on SNMP trap translation first time (7.3, mathias-kettner dot com/cms_ec.html) it seemed to partialy work.
For instance:
SNMPv2-SMI::enterprises.9.0.1 SNMPv2-MIB::sysUpTime.0: 217843968 , SNMP-COMMUNITY-MIB::snmpTrapAddress.0: 172.16.5.5 , SNMP-COMMUNITY-MIB::snmpTrapCommunity.0: , SNMPv2-MIB::snmpTrapEnterprise.0: SNMPv2-SMI::enterprises.9 , SNMPv2-SMI::enterprises.9.2.9.3.1.1.2.1: 6, SNMPv2-SMI::mib-2.6.13.1.1.172.16.1.1.22.136.62.73.219.36158: 8, SNMPv2-SMI::enterprises.9.2.6.1.1.5.172.16.1.1.22.136.62.73.219.36158: 408, SNMPv2-SMI::enterprises.9.2.6.1.1.1.172.16.1.1.22.136.62.73.219.36158: 2565, SNMPv2-SMI::enterprises.9.2.6.1.1.2.172.16.1.1.22.136.62.73.219.36158: 1456, SNMPv2-SMI::enterprises.9.2.9.2.1.18.2: minera
but now traps are untranslated although appropriate MIBs are loaded and SNMP traps translation option is turned on:
1.3.6.1.4.1.9.0.1 1.3.6.1.2.1.1.3.0: 455413843, 1.3.6.1.6.3.18.1.3.0: ¬, 1.3.6.1.6.3.18.1.4.0: , 1.3.6.1.6.3.1.1.4.3.0: 1.3.6.1.4.1.9, 1.3.6.1.4.1.9.2.9.3.1.1.1.1: 6, 1.3.6.1.2.1.6.13.1.1.172.16.1.1.22.80.229.253.212.35849: 1, 1.3.6.1.4.1.9.2.6.1.1.5.172.16.1.1.22.80.229.253.212.35849: 4246, 1.3.6.1.4.1.9.2.6.1.1.1.172.16.1.1.22.80.229.253.212.35849: 23, 1.3.6.1.4.1.9.2.6.1.1.2.172.16.1.1.22.80.229.253.212.35849: 388, 1.3.6.1.4.1.9.2.9.2.1.18.1:
Anybody have some clue for me?
PS. All changes in check_mk were saved and config was reloaded.
I'm trying to serve a big number of small files with G-WAN (version 4.3.14, started with sudo on 64-bit Ubuntu 14.04.3). I start hammering it with requests over a single connection using wget to provide base URL and a file with a list of the URL suffixes. At some point, which is different for different runs, the gwan executable silently exits. There's no trace in the gwan log or in the site error log (I did change '_log' to 'log' to enable logging). The exit status code is 139. What does it mean? When I stop it with Ctrl-C the exit code is 130.
Is there a reference for the exit status codes? I cannot find any with Google.
First, Ubuntu 14.04.3 is very recent while G-WAN v4.3.14 is very old. Almost every new OS release introduces cincompatibilities that require patches and this is why we have to issue more recent releases for registered users. This explains the 'silent exits' that you are experiencing.
Second, process exits codes can be found this way:
./gwan -h
echo $?
0
Zero means no error, and any other value is an error (mixing system flags to be as informative as possible). That's why Ctrl+C returns 130: Control-C is fatal error signal 2, (130 = 128 + 2).
How can I invoke/simulate process/daemon crash on OSX and as result to receive crash report in
/Library/Logs/DiagnosticRepors
(e.g. opendirectoryd_2013-06-11-125032_macmini61.crash)?
I tried to make force quit for daemons using Activity Monitor but didn't receive any report. I need to crash some system or third party process (NOT developed by myself).
You can force almost any process to crash by sending it a "segmentation violation" signal.
Example: Find process id of "opendirectoryd":
$ ps -ef | grep opendirectoryd
0 15 1 0 9:14am ?? 0:01.11 /usr/libexec/opendirectoryd
^-- process id
Send signal to the process:
$ sudo kill -SEGV 15
This terminates the process and causes a diagnostic report to be written,
as can be verified in "system.log":
Oct 31 09:17:17 hostname com.apple.launchd[1] (com.apple.opendirectoryd[15]): Job appears to have crashed: Segmentation fault: 11
Oct 31 09:17:20 hostname ReportCrash[420]: Saved crash report for opendirectoryd[15] version ??? (???) to /Library/Logs/DiagnosticReports/opendirectoryd_2013-10-31-091720_localhost.crash
But note that deliberately crashing system services might cause severe problems (system instability, data loss, ...), so you should know exactly what you are doing.
Unless you can find a legitimate bug and get it to crash that way, you can't externally crash a daemon in such a fashion that it will result in a diagnostic report. All of the quit-forcing functions are exempt from diagnostic reports as they are external issues.