The sample config file says that it looks for /etc/polipo/config by default, you shouldn't need to specify it on the command line.

Confirmed, from the install file:
If you want to use a configuration file, you should put it in one of
the locations `/etc/polipo/config' or `~/.polipo'; you can also use
the `-c' flag to put it in a non-standard location. See the file
`config.sample' for an example.

So it *should* be reading it. If it's not, there's probably something wrong with your config file or there's an upstream bug.

Thank you for your fast reply. I don't think you understand the issue completely. Let try to explain it differently: The polipo package installs /etc/polipo/config by default, so there is not need to create that file. I am also aware of the flags that can be passed to polipo to alter it's behaviour. The issue is that the polipo package supplies it's own systemd file, which doesn't read the config file by default. Have a look at the PKGBUILD and the polipo.service file here: https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/polipo

The polipo.service file clearly has no reference to any config file.

I do understand what you're saying, but you're not understanding me. From everything I can find, you only need to use the -c option to read from a config file that is NOT /etc/polipo/config. Think about pacman, you can use the --config option to specify a different config file, but if you don't, it will read /etc/pacman.conf by default; this seems to be the same thing. It SHOULD be reading /etc/polipo/config by default.

And no, Arch does not install /etc/polipo/config by default. Maybe this is the whole problem, did you rename the sample file?

I have no problems running or configuring Polipo. My point is that the current polipo package can become better by becoming simpler to configure. I agree with you that polipo should read /etc/polipo/config by default. But it isn't doing that. That's exactly the point.

The fix to this is to have the polipo package install itself in a less complicated way, more "The Arch Way", like this:
- Make the polipo service point to the polipo config by default: ExecStart=/usr/bin/polipo -c /etc/polipo/config
- Have the polipo package install the example config to /etc/polipo/config instead of /etc/polipo/config.example

If users then wanted to alter the behaviour of polipo, they would only have to edit /etc/polipo/config.

That's alot simpler than the current setup, which requires doing this:
- rename the example config from /etc/polipo/config.example to /etc/polipo/config
- copy the polipo service file to to /etc/systemd/system/polipo.service
- edit /etc/systemd/system/polipo.service to make it use the /etc/polipo/config

And as I said, if it's not reading that file, talk to upstream, it sounds like a bug there.

It is a mistake to close the ticket. The issue is not upstream. It is in the Arch package. If you'll just have a look at the Arch package, then you'll see that Arch supplies the systemd file:

https://projects.archlinux.org/svntogit/community.git/tree/trunk/polipo.service?h=packages/polipo

Have you looked at this file and do you understand what is happening in that file? This file is supplied by the Arch package, not by upstream.

And once again, the default behavior is to read /etc/polipo/config, so adding -c to the service file does nothing but reduce functionality. If someone wants to use it in a systemd --user session and override the configs with a ~/.polipo file, they no longer could.
Notice that this:
> That's alot simpler than the current setup, which requires doing this:
> - rename the example config from /etc/polipo/config.example to /etc/polipo/config
> - copy the polipo service file to to /etc/systemd/system/polipo.service
> - edit /etc/systemd/system/polipo.service to make it use the /etc/polipo/config
is wrong. All you have to do with the current setup is the first step, and that is how upstream recommends doing things.

I now know what the cause of the misunderstanding is. Doug's last comment gave me an aha-moment. When starting up, polipo does indeed load the config file /etc/polipo/config, by default as Doug states. In my setup though, I changed the logFile parameter in the /etc/polipo/config file to /some_remote_fs/logs/polipo.log, but Polipo was not using that parameter from the config file. It was still using /var/log/polipo.log. So I added the -c /etc/polipo/config parameter to the service file, but also removed the logFile entry while at it. And voila, it worked. This created the illusion that polipo would only read the config file if explicitly told so with -c. While in fact, that it was reading it all along, but it was ignoring only the logFile parameter in the config file because it was already defined as a command line parameter in the service file.

Having said that: Having the logfile 'hard coded' into the service file still necessitates modifying the service file to be able to define an alternative log location. It still might be a good idea to have the logFile parameter defined in the config file and have it installed to /etc/polipo/config by default, which would also facilitate systemd user sessions as Doug points out.

In any case, I'm glad the situation is now cleared up.

Believe me, I'm glad things are cleared up as well.

I agree that having the log file defined on the command line isn't optimal, but neither is having a /etc/polipo/config file by default when upstream recommends against it. If it's one or the other, the latter is probably the better choice. That said, it appears that it will log to /var/log/polipo by default when run with "daemonise=true", instead of the provided /var/log/polipo.log. Would it be easier and more correct to just ditch the command line option and use the default unless the user overrides it with a config file?

As the British would say: Sounds like "the way forward".

I think it would be better to leave this as the default or set it in the configuration file if the default is not sane, but it should be reported as a fresh issue.