Bug 780259

Actually removing -f does not make the service start.
After removing -f and executing systemctl start atd.service the output of
systemctl status atd.service is:

atd.service - Execution Queue Daemon
          Loaded: loaded (/lib/systemd/system/atd.service; disabled)
          Active: inactive (dead) since Thu, 13 Sep 2012 15:47:34 -0400; 2s ago
         Process: 2816 ExecStart=/usr/sbin/atd (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/atd.service

or:

atd.service - Execution Queue Daemon
          Loaded: loaded (/lib/systemd/system/atd.service; disabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/atd.service

Sep 13 15:40:22 linux.site atd[689]: pam_apparmor(atd:session): Unknown error occurred changi...tted

loocking in /var/log/messages there is:

Sep 13 15:40:22 linux atd[689]: pam_apparmor(atd:session): Unknown error occurred changing to root hat: Operation not permitted

So it appears there is a permission problem somewhere that doesn't allow atd to start properly.

So far the only way I have found to start the service is:
cd /etc/init.d ; ./atd start

The apparmor messages are somehow related, but most probably aren't the cause of the problem.

The problem is that atd forks into background. I got it working with the following in the service file:

[Service]
ExecStart=/usr/sbin/atd
Type=forking

Long story short - I created request id 134202 ;-)

This is an autogenerated message for OBS integration:
This bug (780259) was mentioned in
https://build.opensuse.org/request/show/134660 Factory / at

Hi
A user also came across this in the forums for 12.2.
http://forums.opensuse.org/showthread.php?t=478387

The fix you have doesn't take into account the atd sysconfig settings? Or should this be dropped?

[Unit]
Description=Execution Queue Daemon
After=syslog.target
  
[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/atd
ExecStart=/usr/sbin/atd -b ${ATD_BATCH_INTERVAL} -l ${ATD_LOADAVG}
 
[Install]
WantedBy=multi-user.target

This also means modifying the atd sysconfig file to include;

ATD_BATCH_INTERVAL = 60
ATD_LOADAVG = 0.8

These are the compiled defaults, but at least offers the option to configure.

comment 4 looks like a valid issue, but is beyond my knownledge of the atd internals.

Cristian, please take over ;-)  (and also prepare an update for 12.2 please)

Looks like a dupe of bug 772111?

*** Bug 772111 has been marked as a duplicate of this bug. ***

I tried first the same idea mentioned in "Comment 2" by removing the "-f" in atd.service and reloading systemd. I'm running after 90s in a timeout error like

/var/log/messages
"""
systemd[1]: atd.service stopping timed out. Killing.
systemd[1]: Unit atd.service entered failed state.
"""

systemd:
"""
# systemctl start atd.service && systemctl status atd.service
atd.service - Execution Queue Daemon
          Loaded: loaded (/lib/systemd/system/atd.service; enabled)
          Active: deactivating (stop-sigterm) since Wed, 07 Nov 2012 13:49:55 +0100; 1s ago
         Process: 27868 ExecStart=/usr/sbin/atd (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/atd.service
                  └ 27869 /usr/sbin/atd
### after 90s:
# systemctl status atd.service
atd.service - Execution Queue Daemon
          Loaded: loaded (/lib/systemd/system/atd.service; enabled)
          Active: failed (Result: timeout) since Wed, 07 Nov 2012 13:51:25 +0100; 233ms ago
         Process: 27868 ExecStart=/usr/sbin/atd (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/atd.service

"""

Working without timeout but not surviving a reboot ist "Comment 1":
# cd /etc/init.d ; ./atd start

or as well on command line:
# /usr/sbin/atd -d


Using "Comment 4"'s approach in defining explicitly /etc/sysconfig/atd variables and altering /lib/systemd/system/atd.service is working without timeouts

"""
# systemctl status atd.service 
atd.service - Execution Queue Daemon
          Loaded: loaded (/lib/systemd/system/atd.service; enabled)
          Active: active (running) since Wed, 07 Nov 2012 13:57:36 +0100; 1min 51s ago
         Process: 28822 ExecStart=/usr/sbin/atd -b ${ATD_BATCH_INTERVAL} -l ${ATD_LOADAVG} (code=exited, status=0/SUCCESS)
        Main PID: 28823 (atd)
          CGroup: name=systemd:/system/atd.service
                  └ 28823 /usr/sbin/atd -b 60 -l 0.8
"""


Another working test by ignoring the /etc/sysconfig/atd configuration is possible by removing the "-f" and adding "Type=forking" in the original /lib/systemd/system/atd.service for avoiding the 90s timeout.
"""
# systemctl status atd.service 
atd.service - Execution Queue Daemon
          Loaded: loaded (/lib/systemd/system/atd.service; enabled)
          Active: active (running) since Wed, 07 Nov 2012 14:05:32 +0100; 3min 5s ago
         Process: 29788 ExecStart=/usr/sbin/atd (code=exited, status=0/SUCCESS)
        Main PID: 29789 (atd)
          CGroup: name=systemd:/system/atd.service
                  └ 29789 /usr/sbin/atd
"""


Either way with or without reading /etc/sysconfig/atd the last tests are working. I cannot decide which is best if default values are not easily set by systemd units.

(In reply to comment #4)
> A user also came across this in the forums for 12.2.
> http://forums.opensuse.org/showthread.php?t=478387
 
Just did my first migration to 12.2 and was also hit by this bug. The workaround described in the forum solved the issue for me. 

This issue is still around ... please fix.

Frederic, is there a way to use a default value if a variable is empty in the ExecStart line of a service file?

Details: atd has some config variables in /etc/sysconfig, which are empty by default. Unfortunately startup fails if the variables are empty, so we have "failure by default" :-(

I'll describe two possible solutions in pseudocode - please tell me if/how this can be done in a service file.

if ($ATD_BATCH_INTERVAL != "") {
    ExecStart=/usr/sbin/atd -b ${ATD_BATCH_INTERVAL}
} else {
    ExecStart=/usr/sbin/atd    # without -b
}

- or -

if ($ATD_BATCH_INTERVAL != "") {
    $ATD_BATCH_INTERVAL = 60
}
ExecStart=/usr/sbin/atd -b ${ATD_BATCH_INTERVAL}

Can one of those be done in a service file?

(in practise, there are two variables, but that's a technical detail ;-)

(In reply to comment #10)
> if ($ATD_BATCH_INTERVAL != "") {
>     $ATD_BATCH_INTERVAL = 60
> }
> ExecStart=/usr/sbin/atd -b ${ATD_BATCH_INTERVAL}
> 
> Can one of those be done in a service file?
> 

Not really. You can do

Environment=ATD_BATCH_INTERVAL=60
EnvornmentFile=/etc/sysconfig/atd

but this will break if config file contains ATD_BATCH_INTERVAL="" as it does currently. So the only way to do it is

ExecStart=/bin/sh -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd -b $${ATD_BATCH_INTERVAL:-60} -l $${ATD_LOADAVG:-0.8}'

($$ to please systemd environment replacement code).

(In reply to comment #11)
> ExecStart=/bin/sh -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec
> /usr/sbin/atd -b $${ATD_BATCH_INTERVAL:-60} -l $${ATD_LOADAVG:-0.8}'

Thanks, that works (and looks ugly ;-) 

However, I don't like to hardcode the defaults in the service file because this will cause funny effects[tm] if atd ever changes its defaults.
Fortunately bash also offers ${foo:+whatever} so that it's possible to set the parameter only if a value was set in the sysconfig file.

I also changed /bin/sh to /bin/bash because the variable magic looks bash-specific to me.

That all said - here's the final line:

ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'

I just commited the fixed atd.service:
- request #142950 to Base:System
- request #142949 for the 12.2 update

This is an autogenerated message for OBS integration:
This bug (780259) was mentioned in
https://build.opensuse.org/request/show/142949 Maintenance /

This is an autogenerated message for OBS integration:
This bug (780259) was mentioned in
https://build.opensuse.org/request/show/142986 Factory / at

openSUSE-RU-2012:1607-1: An update that has one recommended fix can now be installed.

Category: recommended (low)
Bug References: 780259
CVE References: 
Sources used:
openSUSE 12.2 (src):    at-3.1.8-1110.4.1

Brilliant! It works. Thanks a lot!

Before:
atd.service - Execution Queue Daemon
	  Loaded: loaded (/lib/systemd/system/atd.service; enabled)
	  Active: active (running) since Thu, 06 Dec 2012 11:58:29 +0100; 1min 44s ago
	Main PID: 11415 (atd)
	  CGroup: name=systemd:/system/atd.service
		  └ 11415 /usr/sbin/atd -b 60 -l 0.8


After Update to at-3.1.8-1110.4.1:
atd.service - Execution Queue Daemon
	  Loaded: loaded (/lib/systemd/system/atd.service; enabled)
	  Active: active (running) since Thu, 06 Dec 2012 13:33:45 +0100; 6s ago
	 Process: 21823 ExecStart=/bin/bash -c [ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG} (code=exited, status=0/SUCCESS)
	Main PID: 21824 (atd)
	  CGroup: name=systemd:/system/atd.service
		  └ 21824 /usr/sbin/atd -b 60 -l 0.8

Thanks for testing!

The update for 12.2 was released, therefore I'm closing this bug.

For the records: In the meantime, Factory got a different fix (a patch for atd) for reading the sysconfig file, so the service file looks different than in the 12.2 update.

Instead of iterating over the map with HXmap_traverse, you can just inspect the keys directly, just like everybody would in a scripting language ($sysconfigmap{ATD_BATCH_INTERVAL}) - it's a lot cheaper.

char *v;
v = HXmap_get(sysconfigmap, "ATD_BATCH_INTERVAL");
if (v != NULL && strlen(v) > 0) {
    batch_interval = strtol(v, NULL, 0);
    syslog(LOG_INFO, "sysconfig requested...");
}
v = HXmap_get(sysconfigmap, "ATD_LOADAVG");
//same procedure.

(In reply to comment #18)
> Instead of iterating over the map with HXmap_traverse, you can just inspect the
> keys directly, just like everybody would in a scripting language
> ($sysconfigmap{ATD_BATCH_INTERVAL}) - it's a lot cheaper.

Jan, you don't want me to touch C any code ;-)

Feel free to send a SR - I'm sure the atd maintainer (which I'm not) will happily accept it.

The SR is 147894 - can you test?

This is an autogenerated message for OBS integration:
This bug (780259) was mentioned in
https://build.opensuse.org/request/show/147899 Factory / at

Jan, you added a bug to at-parse-suse-sysconfig.patch ;-)
Fortunately it's only a comment, but I still don't want to take credits for something I didn't do. The initial patch was created by Frederic Crozat, not by me.

Dammit, that's why patch creators should always follow http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Type_2:_Complete_Information_provided_in_patch .

This is an autogenerated message for OBS integration:
This bug (780259) was mentioned in
https://build.opensuse.org/request/show/147979 Factory / at

*argh* I found a bug in /dev/brain :-( and gave you a wrong name - sorry for that!

To avoid another error, I'll just paste the at changelog:

* Mi Nov 28 2012 crrodriguez@opensuse.org
- When sysconfig variables are empty, do not set stuff to zero
  just use the defaults.

* Mi Nov 28 2012 crrodriguez@opensuse.org
- Fix systemd unit and sysconfig parsing the right way.

* Mo Nov 26 2012 opensuse@cboltz.de
- use /etc/sysconfig/atd variables in atd.service (bnc#780259#c4)


(fortunately ;-) your SR was auto-declined because it has no .changes entry)

Once you figure out who procured the patch, you can use that utility they call "osc" and edit the line in the patch.

OK, I'll do that ;-)

fixed with SR 151475

This is an autogenerated message for OBS integration:
This bug (780259) was mentioned in
https://build.opensuse.org/request/show/151477 Factory / at

Where are the maintenance request for 12.2 & 12.3

Still in 13.1 : atd.service doesn't pick sysconfig vars.

(In reply to comment #30)
> Where are the maintenance request for 12.2 & 12.3

12.2 was fixed with
https://build.opensuse.org/project/show/openSUSE:Maintenance:1130

12.3 should have working code from the beginning - at least https://build.opensuse.org/request/show/142986 was accepted a year ago.

> Still in 13.1 : atd.service doesn't pick sysconfig vars.

Then the patch must be broken or was lost :-(

Anyway - I'm not the at maintainer, I just helped out a bit. I'll reassign to the current maintainer...

This bug (In reply to comment #30)
> Where are the maintenance request for 12.2 & 12.3
> 
> Still in 13.1 : atd.service doesn't pick sysconfig vars.

are you sure ? this bug was fixed a long while ago... patch is at-parse-suse-sysconfig.patch, I just tested it, by setting ATD_BATCH_INTERVAL and ATD_LOADAVG 

log says..


Nov 16 16:38:44 xps15z atd[4067]: sysconfig requested batch_interval to be set to 2
Nov 16 16:38:44 xps15z atd[4067]: sysconfig requested load_avg to be set to 2.000000

What is your exact problem ? of course atd.service does not pick the sysconfig values.. /etc/sysconfig/atd is parsed in the application itself.

Okay then we have information misleading comprehension.

Previously in /etc/init.d/atd during the start 
        startproc $ATD_BIN $ATD_ARGS
You finished with a process which clearly indicate how and what option run.
ps auxw ...

Which is perfectly aligned with information contained in man atd

Now running the systemd service you finish only with 
/usr/sbin/atd -f
So yes the optional values are there, visible in the status at.service. But not on the proc line !

My question was wouldn't be better to use something like
EnvironmentFile=/etc/sysconfig/atd
ExecStart=/usr/sbin/atd -f $OPTS

Like the solution fedora has adopted, okay requiring to rewrite the sysconfig atd file with a one line but would have the advantage to be simplier
Then anybody looking at the daemon ps would seen that the options are there.

Patching code daemon to make them behaving differently than what is expected is really really strange.

(In reply to comment #33)
> Okay then we have information misleading comprehension.
> 
> Previously in /etc/init.d/atd during the start 

> My question was wouldn't be better to use something like
> EnvironmentFile=/etc/sysconfig/atd
> ExecStart=/usr/sbin/atd -f $OPTS


This is because we do not have $OPTS , but have separate variables for each option, doing what you said ends in the ugly mess described in comment 12, which other than ugly, is slow as it requires spawning a shell.

 The current approach is correct and works, there is nothing to be fixed.

Without using the #12 mess, You miss two points which I believe are essential.

First you introduce a bug, that none other distribution has with atd
You can't anymore see parameters in ps auxw 

We have a patch that is not upstream. Not that good about our policy.

We reinvent our own soap, in place of trying to collaborate with our neighbors & friends distribution.

The current approach just work, with defect. That's all.