You are not logged in.
I'm trying to setup a system where I can make various systemd user services start and stop with my wm (dwm). I've tried setting up the xorg as a service in https://wiki.archlinux.org/title/System … er_service to no avail so I am searching for a less complicated method. My initial thought was to have dwm start a certain systemd user target when it starts, and stop it when it stops, but I'd like the system to be slightly more robust to error, if say dwm fails and is unable to stop the systemd user target. Is there any way to have systemd monitor a process but otherwise leave it alone and let it start in whatever context it was called? Ideally a command like
systemctl --user --monitor-as dwm.service /usr/local/bin/dwm
or am I thinking about this the wrong way?
Last edited by Vityou (2024-09-13 21:16:13)
Offline
You can use systemd-run(1) to transiently start processes in your user session under the governance of systemd, e.g.
systemd-run --user /usr/local/dwm
The question sounds XY, why do you want to do that, what's the ultimate purpose of this excercise?
Offline
If the WM runs as a detached process, there would be two problems, one easy to fix, the other not so much. Easy to fix would be the lack of DISPLAY in the dwm environment causing dwm to fail; this could be exported from a relevant systemd config. The harder problem is that Xorg requires a controlling process in order to not just exit immediately.
Are you just looking to be able to view / watch the stdout / stderr of dwm while it's running? There are much easier ways of doing that if that's you're goal.
Last edited by Trilby (2024-09-13 13:41:33)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Not exactly, I'm looking to watch whether the dwm process itself is still running, and run a command when it starts/stops.
Offline
Watch? Remotely?
If you're sitting at the computer, it's pretty obvious if the window manager is still running. And generally speaking it'd keep running until you kill it with a key combination or other command. Is dwm crashing on you? What's the actual use case here? This is really sounding like and X-Y-Z problem now.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
If DWM is your session keeping device, x11 and (virtually) every x11 client will die with it.
The uncomplicated traditional approach would be to start whatever you want in the xinitrc, not exec DWM but tail the xinitrc with a cleanup of the processes that don't die with the server.
That being said, arch does not enable lingering so for the most part processes of your session will be terminated with the session.
=> Xy-problem, what actual problem are you trying to solve?
Offline
The Y is clearly stated in the original post, i.e. a robust way to make auxiliary processes start and stop with dwm. No, dwm doesn't usually crash, but I don't want to run my system on the assumption that everything will always work fine. Maybe I should have been more clear in that I would like to use systemd because that is what I use for quite a few other things. systemd-run worked, but I ended up going with a oneshot user service preceeded by
systemctl --user import-environment
which seems to work for my needs. I'll mark this as solved.
Offline
No, wasn't and barely is.
dwm doesn't actively stop anything anyway but w/ a one shot service and since you seem concerned about dwm crashing, you'll lose the session with it.
If you wanted an X11 Session that's robust against dwm crashes you could use a rate controlled loop conditioned on the exit status or, if you insist on a user service, select a different Restart condition.
Offline
No, dwm doesn't usually crash, but I don't want to run my system on the assumption that everything will always work fine.
My question doesn't depend on the frequency or likelihood of a crash. Why do you need to be "notified" of dwm crashing, even if it is an extremely rare thing, as you'll see it happen right in front of your eyes?
This makes absolutely no sense at all. Note that such phrasing is sometimes used to suggest different preferences and a lack of understanding of different tastes - but here I mean it in the quite literal sense that your goals as stated are literally nonsensical. So clearly there has been a failure somewhere in communicating the goals - this is why most people on the thread feel like this is an X-Y problem. If we do not understand your question, we are most certainly not giving you optimal answers to it. So if you want meaningful help, you need to help us understand.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
So I am in fact aware that I can see when dwm crashes, and I could in fact manually handle post-crash cleanup myself. But seeing as I'm on a computer, which are known for being able to automate processes, I figure I can have the computer do it for me.
Further, seeing as I am on a computer with systemd installed, whos purpose is monitoring and handling dependencies between long-running processes, I figure I can use such a program to accomplish this goal in a more elegant and integrated way than say, running a while loop to check for crashes.
With this in mind, my question was mainly asking how to accomplish this in a way that would work with startx. As Trilby points out, this would involve ensuring the process in my xinitrc is controlling.
The issue can be solved with systemd-run with the --wait flag, starting a oneshot unit, or starting a simple unit with the --wait flag.
Offline
You also might want to post your current setup because there's a high chance you're trying to solve a non-existent problem. Certainly if you haven't enabled lingering and aren't running parallel sessions (in which case it's not even clear why non-x11 processes should be bound to a specific login or even wm.
You can of course make this as complicated as you want, but rest assured that the rest of us has a hard time coming up with a sane problem you're trying to solve and the more convoluted and indirect the process becomes, the more fragile it will be.
Offline