bakkeby / dwm-flexipatch

A dwm build with preprocessor directives to decide which patches to include during build time

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

does restarting with restartsig active autostart again?

Goosegit11 opened this issue · comments

I want to use restartsig with autostart.sh, but as I understand it when restarting it restarts everything from autostart.

Is this problem solved in flexipatch?

I don't use flexipatch, but if you have solved this problem, I would be happy to know how.

I want to use restartsig with autostart.sh, but as I understand it when restarting it restarts everything from autostart.

Yes that is the case, because restarting dwm makes it trigger the execution of autostart.sh again.

Is this problem solved in flexipatch?

Not it is not.

if you have solved this problem, I would be happy to know how.

Generally if you are using the autostart patch (autostart.sh) then it is good practice to check if a program is already running before spawning another instance of it. Here is an example using pidof to get the process ID (PID) of a running instance of dwmblocks:

if [ ! $(pidof dwmblocks) ] && [ $(command -v dwmblocks) ]; then
	dwmblocks &
fi

The command -v checks whether an executable dwmblocks exists, not strictly necessary, but saves you a few errors / surprises the next time you (re-)install linux and try to set up your environment again.


If you use the cool autostart patch then dwm will remember the PID of each process spawned as part of the autostart process, then it will forcibly kill those processes when dwm exits. This avoids multiple of the same program running in parallel, but won't work if you are spawning shell scripts that may in turn spawn other programs. In some cases it may also be undesirable to kill a process only to start it again when restarting (if it could in principle just keep on going).

Combined with the restartsig patch this should be fine, provided that you are using the dwm keybinding to restart the window manager. The use of kill signals as the patch suggests is inherently unsafe and can cause random crashes when restarting (regardless of other patches applied). If you rely on kill signals then you may want to refactor sighup and sigterm handling, but that is a different topic.


I took a different approach with my personal build ending up with a variant of cool autostart where:

  • programs start at the initial startup, but are only forcibly killed when the user quits / exits
  • which means that the PIDs are persisted across restarts
  • additionally there is a second set of programs that are executed following every restart (e.g. change wallpaper)

What do you mean by "a variant of cool autostart"?
Did you modified the patch? Where can I get your variant?

I don't have a standalone patch for that and it wouldn't make that much sense creating one as it ties into the seamless restart feature.