/etc/init.d/sendpage-server fails to start as part of install config process

Bug #62807 reported by Nathan Wiebe
2
Affects Status Importance Assigned to Milestone
sendpage (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: sendpage-server

When installing the sendpage-server package ('apt-get install sendpage-server'), the configuration process attempts to start the sendpage-server service. This process hangs after producing the output below:

root@svn:~/web_tap_support# apt-get install sendpage-server
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  sendpage-server
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 0B/23.0kB of archives.
After unpacking 143kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously deselected package sendpage-server.
(Reading database ... 72700 files and directories currently installed.)
Unpacking sendpage-server (from .../sendpage-server_0.9.14-5_all.deb) ...
Setting up sendpage-server (0.9.14-5) ...
Starting Sendpage: (18090: alert) Cannot initialize modem 'default'
(18090: alert) no functioning modems!
sendpage.

It stays like this until ctrl-c is pressed, after which it produces:
 dpkg: error processing sendpage-server (--configure):
 subprocess post-installation script killed by signal (Interrupt)
Errors were encountered while processing:
 sendpage-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

This error happens (I think) because there's a section in the default config file /etc/sendpage/sendpage.cf called [modem:default] saying there's a modem on /dev/ttyS0, which is not the case on my system. Perhaps the default config file should not include default setting. I don't think sendpage should be started until some modems have been defined by the user.

Revision history for this message
Kees Cook (kees) wrote :

I have seen this too.

Changed in sendpage:
status: Unconfirmed → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sendpage - 1.0.3-1

---------------
sendpage (1.0.3-1) unstable; urgency=low

  * New upstream release (Closes: #458951).
  * debian/control:
    - take over maintainership with permission from prior maintainer.
    - add new libdbi-perl dependency.
    - bump Standards-Version to 3.8.1:
      - update Source-Version to binary:Version.
      - add Homepage field.
      - move mta to Suggests, switch to postfix from exim4.
      - move Depends around to reduce redundancy.
      - add Vcs-* fields.
      - add debian/README.source for quilt.
  * debian/rules:
    - general clean-ups, dh 6 capabilities.
    - switch to using .install files.
    - switch to using quilt for patch management.
  * debian/sendpage.init:
    - switch to using LSB log messages.
    - support "status" command.
    - handle unconfigured modems during init (LP: #62807).
  * sendpage:
    - have status return sane exit code, based on running daemons.
    - fix up defaults to run correctly on Debian (user "sendpage", groups
      "tty" and "dialout").
  * debian/sendpage.cf: merge with upstream changes/additions.
  * maintainer scripts: general cleanup, move from "daemon" user to more
    isolated "sendpage" user (Closes: #313646).
  * sendmail2snpp: replace with safer shell version with same functionality.

 -- Kees Cook <email address hidden> Mon, 01 Jun 2009 14:50:35 +0100

Changed in sendpage (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.