# Help with writing a systemd service

## impact0r

I am trying to create a phc service which would undervolt my cpu after migrating from rc.d-based system to systemd.

This is how I used to run it:

```
rc.d start phc-intel 
```

So I copied the content of /etc/rc.d/phc-intel and created an executable like that:

```
#!/bin/bash

shopt -s nullglob

if [ "$1" = set ]; then

   . /etc/conf.d/phc-intel

   [ -n "$VIDS" ] || exit

   for i in $(< /proc/cmdline); do

      [ $i = nophc ] && exit

   done

   for i in /sys/devices/system/cpu/cpu*/cpufreq/phc_vids; do

      echo $VIDS > "$i"

   done

   exit

fi

. /etc/rc.conf

. /etc/rc.d/functions

case "$1" in

start)

   . /etc/conf.d/phc-intel

   if [ -z "$VIDS" ]; then

      printhl 'Please edit /etc/conf.d/phc-intel'

      exit 1

   fi

   stat_busy 'Setting PHC VIDs'

   for i in /sys/devices/system/cpu/cpu*/cpufreq/phc_vids; do

      echo $VIDS > "$i"

   done && stat_done || stat_fail

   ;;

stop)

   stat_busy 'Resetting default PHC VIDs'

   for i in /sys/devices/system/cpu/cpu*/cpufreq; do

      [ -e "$i/phc_default_vids" -a -e "$i/phc_vids" ] && cp "$i"/phc_{default_,}vids

   done && stat_done || stat_fail

   ;;

status)

   check_off () {

      for i in /sys/devices/system/cpu/cpu*/cpufreq; do

         [ "$(< $i/phc_vids)" = "$(< $i/phc_default_vids)" ] || return;

      done

   }

   check_on () {

      for i in /sys/devices/system/cpu/cpu*/cpufreq/phc_vids; do

         [[ "$(< $i)" =~ "$VIDS" ]] || return;

      done

   }

   stat_busy 'PHC status'

   . /etc/conf.d/phc-intel

   if check_off; then

      status_stopped

   elif check_on; then

      status_started

   else

      stat_fail

   fi

   ;;

setup)

   LOG='/var/log/phc-intel.log'

   fail () {

      stat_fail

      printhl "Look at $LOG to find out what went wrong"

      exit 1

   }

   stat_busy 'Removing old phc-intel modules'

   for i in /lib/modules/*; do

      if [ -f "$i/phc-intel.ko" -a ! -f "$i/version" ]; then

         rm -f "$i/phc-intel.ko"

         rmdir --ignore-fail-on-non-empty "$i"

      elif [ -f "$i/extra/phc-intel.ko" -a ! -d "$i/kernel" ]; then

         rm -f "$i/extra/phc-intel.ko"

         rmdir -p --ignore-fail-on-non-empty "$i/extra"

      fi

   done

   stat_done

   stat_busy 'Compiling new phc-intel module'

   cd /usr/src/phc-intel/

   make &>$LOG && stat_done || fail

   stat_busy 'Installing new phc-intel module'

   make install &>>$LOG && stat_done || fail

   stat_busy 'Cleaning up'

   make clean &>>$LOG && stat_done || fail

   ;;

*)

   echo "usage: $0 {start|stop|status|setup|set}"

esac
```

and the service file:

 *Quote:*   

> [Unit]
> 
> Description=CPU undervolting
> 
> After=cpupower.service
> ...

 

However, when I try to run the service, I get this:

 *Quote:*   

> $ systemctl status phc.service
> 
> phc.service - CPU undervolting
> 
> 	  Loaded: loaded (/etc/systemd/system/phc.service; enabled)
> ...

 

How can I make this work?

PS

I also want to have this service restart automatically if it crashes.

----------

## khayyam

 *impact0r wrote:*   

> I am trying to create a phc service which would undervolt my cpu after migrating from rc.d-based system to systemd.

 

impact0r ... and this migration was done because you understood the technical merits?

 *impact0r wrote:*   

> This is how I used to run it:
> 
> ```
> rc.d start phc-intel
> ```
> ...

 

... and just like magic on sysvinit it works!

 *impact0r wrote:*   

> 
> 
> ```
> . /etc/rc.d/functions
> ```
> ...

 

I remember that way back in pre-systemd days there was this thing called "sruptishing", it was really awfull and no one really understood how to make it boot faster. At some point it was vertically removed from the collective memory so I can't tell you how it worked but it had something to do with files, and some files could "sporse" other files, or make other files do things, or something. Still, all thats in the past now ... and the future is waaaay better.

best ... khay

----------

## impact0r

 *khayyam wrote:*   

> impact0r ... and this migration was done because you understood the technical merits?

 

Yes, it's faster, more configurable and future-proof.

I don't understand what were you trying to say in the rest of the post.

----------

## Anon-E-moose

LoL

----------

## khayyam

 *impact0r wrote:*   

>  *khayyam wrote:*   impact0r ... and this migration was done because you understood the technical merits? 
> 
> Yes, it's faster, more configurable and future-proof.

 

impact0r ... with all due respect you have shown that you are not qualified to make that evaluation. The script you provided 'works' because it has all of the supporting 'functions' of that particular variation of sysvinit, you expect that you can simply write a service file and all will be well, when all of those supporting functions are not present. Gentoo doesn't have "/etc/rc.d/functions", nor the rc.d init structure, "/etc/rc.conf" is openrc and not sysvinit, so variables, and functions like "stat_busy", etc, will simply fail.

 *impact0r wrote:*   

> I don't understand what were you trying to say in the rest of the post.

 

My point, which I'll admit was cryptic, is that one of the key components of the init, prior to systemd's coup-de-main, is that if some functionality is requied (ie: configuring phc-intel) various methods are there to do this. These methods use a number of standard tools, ie: "scripts" composed of small tools/functions/etc that "do one thing and do it well", and so are flexable, portable, and transparent. This transparency makes it so that, with a little understanding of the whats involved, when it fails, it can clearly be seen why. Now, I saw "at a glance" why the above failed, and I did so in part because the methods outlined above have the added advantage of creating users with that understanding, whereas you with your "faster, more configurable and future-proof" init did not. I could illustate this point further, but as I intended to point out with my whimsical rejoinder the reasoning involved is effectively erased from the collective memory, as we are now entering a stage where whatever claims are made have no meaning.

best ... khay

----------

## impact0r

Well, I appreciate an occasional philosophical rant, I really do.

But if you could point out more precisely how could I make this service work, I would appreciate it even more.

----------

## khayyam

 *impact0r wrote:*   

> Well, I appreciate an occasional philosophical rant, I really do.

 

impact0r .... I see, so the above is a rant?

 *impact0r wrote:*   

> But if you could point out more precisely how could I make this service work, I would appreciate it even more.

 

I already did, I pointed out that you are relying on functions, and what-have-you, that don't exist on your system, so you need to translate the above to a non sysvinit setup.

What it comes down to is this: you don't really understand whats involved and this fact makes it difficult for anyone to advise you , had this not been the case you would have had a basic understanding of what the script was doing (ie: sourcing /etc/rc.d/functions), and so would have provided a modified script that was attempting to fix some of the more obvious issues. As it stands all I can see is "here is some code from ${distibution} ... make it work". 

best ... khay

----------

## impact0r

The reason for that is because before that I tried writing this from scratch, like so:

- bin file

```
   1 #!/bin/sh

   2 

   3 . /etc/sysconfig/phc

   4 

   5 [ -z "$VIDS" -o -z "$1" ] && exit 1

   6 

   7 set_vids()

   8 {

   9         for i in /sys/devices/system/cpu/cpu*/cpufreq/phc_vids; do

  10                 if [ -f "$i" ]; then

  11                         echo "$1" > "$i"

  12                         [ "$?" -ne "0" ] && exit 1

  13                 fi

  14         done

  15         true

  16 }

  17 

  18 case $1 in

  19         set)

  20                 set_vids "$VIDS"

  21                 ;;

  22         reset)

  23                 [ -f "/sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids" ] || exit 1

  24                 set_vids "$(< /sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids)"

  25                 ;;

  26 esac
```

- service file:

```
   1 [Unit]

   2 Description=Apply phc configuration

   3 After=cpupower.service

   4 

   5 [Service]

   6 ExecStart=/usr/sbin/phc.sh set

   7 ExecStop=/usr/sbin/phc.sh reset

   8 Type=oneshot

   9 StandardOutput=syslog

  10 RemainAfterExit=yes

  11 

  12 [Install]

  13 WantedBy=multi-user.target
```

but it did not work, so I took another approach by taking an existing service file.

But you are right - for the most part, I do not know what would and what would not apply on systemd (and whether what does not work is safe to remove) so I pasted a whole thing hoping someone can point out how to modify it.[/quote]

----------

## ulenrich

Your service looks fine. What if you do as root

- insert "set -x" in your bash script

- run it

Is there a bashism ?

Maybe an extra cpufreq kernel module must be loaded before 

/sys/devices/system/cpu/cpu*/cpufreq/

is available?

----------

## impact0r

In which line should I insert 'set-x'?

The /sys/devices/system/cpu/cpu*/cpufreq/ becomes available  as the acpi-cpufreq module is automatically loaded by /usr/lib/modprobe.d/phc-intel.conf

```
#  We want to use the phc-intel driver instead of the unmodified acpi-cpufreq driver

install acpi-cpufreq /sbin/modprobe phc-intel && /etc/rc.d/phc-intel set || { /sbin/modprobe --ignore-install acpi-cpufreq; }

#  The next two lines prevent the kernel from crashing:

remove acpi-cpufreq /sbin/modprobe -r cpufreq_stats && { /sbin/modprobe --ignore-remove -r acpi-cpufreq ; }

remove phc-intel /sbin/modprobe -r cpufreq_stats && { /sbin/modprobe --ignore-remove -r phc-intel ; }

[/quote]
```

----------

## khayyam

 *impact0r wrote:*   

> The reason for that is because before that I tried writing this from scratch, like so:

 

impact0r ... there is no reason for the above script to fail, so either the necessary conditions are not met, or passing argv[1] via the service file isn't acceptable to systemd ... or systemd fails for some other esoteric reason.

Some comments ... 

```
[ -z "$VIDS" -o -z "$1" ] && exit 1
```

This will be an "or" ... and as you probably want both variables to have a value, in such situations you should use "-z $var && -z $var2".

```
    for i in /sys/devices/system/cpu/cpu*/cpufreq/phc_vids; do

        if [ -f "$i" ]; then

            echo "$1" > "$i"

            [ "$?" -ne "0" ] && exit 1

        fi

    done

    true
```

"$i" will have a value, as  the 'for' will be 0 or {N} so the test isn't needed here. Also, the retval will be provided on the exit status, so success/failure is implicit:

```
% cat test.sh

#!/bin/sh

for i in a b c ; do 

    cat "$i" > /dev/null 2>&1

done

% ./test.sh ; echo $?

1
```

So, I made some small adjustments and the following works here (tested):

```
#!/bin/sh

. /etc/sysconfig/phc

[[ -z "$VIDS" ]] && exit 1

set_vids() { 

    for i in /sys/devices/system/cpu/cpu*/cpufreq/phc_vids ; do

        echo "$1" > "$i"

    done

}

case "$1" in

    set)

        set_vids "$VIDS"

        ;;

    reset)

        [ -f "/sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids" ] || exit 1

        set_vids "$(< /sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids)"

        ;;

    *)

        exit 1

        ;;

esac
```

best ... khay

----------

## impact0r

Thanks, khayyam. I tried that but it still won't start:

```
$ 0.restart phc

Job for phc.service failed. See 'systemctl status phc.service' and 'journalctl -n' for details.

$ systemctl status phc.service

phc.service - CPU undervolting

     Loaded: loaded (/etc/systemd/system/phc.service; enabled)

     Active: failed (Result: exit-code) since Wed, 2012-10-31 12:42:18 CET; 4s ago

    Process: 9546 ExecStart=/usr/sbin/phc.sh start (code=exited, status=1/FAILURE)

     CGroup: name=systemd:/system/phc.service

```

and journalctl -n doesn't show anything phc-related. [/quote]

----------

## khayyam

 *impact0r wrote:*   

> Thanks, khayyam. I tried that but it still won't start:

 

impact0r ... well, as I said I tested and it works here ... as you can see from the following (with some edits: subsituting phc_default_vids for stdout, /etc/sysconfig for /etc/conf.d, and VIDS="41 38 34 30 27 19").

```
# ./phc.sh ; echo $?

1

# ./phc.sh set

41 38 34 30 27 19

41 38 34 30 27 19

# ./phc.sh reset

41 38 34 30 27 19

41 38 34 30 27 19
```

So, as I said, either you can't pass "$1" to the script via systemd (in which case you would have seperate phc.set and phc.reset scripts and call the former via the service file) or systemd fails for some other esoteric reason ...

But anyhow, I shouldn't be providing support for this nonsense, systemd is broken by design, and its looking increasingly like I may have to leave linux for some other OS given that systemd's hostile takeover of init, and users acceptance of it, is becoming more and more of a reality.

best ... khay

----------

## impact0r

Hmm, it's interesting what you said about systemd. I did not encounter such criticism of it before.

Anyway, I was runing journalctl without sudo, which was affecting the output. With sudo I get this in the log:

```
Oct 27 18:21:29 panzor systemd[1]: Starting CPU undervolting...

Oct 27 18:21:29 panzor systemd[1832]: Failed at step EXEC spawning /usr/sbin/phc.sh: Permission denied

Oct 27 18:21:29 panzor systemd[1]: phc.service: main process exited, code=exited, status=203/EXEC

Oct 27 18:21:29 panzor systemd[1]: Failed to start CPU undervolting.

Oct 27 18:21:29 panzor systemd[1]: Unit phc.service entered failed state

Oct 27 18:25:00 panzor phc.sh[3590]: /usr/sbin/phc.sh: line 3: /etc/sysconfig/phc: No such file or directory

Oct 27 18:25:00 panzor systemd[1]: phc.service: main process exited, code=exited, status=1/FAILURE

Oct 27 18:25:00 panzor systemd[1]: Failed to start CPU undervolting.

Oct 27 18:25:00 panzor systemd[1]: Unit phc.service entered failed state
```

/etc/sysconfig/phc  - what should be in that file?

----------

## khayyam

 *impact0r wrote:*   

> Hmm, it's interesting what you said about systemd. I did not encounter such criticism of it before.

 

impact0r ... which doesn't surprise me, the general concensus being that "its faster, more configurable and future-proof" and thats about as much thought the question is generally given, and why should anyone care about anything else, after all, who wouldn't want that. 

 *impact0r wrote:*   

> /etc/sysconfig/phc  - what should be in that file?

 

Oh, and all the time I'd assumed you understood that by sourcing /etc/sysconfig/phc the script would be provided with the variable/values of $VIDS ... and didn't you say you "wrote this from scratch", and wouldn't that suggest that this was your intention?

best ... khay

----------

## impact0r

I would add superior service system. On the old system, I had no ways of automatic restart of phc-intel if it crashed. I had to have cron job which would start it every 5 minutes, just in case.

As for /etc/sysconfig/phc  - I know that, I just don't know in what format should the values be there.

Plus, there is this in journal:

 *Quote:*   

> Oct 28 19:32:24 panzor phc.sh[354]: /usr/sbin/phc.sh: line 26: stat_busy: command not found
> 
> Oct 28 19:32:24 panzor phc.sh[354]: /usr/sbin/phc.sh: line 29: stat_done: command not found
> 
> 

 

Except the phc.sh file has only 25 lines...

----------

## khayyam

 *impact0r wrote:*   

> I would add superior service system. On the old system, I had no ways of automatic restart of phc-intel if it crashed. I had to have cron job which would start it every 5 minutes, just in case.

 

impact0r ... firstly, its comments like this which do nothing but show supreme ignorance in regard to the purpose of init and what constitutes a "service". You are labouring under the illusion that somehow a "service" which does nothing but echo a value into /sys will "crash", and that should that "crash" happen the "service" should be restarted. The problem I have with this is not that you are mistaken, but that you are then inclined to have opinions as to the nature of a "superior service system", something which is out of the scope of your current understanding. Secondly, should some "service" (proper) "crash" then isn't the issue with the service and not the init system, and shouldn't the issue be addressed *there* rather than transpose the "problem" (so called) into one that concerns init? Thirdly, what is it that init should do other than bring the system up in a consistant and dependable way. If the intention, and result, is consistant and dependable, what purpose does init have subsequently ... meaning, why does it then need to hang arround as a meta-service? 

 *impact0r wrote:*   

> As for /etc/sysconfig/phc  - I know that, I just don't know in what format should the values be there.

 

Well, no, you don't "know that" ... there is no "format" other than providing a var=, and I even provided the var in my example above ... but anyhow, as you "know this" the following should be quite clear:

```
% cat test.sh

#!/bin/sh

VIDS="41 38 34 30 27 19"

echo $VIDS

% ./test.sh

41 38 34 30 27 19
```

 *impact0r wrote:*   

> Plus, there is this in journal:
> 
>  *Quote:*   Oct 28 19:32:24 panzor phc.sh[354]: /usr/sbin/phc.sh: line 26: stat_busy: command not found
> 
> Oct 28 19:32:24 panzor phc.sh[354]: /usr/sbin/phc.sh: line 29: stat_done: command not found
> ...

 

... and from this I can deduce that your not using the script I provided above but the script (from some sysvinit distribution) you provided in the first post.

best ... khay

----------

## impact0r

Yes, a service crashing is not a fault of init system, but the service itself. But if there is no way of fixing the service, in systemd it is possible to create a workaround without relying on corn or looped scripts.

As for phc, here's the thing. If I just run

sudo phc.sh set

voltages go down

But the service still won't start.

```
$ sudo systemctl status phc.service

phc.service - CPU undervolting

     Loaded: loaded (/etc/systemd/system/phc.service; enabled)

     Active: failed (Result: exit-code) since Wed, 2012-10-31 17:39:34 CET; 12s ago

    Process: 24591 ExecStart=/usr/sbin/phc.sh start (code=exited, status=1/FAILURE)

     CGroup: name=systemd:/system/phc.service

Oct 31 17:39:34 panzor systemd[1]: phc.service: main process exited, code=e...RE

Oct 31 17:39:34 panzor systemd[1]: Failed to start CPU undervolting.

Oct 31 17:39:34 panzor systemd[1]: Unit phc.service entered failed state

```

And the "line 26: stat_busy: command not found" thing was my oversight - the log was couple of days old, before I introduced your changes.

----------

## khayyam

 *impact0r wrote:*   

> Yes, a service crashing is not a fault of init system, but the service itself. But if there is no way of fixing the service, in systemd it is possible to create a workaround without relying on corn or looped scripts.

 

impact0r ... your not really addressing the points I was making. Anyhow, shouldn't you infact state "superior workaround" as such monitoring of services is not something which is entirely new, so the fact that systemd does this is beside the point.

 *impact0r wrote:*   

> But the service still won't start.

 

What can I say ... you have your "faster, more configurable and future-proof" init, and you can ask a superior systems admin.

best ... khay

----------

## impact0r

 *khayyam wrote:*   

> What can I say ... you have your "faster, more configurable and future-proof" init, and you can ask a superior systems admin.

 

You obviously are quite knowledgeable in the subject. but the fact itself that we are discussing a possible solution is in favour of systemd, because in init it would not be even possible to try and implement it.

However it may be, many thanks for your input.

----------

## khayyam

 *impact0r wrote:*   

> You obviously are quite knowledgeable in the subject. but the fact itself that we are discussing a possible solution is in favour of systemd, because in init it would not be even possible to try and implement it.

 

impact0r ... sorry, how is it not possible to impliment otherwise?

```
# equery belongs /etc/local.d

 * Searching for /etc/local.d ... 

sys-apps/openrc-0.11.2 (/etc/local.d)

# cat /etc/local.d/uksm.start

#!/bin/sh

ENABLED=1

if [ -d /sys/kernel/mm/uksm ] ; then

    if [ ${ENABLED} -eq 0 ] ; then

        echo 0 > /sys/kernel/mm/uksm/run

    fi

fi

# vim:ft=sh
```

best ... khay

----------

## Gusar

Wow, this thread is quite something...

First, impacto0r is proclaiming the awesomeness of systemd, but instead of using this awesomeness, he's using it as a... glorified script launcher. impact0r, at least you should learn how to use it properly. A small hint: systemd-tmpfiles

Second, he's trying to launch not just any script, but a) an Arch init script, and b) a Fedora or maybe OpenSuse init script. How can you not be surprised that they won't work on a distro that is not Arch/Fedora/OpenSuse.

It's funny, I don't even use systemd, and yet I know a lot more about it than impact0r does. How should I call thin mentality, when someone believes something and is making claims about it while being pretty much clueless about how things actually work?

@khayyam: systemd isn't an init system. It's an init system, a service supervisor, a session manager (replacing consolekit), a logging mechanism, and possibly a few things more. A few of these aren't in systemd itself (the actual daemon systemd) but are helper processes, but still, if one is booting with systemd, they'll be using all of them.

----------

## impact0r

You make a lot of assumptions there, bubba.

 *Gusar wrote:*   

> First, impacto0r is proclaiming the awesomeness of systemd, but instead of using this awesomeness

 

What a bull. Nowhere did I do it. I only stated my mildly favourable opinion based on a short article I read on it, and on the fact I can solve with it a phc problem I used to have for a long time PLUS it actually resumes from TOI hinbernation 7 times quicker than previous init system (an issue that no one knew how to solve).

 *Gusar wrote:*   

>  at least you should learn how to use it properly.

 

Which is what I am doing in this thread.

 *Gusar wrote:*   

>  he's trying to launch not just any script, but a) an Arch init script, and b) a Fedora or maybe OpenSuse init script. How can you not be surprised that they won't work on a distro that is not Arch/Fedora/OpenSuse.

 

You see? Assumptions. I am on Arch. Bazinga!

And why am I here?  Because sometimes when Arch forums fail, Gentoo forums often don't.

 *Gusar wrote:*   

> It's funny, I don't even use systemd, and yet I know a lot more about it than he does. 

 

I hardly find that funny. Guess what - I am not a system admin, just a workstation user. In terms of specialist linux knowledge, I rely on opinions of others. I have no ambitions of being a know-it-all in linux as it's just a tool to use my laptop's potential to maximum, not a passion or a bread winning skill.

 *Gusar wrote:*   

> How should I call thin mentality, when someone believes something and is making claims about it while being pretty much clueless about how things actually work?

 

I know it's unrelated, but you just gave the definition of a theist. We call such people theists.

----------

## Gusar

 *impact0r wrote:*   

> Nowhere did I do it. I only stated my mildly favourable opinion based on a short article I read on it

 

Saying "it's faster, more configurable and future-proof" is a proclamation, not a "mildly favorable opinion".

 *impact0r wrote:*   

>  *Gusar wrote:*    at least you should learn how to use it properly. 
> 
> Which is what I am doing in this thread.

 

Not really. Or maybe so, but the way you're going about it is quite wrong. In this thread you're trying to shoehorn init scripts from various distros into systemd. Which goes against the, how should I say it, nature of how systemd functions.

The right way to go about this would be for you to explain what problem you're trying to solve, instead of leading everyone on a wild goose chase with various scripts. That way the correct answer to the problem - tmpfiles - would've come up a lot sooner. Well, that's assuming people here are familiar with systemd. Which, considering Gentoo's anti-systemd stance, is not a given. 

 *impact0r wrote:*   

> You see? Assumptions. I am on Arch. Bazinga!

 

On a Gentoo forum, people made the assumption you're using Gentoo. OMG, what madness is this?? Err, yeah. *Of course* I'll make the assumption you're using Gentoo. Holding this against me is downright silly.

 *impact0r wrote:*   

> And why am I here?  Because sometimes when Arch forums fail, Gentoo forums often don't.

 

Let's say that makes a bit of sense, don't you think that's the kind of stuff you should've mentioned? khayyam quickly pointed out that there's no /etc/rc.d/functions in Gentoo and as such the script can't work. A perfectly normal and correct reaction, considering we're here at the Gentoo forums. A whole bunch of posts would've been unnecessary if you'd given proper information.

Also, considering Arch is now a systemd distro and Gentoo is not, you'll much sooner find people with systemd expertise there than you will here.

 *impact0r wrote:*   

>  *Gusar wrote:*   It's funny, I don't even use systemd, and yet I know a lot more about it than he does.  
> 
> I hardly find that funny. Guess what - I am not a system admin, just a workstation user. In terms of specialist linux knowledge, I rely on opinions of others.

 

It's funny because of the proclamations you made. You came over as behaving somewhere along the line of this: "I have no idea about systemd, how it works and such, but it's faster, more configurable and future-proof!!". You can't be surprised that such an attitude resulted in unfavorable responses.

 *impact0r wrote:*   

>  *Gusar wrote:*   How should I call thin mentality, when someone believes something and is making claims about it while being pretty much clueless about how things actually work? 
> 
> I know it's unrelated, but you just gave the definition of a theist. We call such people theists.

 

Ah, thanks for that. Well, that's exactly the behavior you exhibited regarding init systems in this thread.

----------

## impact0r

I guess we will have to agree to disagree on the nature of my posts.

Just few clarifications:

"there's no /etc/rc.d/functions in Gentoo"

Neither there is on Arch with systemd

"A whole bunch of posts would've been unnecessary if you'd given proper information."

You'd think that. But in this case it wouldn't have.

"considering Arch is now a systemd distro and Gentoo is not, you'll much sooner find people with systemd expertise there than you will here."

You'd think that. But it doesn't always work like that.

"Ah, thanks for that. Well, that's exactly the behavior you exhibited regarding init systems in this thread."

No, sorry. But we've covered that already.

Oh, look. the discussion turned off-topic from the initial off-topic.

----------

## khayyam

 *impact0r wrote:*   

> I am on Arch. Bazinga! And why am I here?  Because sometimes when Arch forums fail, Gentoo forums often don't.

 

impact0r ... had you mentioned your host system was Arch Linux I would have immediatly directed you to the Arch Linux Forums. Why? ... becuase thats where it belongs, this is a "Gentoo" forum, not a general support forum. I can't believe you wasted my time with the whole thing ...

Also, rather than play dodge the bullet with Gustar you might take some of what is said on advisement ... and learn from it. Gustar is quite right, you have shown a high degree of ignorance, not only of systemd but in general. You have also claimed to have "written from scratch" a script which you clearly didn't understand. Then there is the more general lack of being able to back you claims, which as we've seen are outside of your sphere of understanding  ... and now after all of the above your an Arch Linux user, and can't get your problem solved elsewhere so you thought you'd ask here ... well, suprise.

farewell ... khay

----------

## DaggyStyle

 *impact0r wrote:*   

> 
> 
> You see? Assumptions. I am on Arch. Bazinga!
> 
> And why am I here?  Because sometimes when Arch forums fail, Gentoo forums often don't.
> ...

 

this comment doesn't help you at all, in fact, I don't know how can you expect to get help with that attitude. Gentoo is not helpdesk for advanced Arch users.

in fact with the move made by Arch devs to systemd as init system daemon makes Arch more of a sub version of fedora imho, so the best course of action is to either go and ask the Arch devs (they should help you as they decided on the replacement of current init system with systemd) or go to the origin mother distro's forum (e.g. fedora) and ask there, the chances you'll get help here, now (after that comment) and on this matter is virtually zero.

----------

