Resume (sleep.d) script not fully working

Hi,

To workaround a problem with nvidia graphics and fancontrol on both native and asus_atk0110 drivers, I have written a small easy script that runs at resume mode when resuming from suspending to RAM.

The script is called

81fancontrol_cd

and is located

/usr/lib/pm-utils/sleep.d

created as ROOT and EXECUTABLE.

The script does kill 2 processes, but does not restart them. I do not know where the error log file is located, so I can’t troubleshoot.

Anyone would know where the log files are or anyone would know why my script does not start the 2 processes?

#!/bin/bash
case $1 in
    hibernate|suspend)
        #sudo pkill cairo-dock & fancontrol
        ;;
    thaw|resume)
        sudo pkill cairo-dock
        sudo pkill fancontrol
        #nohup sudo fancontrol > /dev/null 2>&1 &
        sudo fancontrol
        #nohup cairo-dock -o > /dev/null 2>&1 &
        cairo-dock -o
        ;;
        *)
        ;;
esac

exit $?

Everything works up to line

sudo pkill fancontrol

included.

But fancontrol and cairo-dock don’t start. I don’t know if the “#” comment is causing a problem, or if it’s something else.

Line

#sudo pkill cairo-dock & fancontrol

is bad I think, but it’s commented, I don’t use it.

tnx

#sudo pkill cairo-dock & fancontrol

is not ‘bad’, it is comment, Can comment be bad?

sudo pkill cairo-dock & fancontrol

is no good bash. The & at the end releases it (the sudo process that is, not the pkill process) from the shell, but the word fancontrol after it?

You say the script is owned by root. But who executes it? I suppose it is started fom a process run by root. That means it also is run by root. What do all the sudo statements then???

fancontrol goes into an infinite loop. You must disassociate it from the calling process (run it as a daemon). Otherwise your script just hangs there. Do some reading: Background Shell Commands.

I say that line is bad cuz the ‘&’ is not doing what I want, I wanted to kill both processes using same command and I thought the ‘&’ or ‘&&’ would do it, but it’s bad bash command. Does not matter as long as it’s commented. I won’t use it anyway, I should remove that line.

It’s owned by root, but how can I know who runs it? All the files located in that folder are owned by root and I read that when writing such sleep.d scripts, the scripts need to be owned by root. So I followed the advise, but I do not know who runs it. I guess if the kill works it means root is running the script, right?

But you are correct, if root runs it, why the sudo statements. lolll Should not be required, but should not harm either. I use ‘no password’ option, so when my user types ‘sudo’, it will run the command as root without prompting for pw. I believe same thing would happen if root runs a sudo command.

Maybe I should try without the sudo just in case.

BTW, fancontrol needs to be started by root, but cairo-dock does not or should not, I am unsure on that one yet. Anyway ‘fancontrol’ does not start at all even under root, so I am not yet into looking at the ‘cairo-dock -o’ statement.

Ok I’ll check that out, tnx.

Of course you should not use sudo here, it is complete nonsense. Why one statement with and other without sudo. And why not

sudo { sudo command ; }

Please try to understand what you are doing. Also:

I use ‘no password’ option, so when my user types ‘sudo’, it will run the command as root without prompting for pw

is not very clever behaviour (to be polite). See: SDB:Login as root - openSUSE

You really should try to find who does what and when. When you need a root action, try to couple it to an existing root action. When you need a user action, try to couple it to e.g. user login (e.g. adding a script to the ~/.kde4/Autostart of the user involved). Else I am afraid you will hose your system sooner or later.

And the & and && in bash are wide different things.
. In short the && let the following statement be executed when the statement before it succeeded (returned 0).
. The & at the end of a statement detaches it from the shell.

Start reading

man bash

or any introduction to shell programmin before you let all sorts of statements loose as root.

I think if kde4/autostart is read at resume state I am better off using that, rather than trying to do something (possibly wrong) in the /sleep.d folder. If it’s not read, then I will continue reading more on such scripts and make sure I write it the right way.

tnx