Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to start Hitch using service hitch start but can using manual methof #373

Open
dv8inpp opened this issue Sep 2, 2022 · 2 comments

Comments

@dv8inpp
Copy link

dv8inpp commented Sep 2, 2022

Cant start using service hitch start

`
● hitch.service - Hitch TLS unwrapping daemon
Loaded: loaded (/lib/systemd/system/hitch.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2022-09-02 08:19:15 UTC; 6s ago
Docs: https://github.com/varnish/hitch/tree/master/docs
man:hitch(8)
Process: 1662 ExecStart=/usr/sbin/hitch --user _hitch --group _hitch --config /etc/hitch/hitch.conf --quiet (code=exited, status=1/FAILURE)
Main PID: 1662 (code=exited, status=1/FAILURE)

Sep 02 08:19:15 hitch systemd[1]: hitch.service: Scheduled restart job, restart counter is at 5.
Sep 02 08:19:15 hitch systemd[1]: Stopped Hitch TLS unwrapping daemon.
Sep 02 08:19:15 hitch systemd[1]: hitch.service: Start request repeated too quickly.
Sep 02 08:19:15 hitch systemd[1]: hitch.service: Failed with result 'exit-code'.
Sep 02 08:19:15 hitch systemd[1]: Failed to start Hitch TLS unwrapping daemon.
`

Can start using /usr/sbin/hitch --log-level=3 --config /etc/hitch/hitch.conf

Ubuntu 20.04 running Hitch 1.5.2 Using OpenSSL version 1010106f

20220902T081709.347951 [ 1514] {core} hitch 1.5.2 starting 20220902T081709.348015 [ 1514] {core} Using OpenSSL version 1010106f. 20220902T081709.350039 [ 1514] {core} Listening on 0.0.0.0:443 20220902T081709.350124 [ 1514] {core} Listening on [::]:443 20220902T081709.350141 [ 1514] {core} Loading certificate pem files (1) 20220902T081709.351226 [ 1514] {core} Note: no DH parameters found in /home/hitch/certs/bundle.pem 20220902T081709.351357 [ 1514] {core} ECDH Initialized with NIST P-256 20220902T081709.351911 [ 1514] {core} Loaded cached OCSP staple for cert '/home/hitch/certs/bundle.pem' 20220902T081709.352225 [ 1515] {core} Process 0 online 20220902T081709.352327 [ 1515] {core} Successfully attached to CPU #0 20220902T081709.352350 [ 1516] {core} Process 1 online 20220902T081709.352442 [ 1516] {core} Successfully attached to CPU #1 20220902T081709.352474 [ 1517] {core} Process 2 online 20220902T081709.352592 [ 1518] {core} Process 3 online 20220902T081709.352633 [ 1514] {core} hitch 1.5.2 initialization complete 20220902T081709.352685 [ 1517] {core} Successfully attached to CPU #2 20220902T081709.352811 [ 1519] {ocsp} Refresh of OCSP staple for /home/hitch/certs/bundle.pem scheduled in 425286 seconds 20220902T081709.352907 [ 1518] {core} Successfully attached to CPU #3

@iammeken
Copy link

iammeken commented Sep 3, 2022

I guess it is because of wrong settings of /lib/systemd/system/hitch.service?

@dugwood
Copy link

dugwood commented Oct 12, 2022

Default Debian's hitch package includes in hitch.service:

PrivateDevices=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=full

Perhaps you have the same thing in Ubuntu, and you're loading files outside of Home and the like.

You should try to override those settings to see if it's working, if then you'll know where to look.

Just add a file named /lib/systemd/system/hitch.service.d/override.conf and add this in it:

PrivateDevices=no
PrivateTmp=no
ProtectHome=no
ProtectSystem=no

If it works, try removing line by line, until you find the issue. My issue was that the certs are in the home of a user which is not _hitch. Perhaps you have the same issue. I've ended up with only ProtectHome=read-only and it works great this way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants