Program Name

[SethGower]

Cool program, I have run into an issue though. I am trying run it with my startup script, which also kills currently running processes of the same name, but I can't figure out what is running for it. I can't find a systemd process for it, or anything from ps -e. I see in the readme it mentions adding it to the "Startup applications" menu, but I don't have one since I am not using a DE. How can I kill the process when I run it using caffeine &.

[WhyNotHugo]

Running ps aux | grep caffeine show show up the program. We use setproctitle so that the process title is caffeine.

Also, caffeine -k should kill any running instances.

[SethGower]

caffeine -k doesn't seem to properly kill the instance. When I run that, it seems the process gets hung, and until I sent the keyboard interrupt (C-c) it doesn't close it. This is not very beneficial, since I use a startup script to start various processes when I restart i3. It would be very helpful if I could just run killall caffeine-ng as I do with my other services. The most obvious solution I see right now to just kill the process is to parse the output of ps aux | grep caffeine using awk to grab the pid.

[WhyNotHugo]

Sorry, running caffeine -k kills the existing instance and starts a new one.

What you want is caffeine kill.

[canalguada]

Hi ! I also run into some issue. I know how to workaround with ps command, but pgrep is pretty standard. Moreover, shellcheck recommends to use pgrep and I am too lazy to write more comments that will only be read by a linting program, if not using this tool.

$ pgrep -il caffeine   

$ pgrep -il caffeine-ng

$ ps -e -o pid,command | grep -v grep | grep caffeine
   1989 caffeine-ng
$ pgrep -ifl caffeine-ng 
1989 c

There is no answer with pgrep unless I check through the whole command line. And when I finally get a process name that could be useful with some pkill or killall command, the answer is neither caffeine as per previous comment, nor caffeine-ng that I expect according to ps | grep caffeine output.

I know that for instance with redshift-gtk, pgrep returns an accurate process name.

$ pgrep -il redshift-gtk
1983 redshift-gtk
$ ps -e -o pid,command | grep -v grep | grep redshift-gtk
   1983 python3 /usr/bin/redshift-gtk

This is also a python program, and since they use their own setproctitle function not the pypi module, maybe it can help. I didn't check furthermore tonight so I won't write a suitable PR, but some work have been done here.

Now :

$ pgrep -il caffeine
87796 caffeine
$ ps -e -o pid,command | grep -v grep | grep caffeine
  87796 /usr/bin/python3 /usr/bin/caffeine

[WhyNotHugo]

Don't you want something like pgrep -f? TBH, I'm not really sure about this. I've used pgrep very little, so I can't help you with that.

Is caffeine kill not working for you?

[canalguada]

pgrep -f does not help me when I wrote a startup script that requires the name of services, like caffeine ou redshift-gtk, as positional parameters… And since it only exits after the process name of each service appears in the table, pgrep -f caffeine shows the script pid (or any another command line that includes the word caffeine) even after caffeine failed to start. Only because there is a bug, the process name being c, neither caffeine-ng nor caffeine.

As I wrote earlier, I know how workaround any issue in my shell script, filtering with awk or grep or whatever another tool that may help here. But I shouldn't have to. With a damn relevant process name.

[canalguada]

Is caffeine kill not working for you?

To be honest, I still fail to understand why you insist so much on this.

As a random GUI user, I click on the popup menu to quit caffeine and don't use CLI. But as the administrator of my desktop environment, I expect that, when required, ANY program terminates gracefully sending the TERM signal to its main pid and if it remains in the process table after that, I expect to be able to kill the process tree forcefully sending the KILL signal with another kill command as per OP request.

When I can't click on the menu item of ANY stuck program, I guess that throwing yet another command at it won't help much. I may be wrong here but, when there is no actual data to save, nobody will actually check if a random program out of the many that run offers such a kill command. That implements caffeine kill instead of kill caffeine.

    def kill(self):
        os.kill(self.pid, 9)

Sure, it can help… But the easy to remember and standard kill caffeine and kill -9 caffeine commands as everybody expects in real world, caffeine being the basename of the executable script, helps much more. And this commit allows using them.

But if you believe that not standard interaction with environment sounds much better for caffeine-ng, I won't struggle anymore to convince you to let anybody else fix this bug.

[WhyNotHugo]

Honestly, I've no idea why pgrep fails. The process name is caffeine-ng for me:

ps aux | grep caffeine
hugo      889215 12.8  0.3 310208 56804 pts/5    Sl+  10:28   0:00 caffeine-ng

I never said anything about wanting non-standard interactions. I never said I didn't want to fix this bug. The thing is, I've not idea what the problem is, nor how to reproduce the issue. Being rude is definitely going to convince me to set aside some free time to research what's going on.

[canalguada]

The thing is, I've not idea what the problem is, nor how to reproduce the issue.

On my up to dated Archlinux system, running bash shell, but the same issue occurs with zsh, when relying on a shell builtin.

$ type kill
kill is a shell builtin
$ which kill
/usr/bin/kill
$ pkgfile /usr/bin/kill
core/util-linux
$ ps aux | grep caffeine
canalgu+  236162  9.6  1.6 394936 64676 ?        Sl   12:20   0:02 caffeine-ng
canalgu+  236240  0.0  0.0   6308  2312 pts/1    S+   12:21   0:00 grep --color=auto caffeine
$ /usr/bin/kill caffeine-ng
kill: cannot find process "caffeine-ng"
$ /usr/bin/kill caffeine
kill: cannot find process "caffeine"
$ sudo /usr/lib/python3.7/site-packages/scripts/procinfo.py 236162  
pid           236162
name          c
parent        1 (systemd)
exe           /usr/bin/python3.7
cwd           /usr/lib/python3.7/site-packages/caffeine
cmdline       caffeine-ng                       
started       2019-10-23 12:20
cpu-tspent    0:11.79
cpu-times     user=8.91, system=2.83, children_user=0.01, children_system=0.04
cpu-affinity  [0, 1]
cpu-num       0
memory        rss=63.3M, vms=385.7M, shared=35.7M, text=8.0K, lib=0.0B, data=59.6M, dirty=0.0B
memory %      1.61

[more not relevant info…]

$ /usr/bin/kill c
$

As per my very first comment, the process name is not set to caffeine-ng, or caffeine, or whatever you think it is, at least nowadays, with the code in master. This commit from my previous said rude comment shows what and where the problem is.

Maybe you should trust more the python standard library, since it provides a safe and sane way through libc to set process name which other standard tools rely on.

With commit mentioned above :

$ /usr/bin/kill --pid caffeine
254210
$ ps aux | grep caffeine    
canalgu+  254210 18.0  1.5 391964 63048 ?        Sl   13:42   0:01 /usr/bin/python3 /usr/bin/caffeine
canalgu+  254294  0.0  0.0   6308  2288 pts/1    S+   13:42   0:00 grep --color=auto caffeine
$ sudo /usr/lib/python3.7/site-packages/scripts/procinfo.py 254210
pid           254210
name          caffeine
parent        1 (systemd)
exe           /usr/bin/python3.7
cwd           /usr/lib/python3.7/site-packages/caffeine
cmdline       /usr/bin/python3 /usr/bin/caffeine
started       2019-10-23 13:42
cpu-tspent    0:01.93
cpu-times     user=1.58, system=0.25, children_user=0.04, children_system=0.06
cpu-affinity  [0, 1]
cpu-num       1
memory        rss=61.7M, vms=382.8M, shared=34.8M, text=8.0K, lib=0.0B, data=58.8M, dirty=0.0B
memory %      1.57

[more not relevant info…]

$ /usr/bin/kill caffeine
$

You can still argue that you'd rather to set the process title while I find much more helpful setting the process name.

On Linux systems, one can use prctl function that allows to control specific characteristics of a process' behaviour, and set properly both title and name. Python bindings are provided with the package and the documentation can be found here

But that doesn't help much, if you wish to keep BSD compatibility. Nethertheless, please note that ps -e, using POSIX options, doesn't show up the process title, but the process name that the OP request you to implement, in order to be able to terminate or kill the program without hassle.

For instance, on Archlinux, kill belongs to core/util-linux package, killall to core/psmisc package and pgrep, pkill, or pidof to core/procps-ng package, the same one that provides ps too. And the base group, for minimal installation, requires these three ones.

So I think that there is only a sane choice. If you want to keep using the same ps aux | grep instead of any other command, you can change the basename of the executable script in setup.py to the package and repository name and choose accordingly caffeine-ng as the actual process name.

[WhyNotHugo]

As per my very first comment, the process name is not set to caffeine-ng, or caffeine

You didn't specify this before. Okay, what's it being set to? How can I check a process' name?

This commit from my previous said rude comment shows what and where the problem is.

Sorry, I don't see any explanation there to (1) what the root of the problem is (2) what this does (3) how it fixes it. Can you explain that?

I don't mind trying to fix the problem, but I honestly don't understand what's causing this weird behaviour with pgrep and pkill.

Maybe you should trust more the python standard library, since it provides a safe and sane way through libc to set process name which other standard tools rely on.

I'm glad that you found a way to do it. Care to explain how, and how it works? Also, what's broken with the current implementation? Can't it be fixed?

You can still argue that you'd rather to set the process title while I find much more helpful setting the process name.

That's just you ranting. I didn't argue that. In fact, I haven't argued anything so far. I've just given a possible workaround, and said I don't really know what's causing this problem. You seem so fixed in arguing you haven't noticed you're the only one doing it.

On Linux systems, one can use prctl function that allows to control specific characteristics of a process' behaviour, and set properly both title and name. Python bindings are provided with the package and the documentation can be found here

We can't really use anything Linux-specific, since that wouldn't work on other platforms.

Finally, I see you mentioned process name and process title. What exactly is the difference between the two? I can't seem to figure that one out.

[canalguada]

I won't argue or rant anymore today. Cause you don't read any damn link that I provide since the very first comment to show you how things can be done right elsewhere.

Neither the documentation of prctl bindings with its tip regarding what the standard prctl() syscall implements or not on Linux, nor the code that I submit for the program you maintain, nor some procedure with more reliable tools that shows up that yours is buggy.

Thus, I won't loose more time trying to explain, again and again, that the process title may shows up in ps with BDS-style options, but that the process name is yet required so that the recommended tools pgrep, kill or killall could work… even on some BSD platform. Feel free to read the C code of these tools, if you don't trust what I said and want to understand why by ourself.

I can deal with my forked repository while you ignore whatever I might wrote trying to fix this annoying issue. Building a package from it was far more easy than trying not to be rude with any stubborn maintainer that don't care of what can help many others users.

[canalguada]

You didn't specify this before. Okay, what's it being set to?

What is this from my very first comment ?

$ pgrep -ifl caffeine-ng 
1989 c

There is no answer with pgrep unless I check through the whole command line. And when I finally get a process name that could be useful with some pkill or killall command, the answer is neither caffeine as per previous comment, nor caffeine-ng that I expect according to ps | grep caffeine output.

How can I check a process' name?

With pgrep -ifl as per above, after reading its manpage. Or with the command mentioned earlier, passing the pid as argument. This comes from the psutil package. I guess we can trust more its output than what you read in order to fix the issue.

$ ps aux | grep caffeine
canalgu+  236162  9.6  1.6 394936 64676 ?        Sl   12:20   0:02 caffeine-ng
canalgu+  236240  0.0  0.0   6308  2312 pts/1    S+   12:21   0:00 grep --color=auto caffeine
$ /usr/bin/kill caffeine-ng
kill: cannot find process "caffeine-ng"
$ sudo /usr/lib/python3.7/site-packages/scripts/procinfo.py 236162  
pid           236162
name          c
parent        1 (systemd)
exe           /usr/bin/python3.7
cwd           /usr/lib/python3.7/site-packages/caffeine
cmdline       caffeine-ng                       
started       2019-10-23 12:20
cpu-tspent    0:11.79
cpu-times     user=8.91, system=2.83, children_user=0.01, children_system=0.04
cpu-affinity  [0, 1]
cpu-num       0
memory        rss=63.3M, vms=385.7M, shared=35.7M, text=8.0K, lib=0.0B, data=59.6M, dirty=0.0B
memory %      1.61

[more not relevant info…]

If you expect people won't be harsh when you demonstrate not giving a shit to what they wrote you many times, they might be really rude at the end of the day. Well, that is if they still care what you may answer.

[WhyNotHugo]

This project has moved to codeberg.

Follow-up for this issue is at https://codeberg.org/WhyNotHugo/caffeine-ng/issues/14