#1031200 hylafax-server: faxgetty.service doesn't work with iaxmodem

Package:
hylafax-server
Source:
hylafax-server
Description:
Flexible client/server fax software - server daemons
Submitter:
Tino Schmidt
Date:
2026-01-03 10:35:03 UTC
Severity:
normal
#1031200#5
Date:
2023-02-13 06:26:24 UTC
From:
To:
Dear Maintainer,

as mentioned in https://debianforum.de/forum/viewtopic.php?t=185052 (German, VERY long) there seems to be an issue with faxgetty's service unit in combination with the shipped udev rules of the package when hylafax is configured with iaxmodem.

When properly configured, iaxmodem creates a device /dev/ttyIAX<n> which is a symlink to /dev/pts/<n>. The appearance of the device does not result in an udev event, since events under /dev/pts/ didn't seem to be covered by udev.

The symlink is also created by iaxmodem itself. Hence, the shipped udev rules (/lib/udev/rules.d/60-hylafax-server.rules) do not come into action, so a line like
KERNEL=="ttyIAX0", SYMLINK="ttyIAX0", TAG+="systemd"
is ignored.

This is fatal, because the attached systemd-tag is necessary for creating device files which are required by faxgetty's systemd-unit (/lib/systemd/system/faxgetty@.service):

[Unit]
Description=HylaFAX faxgetty %I
BindsTo=dev-%i.device
After=dev-%i.device

So, faxgetty.service is waiting for a device that never shows up.

As a temporary workaround the BindsTo and After lines were replaced with a more soft dependency, so it looks like this:

[Unit]
Description=HylaFAX faxgetty %I
Wants=iaxmodem.service dev-%i.device

After that faxgetty started successfully.

Please provide a fix for this.

Thanks,
Tino
#1031200#10
Date:
2023-02-13 08:25:21 UTC
From:
To:
Hello Tino,
I will ask on the udev mailing list in order to find the best solution.
I do have a question, is this "Wants" line working even when you have more
then one IAX modem?


Thank you,
Giuseppe
#1031200#15
Date:
2023-02-13 10:41:53 UTC
From:
To:
Hello Giuseppe,
thank you for working on this and responding so quickly.
Yes, the Wants line is also working with two or more iax modems.


Tino
#1031200#20
Date:
2023-02-13 13:35:52 UTC
From:
To:
Hello,

Il giorno lun, 13/02/2023 alle 10.41 +0000, debian-bug23@dc0wh17f.mooo.com
ha scritto:

Does iaxmodem create the link in /dev when you configure the line, or when
it starts up? Is the link present when iaxmodem service is stopped?

Thank you,
Giuseppe
#1031200#25
Date:
2023-02-13 14:57:42 UTC
From:
To:
It's created at the start of iaxmodem.
No.
#1031200#30
Date:
2023-02-13 22:47:46 UTC
From:
To:
Hello Giuseppe,
from my point of view all we need is a logical OR (||) in this systemd unit. Unfortunately I couldn't find such an option in systemd's manpages. So, I gave it a shot and tried this:

[Unit]
Description=HylaFAX faxgetty %I
BindsTo=iaxmodem.service || dev-%i.device
After=network.target

Well, it works as expected: The devices come up and if I stop iaxmodem.service manually, all faxgetty services are immediately terminated as well. If I start faxgetty again, iaxmodem.service is started automatically. This is just for the iaxmodem part, I couldn't test with a real serial modem though.

The After line is to make sure iaxmodem.service is running if faxgetty wants to start an iax device.

But, again, I am not sure if this logical OR is officially supported by systemd.


Tino
#1031200#35
Date:
2023-02-14 07:57:25 UTC
From:
To:
Hi Tino,

Il giorno lun, 13/02/2023 alle 22.47 +0000, debian-bug23@dc0wh17f.mooo.com
ha scritto:
[...]

The problem is if we may just wait for iaxmodem or if we need to wait for
the device.
The dev-%i.device has events when udev sends them, but since that path is
not a real device, no udev events are sent. This probably means that using
dev-%i.device on any systemd unit is useless.
So, I am wondering if the minimal working unit is just

[Unit]
Description=HylaFAX faxgetty %I
BindsTo=iaxmodem.service
After=iaxmodem.service

The question is: could you confirm that you cannot add/remove/start/stop
IAX devices without stopping the iaxmodem.service? In other words, no
(device) events would be possibile once iaxmodem is started?

Thank you,
Giuseppe
#1031200#40
Date:
2023-02-14 12:54:20 UTC
From:
To:
Hi Giuseppe,
I agree.
I don't think they're useless. The intended behavior (from my understanding) of BindsTo=dev-%i.device is, to make sure faxgetty binds to that device and start it once the device becomes available or terminate it immediately when the underlying real device (say: /dev/ttyS0) is not available anymore. Therefore, the BindsTo-dependency makes sense to me. And this is why I wanted to keep them and add iaxmodem.service in this line with an OR statement, which seems not to be supported by systemd.
This works.
No. You can add/remove devices with a seperate call of iaxmodem <configfile> while iaxmodem.service is running. You can even (re)start running devices. There is no lock or similar for a device once iaxmodem is started.


Thanks,
Tino
#1031200#45
Date:
2023-02-17 12:17:58 UTC
From:
To:
Hello Tino,

Il giorno mar, 14/02/2023 alle 12.54 +0000, debian-bug23@dc0wh17f.mooo.com
ha scritto:

Could you please verify if any of the proposed configuration works also
when adding/removing a new IAX device when iaxmodem is already up and
running?

Thank you,
Giuseppe
#1031200#50
Date:
2023-02-19 19:26:35 UTC
From:
To:
Hi Giuseppe,
Same. I think the behavior is not a systemd issue but an issue of iaxmodem. Once iaxmodem is started, it reads all available config files and assigns any existing symlinks to a new device of /dev/pts/<n>. It doesn't check if it's already running and just overwrites existing symlinks. It doesn't terminate itself either, so any previously started process of iaxmodem remains still active. So, when I type /usr/bin/iaxmodem two times, the result with two available configfiles under /etc/iaxmodem is four iaxmodem processes running at the same time.

As far as I understand the code of iaxmodem.c this is the intended behavior (which, for me, is wrong). Maybe I should file a bug report against iaxmodem first before we work on faxgetty's systemd unit - what do you think?


Thanks,
Tino
#1031200#55
Date:
2023-02-19 21:25:35 UTC
From:
To:
Il giorno dom, 19/02/2023 alle 19.26 +0000, debian-bug23@dc0wh17f.mooo.com ha
scritto:

you may probably just write to iaxmodem-users mailing lists. I already
contacted the author there and he is aware of this Debian bug.

Bye,
Giuseppe
#1031200#60
Date:
2024-03-06 07:09:01 UTC
From:
To:
Dear Maintainer,

Experienced same issue and I'm not sure when it was introduced and what the exact cause ist but I
don't recall I experiencing it on the last reboot (probably several months ago)

But what I suspect the cause to be:

iaxmodem creates a link from /dev/ttyIAX to a dynamic /dev/pts device.

The faxgetty systemd script contains:

BindsTo=dev-%i.device
After=dev-%i.device

And if %i is a link and not a real device, udev never triggers an event and the device binding is never true.

Commenting out those two statements solved the issue for me for now.
#1031200#65
Date:
2024-03-06 07:53:34 UTC
From:
To:
Hello Benoit,
thank you for adding this information. The problem is indeed that one: udev
is not triggering any event when the IAX modem device is created. This lead
to a not existing dev-%i.device and hence, to a non activation of the
faxgetty by systemd.

The solution is to start the device manually. In your case, if the IAX modem
are started at boot, you may just leave the changes you have done to the
unit, and enable it for starting at boot time.

I am looking for a different approach that could starts faxgetty when an IAX
device is created, and stops it when it is removed. I do not have a solution
yet.

Bye,
Giuseppe
#1031200#70
Date:
2024-08-27 15:58:58 UTC
From:
To:
Hello,

Well, just installed a fresh new Debian 12 and I'm facing the same
situation BUT using /dev/ttyS0 and /dev/ttyS1 external serial modems,
instead.

ago 27 09:38:58 stt005 kernel: printk: console [tty0] enabled
ago 27 09:38:58 stt005 kernel: 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
ago 27 09:38:58 stt005 kernel: 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
ago 27 09:38:58 stt005 systemd[1]: Created slice system-getty.slice - Slice /system/getty.
ago 27 09:39:01 stt005 (udev-worker)[283]: ttyS0: Failed to create/update device symlink '/dev/ttyS0', ignoring: File exists
ago 27 09:39:01 stt005 (udev-worker)[283]: ttyS1: Failed to create/update device symlink '/dev/ttyS1', ignoring: File exists
ago 27 09:39:01 stt005 (udev-worker)[281]: ttyS2: Failed to create/update device symlink '/dev/ttyS2', ignoring: File exists
ago 27 09:39:01 stt005 (udev-worker)[279]: ttyS3: Failed to create/update device symlink '/dev/ttyS3', ignoring: File exists
ago 27 09:39:02 stt005 systemd[1]: getty-static.service - getty on tty2-tty6 if dbus and logind are not available was skipped because of an unmet condition check (ConditionPathExists=!/usr/bin/dbus-daemon).
ago 27 09:39:07 stt005 systemd[1]: Started getty@tty1.service - Getty on tty1.
ago 27 09:39:07 stt005 systemd[1]: Reached target getty.target - Login Prompts.

root@stt005:/etc# systemctl -a | grep ttyS[01]
  sys-devices-pnp0-00:03-tty-ttyS0.device                                                  loaded    active   plugged   /sys/devices/pnp0/00:03/tty/ttyS0
  sys-devices-pnp0-00:04-tty-ttyS1.device                                                  loaded    active   plugged   /sys/devices/pnp0/00:04/tty/ttyS1

It seems to fail the same way :-(

By commenting out the «offending» lines (as comment #60 suggests)
faxgetty service can be enabled and started and all runs smoothly on
HylaFAX side:

ago 27 16:55:21 stt005 systemd[1]: Created slice system-faxgetty.slice - Slice /system/faxgetty.
ago 27 16:55:21 stt005 systemd[1]: Started faxgetty@192.168.0.5.service - HylaFAX faxgetty 192.168.0.5.
ago 27 17:00:21 stt005 systemd[1]: Started faxgetty@ttyS1.service - HylaFAX faxgetty ttyS1.
ago 27 17:00:21 stt005 FaxGetty[6342]: OPEN /dev/ttyS1  HylaFAX (tm) Version 6.0.7
ago 27 17:00:31 stt005 FaxGetty[6342]: MODEM ACF3_V1.088-V90_P21_FSH 56000/
ago 27 17:03:37 stt005 FaxGetty[6163]: LOCKWAIT

root@stt005:/etc# systemctl -a | grep ttyS[01]
  dev-ttyS0.device                                                                         loaded    active   plugged   /dev/ttyS0
  dev-ttyS1.device                                                                         loaded    active   plugged   /dev/ttyS1
  sys-devices-pnp0-00:03-tty-ttyS0.device                                                  loaded    active   plugged   /sys/devices/pnp0/00:03/tty/ttyS0
  sys-devices-pnp0-00:04-tty-ttyS1.device                                                  loaded    active   plugged   /sys/devices/pnp0/00:04/tty/ttyS1
  faxgetty@ttyS0.service                                                                   loaded    active   running   HylaFAX faxgetty ttyS0
  faxgetty@ttyS1.service                                                                   loaded    active   running   HylaFAX faxgetty ttyS1

ago 27 09:38:58 stt005 kernel: 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
ago 27 09:38:58 stt005 kernel: 00:04: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
ago 27 09:39:01 stt005 (udev-worker)[283]: ttyS0: Failed to create/update device symlink '/dev/ttyS0', ignoring: File exists
ago 27 09:39:01 stt005 (udev-worker)[283]: ttyS1: Failed to create/update device symlink '/dev/ttyS1', ignoring: File exists

(...)

ago 27 16:56:07 stt005 systemd[1]: Started faxgetty@ttyS0.service - HylaFAX faxgetty ttyS0.
ago 27 16:56:07 stt005 FaxGetty[6163]: OPEN /dev/ttyS0  HylaFAX (tm) Version 6.0.7
ago 27 17:00:21 stt005 systemd[1]: Started faxgetty@ttyS1.service - HylaFAX faxgetty ttyS1.
ago 27 17:00:21 stt005 FaxGetty[6342]: OPEN /dev/ttyS1  HylaFAX (tm) Version 6.0.7

BUT not sure if this approach is the RIGHT one for standard serial
modems nor if this will work for the two (2) modems (ttyS0 and ttyS1)
to gte properly initializated after system reboots.

Any advice or comment on this would be appreciated :-)

P.S. Sorry for this kinda «bug hijacking». Just tell me should I better
open a new bug report instead of keeping the new stuff into this one.

Greetings,
#1031200#75
Date:
2024-08-28 06:54:15 UTC
From:
To:
On Tue, 27 Aug 2024 17:58:58 +0200 =?utf-8?B?Q2FtYWxlw7Nu?=  <noelamac@gmail.com> wrote:

Just an update on this...

(...)

(...)

After a system restart, all seems to be working fine (both modems are
up and listenig, HylaFAX services up and runing, in-out-faxing service
working...).

root@stt005:~# journalctl -b0 | grep -i fax
ago 28 05:14:21 stt005 systemd[1]: Created slice system-faxgetty.slice - Slice /system/faxgetty.
ago 28 05:14:27 stt005 systemd[1]: Started faxgetty@192.168.0.5.service - HylaFAX faxgetty 192.168.0.5.
ago 28 05:14:27 stt005 systemd[1]: Started faxgetty@ttyS0.service - HylaFAX faxgetty ttyS0.
ago 28 05:14:27 stt005 systemd[1]: Started faxgetty@ttyS1.service - HylaFAX faxgetty ttyS1.
ago 28 05:14:27 stt005 systemd[1]: Starting hylafax.service - HylaFAX...
ago 28 05:14:28 stt005 systemd[1]: Finished hylafax.service - HylaFAX.
ago 28 05:14:28 stt005 systemd[1]: Starting faxq.service - HylaFAX queue manager process for outbound facsimile jobs...
ago 28 05:14:30 stt005 systemd[1]: Started faxq.service - HylaFAX queue manager process for outbound facsimile jobs.
ago 28 05:14:30 stt005 FaxQueuer[343]: HylaFAX (tm) Version 6.0.7
ago 28 05:14:30 stt005 FaxQueuer[343]: Copyright (c) 1990-1996 Sam Leffler
ago 28 05:14:30 stt005 FaxQueuer[343]: Copyright (c) 1991-1996 Silicon Graphics, Inc.
ago 28 05:14:30 stt005 FaxGetty[308]: OPEN /dev/ttyS1  HylaFAX (tm) Version 6.0.7
ago 28 05:14:31 stt005 FaxGetty[307]: OPEN /dev/ttyS0  HylaFAX (tm) Version 6.0.7
ago 28 05:14:33 stt005 HylaFAX[408]: Listening to 0.0.0.0:4559
ago 28 05:14:33 stt005 HylaFAX[408]: HylaFAX INET Protocol Server: restarted.
ago 28 05:14:33 stt005 HylaFAX[408]: HylaFAX SNPP Protocol Server: restarted.
ago 28 05:14:32 stt005 systemd[1]: Started hfaxd.service - HylaFAX client-server protocol server.
ago 28 05:14:40 stt005 FaxGetty[308]: MODEM ACF3_V1.088-V90_P21_FSH 56000/
ago 28 05:14:40 stt005 FaxGetty[307]: MODEM ACF3_V1.088-V90_P21_FSH 56000/

ago 28 05:15:31 stt005 FaxQueuer[343]: NOTIFY exit status: 0 (1068)

ago 28 07:40:10 stt005 FaxGetty[307]: log/seqf: open: Permission denied
ago 28 07:40:10 stt005 FaxGetty[307]: Couldn't get next seqnum for session log: Unable to open sequence number file log/seqf; Permission denied.
ago 28 07:40:16 stt005 FaxGetty[307]: ANSWER: FAX CONNECTION  DEVICE '/dev/ttyS0'
ago 28 07:41:07 stt005 FaxGetty[307]: MODEM ACF3_V1.088-V90_P21_FSH 56000/
ago 28 08:07:01 stt005 HylaFAX[1496]: `-> Got a: 127.0.0.1[13]
ago 28 08:07:01 stt005 HylaFAX[1496]: `-> Got a: 41661[19]

root@stt005:~# systemctl status faxgetty@*
● faxgetty@ttyS1.service - HylaFAX faxgetty ttyS1
     Loaded: loaded (/lib/systemd/system/faxgetty@.service; enabled; preset: enabled)
     Active: active (running) since Wed 2024-08-28 05:14:27 CEST; 3h 25min ago
   Main PID: 308 (faxgetty)
      Tasks: 1 (limit: 9509)
     Memory: 1.4M
        CPU: 68ms
     CGroup: /system.slice/system-faxgetty.slice/faxgetty@ttyS1.service
             └─308 /usr/sbin/faxgetty ttyS1

ago 28 05:14:27 stt005 systemd[1]: Started faxgetty@ttyS1.service - HylaFAX faxgetty ttyS1.
ago 28 05:14:30 stt005 FaxGetty[308]: OPEN /dev/ttyS1  HylaFAX (tm) Version 6.0.7
ago 28 05:14:40 stt005 FaxGetty[308]: MODEM ACF3_V1.088-V90_P21_FSH 56000/

● faxgetty@ttyS0.service - HylaFAX faxgetty ttyS0
     Loaded: loaded (/lib/systemd/system/faxgetty@.service; enabled;preset: enabled)
     Active: active (running) since Wed 2024-08-28 05:14:27 CEST; 3h25min ago
   Main PID: 307 (faxgetty)
      Tasks: 1 (limit: 9509)
     Memory: 1.3M
        CPU: 73ms
     CGroup: /system.slice/system-faxgetty.slice/faxgetty@ttyS0.service
             └─307 /usr/sbin/faxgetty ttyS0

ago 28 05:14:27 stt005 systemd[1]: Started faxgetty@ttyS0.service - HylaFAX faxgetty ttyS0.
ago 28 05:14:31 stt005 FaxGetty[307]: OPEN /dev/ttyS0  HylaFAX (tm) Version 6.0.7
ago 28 05:14:40 stt005 FaxGetty[307]: MODEM ACF3_V1.088-V90_P21_FSH 56000/
ago 28 07:40:10 stt005 FaxGetty[307]: log/seqf: open: Permission denied
ago 28 07:40:10 stt005 FaxGetty[307]: Couldn't get next seqnum for session log: Unable to open sequence number file log/seqf; Permis>
ago 28 07:40:16 stt005 FaxGetty[307]: ANSWER: FAX CONNECTION  DEVICE '/dev/ttyS0'
ago 28 07:41:07 stt005 FaxGetty[307]: MODEM ACF3_V1.088-V90_P21_FSH 56000/

So far so good, but when systemd package is updated, edited init script
will be gone and faxgetty will fail again.

Until this is solved upstream and globally, what would be the best way
to get this systemd tweak permanent? Maybe this approach used in
HylaFAX+ would be the way to go?

****
https://hylafax.sourceforge.io/howto/install.php#ss2.2.5

2.2.5 - Starting the hfaxd, faxq, and faxgetty Daemons

 On systems using systemd the same is done by creating a file such as
/etc/systemd/system/faxgetty-ttyS0.service that looks like this:

[Unit]
Description=HylaFAX faxgetty for ttyS0

[Service]
User=root
Group=root
Restart=always
RestartSec=30
ExecStart=/usr/sbin/faxgetty ttyS0

[Install]
WantedBy=multi-user.target

Then issue 'systemctl start faxgetty-ttyS0.service' to start up that
faxgetty process. If you want it to start at boot-time then issue
'systemctl enable faxgetty-ttyS0.service'.
****

Cheers,
#1031200#80
Date:
2024-09-15 09:39:27 UTC
From:
To:
Not sure what has happened but yesterday, I removed the commented lines
in «/lib/systemd/system/faxgetty@.service», that is, back to the
original Debian's 12 stock file and HylaFAX service and modems and
working fine:

root@stt005:~# cat /lib/systemd/system/faxgetty@.service
[Unit]
Description=HylaFAX faxgetty %I
BindsTo=dev-%i.device
After=dev-%i.device

[Service]
ExecStart=/usr/sbin/faxgetty %i
BindPaths=/etc/hylafax:/var/spool/hylafax/etc
WorkingDirectory=/var/spool/hylafax
Restart=on-failure

[Install]
WantedBy=multi-user.target

root@stt005:~# systemctl status faxgetty@*.service
● faxgetty@ttyS1.service - HylaFAX faxgetty ttyS1
     Loaded: loaded (/lib/systemd/system/faxgetty@.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-09-15 05:19:30 CEST; 6h ago
   Main PID: 419 (faxgetty)
      Tasks: 1 (limit: 9507)
     Memory: 1.0M
        CPU: 91ms
     CGroup: /system.slice/system-faxgetty.slice/faxgetty@ttyS1.service
             └─419 /usr/sbin/faxgetty ttyS1

● faxgetty@ttyS0.service - HylaFAX faxgetty ttyS0
     Loaded: loaded (/lib/systemd/system/faxgetty@.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-09-15 05:19:30 CEST; 6h ago
   Main PID: 418 (faxgetty)
      Tasks: 1 (limit: 9507)
     Memory: 2.0M
        CPU: 96ms
     CGroup: /system.slice/system-faxgetty.slice/faxgetty@ttyS0.service
             └─418 /usr/sbin/faxgetty ttyS0

sep 15 05:19:30 stt005 systemd[1]: Started faxgetty@ttyS0.service - HylaFAX faxgetty ttyS0.
sep 15 05:19:33 stt005 FaxGetty[418]: OPEN /dev/ttyS0  HylaFAX (tm) Version 6.0.7
sep 15 05:19:43 stt005 FaxGetty[418]: MODEM ACF3_V1.088-V90_P21_FSH 56000/

root@stt005:~# journalctl -b0 | grep -i fax
sep 15 05:19:21 stt005 systemd[1]: Created slice system-faxgetty.slice - Slice /system/faxgetty.
sep 15 05:19:30 stt005 systemd[1]: Started faxgetty@ttyS0.service - HylaFAX faxgetty ttyS0.
sep 15 05:19:30 stt005 systemd[1]: Started faxgetty@ttyS1.service - HylaFAX faxgetty ttyS1.
sep 15 05:19:31 stt005 systemd[1]: Starting hylafax.service - HylaFAX...
sep 15 05:19:31 stt005 systemd[1]: Finished hylafax.service - HylaFAX.
sep 15 05:19:31 stt005 systemd[1]: Starting faxq.service - HylaFAX queue manager process for outbound facsimile jobs...
sep 15 05:19:32 stt005 systemd[1]: Started hfaxd.service - HylaFAX client-server protocol server.
sep 15 05:19:33 stt005 systemd[1]: Started faxq.service - HylaFAX queue manager process for outbound facsimile jobs.
sep 15 05:19:33 stt005 FaxQueuer[478]: HylaFAX (tm) Version 6.0.7
sep 15 05:19:33 stt005 FaxQueuer[478]: Copyright (c) 1990-1996 Sam Leffler
sep 15 05:19:33 stt005 FaxQueuer[478]: Copyright (c) 1991-1996 Silicon Graphics, Inc.
sep 15 05:19:33 stt005 HylaFAX[452]: Listening to 0.0.0.0:4559
sep 15 05:19:33 stt005 HylaFAX[452]: HylaFAX INET Protocol Server: restarted.
sep 15 05:19:33 stt005 HylaFAX[452]: HylaFAX SNPP Protocol Server: restarted.
sep 15 05:19:33 stt005 FaxGetty[419]: OPEN /dev/ttyS1  HylaFAX (tm) Version 6.0.7
sep 15 05:19:33 stt005 FaxGetty[418]: OPEN /dev/ttyS0  HylaFAX (tm) Version 6.0.7
sep 15 05:19:43 stt005 FaxGetty[418]: MODEM ACF3_V1.088-V90_P21_FSH 56000/
sep 15 05:19:43 stt005 FaxGetty[419]: MODEM ACF3_V1.088-V90_P21_FSH 56000/
sep 15 05:20:50 stt005 systemd[1]: Dependency failed for faxgetty@192.168.0.5.service - HylaFAX faxgetty 192.168.0.5.
sep 15 05:20:50 stt005 systemd[1]: faxgetty@192.168.0.5.service: Job faxgetty@192.168.0.5.service/start failed with result 'dependency'.
sep 15 08:48:35 stt005 HylaFAX[1383]: `-> Got a: 127.0.0.1[13]
sep 15 08:48:35 stt005 HylaFAX[1383]: `-> Got a: 42455[19]

So, sorry for the noise.
I cannot reproduce this bug anymore.

Cheers,
#1031200#85
Date:
2024-12-01 17:05:48 UTC
From:
To:
After upgrading from Bullseye to Bookworm, I encountered this bug as
well.

Commenting out the BindsTo and After lines in the faxgetty@.service
file is a temporary workaround as previously mentioned.
#1031200#90
Date:
2025-06-13 15:12:18 UTC
From:
To:
Hello Tino,
finally I think I found a solution: I would crate a second systemd unit
template coping faxgetty@.service to faxgetty-iax@.service and then
I'll remove from the latter the BindsTo= and After= lines, replacing
them with a dependency on the iaxmodem.service unit.

This means that "real" devices, the one managed by udev, like ttyS0 or
ttyUSB3 will get a normal faxgetty@.service unit that depends on the
device; while the "virtual" device like ttyIAX0 will only get a
dependency on the iaxmodem service and will be coupled with a systemd
path unit that watches the IAX device name.

Bye,
Giuseppe
#1031200#95
Date:
2026-01-03 10:22:55 UTC
From:
To:
Dear Maintainer,

+1 thank you for the report. I was starting to get desperate and not understanding why faxgetty kept timing out checking for /dev/ttyIAX despite it clearly being present and a symlink to a valid and working pts tty.