Thanks. That is the thing I am also wondering about. I will see if the solution there is useful. On Wed, Jan 14, 2015 at 2:15 PM, Malcolm wrote:

On Wed 14 Jan 2015 02:01:43 PM CST, Roger Oberholtzer wrote:

...

I am curious if there are any plans for a systemd method to start gpsd. I see that if the GPS is a USB device, then it is started via udev. But what if it is an RS-232 device? I think that then you must make your own startup script. I have no problem doing so. But is seems a bit odd to only start it automatically for a certain class of devices and do nothing at all for another class.

Hi A forum user with a serial gpsd device... http://forums.opensuse.org/showthread.php?t=503764

-- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default up 11 days 18:01, 4 users, load average: 0.32, 0.27, 0.27 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Agreed that the user must know if a serial port GPS is present. That is the same with many devices. But if the user knows there is a serial port GPS and would like it enabled, there is no current mechanism to do so. Each user must make their own startup script. The forum link in another reply to this thread was about that. Maybe the result of that thread can be systemd logic for this that can be added to the gpsd package that can optionally be enabled by a user. In many cases it will effect the ntp startup as well since the two daemons can cooperate. I know that there is startup logic for ntp provided, but I have not checked if it is systemd or init.d On Wed, Jan 14, 2015 at 2:30 PM, Andrei Borzenkov wrote:

On Wed, Jan 14, 2015 at 4:01 PM, Roger Oberholtzer wrote:

...

But is seems a bit odd to only start it automatically for a certain class of devices and do nothing at all for another class.

USB devices can be auto-discovered so there is no point to start something if device is not present. Serial devices cannot, so it is up to user to know they are there and start programs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd: yes there is need for system control. gpsd will not start magically if the gps is connected to the serial port. Something must make that happen. With a USB device, there is the possibility of adding a udev rule for your device. A serial port is more difficult. We use serial ports because we need the accuracy gained with the PPS signal that is only accurately available via the serial port. We are timing locations in a fast (up tp 90 km/h) vehicle. Everything is tagged with time. The location is then obtained for that time in the GPS data. Synchronization is key. On Wed, Jan 14, 2015 at 3:43 PM, Roger Oberholtzer wrote:

Of course that is why is it not automatic. I have no problem with that. But if I know there is a device, there is no mechanism for starting it. In the forum thread referenced earlier, there is a claim that older versions of gpsd in openSUSE had an init.d script that could be enabled. The same thing is still needed. If it is init.d or systemd is less a question. But the thread has a start at a systemd startup definition. So I will peruse that. Maybe it will find it's way in to the gpsd package if the maintainers are interested.

On Wed, Jan 14, 2015 at 3:36 PM, Per Jessen wrote:

...

Roger Oberholtzer wrote:

...

I am curious if there are any plans for a systemd method to start gpsd. I see that if the GPS is a USB device, then it is started via udev. But what if it is an RS-232 device? I think that then you must make your own startup script. I have no problem doing so. But is seems a bit odd to only start it automatically for a certain class of devices and do nothing at all for another class.

Might that not be because USB produces an interrupt when devices are connected/disconnected whereas you get no such thing with RS232?

-- Per Jessen, Zürich (7.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Roger Oberholtzer

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2015-01-14 15:43, Roger Oberholtzer wrote:

In the forum thread referenced earlier, there is a claim that older versions of gpsd in openSUSE had an init.d script that could be enabled.

If the script is somewhere, it should still run under systemd. However, if it has been removed... why? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Roger Oberholtzer wrote:

Of course that is why is it not automatic. I have no problem with that. But if I know there is a device, there is no mechanism for starting it. In the forum thread referenced earlier, there is a claim that older versions of gpsd in openSUSE had an init.d script that could be enabled. The same thing is still needed. If it is init.d or systemd is less a question. But the thread has a start at a systemd startup definition. So I will peruse that. Maybe it will find it's way in to the gpsd package if the maintainers are interested.

Maybe the maintainer didn't quite think far enough to imagine non-USB devices being used :-( I looked at the changelog for gpsd, it only goes back to Aug 2009 and there's no mention of systemd or init changes. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Not a solution. The PPS signal on an RS-232 port allows for greater accuracy when syncing time than does anything on a USB. That is one of the main reasons high end GPS receivers still provide RS-232 data. It is not so much the data as it is the PPS signal, which on a modern UART causes an interrupt. Most users don't need this accuracy. But we do. On Wed, Jan 14, 2015 at 3:48 PM, Yamaban wrote:

On Wed, 14 Jan 2015 15:36, Per Jessen wrote:

...

Roger Oberholtzer wrote:

...

I am curious if there are any plans for a systemd method to start gpsd. I see that if the GPS is a USB device, then it is started via udev. But what if it is an RS-232 device? I think that then you must make your own startup script. I have no problem doing so. But is seems a bit odd to only start it automatically for a certain class of devices and do nothing at all for another class.

Might that not be because USB produces an interrupt when devices are connected/disconnected whereas you get no such thing with RS232?

RS232 was original defined as polling with hardware buffers only. During the later days of the ISA bus (ISA 32bit IIRC) there where cards available the generated a IRQ if new data arrived at the buffers.

Today it is much easier to use a micro-controller with a USB interface and program a equivalent.

I had to do this for a semester work during my college time 1997/98.

Look at Serial/USB adaptors at sale for such a feature.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

jdd: gpsd IS the application. It runs all the time providing time to NTP so that the system can be a stratum 1 time source. It is not started by an application. It should always be running. The application you referenced can of course talk to the GPS. The locations are not so accurate. They are what ever has come in on the serial port or perhaps the NMEA stream from gpsd. When you eventually read those locations and when you were actually at those locations are not the same. A simplified description is that the GPS pulses on the serial port when you are at a location it knows about internally but has not had a chance to communicate externally. Eventually, that location arrives in the NMEA stream. When it arrives is not deterministic. The GPS can have a delay. The baud rate can cause a delay. Process run states can have a delay. etc etc. But the PPS is a hardware interrupt with a pretty predictable latency. At least far better than hoping for the best reading the NMEA stream. Synchronizing time with a GPS is a totally different activity from just reading the locations as they come in. At least it is the case if you want accuracy. On Wed, Jan 14, 2015 at 5:40 PM, James Knott wrote:

On 01/14/2015 09:48 AM, Yamaban wrote:

...

RS232 was original defined as polling with hardware buffers only. During the later days of the ISA bus (ISA 32bit IIRC) there where cards available the generated a IRQ if new data arrived at the buffers.

That was the case with DOS, which had very poor com port support. Interrupts were common in mini and mainframe computers long before there was DOS & PC. I used interrupts for an 8 port serial card I designed for my IMSAI 8080, S-100 bus computer. That bus goes back to the Altair 8800 in 1974, which was 8 years before the IBM PC appeared.

One absolutely dumb thing IBM did with the PC was to use edge triggered interrupts, which made sharing them difficult. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 14 Jan 2015 18:38, jdd wrote:

Le 14/01/2015 18:16, Roger Oberholtzer a écrit :

...

jdd: gpsd IS the application. It runs all the time providing time to NTP so that the system can be a stratum 1 time source. It is not started by an application. It should always be running.

then you need only to start gpsd? why not use boot.local?

I had problem, long time ago with I don't remember what application stating too fast. at the moment boot.local was starting too early in the process.

I simply added a wait in the script, as this computer was almost never stopped I could wait a minute.

writing a stystemd unit may be more elegant, there are many tutorials on the web, but is it necessary?

https://wiki.archlinux.org/index.php/systemd#Writing_unit_files

Hmm, is ntp started still via a sysV init file (/etc/init.d/ntp) ? If yes, build a gpsd init file, and add it to the Init-Info-Block [code] # Required-Start: [...some other stuff...] gpsd [/code] a group of following calls to systemctl: systemctl daemon-reload systemctl disable ntp systemctl enable gpsd systemctl enable ntp (to get systemd up to speed about the new 'requirement') followed by: systemctl restart ntp this should pull up gpsd and then start ntp. If ntp already uses a systemd - service file (/usr/lib/systemd/system/ntp.service) add a line with the needed info into this file: [code] Requires=gpsd [/code] or a line with "Wants=gpsd" please read "man 5 systemd.unit" carefully about what to prefer. Afterwards its the same 4 systemctl calls from above to make the change known and to be able to restart ntp successfully afterwards. make sure that the init file of gpsd checks that a valid config exists. Just my 2 ct. - Yamaban. -- Nothing good was ever easy to get, only easy to loose.

On 01/14/2015 02:07 PM, Carlos E. R. wrote:

...

On 01/14/2015 09:48 AM, Yamaban wrote:

...

RS232 was original defined as polling with hardware buffers only. During the later days of the ISA bus (ISA 32bit IIRC) there where cards available the generated a IRQ if new data arrived at the buffers. That was the case with DOS, which had very poor com port support. The operating system itself was very basic, true. But applications commonly supported themselves whatever they needed that the OS did not,

On 2015-01-14 17:40, James Knott wrote: like printer driver, graphic drivers, sound, etc. Interrupt hardware was handled the same way, by the application, or by a TSR. I wrote one myself, using sample code that came with Turbo Pascal from Borland, so it was not that difficult.

Again, that is the software, not hardware that's not using IRQs. The hardware has supported IRQs from the beginning on the IBM PC, as well as long before then on other computers. I mentioned my 8 port serial board that I designed and built for my IMSAI 8080. I built the board to use interrupts and wrote the software to do so as well. So, when the UART needed service, it sent an interrupt, which my software then handled. BTW, in developing & testing that board, I discovered a bug in the Natioal Semiconductor 8250 UART. If the chip was selected, a character send and the chip not deselected, the UART would keep repeating the same character. I had to modify my board logic to work around that. I wrote a letter to National describing the problem. They wrote back to let me know they verified what I said and they hadn't known about that bug prior to my letter.

(By the way, SUSE is cousin to Borland, in a way. Same owner ;-) )

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2015-01-14 22:17, James Knott wrote:

On 01/14/2015 02:07 PM, Carlos E. R. wrote:

...

(By the way, SUSE is cousin to Borland, in a way. Same owner ;-) )

Phillipe Kahn?

Micro Focus -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Thu, Jan 15, 2015 at 9:44 AM, Roger Oberholtzer wrote:

My post was not to learn how to make a service start at system boot. We have our own services that we have start via init.d and systemd. I know how to do that.

The reason for the post was to see why gpsd, which I bet is usually run as a system service, no longer has a start script in the installable package. It seems it did in the days of init.d. But that was removed recently.

When have you seen it last time? I do not see initscript in https://build.opensuse.org/package/show/Application:Geo/gpsd?rev=67 which is "over 3 years ago".

Perhaps because it should now be started via systemd. Or for some other reason. Or perhaps the package maintainer assumed that only USB GPS are used. Which is very much not the case in any server using the GPS to be a stratum 1 time source.

On Thu, Jan 15, 2015 at 12:44 AM, Carlos E. R. wrote:

...

On 2015-01-14 22:17, James Knott wrote:

...

On 01/14/2015 02:07 PM, Carlos E. R. wrote:

...

(By the way, SUSE is cousin to Borland, in a way. Same owner ;-) )

Phillipe Kahn?

Micro Focus

-- Cheers / Saludos,

Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

That is possible. As I said, the forum thread related to this that was referenced early on in this thread made the claim. Zero configuration would probably only work with USB devices. I think there is some logic in gpsd to explore if a GPS can be detected on all serial ports. But I do not know how well that works or if it messes things up. Still, for that to happen, a startup mechanism is needed. It cannot check if it is not started. gpsdrive can talk to a gpsd to get data. gpsd is a GPS multiplexer making GPS data available to any number of clients. I think it is probably bad that gpsdrive contains it's own gpsd. On Thu, Jan 15, 2015 at 12:34 PM, Carlos E. R. wrote:

On 2015-01-15 09:19, Andrei Borzenkov wrote:

...

On Thu, Jan 15, 2015 at 9:44 AM, Roger Oberholtzer <> wrote:

...

When have you seen it last time? I do not see initscript in https://build.opensuse.org/package/show/Application:Geo/gpsd?rev=67 which is "over 3 years ago".

Looking at discontinued distributions (http://ftp5.gwdg.de/pub/opensuse/discontinued/distribution/), I see gpsd-2.95-3.6.x86_64.rpm for 11.4, but on 10.2 I don't; instead I see gpsdrive-2.09-63.x86_64.rpm, which I do not know if it is the same thing or not.

11.0 has gpsd-2.37-25.1.x86_64.rpm. It has an udev rule, no initd script.

10.3 does not have gpsd, but has gpsdrive-2.09-135.x86_64.rpm

So, gpsd never had an init script in openSUSE. The readme file says that the goal is zero config, autoplug.

gpsdrive I don't know what it is, but it has no init file either. It has a gpsd binary, though, so it is probably the ancestor of the gpsd package.

So, if there ever was an init script, it was not here. Maybe someone contributed it externally.

-- Cheers / Saludos,

Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Roger Oberholtzer wrote:

My post was not to learn how to make a service start at system boot. We have our own services that we have start via init.d and systemd. I know how to do that.

The reason for the post was to see why gpsd, which I bet is usually run as a system service, no longer has a start script in the installable package.

Sounds like a bugreport to me. As many have suggested, it's easily fixed, but if you want it packaged too, I think you need bugzilla. -- Per Jessen, Zürich (6.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2015-01-14 15:48, Yamaban wrote:

On Wed, 14 Jan 2015 15:36, Per Jessen wrote:

RS232 was original defined as polling with hardware buffers only. During the later days of the ISA bus (ISA 32bit IIRC) there where cards available the generated a IRQ if new data arrived at the buffers.

No, I used serial port, RS232 IRQ with 8086 16 bit hardware, it was in the original specs.

Today it is much easier to use a micro-controller with a USB interface and program a equivalent.

Easier, yes. But for the purpose of timing accuracy, it is worse, because you can not ascertain how many processor cycles will take since the external device says it has data till it is read. It is a BUS, devices have to wait their turn. An RS232 has a pin that directly triggers an IRQ, directly from the outside device. It happens within a CPU clock cycle. Unless the interrupts are masked when it arrives, it is attended to immediately (and probably faster in the old 8086, no contexts, just a few pushes to the the stack for some registers) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)