I'm getting this error when ever I install any packages via apt-get
:
hostname: Name or service not known
dpkg: error processing ssmtp (--configure):
subprocess installed post-installation script returned error exit status 1
Setting up libt1-5 (5.1.2-3.4ubuntu1) ...
Setting up php5-gd (5.3.10-1ubuntu3.2) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
ssmtp
E: Sub-process /usr/bin/dpkg returned an error code (1)
Why this is happening?
run
hostname --fqdn
If you get an error, edit /etc/hostname and /etc/hosts with a proper hostname.
Then
aptitude install ssmtp
again to get it to install.Editing of
/etc/hosts
did the trick. The file/etc/hostname
was correct with containing onlyserver.exmaple.com
But the hosts was not correct
I changed it to this:
then I ran
hostname -f
(short forhostname --fqdn
) and got the following.Solution:
(These types of problems don't have good solutions. But only some haking-ish)
You should first try this command in a terminal:
If it doesn't work, process with haking-ish solution.
Try temporarily moving the configuration script of
ssmtp
.Open a terminal and execute this command to move them to the current dir
Then try using
apt-get
The cause of the problem:
The previous installation or removal might not completed successfully, leaving some configuration step to be done for
ssmtp
package. Since, dpkg won't progress without first completing the steps, subsequent use ofapt-get
now get stuck on that step.Most likely your internet connection is not working properly. Specifically I think your DNS is not resolving properly.
try to add the line
to your
/etc/resolv.conf
This will add the freenom DNS server temporarily (until the next boot)
I've gotten the message on my home network on an Ubuntu system with a dynamically assigned IP address from a router providing a combined DHCP and DNS server for my network.
The message:
hostname: Name or service not known
can be caused by such a device going down, if only for an instant.For example this can happen if my home router is rebooted when my power goes out.
The problem here is that the DHCP service your network is relying upon forgets all of the IP addresses it has assigned and the associated domain names. When your computer checks the associated dns server for its own name the server no longer has it. Some DHCP servers may avoid problems by writing the assignments they have made to their disk or flash memory so nothing is lost when they restart.
The server may ordinarily take your computername from your systems DHCP request, make it computername.local and store that in its records, making it available in its associated DNS server simultaneously. Usually
hostname -fqdn
requests the full domain name over your network from your DNS server and if it has the record it will return that name. The.local
suffix makes it look like a valid fully qualified domain name (though it isn't really a valid global domain name). This is why you may not have to specify a domain name manually in /etc/hosts or /etc/hostname files.The DHCP server restarting may cause further problems as IP addresses may be assigned to multiple computers simultaneously, causing some not to be able to communicate. The address is assigned once before the server restarts, and again after it does.
If your DHCP server forgets its assignments the safe thing to do is to reconnect each computer it serves when it restarts. When I lost mine I simply disconnected and reconnected to my wifi access point. On a wired network you can use
ifdown
andifup
or simply disconnect and reconnect the network cable. When reconnecting my system automatically uses dhclient to get a new address--my computer and the server now agree on who I am, and the message no longer appears.If you wait long enough the DHCP lease will timeout and your system will ask for and get a new lease from the server--clearing up the problem. This will probably be hours or days later (for my server it is one day).
If you have defined a static IP name and address and if the DNS reverse look-up records are correct the problem shouldn't happen.
I ran into this error this morning, and it turned out that the hostname was misspelled in
/etc/hostname
. Correcting this so it agreed with the hostname spelling in/etc/hosts
cleared up the problem. Thehostname -b -F /etc/hostname
command that runs at boot time apparently cannot complete unless/etc/hostname
and/etc/hosts
agree.