Dear maintainers,

The latest version of suricata is failing its autopkgtests in Ubuntu because
the suricata daemon does not start in the test environment.  This appears to
be due to the fact that the default suricata config assumes eth0 as an
interface name, but the testbed has ens2 as its default interface:

# /usr/bin/suricata --af-packet -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid
10/4/2018 -- 05:31:56 - <Notice> - This is Suricata version 4.0.4 RELEASE
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19)
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19)
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/botcc.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/ciarmy.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/compromised.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/drop.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/dshield.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-attack_response.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-chat.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-current_events.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-dns.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-dos.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-exploit.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-ftp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-imap.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-malware.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-misc.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-mobile_malware.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-netbios.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-p2p.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-policy.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-pop3.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-rpc.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-scan.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-smtp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-snmp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-sql.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-telnet.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-tftp.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-trojan.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-user_agents.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-voip.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-web_client.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-web_server.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-worm.rules
10/4/2018 -- 05:31:56 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/tor.rules
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Unable to find type for iface "eth0": No such device
10/4/2018 -- 05:31:56 - <Notice> - all 1 packet processing threads, 4 management threads initialized, engine started.
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Unable to find iface eth0: No such device
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't init AF_PACKET socket, fatal error
10/4/2018 -- 05:31:56 - <Error> - [ERRCODE: SC_ERR_FATAL(171)] - thread W#01-eth0 failed
#

Previous versions of suricata also had a default interface name of eth0
configured, but this was not a fatal error; the suricata daemon still
started and the tests could be run.

I'm filing this as serious because it seems to me that neither of these
behaviors - either starting up and being ineffective because it's running on
the wrong interface, or failing to start up because the interface is
hard-coded and not present - is a reasonable default behavior for an IDS.  I
think the interface should either be autodetected or prompted for at install
time.

Feel free to downgrade if you disagree.

In any case, while the autopkgtests do not pass, the new version of suricata
will not be included in the Ubuntu release, as regressing autopkgtests are
considered release blockers there.

If you check debian/tests/systemd-service-test.sh [0], the interface
in use by the config file is decided at runtime.

What autopkgtest tests are you running?

This seem like an ubuntu specific issue. All tests in debian are going
fine, both in unstable and in testing [1].
This Debian bug may result in the package being removed from Debian
testing for no actual reason.

Closing this bug now as it seems totally bogus.

[0] https://salsa.debian.org/pkg-suricata-team/pkg-suricata/blob/master/debian/tests/systemd-service-test.sh
[1] https://ci.debian.net/packages/s/suricata/

If you check debian/tests/systemd-service-test.sh [0], the interface
in use by the config file is decided at runtime.

What autopkgtest tests are you running?

This seem like an ubuntu specific issue. All tests in debian are going
fine, both in unstable and in testing [1].
This Debian bug may result in the package being removed from Debian
testing for no actual reason.

Closing this bug now as it seems totally bogus.

[0] https://salsa.debian.org/pkg-suricata-team/pkg-suricata/blob/master/debian/tests/systemd-service-test.sh
[1] https://ci.debian.net/packages/s/suricata/

Hi Arturo,

This code runs only for one of the tests.  It doesn't change the fact that
the suricata service as a whole is broken on install when eth0 is not
present, and all commands which try to talk to the daemon prior to that
point in the tests will fail.

You could fix the autopkgtests to not depend on eth0 if you moved the
systemd-service-test.sh to run before all other tests.  But I don't think
that would fix this bug, because I think the behavior of the package itself
is still wrong.

The ones shipped in your package.

The tests work fine in Debian because the testbed HAPPENS TO HAVE AN eth0
INTERFACE, as I said in the original bug report.  I know the difference
between Debian and Ubuntu and am not in the habit of gratuitously
overinflating the severity of bugs filed in Debian for Ubuntu-specific
issues.

I wrote the reason in my original bug report:

  I'm filing this as serious because it seems to me that neither of these
  behaviors - either starting up and being ineffective because it's running on
  the wrong interface, or failing to start up because the interface is
  hard-coded and not present - is a reasonable default behavior for an IDS.  I
  think the interface should either be autodetected or prompted for at install
  time.

I also wrote:

  Feel free to downgrade if you disagree.

It's not clear to me that you disagree.  It's not clear to me that you even
read my bug report.  So, reopening at original severity.

There is at least one bug here in the package, which is that the
autopkgtests make a brittle assumption that eth0 will be available in the
test bed.  eth0 is a legacy interface name in the kernel, and despite the
fact that eth0 is currently present on the ci.debian.net testbeds, this is
not a robust assumption.  If you want to reorder the tests so that the
config file setup is done first, then that would address the bug in the
autopkgtests.

I still also think it's a bug that the package installs successfully but the
daemon fails to start if there is no eth0 interface.  I think best practice
is that a package ensures its daemons can be started before the package is
configured, because it's better to surface a failure to the admin than to
consider a package "configured" without providing core functionality to
reverse-dependencies.  This was in my view the issue that warranted a
'serious' severity, but you are free to disagree and downgrade the bug.

Control: severity -1 normal

thanks for taking the time to elaborate.

I talked to upstream to know if they plan to implement something for
interface names at runtime. No plans.
And I don't have time to work on that myself.

Downgrading the severity to avoid the package removal from testing.

On a side note: you mentioned the daemon should be up and running to
consider the package being OK installed.
While I agree that by installing the package we should get a daemon
ready to use, How would you do that?
given suricata acts as a firewall, the config is strictly baked per
environment and no preset could be used as default?

Hi Steve and Arturo,

just a few comments from my side…

I might agree that the tests make some fragile assumptions, and I think that this
problem can be solved quickly by wrapping the suricatasc calls, making sure
that there is a Suricata instance running (in IDS mode) on an existing interface.

The other issue raised by Steve is a bit more complex. Suricata is an IDS/IPS
system, which rarely is used 'out of the box' but usually requires setup by a
knowledgeable person. I think, however, that we can arrive at some sensible
default configuration that leaves the least moment of surprise to a user who
just installed the software.

AFAICS we have several options here:

 a) Explicitly disable the service by default and display a note (via debconf)
    that informs the user that configuration is required before the system
    is usable. This is probably the easiest way -- but in essence avoiding the
    problem altogether ;)

 b) Use debconf to let the user choose a set of interfaces detected at install
    time (or pre-define at pressed, obviously), and pre-generate a config file
    that uses a lowest common denominator of basic but likely configuration
    choices (e.g. AF_PACKET, IDS mode, default bundled ruleset, ...) for
    monitoring the chosen interfaces, staying as close
    to upstream’s default config file as possible. If a user wants
    something more involved, then they can customize the setup by themselves.
    I have just played around with debconf a bit and it looks like this is quite
    straightforward to do. I'm just not sure yet how to handle non-interactive
    cases (such as the autopkgtests), but my first suggestion would be to go
    with the interface that provides the default route.

What do you think?

Cheers
Sascha

Hi,

I have looked into this bug and would like to outline how I intend to
resolve it, so that others can comment before anything is uploaded.

The report raises two separate issues, and both are addressed.

The first one is the autopkgtest suite, which implicitly assumed the
presence of an eth0 interface and of a daemon started by the package
installation. The suricatasc checks now start their own instance in unix
socket mode, which does not attach to a capture interface at all, and
the systemd test detects an interface that actually exists in the
testbed instead of relying on the shipped configuration.

The second one is the daemon itself. The package ships the upstream
default configuration, which uses eth0 as af-packet capture interface,
and enabled and started the service on installation. On a system without
eth0 the service ends up in the 'failed' state right after 'apt
install'; on a system that happens to have one, the daemon monitors an
interface the administrator never chose. The package is also frequently
installed only to analyse pcap files, where no service is wanted at all.

The fix is to no longer enable the service on first installation, using
a systemd preset that disables suricata.service. Administrators and
downstream distributions can override that policy with a preset file of
their own in /etc/systemd/system-preset/, without having to patch the
package. Existing installations are unaffected, because presets are only
evaluated when a package is installed for the first time. README.Debian
gained a section on the initial configuration (capture interface,
HOME_NET), and there is a NEWS entry for the behaviour change.

Interface autodetection was considered and rejected. Upstream does not
implement it and has repeatedly declined to make a missing interface
non-fatal, pointing at udev and the init system instead. A monitoring
port in a typical IDS deployment has neither an address nor a default
route, so a heuristic would systematically pick the wrong interface.
Above all, configuring the interface anywhere but in suricata.yaml
introduces a second source of truth; that construction exists in the
upstream RPM packaging and is a recurring source of confusion in
upstream support requests.

An installation-time prompt was considered as well. A meaningful
first-time configuration is not limited to the interface, it also
involves HOME_NET, the capture mode and the ruleset, so a debconf
dialogue would either be incomplete or fairly involved. It would also
require moving suricata.yaml to ucf handling. This may be revisited
later, but it is out of scope here.

For what it is worth, this matches what upstream does in the packaging
they control themselves: the OISF RPMs do not enable the service either
and document 'systemctl enable suricata' as an explicit step. Within
Debian, src:libreswan uses the same preset mechanism for the same reason.

The changes are prepared and will be uploaded to experimental after the
upcoming 8.0.7 release, so that the behaviour on ci.debian.net can be
observed before anything is merged or even reaches unstable.

My current implementation is here:
https://salsa.debian.org/ecite/pkg-suricata/-/commits/bug-895342

Comments are welcome.

Regards,
Andreas

We believe that the bug you reported is fixed in the latest version of
suricata, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 895342@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Dolp <dev@andreas-dolp.de> (supplier of updated suricata package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 22 Sep 2026 09:41:20 +0200
Source: suricata
Architecture: source
Version: 1:8.0.7-2~exp1
Distribution: experimental
Urgency: medium
Maintainer: Sascha Steinbiss <satta@debian.org>
Changed-By: Andreas Dolp <dev@andreas-dolp.de>
Closes: 895342
Changes:
 suricata (1:8.0.7-2~exp1) experimental; urgency=medium
 .
   * Update changelog for 1:8.0.7-2~exp1 release
   * d/t/unix-socket-test.sh: Add unix-socket-test.sh, which starts its own
     Suricata instance for unix socket tests instead of silently relying on
     hardcoded interface names from suricata.yaml.
   * d/t/systemd-service-test.sh: Improve tests by:
     * detecting a capture interface that exists in the testbed,
     * keeping the shipped suricata.yaml,
     * waiting for the systemd service state instead of sleeping,
     * re-enabling the reload test and
     * testing the suricatasc commands that need a live capture instance.
   * d/t/control: Set explicit test names for the remaining tests.
   * d/t/control: Remove unnecessary test dependencies for unit tests.
   * Do not enable the Suricata systemd service on first installations because
     it fails on all systems without an 'eth0' interface.
     Add a test to d/t/systemd-service-test.sh to verify the stopped service.
     Closes: #895342
Checksums-Sha1:
 b9404312c5760ec5f05247e342ef437c52b73e3d 2511 suricata_8.0.7-2~exp1.dsc
 83481e95cde5452794fe0ef1b549c52c64370ffd 26992 suricata_8.0.7-2~exp1.debian.tar.xz
 a9645e7e7fa904635b89d2a718ec941582082560 17197 suricata_8.0.7-2~exp1_arm64.buildinfo
Checksums-Sha256:
 be7eae18cec702d3fdc036eff00538d42076088cbf6b1ad51c6cb883355f0a5e 2511 suricata_8.0.7-2~exp1.dsc
 5d5896c2477d7748208c81dedeea0229ade382ce17142c0b78d163cae86662e9 26992 suricata_8.0.7-2~exp1.debian.tar.xz
 72faf3f03e8ba4e523295c816d73e70feaa9a72c86d8c33b6a1cf3954d497e75 17197 suricata_8.0.7-2~exp1_arm64.buildinfo
Files:
 83ac89649d94a9dcdf02edba10606c8f 2511 net optional suricata_8.0.7-2~exp1.dsc
 e7244eacd8e7ade98119fa2bbf5de1e5 26992 net optional suricata_8.0.7-2~exp1.debian.tar.xz
 d7ea7c5e648503f25e9222cf98fca769 17197 net optional suricata_8.0.7-2~exp1_arm64.buildinfo
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTjqpLKhithiGov9EruqOTPfpjPmQUCarIzFgAKCRDuqOTPfpjP
mXpgAPsEKmr6rK2mOU1CHqQfOFRxJjUpzLwjw3mNQpeukdY4sgEAghPLruKe93M2
09nONMYUR2S/4622IDac/klCFPiFHgU=
=5g+o
-----END PGP SIGNATURE-----

Hi all,
I did an upload of suricata/8.0.7-2~exp1 to experimental. [1]

Because the tests on ci.debian.net did not run for more than 3 weeks, I
now ran the tests locally in an incus unstable container:

```
autopkgtest --apt-upgrade --no-built-binaries
./suricata_8.0.7-2~exp1_arm64.changes -- incus
autopkgtest/debian/unstable/arm64
...
autopkgtest [20:13:05]: @@@@@@@@@@@@@@@@@@@@ summary
suricata-buildinfo   PASS
unix-socket-test     PASS
systemd-service-test PASS
suricata-unittests   PASS
```

The tests are successful and so I think we should merge this to master
and try it in a new unstable upload of suricata/8.0.7-2.

Any objections about that?

Regards,
Andreas

[1]
https://salsa.debian.org/pkg-suricata-team/pkg-suricata/-/tree/75addbdbf738dad9adde36fe953adfecffcf8dec/

No objections, I think we discussed this and I'd say let's go.

Thanks for your work on this
Sascha

We believe that the bug you reported is fixed in the latest version of
suricata, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 895342@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Dolp <dev@andreas-dolp.de> (supplier of updated suricata package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 16 Oct 2026 07:52:03 +0200
Source: suricata
Architecture: source
Version: 1:8.0.7-2
Distribution: unstable
Urgency: medium
Maintainer: Sascha Steinbiss <satta@debian.org>
Changed-By: Andreas Dolp <dev@andreas-dolp.de>
Closes: 895342
Changes:
 suricata (1:8.0.7-2) unstable; urgency=medium
 .
   * d/t/unix-socket-test.sh: Add unix-socket-test.sh, which starts its own
     Suricata instance for unix socket tests instead of silently relying on
     hardcoded interface names from suricata.yaml.
   * d/t/systemd-service-test.sh: Improve tests by:
     * detecting a capture interface that exists in the testbed,
     * keeping the shipped suricata.yaml,
     * waiting for the systemd service state instead of sleeping,
     * re-enabling the reload test and
     * testing the suricatasc commands that need a live capture instance.
   * d/t/control: Set explicit test names for the remaining tests.
   * d/t/control: Remove unnecessary test dependencies for unit tests.
   * Do not enable the Suricata systemd service on first installations because
     it fails on all systems without an 'eth0' interface.
     Add a test to d/t/systemd-service-test.sh to verify the stopped service.
     Closes: #895342
   * Use /run/suricata instead of /var/run/suricata for pidfiles.
Checksums-Sha1:
 70d8300aedb62b9338f99b6cdc10d65b028e5c73 2491 suricata_8.0.7-2.dsc
 d1096c956c98ddfc458e7f8bf6de92c66f97cec3 27188 suricata_8.0.7-2.debian.tar.xz
 f4bf40e77558c36bb85619f1360cb44483a7dbca 17168 suricata_8.0.7-2_arm64.buildinfo
Checksums-Sha256:
 2db5c01ee5e3ff9d17bb873799566a9854e395ed1829664dcf5f9ed79686a49e 2491 suricata_8.0.7-2.dsc
 860e806f3c87780369bc17d792bf31b6d3a7850354e37a3335c5efaa26ea44eb 27188 suricata_8.0.7-2.debian.tar.xz
 339dc9036f4c254c97753a09e156eb804ecfb88aa91adbfdf508089826c1baa2 17168 suricata_8.0.7-2_arm64.buildinfo
Files:
 3b996d5aa668ab070b725f4fd7ef5d0c 2491 net optional suricata_8.0.7-2.dsc
 f6283db1f2f3180ac4fa07ddb0ca752c 27188 net optional suricata_8.0.7-2.debian.tar.xz
 140f156c354445f1f59ae571ae1348b9 17168 net optional suricata_8.0.7-2_arm64.buildinfo
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTjqpLKhithiGov9EruqOTPfpjPmQUCatH78gAKCRDuqOTPfpjP
mWieAP9IgrpH1mjN/col9ZF7yMZTVkLYQx3fku7PWLJ/1ttWBgEAz+dfDPap3Dmj
3k+sJf6tIJNYtqO/CVMffVdb5XAJjgg=
=Cz2Y
-----END PGP SIGNATURE-----