# Bizarre init.d script start problem, anyone got any ideas?

## digitalamish

OK, I recently did an emerge -e world on my system after upgrading to a newer version of gcc.  Before that my courier-authlib start script (in init.d) worked fine.  Now I get the following error:

 *Quote:*   

> 
> 
> mailserv authlib # /etc/init.d/courier-authlib start
> 
>  * Starting courier-authlib: authdaemond ...
> ...

 

OK, now for the bizarre part.  I echoed the command in the start script out and it looks like this:

 *Quote:*   

> start-stop-daemon --quiet --start --pidfile /var/run/authdaemon.pid --exec /usr/bin/env -- - /usr/sbin/courierlogger -pid=/var/run/authdaemon.pid -start /usr/lib/courier/courier-authlib/authdaemond

 

If I cut and paste that in, it works fine, but the script fails.

I haven't changed anything, and I even unmerged courier-authlib, removed the init.d script and authdaemond, and re-emerged.  Does anyone have any idea why I would be able to run the command manually, but the script fails?  How is pidof used here?

----------

## DavidMCS

Well you're not alone digital. I had to shutdown a production mail server last night for a minor hardware upgrade. When I started the server up again I experienced the same issue with both courier-authlib and courier-pop3d exactly as you described. 

I wasted a couple hours trying to troubleshoot the courier init.d script errors to no avail. In desperation I also emulated the start() section of both the aforementioned init.d scripts on the command line to get the mail server working again before the sun came up and the phone started ringing off the wall with agitated users.

Unfortunately I can't do anymore on the server until late tonight for obvious reasons, that and I'm in desperate need of some sleep.  :Shocked: 

-- 

David-

----------

## UberLord

There's a bug in the init script. You're both using ~ARCH baselayout on servers - and one of them is a production one? hehehe - brave or foolish

Anyway, the fix should be to remove the single '-' after the '--' so it reads

```
/usr/bin/env -- $logger
```

https://bugs.gentoo.org/show_bug.cgi?id=98745

For fixed courier scripts

----------

## digitalamish

 *UberLord wrote:*   

> There's a bug in the init script. You're both using ~ARCH baselayout on servers - and one of them is a production one? hehehe - brave or foolish

 

Both, but it's my home machine, so the only angry user is me.   :Smile: 

 *Quote:*   

> 
> 
> Anyway, the fix should be to remove the single '-' after the '--' so it reads
> 
> ```
> ...

 

Nope, that didn't do it for me (same error).  I looked at that bug report, and the script is attached looks wrong (how do the variables get initialized?).  I tried copying it over, but it didn't work.

My kludgy fix was to refer back to the /usr/sbin/authdaemond instead of using the start-stop-daemond call in the active script.  Basically I removed the entire command and replaced it with:

```
/usr/sbin/authdaemond start
```

and the 'stop' command in the stop section.  It's not perfect, but it got me back up and running.

----------

## tecknojunky

you can either ln -s /sbin/pidof /bin/ or you can modify line 191 of /lib/rcscripts/sh/rc-daemon.sh and change /bin/pidof to /sbin/pidof

But I think there are much more bugs in this baselayout, and one wonders who's the goofie who let this go in the tree not hard masked  :Sad: 

I'm telling you, one day, because the Gentoo process does not take seriously quality insurance, they'll end up with a law suit on their heads.  :Razz: 

----------

## UberLord

 *tecknojunky wrote:*   

> you can either ln -s /sbin/pidof /bin/ or you can modify line 191 of /lib/rcscripts/sh/rc-daemon.sh and change /bin/pidof to /sbin/pidof

 

They are the same file .......

md5sum /sbin/pidof

md5sum /bin/pidof

 *Quote:*   

> But I think there are much more bugs in this baselayout, and one wonders who's the goofie who let this go in the tree not hard masked 

 

It's package.masked the last I checked.  :Shocked: 

 *Quote:*   

> I'm telling you, one day, because the Gentoo process does not take seriously quality insurance, they'll end up with a law suit on their heads. 

 

So send patches!  :Rolling Eyes: 

----------

## tecknojunky

 *UberLord wrote:*   

>  *tecknojunky wrote:*   you can either ln -s /sbin/pidof /bin/ or you can modify line 191 of /lib/rcscripts/sh/rc-daemon.sh and change /bin/pidof to /sbin/pidof 
> 
> They are the same file .......
> 
> md5sum /sbin/pidof
> ...

  :Shocked:  Me I did not have any pidof in bin.  Running the start part directly from the shell showed me error in sc_daemon at line 119: pidof: file or directory does not exist (approximate message).  Doing which pidof showed me that it was located in /sbin, changed the script and it worked.

Maybe your error is different, so I suggest you run the start-stop-daemon part of whatever the rc script and see what it spit.

 *UberLord wrote:*   

>  *tecknojunky wrote:*   But I think there are much more bugs in this baselayout, and one wonders who's the goofie who let this go in the tree not hard masked  
> 
> It's package.masked the last I checked.  

 Hum, I don't have anything in my /etc/portage/package.unmask  :Confused: 

 *UberLord wrote:*   

>  *tecknojunky wrote:*   I'm telling you, one day, because the Gentoo process does not take seriously quality insurance, they'll end up with a law suit on their heads.  
> 
> So send patches! 

 ... or a summons  :Very Happy: 

----------

## UberLord

 *tecknojunky wrote:*   

>  *UberLord wrote:*    *tecknojunky wrote:*   you can either ln -s /sbin/pidof /bin/ or you can modify line 191 of /lib/rcscripts/sh/rc-daemon.sh and change /bin/pidof to /sbin/pidof 
> 
> They are the same file .......
> 
> md5sum /sbin/pidof
> ...

 

I'll check which it should be tomorrow

 *UberLord wrote:*   

>  *tecknojunky wrote:*   But I think there are much more bugs in this baselayout, and one wonders who's the goofie who let this go in the tree not hard masked  
> 
> It's package.masked the last I checked.  

 Hum, I don't have anything in my /etc/portage/package.unmask  :Confused:  [/quote]

/usr/portage/profiles/package.mask

IE you have to unmask it to install it via /etc/portage/package.unmask

unless someone else umasked it there ....

 *UberLord wrote:*   

>  *tecknojunky wrote:*   I'm telling you, one day, because the Gentoo process does not take seriously quality insurance, they'll end up with a law suit on their heads.  
> 
> So send patches! 

 ... or a summons  :Very Happy: [/quote]

I'll call the balifs then :p

----------

## tecknojunky

 *UberLord wrote:*   

>  *tecknojunky wrote:*    *UberLord wrote:*    *tecknojunky wrote:*   But I think there are much more bugs in this baselayout, and one wonders who's the goofie who let this go in the tree not hardmasked  
> 
> It's package.masked the last I checked.   Hum, I don't have anything in my /etc/portage/package.unmask   
> 
> /usr/portage/profiles/package.mask
> ...

 

Read again carefuly please...

----------

## UberLord

 *tecknojunky wrote:*   

> Me I did not have any pidof in bin.

 

Then re emerge sysvinit

 *UberLord wrote:*   

>  *tecknojunky wrote:*   But I think there are much more bugs in this baselayout, and one wonders who's the goofie who let this go in the tree not hard masked  
> 
> It's package.masked the last I checked.  

 Hum, I don't have anything in my /etc/portage/package.unmask  :Confused:  [/quote]

Ok - it was package.masked and someone removed the mask

----------

## tecknojunky

 *UberLord wrote:*   

>  *tecknojunky wrote:*   Me I did not have any pidof in bin. 
> 
> Then re emerge sysvinit

 

Right.  pidof now is symlynked in /bin.  Maybe sys-apps/baselayout-1.12.0_pre5 should have a dependancy on sys-apps/sysvinit-2.86.

 *UberLord wrote:*   

>  *tecknojunky wrote:*    *UberLord wrote:*    *tecknojunky wrote:*   But I think there are much more bugs in this baselayout, and one wonders who's the goofie who let this go in the tree not hard masked  
> 
> It's package.masked the last I checked.   Hum, I don't have anything in my /etc/portage/package.unmask   
> 
> Ok - it was package.masked and someone removed the mask

 

I do have baselayout in packages.keywords though.  I'm not to happy with the fact of having a _pre version into my system and since I'm sure a lot of people also have baselayout ~arch keyworkded, that's why I think it should have been hardmasked.  So, I did their job and added =sys-apps/baselayout_1.12.0_pre* to my own packages.mask.  :Rolling Eyes:  _pre is gone and I hope I'll still be warned when 1.12.0 is out of detox.

----------

## UberLord

 *tecknojunky wrote:*   

> 
> 
> Right.  pidof now is symlynked in /bin.  Maybe sys-apps/baselayout-1.12.0_pre5 should have a dependancy on sys-apps/sysvinit-2.86.

 

/bin/pidof has always been provided by sysvinit and is baselayout depends on sysvinit-2.84

 *Quote:*   

> I do have baselayout in packages.keywords though.  I'm not to happy with the fact of having a _pre version into my system and since I'm sure a lot of people also have baselayout ~arch keyworkded, that's why I think it should have been hardmasked.  So, I did their job and added =sys-apps/baselayout_1.12.0_pre* to my own packages.mask.  _pre is gone and I hope I'll still be warned when 1.12.0 is out of detox.

 

People who have baselayout in ~ARCH and expect it to work 100% are idiots. They should be using stable baselayout.

Of course, that applies to any package, not just baselayout.

It's also interesting to note that many init scripts broke with baselayout-1.12.0 because they were abusing start-stop-daemon calls. This is not the fault of baselayout that we're now more strict, it's the fault of the person who wrote the init script for not reading the start-stop-daemon man page.

It's also interesting to note that I've been using baselayout-1.12.0_pre on all my boxes (including production boxes at work) without issue. This is because I have faith that it works 100% with the software I use and is stable. However, this may not be the case with other software such as courier-imap. Which is why it's in ~ARCH so we can fix these bugs before baselayout goes stable.

----------

## tecknojunky

 *UberLord wrote:*   

>  *tecknojunky wrote:*   
> 
> Right.  pidof now is symlynked in /bin.  Maybe sys-apps/baselayout-1.12.0_pre5 should have a dependancy on sys-apps/sysvinit-2.86. 
> 
> /bin/pidof has always been provided by sysvinit and is baselayout depends on sysvinit-2.84

 Then I can't explain it.  I never delete anything whatsoever in bin.

 *UberLord wrote:*   

> People who have baselayout in ~ARCH and expect it to work 100% are idiots. They should be using stable baselayout.
> 
> Of course, that applies to any package, not just baselayout.

 I updated to ~arch baselayout because I had to, but I have forgotten why, which feature I needed.

I have commented out all the baselayout and deps of it in packages.keywords, as it seems they all got stable but I was not aware of that.  So I guess the very first package version of sysinit did not create the /bin symlink because I did not have it.

----------

