Any plans to make this work on remote systems?

[mojochao]

One of the great things about tramp mode is that if I'm remote editing a file and open a shell it opens on the remote host. What would it take for daemons.el to support something like that?

Thanks!

[cbowdon]

This should be possible because the underlying shell commands work with tramp. If you set default-directory in the daemons buffers to a remote path then the commands should be run against the remote host. It would interfere with the "always sudo" option, which uses the same trick.

I'm interested in doing this (it was a popular request on Reddit too) but not likely to have the time for a little while. PRs welcome of course. I guess it would be necessary to add a daemons-remote command or similar.

[Ambrevar]

I've implemented similar TRAMP support for https://github.com/emacs-helm/helm-system-packages.

It might be much easier for daemons.el if you don't have to track different caches.

[cbowdon]

Hey, thanks for the tip. Tracking state is indeed what I'm struggling with. :)

[Ambrevar]

To get get the host-name of the default-directory of a TRAMP buffer, I use (tramp-file-name-host (tramp-dissect-file-name ...)).

Beware of the incompatibilities in the TRAMP file-name structure and functions between Emacs 24, 25 and 26. Helm System Packages has some provision for this.

[cbowdon]

Ok, with that help from @Ambrevar this is now done. Thank you!

Would anyone mind giving it a try before I release to MELPA please? In my experience it is working well, but it's a fairly large refactoring so I am wary.

The branch is: https://github.com/cbowdon/daemons.el/tree/buffer-per-host

[Ambrevar]

It does not find the remote init system in my test. Recipe:

• M-x eshell
• cd /ssh:
• M-x daemons Result:

  error: "I’m sorry, your init system isn’t supported yet!"

I suppose the detection test gets confused. Let me know if you want me to investigate more.

[cbowdon]

That’s a good start, thanks. I’ll take a look next chance I get.

[cbowdon]

Did you redact some of your TRAMP path? This is working for me:

• M-x eshell
• cd /ssh:myuser@myserver:
• M-x daemons

The same is working for cd /sudo::.

That was for systemd and SysV though. Perhaps I've just screwed up the detection test for Shepherd? I added a check for system type, in hopes of avoiding an unnecessary shell command.

(and (eq system-type 'gnu/linux)
             (equal 0 (daemons--shell-command "which herd")))

[cbowdon]

Just had a thought, not able to check right now though: this could be playing badly with daemons-always-sudo.

[Ambrevar]

I just re-tried, I now get the following error:

helm-M-x: Symbol’s function definition is void: tramp-file-name-real-user

[Ambrevar]

Note that the remote system I connect to runs systemd.

[cbowdon]

That tramp error is the same as #9 - are you running Emacs master?

Doesn’t necessarily explain the first error though. Have you tried without always-sudo by any chance?

Cheers for your patience, I’m trying to find time to work on this.

[Ambrevar]

Yes, I run Emacs master.

I tried with and without always-sudo, but that should not matter for systemd.

[Ambrevar]

Also see comment above for TRAMP compatibility functions: https://github.com/cbowdon/daemons.el/issues/4#issuecomment-379445840.

[cbowdon]

The TRAMP compatibility issue is fixed (tested with Emacs 26 not master, but believe this is sufficient).

You're right that always-sudo shouldn't matter for systemd, but the way I've implemented it will mess up the TRAMP paths - it essentially just does cd /sudo::. Ideally the implementation should be smarter and add a hop to the current path if we're on a remote system.

However because I don't have much spare time, I've started by just ignoring always-sudo if we are on a remote system. So the user is responsible for ensuring their current TRAMP session has enough privileges, i.e. you need to do something like /ssh:me@example.com|sudo:example.com:. When the basic functionality is working properly the nice stuff like automatic sudo can be re-visited.

Please let me know if this is working any better for you.

[Ambrevar]

It still does not work. Sorry for now investigating further, I have little time on my hands at the moment. I get the following in the Message buffer:

which: no systemd in (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin) which: no service in (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin) which: no herd in (/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin)

Why is it checking for systemd? I believe it should check for systemctl.

Also I'm not completely sure the path are right: the TRAMP prefix might be missing.

[cbowdon]

No worries, I’m very grateful for any help you can give. You’re right it should be checking for systemctl not systemd. Will fix shortly.

[cbowdon]

Fixed the systemd/systemctl issue. Apparently some systems (e.g. mine) do have a systemd binary which is why I didn't spot this not working.

[Ambrevar]

The systemd issue is gone, but now connecting from GuixSD to Arch Linux I get the following list of daemons:

sh: /gnu/store/y9ikcs0lcsip95p1914jv355034yjc6i-bash-4.4.12/bin/bash:

/gnu/store/... belongs to GuixSD, not Arch, so daemons.el gets it wrong.

[cbowdon]

Is that with the same method you used earlier? (i.e. with eshell)

[Ambrevar]

Yes.

[cbowdon]

Just updating thread to say that I haven't as yet had chance to test this, but it's not forgotten.

[cbowdon]

Given that there aren't outstanding issues with existing functionality and from my testing across systemd/sysv the new functionality works well, this has been merged to master. Hopefully this will generate more information about the issue you're experiencing.

[cbowdon]

Closing this as the functionality works in my tests and it's been a few months without comment. Feel free to reopen if it troubles you.