Error -103 #4

IvanVojtko · 2019-01-17T14:37:32Z

I've installed your AUR package and when I try to run fprintd-enroll, id gives me this:
Using device /net/reactivated/Fprint/Device/0 Enrolling right-index-finger finger. EnrollStart failed: Enroll start failed with error -103
Can you help me with this?

The text was updated successfully, but these errors were encountered:

inpos · 2019-01-18T09:12:59Z

Same issue on Gentoo.
Additional journalctl output:

янв 18 12:12:04 inpos-hpe dbus[1448]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
янв 18 12:12:04 inpos-hpe systemd[1]: Starting Fingerprint Authentication Daemon...
янв 18 12:12:04 inpos-hpe dbus[1448]: [system] Successfully activated service 'net.reactivated.Fprint'
янв 18 12:12:04 inpos-hpe systemd[1]: Started Fingerprint Authentication Daemon.
янв 18 12:12:05 inpos-hpe fprintd[21422]: capture-helper probably died while we were waiting for img ready signal
янв 18 12:12:05 inpos-hpe fprintd[21422]: capture-helper output:
                                             SIGALRM caught: timed out waiting for VFS service
янв 18 12:12:05 inpos-hpe fprintd[21422]: TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
янв 18 12:12:05 inpos-hpe fprintd[21422]: activation failed with error -103
янв 18 12:12:05 inpos-hpe fprintd[21422]: failed to start enrollment

rindeal · 2019-01-19T01:18:44Z

And can you confirm the vcsFPService daemon is running?

inpos · 2019-01-21T07:59:01Z

~ # systemctl status vcsFPService
● vcsFPService.service - Validity Fingerprint Service
   Loaded: loaded (/lib/systemd/system/vcsFPService.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-01-21 10:55:50 MSK; 2min 47s ago
  Process: 5776 ExecStart=/usr/sbin/vcsFPService (code=exited, status=0/SUCCESS)
  Process: 5775 ExecStartPre=/usr/bin/find /tmp -maxdepth 1 -type p -name CH_* -delete (code=exited, status=0/SUCCESS)
  Process: 5774 ExecStartPre=/usr/bin/find /tmp -maxdepth 1 -type f -name vcsSemKey_* -delete (code=exited, status=0/SUCCESS)
 Main PID: 5778 (vcsFPService)
   Memory: 2.1M
   CGroup: /system.slice/vcsFPService.service
           └─5778 /opt/validity-sensor/usr/sbin/vcsFPService

янв 21 10:55:50 inpos-hpe systemd[1]: Starting Validity Fingerprint Service...
янв 21 10:55:50 inpos-hpe Validity_service_main[5776]: Validity service start up
янв 21 10:55:50 inpos-hpe systemd[1]: Started Validity Fingerprint Service.

inpos · 2019-01-21T07:59:58Z

journalctl output

янв 21 10:57:40 inpos-hpe dbus[1448]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
янв 21 10:57:40 inpos-hpe systemd[1]: Starting Fingerprint Authentication Daemon...
янв 21 10:57:40 inpos-hpe dbus[1448]: [system] Successfully activated service 'net.reactivated.Fprint'
янв 21 10:57:40 inpos-hpe systemd[1]: Started Fingerprint Authentication Daemon.
янв 21 10:57:41 inpos-hpe fprintd[6951]: capture-helper probably died while we were waiting for img ready signal
янв 21 10:57:41 inpos-hpe fprintd[6951]: capture-helper output:
                                            SIGALRM caught: timed out waiting for VFS service
янв 21 10:57:41 inpos-hpe fprintd[6951]: TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
янв 21 10:57:41 inpos-hpe fprintd[6951]: activation failed with error -103
янв 21 10:57:41 inpos-hpe fprintd[6951]: failed to start enrollment

inpos · 2019-01-21T08:00:32Z

inpos@inpos-hpe ~ $ fprintd-enroll 
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
EnrollStart failed: Enroll start failed with error -103

inpos@inpos-hpe ~ $ fprintd-list inpos
found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
User inpos has no fingers enrolled for Validity Sensors (proprietary driver).

lighterowl · 2019-01-25T17:55:16Z

Getting the same errors here, and the same logs.
Weirdly, the img_capture application from libfprint examples works just fine : I can get an image without any problems.

[daniel@foobar examples]$ ./img_capture 
(process:675): libfprint-DEBUG: 19:56:36.206: 1639251876: ../libfprint/core.c:752
(process:675): libfprint-DEBUG: 19:56:36.215: registered driver vfs_proprietary
(process:675): libfprint-DEBUG: 19:56:36.215: driver vfs_proprietary supports USB device 138a:003f
(process:675): libfprint-DEBUG: 19:56:36.215: selected driver vfs_proprietary supports USB device 138a:003f
Found device claimed by Validity Sensors (proprietary driver) driver
(process:675): libfprint-sync-DEBUG: 19:56:36.215: 1639260356: ../libfprint/sync.c:56
(process:675): libfprint-async-DEBUG: 19:56:36.215: 1639260375: ../libfprint/async.c:59
(process:675): libfprint-async-DEBUG: 19:56:36.215: status 0
(process:675): libfprint-sync-DEBUG: 19:56:36.215: status 0
Opened device. It's now time to scan your finger.

(process:675): libfprint-sync-DEBUG: 19:56:36.215: to be handled by vfs_proprietary
(process:675): libfprint-async-DEBUG: 19:56:36.215: 1639261173: ../libfprint/async.c:526
(process:675): libfprint-DEBUG: 19:56:36.216: action 4
(process:675): libfprint-vfs_proprietary-DEBUG: 19:56:36.216: dev_activate(1)
(process:675): libfprint-capture-helper-DEBUG: 19:56:36.219: capture-helper spawned successfully, pid=677
(process:675): libfprint-DEBUG: 19:56:36.219: status 0
(process:675): libfprint-async-DEBUG: 19:56:36.219: 1639264564: ../libfprint/async.c:547
(process:675): libfprint-capture-helper-DEBUG: 19:56:36.219: entering epoll loop
TRACE vfs_proprietary.c: ch_img_ready_callback() [103]
(process:675): libfprint-DEBUG: 19:56:42.355: finger on sensor
TRACE vfs_proprietary.c: ch_img_ready_callback() [111]
TRACE vfs_proprietary.c: ch_img_meta_callback() [119]
(process:675): libfprint-DEBUG: 19:56:42.356: length=47000
(process:675): libfprint-vfs_proprietary-DEBUG: 19:56:42.357: img: dimensions=200x235, length=47000, flags=5
TRACE vfs_proprietary.c: ch_img_meta_callback() [152]
TRACE vfs_proprietary.c: ch_img_meta_callback() [159]
TRACE vfs_proprietary.c: ch_img_data_callback() [167]
(process:675): libfprint-DEBUG: 19:56:42.357: 1645402897: ../libfprint/imgdev.c:234
(process:675): libfprint-DEBUG: 19:56:42.358: finger removed
(process:675): libfprint-async-DEBUG: 19:56:42.358: result 0
TRACE vfs_proprietary.c: ch_img_data_callback() [177]
TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
(process:675): libfprint-sync-DEBUG: 19:56:42.367: result: complete
(process:675): libfprint-sync-DEBUG: 19:56:42.368: ending capture
(process:675): libfprint-async-DEBUG: 19:56:42.369: 1645414935: ../libfprint/async.c:605
(process:675): libfprint-DEBUG: 19:56:42.370: 1645415532: ../libfprint/imgdev.c:363
(process:675): libfprint-async-DEBUG: 19:56:42.371: 1645416259: ../libfprint/async.c:580
(process:675): libfprint-sync-DEBUG: 19:56:42.371: 1645416971: ../libfprint/sync.c:608
(process:675): libfprint-DEBUG: 19:56:42.373: written to 'finger.pgm'
(process:675): libfprint-DEBUG: 19:56:42.375: written to 'finger_standardized.pgm'
(process:675): libfprint-sync-DEBUG: 19:56:42.376: 1645421464: ../libfprint/sync.c:96
(process:675): libfprint-async-DEBUG: 19:56:42.377: 1645423073: ../libfprint/async.c:93
(process:675): libfprint-sync-DEBUG: 19:56:42.378: 1645423675: ../libfprint/sync.c:77
(process:675): libfprint-DEBUG: 19:56:42.378: 1645423861: ../libfprint/core.c:772

lighterowl · 2019-01-25T20:40:07Z

I think I got it. The fact that the libfprint examples work fine, but accessing the device via fprintd doesn't made me think, and I went to fprintd's systemd unit file in order to add G_MESSAGES_DEBUG so it produces more output.
At least on Arch - but I suppose the same applies to Gentoo as well, given the comments here - the unit file has the following directives, among other things meant to protect the system from misbehaving applications :

# Filesystem lockdown
ProtectSystem=strict
ProtectKernelTunables=true
ProtectControlGroups=true
ReadWritePaths=/var/lib/fprint
ProtectHome=true
PrivateTmp=true

After commenting everything out, fprintd-enroll started working. After re-enabling everything and retrying, the minimal set of stuff that needs commenting out seems to be ProtectSystem, ReadWritePaths (which has no effect if there's no ProtectSystem anyway, according to the documentation), and PrivateTmp. Running fprintd-enroll with only these three commented out works for me.

I guess the shared library that capture-helper links to does some weird stuff that causes vfs_wait_for_service to fail, at least everything seems to point in this direction. The exact system call that fails could probably be tracked down with strace, but I think this solution somewhat works for now.

This is going to be weird from a packaging perspective, since we now effectively have a package which needs to modify third-party package's (fprintd's) files. I'm not really sure how to solve this in the AUR package that I'm maintaining : let me know how/if you solve it in Gentoo.

Thanks!

rindeal · 2019-01-27T01:28:27Z

It's true that when developing this driver I tested it only with 'fprint_demo' and 'Fingerprint GUI', not 'fprintd' and not fprintd running under systemd's direction. The excerpt from the systemd's unit file is definetely too restrictive though. Because the proprietary library communicates with the proprietary daemon through special files inside '/tmp'. So forget about PrivateTmp= right away. As to the other two offending directives, I'm not sure, since I don't remember the library would need access to paths other than /tmp and /sys. The service file I created years ago for the deamon, however, uses only ProtectSystem=True and ReadWritePaths family of directives is explicitely commented out citing issues with symlink resolving, ie it blocked paths in whitelisted directories which resolved into blacklisted ones. So that may be the way to go with fprintd as well.

If you want to have fprintd working by default and cannot fix it upstream, you could modify the service file for the daemon to include PrivateTmp=true and JoinsNamespaceOf=fprintd.service. This would make this driver unusable for everyone else except fprintd though.

Anyway, this is an issue with the systemd service file shipped with fprintd. Thus, to my relief, my driver remains bug-free.

inpos · 2019-01-28T06:46:41Z

I've created /etc/systemd/system/vcsFPService.service.d/local.conf with following content:

[Service]
PrivateTmp=true
JoinsNamespaceOf=fprintd.service

then execute:
systemctl reenable vcsFPService.service
and reboot system.
After that try fprintd-enroll and get:

inpos@inpos-hpe ~ $ fprintd-enroll 
Using device /net/reactivated/Fprint/Device/0
Enrolling right-index-finger finger.
EnrollStart failed: Enroll start failed with error -103

and output of journalctl -f :

янв 28 09:45:33 inpos-hpe dbus[1417]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
янв 28 09:45:33 inpos-hpe systemd[1]: Starting Fingerprint Authentication Daemon...
янв 28 09:45:34 inpos-hpe dbus[1417]: [system] Successfully activated service 'net.reactivated.Fprint'
янв 28 09:45:34 inpos-hpe systemd[1]: Started Fingerprint Authentication Daemon.
янв 28 09:45:35 inpos-hpe fprintd[5865]: capture-helper probably died while we were waiting for img ready signal
янв 28 09:45:35 inpos-hpe fprintd[5865]: capture-helper output:
                                            SIGALRM caught: timed out waiting for VFS service
янв 28 09:45:35 inpos-hpe fprintd[5865]: TRACE vfs_proprietary.c: vfs_proprietary_dev_activate() [229]
янв 28 09:45:35 inpos-hpe fprintd[5865]: activation failed with error -103
янв 28 09:45:35 inpos-hpe fprintd[5865]: failed to start enrollment

IvanVojtko · 2019-01-28T13:11:11Z

Try to kill process vcsFPService and run
sudo vcsFPService
Or try reboot, kill service and run manually. Works for me, but sometimes I still get -103 error.

inpos · 2019-01-28T14:14:32Z

@IvanVojtko I think this is not "daily use" workaround ;)

rindeal · 2019-02-02T07:49:23Z

Works for me, but sometimes I still get -103 error.

That shouldn't happen. One reason I see is that it could be at boot, because the systemd service is not properly ordered and you're trying to login before the proprietary daemon is started. Another reason could be that I set the timeout just too low (1sec currently) and it errors out pointlessly. I will increase the timeouts today, and will add code to check that the driver can see the daemon later this month, so that I can debug this common issue more properly. Although I didn't want to go this way initially since it adds dependencies and assumptions.

#4

Prn-Ice · 2019-09-03T23:41:50Z

I get the same error 103 but when I run

systemctl status vcsFPService

I get

Unit vcsFPService.service could not be found.

I installed this package from the AUR on manjaro, and use it with fprintd-vfs_proprietary

DiceShard · 2020-03-07T14:32:38Z

I have the exact same issue

systemctl status vcsFPService

And i get

Unit vcsFPService.service could not be found.

lighterowl · 2020-03-07T14:37:02Z

I get the same error 103 but when I run
systemctl status vcsFPService
I get
Unit vcsFPService.service could not be found.
I installed this package from the AUR on manjaro, and use it with fprintd-vfs_proprietary

I have the exact same issue

systemctl status vcsFPService

And i get

Unit vcsFPService.service could not be found.

This is probably because the name of the unit in the AUR package is vfs495-daemon.

perceival · 2020-03-20T06:21:53Z

For people coming here with the same error: please make sure you reset fingerprint scanner from BIOS (on Elitebook 840 G1 that requires setting up BIOS password first).
Please note that might affect ability to login to other OS if you are dual booting.
In short there are three components required for FPS to work:
vfs495-daemon
libfprint-vfs_proprietary-git
fprintd-vfs_proprietary

Which avoids passing zero lines to fpi_assemble_lines() "gmem.c:130: failed to allocate 18446744073709551612 bytes" rindeal#3 0x00007fe4f6ef428f in g_log (log_domain=log_domain@entry=0x7fe4f6f3506e "GLib", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7fe4f6f3e610 "%s: failed to allocate %lu bytes") at gmessages.c:1398 rindeal#4 0x00007fe4f6ef2ac4 in g_malloc0 (n_bytes=n_bytes@entry=18446744073709551612) at gmem.c:129 rindeal#5 0x00007fe4f8052020 in median_filter (filtersize=25, size=-1, data=0x0) at assembling.c:309 rindeal#6 fpi_assemble_lines (ctx=ctx@entry=0x7fe4f82ac3c0 <assembling_ctx>, lines=0x0, lines_len=0) at assembling.c:389 rindeal#7 0x00007fe4f805f3db in submit_image (ssm=ssm@entry=0x16c3cba360, data=data@entry=0x16c3cb9cc0) at drivers/vfs5011.c:412 See https://bugzilla.redhat.com/show_bug.cgi?id=1484812 Closes: #42

ReyMagos · 2023-05-27T15:10:41Z

I have similar issue and I don't have vcsFPService at all. Can someone post this systemd file? Or give me some instructions what I did wrong?

rindeal added a commit that referenced this issue Feb 2, 2019

capture-helper: increase timeouts during initialization

439a94d

#4

rindeal added a commit that referenced this issue Feb 25, 2019

capture-helper/main.c: improve debugging of /tmp namespace issues

eca6935

#4

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error -103 #4

Error -103 #4

IvanVojtko commented Jan 17, 2019 •

edited

Loading

inpos commented Jan 18, 2019 •

edited

Loading

rindeal commented Jan 19, 2019 •

edited

Loading

inpos commented Jan 21, 2019

inpos commented Jan 21, 2019

inpos commented Jan 21, 2019

lighterowl commented Jan 25, 2019 •

edited

Loading

lighterowl commented Jan 25, 2019

rindeal commented Jan 27, 2019

inpos commented Jan 28, 2019

IvanVojtko commented Jan 28, 2019

inpos commented Jan 28, 2019

rindeal commented Feb 2, 2019

Prn-Ice commented Sep 3, 2019 •

edited

Loading

DiceShard commented Mar 7, 2020

lighterowl commented Mar 7, 2020

perceival commented Mar 20, 2020 •

edited

Loading

ReyMagos commented May 27, 2023

Error -103 #4

Error -103 #4

Comments

IvanVojtko commented Jan 17, 2019 • edited Loading

inpos commented Jan 18, 2019 • edited Loading

rindeal commented Jan 19, 2019 • edited Loading

inpos commented Jan 21, 2019

inpos commented Jan 21, 2019

inpos commented Jan 21, 2019

lighterowl commented Jan 25, 2019 • edited Loading

lighterowl commented Jan 25, 2019

rindeal commented Jan 27, 2019

inpos commented Jan 28, 2019

IvanVojtko commented Jan 28, 2019

inpos commented Jan 28, 2019

rindeal commented Feb 2, 2019

Prn-Ice commented Sep 3, 2019 • edited Loading

DiceShard commented Mar 7, 2020

lighterowl commented Mar 7, 2020

perceival commented Mar 20, 2020 • edited Loading

ReyMagos commented May 27, 2023

IvanVojtko commented Jan 17, 2019 •

edited

Loading

inpos commented Jan 18, 2019 •

edited

Loading

rindeal commented Jan 19, 2019 •

edited

Loading

lighterowl commented Jan 25, 2019 •

edited

Loading

Prn-Ice commented Sep 3, 2019 •

edited

Loading

perceival commented Mar 20, 2020 •

edited

Loading