Dahdi restart needed with asterisk.service: why?

Asterisk 16.15.1 with DAHDI 3.1.0 on CentOS7; Amfeltec Piranha USB-FXS adapter.
All works nicely if I start Asterisk as root once the system has booted.
But if I start Asterisk from systemd with “asterisk.service”, I find that DAHDI can’t see my FXS channel until I issue “dahdi restart”, either from Asterisk CLI or using asterix -rx.
Anyone know how to resolve this, or work around, so that the DAHDI FXS channel is automatically available? Had a look on the issue tracker and on web, no joy yet.
Transcript below: pretty sure the warnings are harmless (?).

Connected to Asterisk 16.15.1 currently running on fitlet2-c7a (pid = 1364)
fitlet2-c7aCLI> dahdi show status
Description Alarms IRQ bpviol CRC Fra Codi Options LBO
AMF_USB_FXS 1 OK 0 0 0 CAS Unk 0 db (CSU)/0-133 feet (DSX-1)
[JCT_CVE: look at channels before dahdi restart:]
fitlet2-c7a
CLI> dahdi show channels
Chan Extension Context Language MOH Interpret Blocked In Service Description
pseudo default default Yes
[JCT_CVE: note that no channel 1 is showing yet…]
fitlet2-c7aCLI> dahdi restart
[May 25 11:27:42] WARNING[4520]: chan_dahdi.c:12535 mkintf: Attempt to configure channel 1 with signaling Unknown signalling -1 ignored because it is already configured to be FXO Kewlstart.
[May 25 11:27:42] WARNING[4520]: chan_dahdi.c:19258 process_dahdi: Ignoring any changes to ‘userbase’ (on reload) at line 18.
[JCT_CVE: now look at channels after restart:]
fitlet2-c7a
CLI> dahdi show channels
Chan Extension Context Language MOH Interpret Blocked In Service Description
1 phones default Yes
[JCT_CVE: channel 1 has now appeared, and works].

Thanks in advance…
JCT_CVE

I’d appreciate a reply from someone out there, even if it’s of the “don’t be so stupid” kind. Has anyone seen this DAHDI-needing-restart problem before? Has anyone solved it cleanly? Thanks.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.