localhost:631 printer problem (SOLVED)

scottro said:
tingo, I'm not familiar with that use of one character in a bracket, and I can't find a web page search term that is working for me. (Nor skimming through some regex sites). Would you mind explaining why that [c]ups doesn't show the grep PID?
Thanks.

And as soon as I posted that I found the answer, that it prevents grep from matching itself. Going to add a thanks though, as I hadn't known about that one, and it is useful, in my opinion.
Click to expand...
Keep in mind this "quirk" is shell dependent. bash and sh will be fine. You might not get what you expect using csh/tcsh. Try it! :)
 
For completeness: it is documented in "Shell Patterns" in the sh(1) man page.
If you use csh, you need to escape the relevant characters:
Code: 
tingo@kg-core2:~ % ps aux | grep cups
root         679    0.0  0.0    82684    4708  -  Is   15Feb21      0:00.23 /usr/local/sbin/cupsd -
tingo      67469    0.0  0.0     6652    2296 39  S+   13:29        0:00.00 grep cups

tingo@kg-core2:~ % ps aux | grep \[c\]ups
root         679    0.0  0.0    82684    4708  -  Is   15Feb21      0:00.23 /usr/local/sbin/cupsd -
 
chrbr said:
Please run as root service cupsd onestart and see if there will be an output as on my system.
Click to expand...
command in xterm says 'cupsd already running (pid=1077)'
Does that get me any closer to establishing why I can't open localhost:631?
 
tingo said:
Here is a tip to avoid false positives when using grep: ps aux | grep [c]ups. Example to show the difference:
Code: 
tingo@kg-core2$ ps aux | grep cups
root         679    0.0  0.0    82684    4708  -  Is   15Feb21      0:00.23 /usr/local/sbin/cupsd -
tingo      65992    0.0  0.0     6652    2296 39  S+   22:34        0:00.00 grep cups
tingo@kg-core2$ ps aux | grep [c]ups
root         679    0.0  0.0    82684    4708  -  Is   15Feb21      0:00.23 /usr/local/sbin/cupsd -
this is just one of the useful things you can do with regexps...
Click to expand...
I'm a relative newbie to FBSD so I am struggling with the significance of the 2nd line being missing in your example. My output is 'no match'. What Is the
significance of that response?
 
Short, generic, explanation; ps -aux shows a list of processes, grep(1) is a search command. When you pipe the output from one command to grep(1) it only shows lines that have the keyword you searched for. If it prints "no match" it means it didn't find anything. You searched the ps(1) output for 'cups' (that's what ps -aux | grep 'cups' does) and there's nothing matching, which means there's no process running that resembles the 'cups' search key. In other words, the process isn't running.

Normally when you use grep on the process list you also find the grep(1) process itself. Because that too has the keyword you're looking for. The trick with the square brackets prevents the grep(1) process itself from showing up. The reason being that the literal string '[c]ups' doesn't match with the keyword 'cups' that's searched for. Traditionally you would use ps -aux | grep 'cups' | grep -v grep to filter out the grep process itself. Within scripts is usually better to use pgrep(1), that will never show the grep process itself.
 
mark_j said:
.
You mentioned a firewall? We can rule out the firewall by finding the pid of cupsd and truss -p {cupsd_pid_number} and then try to connect via your browser. If a bunch of stuff scrolls on the screen, you're connecting. If not, it's the firewall.
Click to expand...
response is 'no such process'
 
I'm very appreciative of all the responses thus far guys but I need to say that I seem to be no closer to solving the localhost:631 negative.
Any more suggestions/ Thanks.
 
dalpets said:
command in xterm says 'cupsd already running (pid=1077)'
Does that get me any closer to establishing why I can't open localhost:631?
Click to expand...
Please check that. You can run as below
Code: 
 ls -l /var/run/cups/cupsd.pid
-rw-r--r--  1 root  cups  5 30 März 17:44 /var/run/cups/cupsd.pid
If the file is older than your latest reboot you might delete it.
But just if you do not see cupsd in the ps aux output.
 
Does service cupsd status also say that cupsd is running? Both that and the pgrep -lf cupsd should show that cupsd is running. Is it?
 
dalpets said:
I'm very appreciative of all the responses thus far guys but I need to say that I seem to be no closer to solving the localhost:631 negative.
Any more suggestions/ Thanks.
Click to expand...
Ok, here's a suggestion:
All output and all command you perform to diagnose this issue are to be wrapped in a program called script. This logs everything you do on the keyboard and output of the terminal screen so that you can then post this output to the forums and we can stop guessing at what you're seeing.

So, can you perform the following (as root, just in case):
Start up a terminal session (xterm, whatever).

Code: 
cd ~

script output.txt

ps aux|grep cups

exit

This will change directory to your home, run script with output to output.txt and then run the ps command searching for cups in the output of ps.
Finally we exit the script program.

Then post the file output.txt to this forum.
Then we will move onto the next step in the solution.
 
We need to start with a firm foundation in order to diagnose the problem.

Please logon as root, or use the su command to become root, on the FreeBSD host where you want the print/cups package/port to work.

Then do the following on that host:
Code: 
exec /bin/sh
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin
export PATH
pkg install lsof nmap
To see if anything is listening on port 631 do the following:
Code: 
nmap -p 631 localhost
You should see that the "localhost" (i.e. the machine on which you typed the command) is listening (PORT "631", protocol "tcp", STATE "open", SERVICE "ipp") with a response like this:
Code: 
$ nmap -p 631 localhost                          
Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-31 10:48 AEDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00020s latency).
Other addresses for localhost (not scanned): ::1

PORT    STATE SERVICE
631/tcp open  ipp

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
To verify what is listening on TCP port 631, do this:
Code: 
 lsof -i TCP:631
You should see at least one (TYPE IPV4) and probably two (plus TYPE IPV6) lines of output, like this:
Code: 
$ sudo lsof -i TCP:631      
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
cupsd   45238 root    6u  IPv6 0xfffff8000ecb1418      0t0  TCP localhost:ipp (LISTEN)
cupsd   45238 root    7u  IPv4 0xfffff8012ea4f830      0t0  TCP localhost:ipp (LISTEN)
This will verify that the cupsd(8) daemon is running on the "localhost". The port on which it is listening is coded as "ipp" above. We translate this to numeric port number by looking in the file /etc/services:
Code: 
$ grep 631 /etc/services
ipp        631/tcp       ipps    #IPP (Internet Printing Protocol)
ipp        631/udp       ipps    #IPP (Internet Printing Protocol)
Once we establish that cupsd(8) is running and listening on TCP port 631, we can then look at why you can't get the web browser to connect.
 
dalpets said:
At the moment my system has gone down , Will come back ASAP. Thanks all.
Click to expand...
back up now thanks to SirDice. It was not a corrupted entry in /etc/rc.conf, due to a spelling error, but rather a non recognised foreign entry that sent memory crazy, even swap.
 
mark_j said:
Note, lsof and nmap are ports, they are not part of the base system.
Click to expand...
How is that relevant to this OP? Thanks
BTW: I'm trying to steer clear of ports & only use packages as I believe mixing the two can have serious repercussions for major OS upgrades. My concern, though, is that that view may introduce admin limitations.
Which point of view do you agree with?
 
I had a warning that this pkg was compiled for 11.1-RELEASE-p6; this is 11.1 RELEASE-p4(?). The warning can be ignored if you are using a system that is updated via freebsd-update & are prebuilt packages.
It is due to the way FBSD builds clusters make packages. In this case my 12.2 OS was built from an internet downloaded ISO, so I don't know if the warning applies in this case..

gpw928 said:
We need to start with a firm foundation in order to diagnose the problem.

Please logon as root, or use the su command to become root, on the FreeBSD host where you want the print/cups package/port to work.

Then do the following on that host:
Code: 
exec /bin/sh
PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/sbin:/usr/sbin
export PATH
pkg install lsof nmap
Click to expand...
/bin/sh: nmap not found
gpw928 said:
To see if anything is listening on port 631 do the following:
Code: 
nmap -p 631 localhost
You should see that the "localhost" (i.e. the machine on which you typed the command) is listening (PORT "631", protocol "tcp", STATE "open", SERVICE "ipp") with a response like this:
Code: 
$ nmap -p 631 localhost                        
Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-31 10:48 AEDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00020s latency).
Other addresses for localhost (not scanned): ::1

[/QUOTE]
/bin/sh:nmap not found
[QUOTE="gpw928, post: 503297, member: 13095"]
PORT    STATE SERVICE
631/tcp open  ipp

[/QUOTE]
/bin/sh:: not found

[QUOTE="gpw928, post: 503297, member: 13095"]
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
To verify what is listening on TCP port 631, do this:
Code: 
lsof -i TCP:631
Click to expand...
lsof: WARNING: access/root/.sof: no such file or directory
lsof; WARNING: created device cache files: /root/.lsof_Mistletoe
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
cupsd 1134 root 6u IPv6 0x1cce85d0 0t0 TCP localhost:ipp (LISTEN)
cupsd 1134 root 7u IPv4 0x1cce82e8 0t0 TCP localhost:ipp (LISTEN)
gpw928 said:
You should see at least one (TYPE IPV4) and probably two (plus TYPE IPV6) lines of output, like this:
Code: 
$ sudo lsof -i TCP:631    
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
cupsd   45238 root    6u  IPv6 0xfffff8000ecb1418      0t0  TCP localhost:ipp (LISTEN)
cupsd   45238 root    7u  IPv4 0xfffff8012ea4f830      0t0  TCP localhost:ipp (LISTEN)
This will verify that the cupsd(8) daemon is running on the "localhost". The port on which it is listening is coded as "ipp" above. We translate this to numeric port number by looking in the file /etc/services:
Code: 
[/QUOTE]
[QUOTE="gpw928, post: 503297, member: 13095"]
$ grep 631 /etc/services
ipp        631/tcp       ipps    #IPP (Internet Printing Protocol)
ipp        631/udp       ipps    #IPP (Internet Printing Protocol)
Once we establish that cupsd(8) is running and listening on TCP port 631, we can then look at why you can't get the web browser to connect.
Click to expand...
No such file or directory
 
dalpets said:
I disabled the proxy setting in firefox to no avail. Also tried wget in the terminal, but that just times out.
var/logs/cups has no access or error log files. I have also disabled my firewall setting. Using 127.0.0.1 doesn't work either.
Thanks for your contribution.
Click to expand...
Let's see your ruleset. Because if you're using my normal pf ruleset you will not be using CUPS.
Unless you use the one I made for people who use CUPS.
 
You must log in or register to reply here.
Back
Top